Home

Автор Нина Агеева – тренер курса “Первый Онлайн ИНститут Тестировщиков”  (ПОИНТ).

Сегодня поговорим с вами про исследовательское тестирование. Причём про такое исследование продукта, которое никто не назовёт обезьяньей работой.

Бытует мнение, что исследовательское тестирование – удел молодых специалистов, якобы думать там совсем не нужно, тыкай себе хаотично всё подряд – авось и баги найдутся. Ан нет. Исследовательское тестирование – это целая наука со своими методологиями и техниками.

Давайте обратимся к теории, что же такое исследовательское тестирование? Что значит “мы исследуем”? Исследовать – значит изучать, знакомиться, смотреть на продукт и на то, как он будет реагировать на ваши действия.

Исследовательское тестирование – это одновременное создание тестов, их прохождение и корректировка в зависимости от поведения вашего  продукта.

У исследовательского тестирования есть определённые характеристики, и мы рассмотрим  их в сравнении со скриптовым тестированием, то есть с тестированием по готовым тестам.

Первая характеристика – гибкость 

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

Вы не должны тратить время на подготовку и продумывание маршрута. Вы тестируете продукт, опираясь лишь на определённые техники, инструменты и на свой предыдущий релевантный опыт.

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

Вторая характеристика – параллельность

При параллельном планировании, создании и выполнении тестов вы одновременно проводите тестирование, знакомитесь со своим продуктом и определяете дальнейшие шаги, опираясь на поведение продукта.

А при скриптовом подходе всё идет поэтапно: сначала этап анализа, потом создание и выполнение тестов, затем предоставление отчётов по пройденным тестам.

Третья характеристика – возможность быстрого старта

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

Подведём небольшой итог: любой подход в тестировании имеет свои несомненные плюсы и минусы.

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

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

Сравнение разных подходов

Как же найти золотую середину? Возможно ли сделать тестирование и интересным, и творческим, и прогнозируемым одновременно? Измеримым, но не переполненным бюрократией и прочими бумажками? Можно! Session based testing – вот за счёт чего обезьяна эволюционировала в настоящего тестировщика!

Сессионное исследовательское тестирование или session based testing

Этот подход придумали братья Джеймс и Джон Бах в 2000 году. Смысл его очень простой и интуитивно понятный из названия – тестирование происходит сессиями, то есть определёнными промежутками времени.

В самом начале тестирования необходимо определить функциональные области продукта, то есть то, из каких частей состоит продукт. Это будет правильным для любого из подходов: исследовательского или скриптового.

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

Для начала вам необходимо проверить, работает ли вообще основной функционал вашего продукта, то есть самый первый уровень декомпозиции. Проводите так называемый нулевой тест, самый типичный и, конечно же, позитивный.

Определяете тестовую сессию на продукт в целом. Это будет чартер или цель тестирования.

Далее договариваетесь внутри команды о продолжительности сессии: час, полтора-два – то есть о времени, в течение которого вы  будете исследовательски тестировать продукт. Кстати, сам Бах рекомендует проводить одну тестовую сессию не более полутора часов.

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

А по результатам сессии к вам приходит менеджер и спрашивает: "Продлевать будете?"

На самом деле по результатам сессии создаётся session report, то есть своего рода отчёт, представляющий собой тестовый артефакт.

В отчёт входит следующая информация:

Чартер – это цель вашего тестирования, функционал или какая-то функциональная часть, которую вы проверяли. Указываете, кто и когда тестировал, дату, время начала тестовой сессии.

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

Также можете оставить в отчёте какие-то свои заметки, выписать появившиеся вопросы, и, конечно, все найденные ошибки!

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

Смотрите, какая классная штука будет дальше: если нулевой тест прошёл и в целом продукт работает, вы начинаете повторять тестовые сессии, но идёте уже на уровень глубже. И с каждой такой тестовой сессией всё глубже и глубже погружаетесь в продукт.

Всё лучше его изучаете, исследуете, узнаёте какие-то особенности и нюансы.

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

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

Как правило, после сессии происходит такое интересное событие как де-бриф, когда вся команда собирается и обсуждает “натестированное добро”.

Если это офис – команда идёт в переговорную комнату, если хоум-офис – ребята созваниваются по какой-нибудь “звонилке” с камерами и обсуждают, что тестировали, с какими проблемами столкнулись, какие баги нашли. И реальная, ощутимая  польза таких де-брифов в том, что имеет место взгляд со стороны: свежий, интересный, нестандартный. Ваши коллеги могут подкинуть вам пару идей, дать советы, да и вообще вербальное обсуждение – очень хорошая и полезная практика. Пусть даже при помощи мобильной конференц-связи.

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

Либо можете выбрать наиболее приоритетные уровни продукта, если время на тестирование у вас ограничено. Согласитесь, это совсем не обезьянья работа, а полноценное качественное тестирование продукта, да еще с тестовыми артефактами и обменом опытом на де-брифах.

Итак, плюсы сессионного подхода:

1. Планирование тестирования;
2. Предсказуемость тестирования;
3. Приоритезация тестирования;
4. Обмен опытом и знаниями;
5. Тестовые артефакты.

Несмотря на всю важность и пользу исследовательского подхода в тестировании продукта в целом и session based тестинга  в частности, это далеко не панацея.

Когда же нужно проводить исследовательское тестирование, а когда всё же стоит отдать предпочтение более формальному подходу и скриптовому тестированию?

Исследовательское тестирование применимо в следующих случаях:

• когда вы очень ограничены во времени и совсем не можете себе позволить писать тесты;
• сюда же можно отнести внезапный запрос на изменение в продукте (помните про гибкость исследовательского подхода?);
• когда у вас в команде специалисты с высокой квалификацией, то есть когда вы уверены, что не будет “манки-кликания”, а будет осознанное исследование продукта со всеми вытекающими.

Когда исследовательское тестирование лучше заменить на скриптовое:

• когда вы занимаетесь тестированием какого-то стандартизированного приложения: госпроектов, проектов с высокой значимостью, там где цена ошибки может стоить человеческих жизней;
• когда ваш продукт интегрирован с другими сервисами. Как правило, при тестировании API бОльшая часть проверок задокументирована и даже автоматизирована;
• когда у вас большая команда и важен момент передачи опыта и обучения. По скриптам, по тест-кейсам гораздо проще организовать обмен опытом между тестировщиками. Если кто-то уходит в отпуск или на больничный или в команде появляется новичок – гораздо проще организовать работу.

Иногда применяется комбинированный подход, когда критично важный функционал проверяется скриптовым тестированием с расписанными детально тест-кейсами, полируется исследовательским сессионным тестированием, а менее важный функционал покрывается чек-листами.

Научиться внедрять эти рекомендации на практике вы можете на курсе “Первый Онлайн ИНститут Тестировщиков” (ПОИНТ) от компании “Лаборатория Качества”.

Обсудить в форуме