Предупреждаем о возможных подводных камнях, с которыми рискует столкнуться начинающий тестировщик на разных этапах.

Привет! Меня зовут Настя Мордвинцева, я руковожу отделом тестирования в Red Collar. Мы разрабатываем решения для компаний из самых разных областей и работаем с разнообразными продуктами, поэтому в моём отделе порой не хватает рук. И когда мы набираем новых людей, их приходится очень быстро вводить в курс дела. 

Среди них есть ребята, наизусть выучившие ISTQB и с отличием окончившие курсы, но когда дело доходит до реальной работы, многие опускают руки. Чтобы этого не произошло, я расскажу, чем же реальное тестирование отличается от того, что написано в учебниках, и как мы справляемся с задачами, которые из-за этого возникают.

Обращаю внимание на то, что процесс тестирования и документирования в вашей компании может отличаться от принятого у нас.

Требования

Ожидание: требования, собранные менеджером и структурированные аналитиками, сразу передаются тестировщикам для статического тестирования. Все дефекты выявляются в самой структуре будущего продукта, пока ещё не написано ни строчки кода.

Реальность: все сведения о проекте тестировщик собирает самостоятельно. У аналитика не всегда есть время на составление полной структуры будущего продукта, поэтому её приходится дописывать с опорой на другие источники. Информацию приходится добирать из созвонов, чатов и комментариев под задачами. Также стоит расспросить менеджеров на предмет устных договоренностей с заказчиком, которые остались не зафиксированными. По итогам такого исследования мы проводим синк с командой — делимся результатами, указываем на расхождения в требованиях, узнаём, кто за что отвечает в этом проекте.

Структура продукта

Ожидание: структуру проекта готовят аналитики. Они пошагово расписывают основной функционал проекта. Структур может быть несколько: для TMS (Test Management System), для метрик (чтобы выявить, где больше багов), для понимания, насколько готов продукт, для создания задач на проверку требований и на написание тестовой документации.

Реальность: структуру пишут тестировщики, разбирая, например, разные пользовательские сценарии. Аналитик может подсказывать и давать обратную связь, но большую часть работы делается тестировщиком.

Тест-план и тест-стратегия

Ожидание: QA-лид составляет стратегию тестирования. Отдельно готовятся мастер тест-план и тест-план на первую итерацию. Каждый шаг согласуется с заказчиком, и весь процесс занимает от пары часов до недели. 

Реальность: из-за обилия мелких проектов на составление высокоуровневой стратегии попросту не остаётся времени. Поэтому мы пишем тест-план, который будет включать в себя и план-мастер, и план на первую итерацию. 

Тест-план должен отвечать на следующие вопросы:

Что? 

Какая тестовая документация должна быть готова, и что мы делаем, чтобы уложиться ко времени. Какие виды тестирования будем применять? Будем ли требовать от разработчиков точного соответствия макету, или менеджер предложит клиенту другие варианты?

Где?

Здесь мы расписываем, на каком стенде тестируем продукт. Уточняем, под какую платформу его готовим — под десктоп, под мобильные устройства, или под всё сразу. 

На этом этапе нужно составить полный список браузеров и ОС, в которых будет работать продукт, чтобы представлять себе, сколько раз нужно повторить цикл тестирования.

Когда?

Узнайте, в какой период времени будут готовы задачи к тестированию и когда их обещали заказчику. Напомните менеджеру, что тестирование требует времени. Отдать вечером в пятницу на тест то, что заказчик ждёт этим же вечером, — хуже, чем моветон!

Написание тестовой документации

Ожидание: мы стремимся к максимальному тестовому покрытию. Для критически важных участков пишем тест-кейсы, для некритичных — чек-листы,  делаем огромную матрицу трассировки требований, то есть, стараемся проверить всё, что только возможно. 

Реальность: у нас часто горят сроки, и мы пишем тест-кейсы только на основной функционал. В остальных случаях ограничиваемся чек-листами. 

Собственно тестирование

Если предыдущие этапы выполнены корректно, то само тестирование проходит достаточно легко: идём себе спокойно по чек-листам и тест-кейсам, заполняем результат, заводим баг-репорты, а потом ре-тестим исправленные баги. 

В первую очередь мы тестируем функционал. Во вторую — вёрстку и отображение элементов. Тут время считается по формуле: время прогона на одной конфигурации (ОС + браузер) х количество конфигураций = время потраченное на тестирование. 

Плюсуются риски: время на заведение дефектов, их обсуждение и ре-тест. А ещё дефекты может присылать заказчик, и тут мы должны проверить — а заведён ли нами такой дефект? Если нет, то нужно его завести (проверив воспроизведение дефекта), если да, то включить его в задачу. 

В среднем, тестирование занимает почти столько же времени, сколько и тест-дизайн, но первый часто делается несколько дольше.

Ожидания vs реальность: В период тестирования могут вноситься изменения в дизайн и требования. Это вынуждает нас откатиться назад к предыдущему этапу — тест-дизайну.

Анализ результатов

На этом этапе QA-лид проверяет тестовое покрытие и статусы прогонов, а также вычисляет метрики. Время, отведённое на это, может варьироваться.

Например, можно по количеству дефектов искать узкие места в продукте. А можно просто собрать большую матрицу покрытия.

Ожидания vs реальность: в идеальном мире после анализа результатов мы дорабатываем баги, но в реальности это может превратиться бесконечный цикл. Причина достаточно простая — исчерпывающего тестирования не существует. И полностью протестировать весь продукт от и до нереально и нецелесообразно, поскольку это потребует огромных ресурсов.

Когда остановиться?

Определить критерий окончания тестирования достаточно трудно, поскольку, согласно принципам тестирования, мы никогда не можем быть уверены в том, что продукт на 100% свободен от дефектов. Поэтому используются другие условия:

1. Сроки, установленные заранее.

2. Выполнение всех предусмотренных тест-кейсов.

3. Достижение определенного уровня тестового покрытия.

4. Когда после определенного момента мы практически не находим новых багов или критических дефектов.

5. Решение менеджмента.

Также необходимо понимать, что баги будут всегда, даже если мы их не нашли. Но если у них маленький приоритет, их вряд ли будут исправлять.

Ожидания vs реальность: а тут суровая действительность такова, что часто мы останавливаемся тогда, когда заканчивается бюджет или когда пришло решение от менеджера.

Отчёт о проведенном тестировании

Это документ который отображает весь пул работ, который мы провели: собрали данные, написали тесты, протестировали, нашли ошибки.

Внутри компании мы используем собственные шаблоны, рекомендую сделать тоже самое — это сильно упрощает жизнь.

Ожидания vs реальность: в данном пункте особых расхождений нет — отчёты делаются, они полезны и добавляют понимания, какие работы были проведены со стороны тестирования. 

А теперь для не тестировщиков

Что делать, если тестера в команде нет? Используйте базу — свой пользовательский опыт. Это простейший инструмент, доступный каждому, но который позволяет выявлять самые неочевидные баги. Забудьте на время всё, что вы видели «под капотом» у своего продукта, и попытайтесь «порулить». Например, если вы разрабатываете интернет-магазин, то попробуйте зарегистрироваться и оформить покупку. Все неработающие сценарии, с которыми вы столкнетесь на пути, и будут багами. 

Такой подход в тестировании ПО называется исследовательским. К сожалению, при всей своей мощи это не панацея, и это не поможет вам убедиться в состоянии продукта наверняка. Но вы можете представить себя тестировщиком, пройтись по всем предыдущим пунктам и, возможно, что-то у вас и получится.

А можете найти себе тестировщика на проект ????

Если у вас нет QA

Теоретически, тестировать продукт может вся команда. Такое решение должно быть согласовано с менеджером. Он же выбирает подход и руководит процессом. В зависимости от этапа, в тестировании могут участвовать менеджер продукта, системный и бизнес-аналитик, разработчик и дизайнер.

А как всё-таки тестить?

Вооружившись моими рекомендации и собственным опытом, вы можете попробовать пройти путь тестирования. 

Но напомню, что это всё наработки, которые хорошо применимы к небольшому отделу тестирования и большому количеству срочных и креативных проектов. При перенесении методик на другие форматы проектов и команд могут возникнуть сложности.