Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Перевод статьи «5 Most Common Testing Tasks Testers Forget to Test (and How to Avoid That)».
В конференц-зале стояла тишина, и все лица смотрели на меня. Только что закончившийся звонок клиента оставил всех в полной растерянности. Клиент был очень недоволен и думал, что продукт вообще не тестировался.
Когда мой менеджер попытался возразить, уверяя клиента, что функционал приложения работает отлично, клиент перебил его вопросом: “Что толку от вашего функционала, если пользователи не могу установить само приложение?” Это прозвучало как гром среди ясного неба.
У нас заняло 2 часа, чтобы разобраться в этом вопросе. Но никто не спешил уходить из зала. Все задавались одним и тем же вопросом – как это могло произойти? Почему мы этого не заметили?
Я знал ответ.
Проблема была в том, что мы не тестировали документацию, особенно руководство пользователя и инструкцию по установке. Мы просто тестировали функциональность приложения, чтобы она соответствовал требованиям клиента. Мне потребовалось полчаса, чтобы объяснить руководству, что пошло не так, и почему мы столкнулись с этой ситуацией.
Как тестировщики большинство из нас думают, что знают, как правильно проводить тестирование, что именно тестировать и как обеспечить максимальное тестовое покрытие. Мы полагаем, что все, чему мы научились за годы опыта в тестировании ПО, сделало нас экспертами.
Однако, мы забываем определение QA – наша задача не ограничивается просто тестированием качества продукта. Она заключается в предоставлении ценных рекомендаций для улучшения качества приложения.
В этой статье я расскажу о некоторых моментах или задачах тестирования, о которых мы иногда забываем или намеренно избегаем их.
1. Тестирование документации
Представьте, вы следуете руководству пользователя и хотите включить холодильник. Что вы будете делать, если не сможете его включить?
Вероятнее всего, вы позвоните в службу поддержки. В итоге, они расспросят вас о том, что вы сделали, чтобы включить холодильник. Затем они скажут, что нужно подключить холодильник к источнику питания, а потом кабель подключить к розетке.
Какова будет ваша реакция? Вы подумаете – тогда почему они не упомянули об этом в руководстве пользователя?
Да, такой же будет реакция наших клиентов, если мы не протестируем руководство по эксплуатации и установке приложения.
Чаще всего мы недовольны тем, что клиенты постоянно меняют требования к приложению, заставляют повторно проводить тестирование. А вы когда-нибудь пробовали поставить себя на их место? Что произойдет, когда пользователи узнают, что компания выпустила отличный продукт с дефектным руководством пользователя? Это неизбежно скажется на продажах и репутации компании.
2. Парное тестирование
Представьте ситуацию, когда вы пытаетесь решить головоломку самостоятельно, и когда вы делаете это вместе с напарником. Конечно же, игра станет гораздо интереснее, если у вас будет напарник. Вы сможете быстрее решить головоломку, а также научитесь работать в команде.
То же самое относится и к тестированию. Независимо от вашего опыта и стажа, парное тестирование всегда более эффективно. Если вы работаете в паре с новичком, вы получите новые идеи для тестирования, а если работаете с опытным коллегой, то узнаете много новых приемов в тестировании.
3. Изучение исправления ошибок
Когда работник шиномонтажа ремонтирует прокол, он не просто ремонтирует его, а обращает внимание и на другие вещи, например, какова причина прокола шины, и советует нам предпринять определенные меры, чтобы не столкнуться с такой ситуацией снова.
Да, разработчики исправляют баги, а мы как тестировщики проверяем их, помечаем их закрытыми и чувствуем удовлетворение от того, что сделали свою работу.
А пытались ли вы хоть раз понять, как именно разработчик пофиксил баг? Какие изменения он внес в код? Может быть, это небольшое знание помогло бы вам улучшить ваши навыки тестирования?
Попробуйте понять, как именно разработчик исправил ошибку и связать это с другими частями продукта. Что, если бы разработчик применил другой подход для исправления ошибки? Задавайте вопросы и обсуждайте.
4. Связь тестирования продукта с реальной жизнью
Вы участвуете в соревновании. Вам дают мешок с зерном – смесь пшеницы и риса. Чтобы победить в соревновании, вам нужно отделить пшеницу от риса. Время ограничено. Если вы попытаетесь извлечь пшеницу из смеси вручную, вы уже проиграли соревнование. Воспользуйтесь умом. Используйте сито, чтобы отделить пшеницу от риса. Разве это не просто?
Теперь свяжите это с работой тестировщика. Поймите концепцию, используйте соответствующие инструменты, постоянно улучшайте свои навыки, расширяйте свои знания. Независимо от того, что вы тестируете, постарайтесь соотнести это с реальными сценариями и применить ту же логику. Ваша работа станет гораздо проще.
5. Приоритеты в обучении
При тестировании программного обеспечения мы часто сталкиваемся с дедлайнами, напряженными ситуациями в коллективе. Все это приводит к тому, что мы стараемся как можно быстрее представить отчет о результатах тестирования. И, разумеется, такая поспешность может оказаться неблагоприятной для нашей карьеры.
Да, сроки всегда присутствуют. И со временем нам нужно научиться понимать и определять приоритеты. Правильно расставленные приоритеты – важная часть качественного выполнения нашей работы как тестировщиков.
Заключение
Несмотря на то, что разработчик попросил вас проверить только функционал приложения, вы должны позаботиться также о графическом интерфейсе и производительности приложения. Ведь заказчик всегда хочет получить полностью рабочий продукт, а для этого, в некоторых ситуациях, он может даже подумать о том, чтобы продлить сроки на реализацию проекта.
Никогда не останавливайтесь на достигнутом. Всегда стремитесь к самосовершенствованию и постоянно развивайтесь в своей профессиональной области.