Многие скептически относятся к исследовательскому тестированию, так как считают, что это пустая трата времени и ресурсов. Но на самом деле это не так. В этой статье я расскажу, когда исследовательское тестирование принесет проекту пользу. В русскоязычной литературе дается очень много различных определений для термина «исследовательское тестирование». Нередко под этим понятием подразумевается ad-hoc тестирование и наоборот. Почему так сложилось исторически можно узнать там — Исследовательское тестирование 3.0. Чтобы при чтении статьи не возникало путаницы, сверим часы и зафиксируем определения.
Что такое исследовательское тестирование
Ad-hoc тестирование
Под ad-hoc тестированием будем понимать тестирование без использования спецификаций, планов и разработанных тест-кейсов: чистая импровизация.
Исследовательское тестирование
Более формальная версия ad-hoc: тестирование, не требующее написания тест-кейсов, но подразумевающее, что каждый последующий тест выбирается на основании результата предыдущего теста. А по Сэму Канеру, «Testing Computer Software», «исследовательское тестирование» — вдумчивый подход к ad-hoc тестирования.
Сценарное тестирование
Классическое тестирование по предварительно написанным и задокументированным сценариям.
В пользу сценарного тестирования:
- сравнительная легкость планирования: тест-кейсы можно легко поделить между различными тестировщиками или командами.
- важные кейсы не останутся не пройденными;
- проще оценить процент покрытия проекта тестированием и понять, какая часть уже протестирована;
- легче ввести в проект нового человека: действия, которые от него ожидаются, уже структурированы в последовательности шагов тестовых сценариев;
- при достаточно детальном описании тестовых сценариев квалификация тестировщика может быть минимальной;
- разработанные тестовые сценарии можно передать заказчику для приемочных испытаний продукта.
В пользу исследовательского тестирования:
- без предсказуемости и жесткой привязанности к фиксированной последовательности шагов можно найти больше дефектов. В основном это будут дефекты, не относящиеся к основной функциональности;
- не нужно тратить время на предварительное доскональное описание всех сценариев;
- не нужна поддержка тестовых сценариев;
- не происходит привыкание к тестовым сценариям, и их прохождение не происходит «не глядя»;
- не теряется цельное видение продукт;
- критические дефекты находятся быстрее;
- повышается скорость тестирования;
- можно сразу начинать тестировать продукт, даже если требований нет вообще. Кроме того, что это весело, это еще и значительная экономия времени, в сравнении с отдельным изучением документации и последующем тестированием;
- интереснее и креативнее. Тесты ограничиваются только фантазией проходящего и его глубиной знаний о продукте.
Перечитайте эти пункты еще раз, но уже с мыслью о том, почему плюсы сценарного тестирования могут оказаться минусами для исследовательского и наоборот.
Когда можно применять исследовательское тестирование в чистом виде
Мало времени
Если тестовая документация написана, но времени на прохождение тестов уже нет, нужно выбирать наиболее критичные области приложения, которые реально протестировать за имеющееся время. Составить чек-лист с идеями и тестировать вокруг них.
Сложности с требованиями
Требований нет, они не полны или устарели и нет возможности их актуализировать.
Небольшой проект
Продукт маленький, и разработка тестовых сценариев займет больше времени, чем сам процесс тестирования.
Когда можно применять исследовательское тестирование в дополнение к обычному тестированию
Тестировщики постоянно проходят одни и те же тестовые сценарии
При многократном прохождении одних и тех же тестов, например, при регресионном тестировании, тестировщики теряют концентрацию и начинают пропускать дефекты. В этом случае исследовательское тестирование помогает взглянуть на проект под новым углом и найти пропущенные дефекты.
Тестировщик отвлекается от шаблонных действий и чувствует себя в большей степени обычным пользователем. Это помогает найти дефекты, сильнее влияющие на конечного потребителя разрабатываемого продукта.
Здесь можно воспользоваться концепцией туров. Почитать подробнее на русском — Жизнь — это движение! А тестирование — это жизнь :) Большинство туров тестировщики используют интуитивно, а остальные не приносят большой пользы, но боевой дух и желание исследовать после прочтения статьи должно появиться точно.
Пришел внезапный запрос на изменения
Времени на разработку новых сценариев нет, так как все заняты другими запланированными задачами или изменения потребуют переработать большую часть документации. В этой ситуации тестирование исследовательским методом может быть наиболее оптимальным.
Когда хочется перестраховаться
Продукт уже протестирован по сценариям, но всё еще хочется убедиться в том, что ничего не было упущено.
Когда одним исследовательским тестированием не обойтись:
Приложение стандартизованное
Приложения, работающие по стандартам и гостам, а также системы, для которых малейшее отклонение может быть критичным. Это могут быть приложения, отвечающие за полеты ракет или проводящие финансовые операции.
Проводится интеграционное тестирование
В этом случае исследовательское тестирование возможно, например, при тестировании API. Но обычно интеграционное тестирование проводится для проверки взаимодействия внутренних компонентов приложений. Эта работа хорошо покрыта документацией и часто автоматизируется.
Тестовые сценарии отдаются на аутсорс
Аутсорс аутсорсу рознь, но контролировать поставленную задачу и процент ее выполнения проще по формализованным сценариям.
Длительный проект
Тестировщики могут быть подключены к проекту на время определенной фазы, а после, пока разработчики реализовывают новый функционал, заниматься другими проектами. Если долго не тестировать конкретную функциональность, то ее специфика забывается.
Развенчание мифов или как применять исследовательское тестирование
Миф 1:
«Исследовательское тестирование невозможно проконтролировать, им нельзя управлять. Сложно определить, когда пора остановиться и покрыт ли весь функциональность»
Иногда исследовательское тестирование воспринимают как антоним к сценарному и относятся к нему как к тестированию в полном хаосе.
На самом деле эффекта измеримости и распараллеливания задач добиться достаточно просто. Хватает зафиксировать объем работ и разделить его на измеримые по времени части.
Миф 2:
«Нельзя доверить выполнение тестирования первому встречному»
Отчасти это действительно так. Но и сценарное тестирование не следует отдавать «случайному» человеку. На практике невозможно хорошо тестировать продукт, следуя только по заранее подготовленным шагам. Всегда возникает желание отступить от тщательно выверенных сценариев и поработать с деталями — добавить негативных проверок, проверить работу с прерываниями и так далее. И это хорошо, так как покрыть продукт тестами на 100% невозможно и никогда нельзя до конца исключить фактор человеческой ошибки.
В целом, улучшение навыков QA-команды всегда является одной из целей QA-подразделения. Используя исследовательское тестирование, инженеры задействуют интуицию и опыт, накопленные ранее и привыкают постоянно анализировать продукт.
Миф 3:
«Сложно „продать“ исследовательское тестирование заказчику, объяснить его необходимость»
На самом деле для заказчика важен результат и прозрачность процессов. В данном случае результат – это продукт, удовлетворяющий представлениям заказчика о качестве. А необходимой прозрачности процессов можно достигнуть с помощью грамотных отчетов.
Если в случае сценарного тестирования упрощенным отчетом может быть список тестовых сценариев с проставленным результатом, то для отчета об исследовательском тестировании нужно выработать немного иной формат.
«Хороший» отчет об исследовательском тестировании может выглядеть следующим образом:
- список протестированных функциональностей продукта (чтобы примерно оценить тестовое покрытие, а также необходимость дополнительных исследований);
- список дефектов (найденных вообще или только самых критических – в зависимости от того, для кого и на какой стадии тестирования делается отчет. А также в зависимости от общего количества дефектов в продукте в целом);
- внутренние отчеты можно дополнить проблемами, вопросами и/или наблюдениями;
- риски. Здесь важно рассказать о том, что не было протестировано и в связи чем это произошло – функциональность не входила в cкоуп работ, не работал сервер, не было подходящих тестовых данных и так далее;
- краткий вывод по результатам тестирования (в зависимости от изначальной цели тестирования – например, можно ли передавать продукт заказчику для ознакомления).
Естественно, эти пункты не теряют актуальности и для отчетов о тестировании другими методами.
Выводы
Исследовательское тестирование — не означает полное отсутствие документации и хаос, а является мощным инструментом.
Используя ранжирование типов тестирования от полностью исследовательского до полностью сценарного, детализируя структурно составленные чек-листы, можно подобрать оптимальный уровень документации для вашего проекта и сэкономить время.
Сценарное и исследовательское тестирование являются полностью совместимыми и компенсируют недостатки друг друга. Можно покрыть детальными тестами сложные технические аспекты проекта и написать поверхностные чек-листы для пользовательского интерфейса.
Будьте гибкими. Вырабатываете стратегию, которая наилучшим образом подойдет для вашего продукта. Качественных вам проектов.
Автор: REDMADROBOT
