- PVSM.RU - https://www.pvsm.ru -
Многие скептически относятся к исследовательскому тестированию, так как считают, что это пустая трата времени и ресурсов. Но на самом деле это не так. В этой статье я расскажу, когда исследовательское тестирование принесет проекту пользу. В русскоязычной литературе дается очень много различных определений для термина «исследовательское тестирование». Нередко под этим понятием подразумевается ad-hoc тестирование и наоборот. Почему так сложилось исторически можно узнать там — Исследовательское тестирование 3.0 [1]. Чтобы при чтении статьи не возникало путаницы, сверим часы и зафиксируем определения.
Ad-hoc тестирование
Под ad-hoc тестированием будем понимать тестирование без использования спецификаций, планов и разработанных тест-кейсов: чистая импровизация.
Исследовательское тестирование
Более формальная версия ad-hoc: тестирование, не требующее написания тест-кейсов, но подразумевающее, что каждый последующий тест выбирается на основании результата предыдущего теста. А по Сэму Канеру, «Testing Computer Software», «исследовательское тестирование» — вдумчивый подход к ad-hoc тестирования.
Сценарное тестирование
Классическое тестирование по предварительно написанным и задокументированным сценариям.
В пользу сценарного тестирования:
В пользу исследовательского тестирования:
Перечитайте эти пункты еще раз, но уже с мыслью о том, почему плюсы сценарного тестирования могут оказаться минусами для исследовательского и наоборот.
Мало времени
Если тестовая документация написана, но времени на прохождение тестов уже нет, нужно выбирать наиболее критичные области приложения, которые реально протестировать за имеющееся время. Составить чек-лист с идеями и тестировать вокруг них.
Сложности с требованиями
Требований нет, они не полны или устарели и нет возможности их актуализировать.
Небольшой проект
Продукт маленький, и разработка тестовых сценариев займет больше времени, чем сам процесс тестирования.
Когда можно применять исследовательское тестирование в дополнение к обычному тестированию
Тестировщики постоянно проходят одни и те же тестовые сценарии
При многократном прохождении одних и тех же тестов, например, при регресионном тестировании, тестировщики теряют концентрацию и начинают пропускать дефекты. В этом случае исследовательское тестирование помогает взглянуть на проект под новым углом и найти пропущенные дефекты.
Тестировщик отвлекается от шаблонных действий и чувствует себя в большей степени обычным пользователем. Это помогает найти дефекты, сильнее влияющие на конечного потребителя разрабатываемого продукта.
Здесь можно воспользоваться концепцией туров. Почитать подробнее на русском — Жизнь — это движение! А тестирование — это жизнь :) [2] Большинство туров тестировщики используют интуитивно, а остальные не приносят большой пользы, но боевой дух и желание исследовать после прочтения статьи должно появиться точно.
Пришел внезапный запрос на изменения
Времени на разработку новых сценариев нет, так как все заняты другими запланированными задачами или изменения потребуют переработать большую часть документации. В этой ситуации тестирование исследовательским методом может быть наиболее оптимальным.
Когда хочется перестраховаться
Продукт уже протестирован по сценариям, но всё еще хочется убедиться в том, что ничего не было упущено.
Приложение стандартизованное
Приложения, работающие по стандартам и гостам, а также системы, для которых малейшее отклонение может быть критичным. Это могут быть приложения, отвечающие за полеты ракет или проводящие финансовые операции.
Проводится интеграционное тестирование
В этом случае исследовательское тестирование возможно, например, при тестировании API. Но обычно интеграционное тестирование проводится для проверки взаимодействия внутренних компонентов приложений. Эта работа хорошо покрыта документацией и часто автоматизируется.
Тестовые сценарии отдаются на аутсорс
Аутсорс аутсорсу рознь, но контролировать поставленную задачу и процент ее выполнения проще по формализованным сценариям.
Длительный проект
Тестировщики могут быть подключены к проекту на время определенной фазы, а после, пока разработчики реализовывают новый функционал, заниматься другими проектами. Если долго не тестировать конкретную функциональность, то ее специфика забывается.
Миф 1:
«Исследовательское тестирование невозможно проконтролировать, им нельзя управлять. Сложно определить, когда пора остановиться и покрыт ли весь функциональность»
Иногда исследовательское тестирование воспринимают как антоним к сценарному и относятся к нему как к тестированию в полном хаосе.
На самом деле эффекта измеримости и распараллеливания задач добиться достаточно просто. Хватает зафиксировать объем работ и разделить его на измеримые по времени части.
Миф 2:
«Нельзя доверить выполнение тестирования первому встречному»
Отчасти это действительно так. Но и сценарное тестирование не следует отдавать «случайному» человеку. На практике невозможно хорошо тестировать продукт, следуя только по заранее подготовленным шагам. Всегда возникает желание отступить от тщательно выверенных сценариев и поработать с деталями — добавить негативных проверок, проверить работу с прерываниями и так далее. И это хорошо, так как покрыть продукт тестами на 100% невозможно и никогда нельзя до конца исключить фактор человеческой ошибки.
В целом, улучшение навыков QA-команды всегда является одной из целей QA-подразделения. Используя исследовательское тестирование, инженеры задействуют интуицию и опыт, накопленные ранее и привыкают постоянно анализировать продукт.
Миф 3:
«Сложно „продать“ исследовательское тестирование заказчику, объяснить его необходимость»
На самом деле для заказчика важен результат и прозрачность процессов. В данном случае результат – это продукт, удовлетворяющий представлениям заказчика о качестве. А необходимой прозрачности процессов можно достигнуть с помощью грамотных отчетов.
Если в случае сценарного тестирования упрощенным отчетом может быть список тестовых сценариев с проставленным результатом, то для отчета об исследовательском тестировании нужно выработать немного иной формат.
«Хороший» отчет об исследовательском тестировании может выглядеть следующим образом:
Естественно, эти пункты не теряют актуальности и для отчетов о тестировании другими методами.
Исследовательское тестирование — не означает полное отсутствие документации и хаос, а является мощным инструментом.
Используя ранжирование типов тестирования от полностью исследовательского до полностью сценарного, детализируя структурно составленные чек-листы, можно подобрать оптимальный уровень документации для вашего проекта и сэкономить время.
Сценарное и исследовательское тестирование являются полностью совместимыми и компенсируют недостатки друг друга. Можно покрыть детальными тестами сложные технические аспекты проекта и написать поверхностные чек-листы для пользовательского интерфейса.
Будьте гибкими. Вырабатываете стратегию, которая наилучшим образом подойдет для вашего продукта. Качественных вам проектов.
Автор: REDMADROBOT
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/qa/116661
Ссылки в тексте:
[1] Исследовательское тестирование 3.0: http://software-testing.ru/library/testing/general-testing/2080--30
[2] Жизнь — это движение! А тестирование — это жизнь :): http://okiseleva.blogspot.ru/2015/01/blog-post_64.html
[3] Источник: https://habrahabr.ru/post/280618/
Нажмите здесь для печати.