Мексиканские мотивы: использование приоритетов при построении карты сценариев регрессионного тестирования

Недавно был соучастником спора тестировщиков - спорили о том, с каких сценариев нужно начинать регрессию. Это, кстати, один из краеугольных камней тестирования - как начинать и когда заканчивать тестирование. У каждого тестировщика с n-летним стажем найдется масса советов и достаточное количество достоверных жизненных ситуаций в подтверждение именно своей точки зрения (замечено, что страдают подобным подходом не только тестировщики). Я в свое время для себя уяснил одно: если мой опыт восстает против слов оппонента - значит может быть и так как говорю я, и так как говорит оппонент, и еще как-то другому.

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

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

Третьи рассказывали о профессиональном чутье тестировщика и опыте, ибо только опыт отличает тестировщика от Тестировщика...

Рождение системы

Конечно же, я тоже спорил )). Но я спорил хитро - что важно не выбирать отдельные стратегии, а построить систему. И в этой системе использовать приоритеты.

Задумка использовать приоритеты в нашем проекте пришла, к сожалению, не мне, а нашему менеджеру.  Он попросил нас составить карту сценариев (ее можно также обозвать чек листом) и проставить приоритеты (те приоритеты, которые нам тестировщикам кажутся правильными): major, high, normal.

Изначально мне эта идея сильно не понравилась. И тому было несколько причин.

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

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

Ну и если быть честным, была третья причина. Я был против потому, что это была не моя идея, а я считал только себя способным давать здравые идеи в своем проекте. Эгоистично - правда?

Но карта сценариев получилась на редкость удачной. Ниже скриншот одной из карт .

Логика системы

 

1. Главная таблица (первая таблица на скриншоте) представляет собой дерево. Его основные ветви: атомарный функционал - не пересекающиеся, взаимоисключающие друг друга фичи. Например, вы "никогда" не сможете одновременно нажать кнопки [Подтвердить] или [Отставить] ;). В нашем конкретном случае продукты, которые торгуются на биржах и есть эти ветви функционала. И в нашем конкретном случае есть еще региональные правила, поэтому разные регионы могут иметь разную логику по продуктам. И выглядит это примерно в нашей системе так:

#	Location	Продукты
SP-1	FRANKFURT	Продукт 1
SP-2		Продукт 2
SP-3		Продукт 3

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

Эти колонки у нас идут после названия продукта, например:
 

Продукты	Workflow
	1.Создать	2.Изменить	3.Повторное изменение					Retry Feed in Imagine
Продукт 1	Critical	Critical	High					Normal

3. Далее третья объединенная колонка представляет собой ряд фич, которые могут повторяться, проверяться, исполняться для каждого"атомарного" продукта.

Продукты Фичи ... Фича 1 Фича 2 Фича 3 Продукт 1 ... Critical  High Normal

4. Каждая фича, конечно же, может быть логически разбита на части. И как раз вторая таблица (см.  скриншот) представляет чек лист для фич. Т.е. в главной таблице для каждого продукта мы можем проставить насколько приоритетно = важно тестировать ее совместно с  данным продуктом, а во второй (вторичной) - какие функциональные области для тестирования существуют в фиче и какие из них нужно прогонять или можно прогонять если позволяет время.

Фичи	Подфичи	Приоритет
Фича 1	Фича1-1	Critical
	Фича1-2	High
	Фича1-3	Normal
Фича 2	Фича2-1	Normal
	Фича2-2	Normal

Собственно это основная логика построения наших карт сценариев.

Выводы

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

Приоритеты карты живут и меняются и зависят больше от статистики в бизнесе. Но изменения в релизах, опыт Тестировщиков (с большой буквы Т), баги предыдущих релизов оказывают влияние на приоритеты также сильно, как и письмо клиента.  Кстати - наши приоритеты впоследствии были переданы бизнесу, который также добавил несколько фич и дополнительный приоритет Low. Т.е. смысл в построении такой системы был - и самое главное есть смысл его продолжать.

Повторю некоторые мысли по поводу плюсов подобного "приоритетного" подхода к отображению регрессии:

1. Наглядность. Картинки получаются "архисуперские" (как сказал менеджер "мексиканская еда"). Строится когнитивный граф для дальнейшего планирования и принятия решений - достигается цель "как нужно начинать тестирование". Видно что пропустили, и что можно пропустить.

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

3. Получение минимального критического набора сценариев,  и как следствие ограничение скопа тестирования - достигается цель "когда заканчивать тестирование".

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

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