Не нужно лишний раз
рассказывать о том, что такое исследовательское тестирование (ИТ,
Exploratory testing, ET). Существует множество источников, где это
понятие описано достаточно хорошо. Вы можете почитать книги Элизабет Хендриксон, Джеймса Виттекера, блоги Майкла Болтона, Джеймса Баха, Кема Канера.
В этом сообщении я расскажу о плюсах и минусах ИТ - как я их вижу. И о том, как можно сделать минусы не такими серьезными.
Исследовательское
тестирование делает нашу работу интереснее. Оно добавляет больше
креатива и больше индивидуальности в то, что мы делаем. Успех
исследовательского тестирования в большой степени зависит от мастерства
самого тестировщика. Этот подход предъявляет к человеку, использующему
его, повышенные требования. Исследовательское тестирование учит нас
думать: на каждом шаге мы прислушиваемся к себе, задаем вопросы,
принимаем решения. Это большая нагрузка и большая ответственность. И это
очень здорово - для нашего развития как тестировщиков.
При
своих плюсах исследовательское тестирование не используется
повсеместно. Могу сказать по своему опыту: ни в одной из компаний, где я
работал, тестирование не было полностью исследовательским. Та или иная
часть тестов была повторяемой и описанной по шагам - от и до. Всегда
было что-то, что заставляло подстраховываться и использовать старый
добрый подход, основанный на тест кейсах.
Думаю,
исследовательское тестирование - довольно рискованный подход, которому
не хватает прозрачности, прогнозируемости и измеримости - в глазах
руководства.
Сравните
с процессом, использующим тест кейсы: есть 10 тест кейсов для
функционального тестирования, которые занимают 10 дней, есть 20 тест
кейсов для регрессионного тестирования, которые занимают 15 дней. Всего
25 дней на один цикл тестирования. Да, могут быть баги, которые заставят
повторить некоторые тесты несколько раз. Да, есть риск не закончить
тестирование вовремя из-за других проблем. Но начальство имеет
определенную долю уверенности в том, что тестирование действительно
закончится на этих 30 тестах. Скоуп тестирования прозрачен и измерим.
Любой желающий может посмотреть описание тестов и понять, что
проверяется и как.
Другое
дело - исследовательское тестирование. Мы не можем измерить его в тест
кейсах. И по прозрачности оно проигрывает - редко мы готовим отчеты по
ИТ, которые по детализации сравнимы с тест кейсами. Прогнозируемость
тоже как правило ухудшается - нам сложнее сказать, когда закончится
тестирование. По-хорошему, не дело тестировщиков это решать, но это
другой разговор :)
Не каждому
менеджеру понравится такой гибкий и креативный подход. Иногда лучше
пожертвовать гибкостью и получить стабильный результат через
прогнозируемый промежуток времени. Другое дело, что результат
тестирования по тест кейсам будет таким: выполнено 30 тестов, критичных
багов не найдено. Все запланированные тест кейсы выполнены - что может
быть лучше? :)
Может поэтому компаний, в которых преобладает исследовательское тестирование, не так много?
Нам стоит подумать о том, как сделать исследовательское тестирование измеримее и понятнее.
1.
Одно из возможных решений, которое напрашивается - ограничение скоупа
исследовательского тестирования и разделение его на измеримые части.
Если мы можем сказать, что, к примеру, на выполнение самых приоритетных
тестов у нас уйдет 5 дней - уже хорошо. В этом случае нам нужно уметь
контролировать исследовательское тестирование, если оно выходит за
рамки.
2. В улучшении
прозрачности ИТ нам могут помочь грамотные отчеты. В случае
тестирования по тест кейсам сам тест кейс может быть отчетом: нужно
просто расставить passed/failed напротив шагов. Чтобы подготовить отчет
об исследовательском тестировании - нужно больше времени и нужно умение
выразить множество информации в короткой и понятной форме.
3.
Улучшение скилов команды. Как мы сказали, исследовательское
тестирование - очень требовательный подход. Поэтому нам нужно учиться
его использовать. У тестировщиков должен быть опыт использования разных
техник, должна быть интуиция и опыт, накопленные при работе с разными
продуктами и в разных командах. Кроме того, нам нужно привыкнуть
постоянно думать и анализировать то, что мы делаем - без этого
исследовательское тестирование теряет свою силу.
В
области улучшения управляемости и измеримости ИТ есть готовые
фреймворки. Например, SBTM от братьев Бах. В основе этой модели:
- Тест сессии - ограниченные промежутки времени, в рамках которых происходит тестирование. Каждая сессия имеет тему (charter).
- Отчеты по результатам сессий, которые оформляются в специальной форме, пригодной для парсинга и сбора статистики.
- Обсуждение результатов (Debriefings). Тим лид и тестировщик обсуждают каждую проведенную сессию.
Я не встречал компаний, в которых использовалась эта модель. А вы? Но отдельные фрагменты этой модели встречались.
В общем, я считаю ИТ полезным подходом. Мне нравится, что ИТ зависит от самого тестировщика и учит его думать над тем, что он делает.
На
след сессии Weekend testing мы поговорим о том, как выполнять ИТ, как
готовить отчеты по результатам, как делать заметки в процессе
тестирования. Приходите :)
Комментариев нет:
Отправить комментарий