вторник, 31 августа 2010 г.

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



Недавно был соучастником спора тестировщиков - спорили о том, с каких сценариев нужно начинать регрессию. Это, кстати, один из краеугольных камней тестирования - как начинать и когда заканчивать тестирование. У каждого тестировщика с 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. В дальнейшем данная карта может служить планом по обновлению сценариев. Оценка трудоемкости проводится по среднему - каждая отдельная ячейка - есть отдельный сценарий. Трудоемкость каждого сценария можно просто копипастить и применять формулы электронных таблиц. В нашем проекте это весьма и весьма актуально.

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

13 комментариев:

  1. Идея такой карты, особенно визуальной - весьма классная. Только вот, к сожалению, из ваших объяснений я не понял ровным счетом ничего. Особенно места, где идет отсылка к скриншоту, на котором также не видно ничего.

    И еще, я не понял, каким образом идет привязка к изменениям? За счет изменения приоритетов для каждой новой сборки что-ли?

    ОтветитьУдалить
  2. >Leshal

    1. >> я не понял ровным счетом ничего. Особенно места, где идет отсылка к скриншоту, на котором также не видно ничего.

    Ну собственно если бы скриншот показывал бы все и вам было бы понятно какие фичи в нашем приложении, мне очевидно, пришлось бы писать заявление )) или не писать - написали бы за меня.

    Ну честно - я же описал только идею для визуализации следующих данных:

    1. Есть ствол основных/атомарных/уникальных/непересекающися фич

    2. Есть действия над основными фичами

    3. Есть фичи, которые могут быть протестированы совместно или во время тестирования основных

    По сути есть паттерн из этих трех условий и его реализация в виде многомерного объекта развернутого на плоскости в виде двух таблиц.

    На картинке одна Большая = главная таблица и другая маленькая = добавочная.

    2. >>>И еще, я не понял, каким образом идет привязка к изменениям?

    Изменения в карте для каждого релиза имеют следующую логику:

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

    Статистика с продакшена изменяет приоритеты.

    Баги также влияют на приоритеты в обеих таблицах.

    ОтветитьУдалить
  3. Как и LeshaL, я был поражен тем, что вроде все так изложено, а все равно не очень понятно :)

    Во-вторых, надо это дело перечитать еще раз.

    ОтветитьУдалить
  4. Мы делали нечто подобное, однако, не прижилось :)

    ОтветитьУдалить
  5. >Мы делали нечто подобное, однако, не прижилось
    Можно спросить почему?

    ОтветитьУдалить
  6. Для каждого продукта одинаковый список фич, они различаются только по приоритетам, для каждого продукта свой, правильно я понимаю?

    ОтветитьУдалить
  7. >Для каждого продукта одинаковый список фич, они различаются только по приоритетам, для каждого продукта свой, правильно я понимаю?

    Можно и так сказать)): для каждого продукта можно подобрать набор критически важных фич/областей с самым высоким приоритетом, и фич/областей, которые можно назвать "все остальное"

    А можно еще уточнить, что мы выбрали "продукт" как главную фичу с которой совместно могут быть тестированы (кросс-тестирование) другие фичи. Возможно было выбрать за главную фичу что-нибудь другое (например действия: создать, изменить, удалить,...). Но мы остановились на текущей модели.

    ОтветитьУдалить
  8. Александр, я все равно не понял :(. Идея-то такой визуализации весьма заманчива. И не только визуализации - это прямой путь к интелектуальной автоматизированой выборке сабсетов из всего объема тестов. Но вот все-равно не понимаю на чем основаны приоритеты и сколько дополнительной возни приходится на поддержание (не на создание).

    По поводу таблицы - можно ведь сделать не настоящую, а например для Notepad.exe или calculator.exe

    Хотя, лучше, приезжайте в Питер на конфу SQA Days 8 и сделайте доклад про это ;)

    ОтветитьУдалить
  9. >LeshaL
    >> Александр, я все равно не понял :(.
    Ну значит я плохо объяснил. Попытаюсь в другой заметке все показать на пальцах с примерами из жизни.

    Приоритеты в таблице основаны на нескольких исходных утверждений:
    1. Согласно статистике с прода бизнесс создает определенные продукты (я их использую как основные фичи) и использует определенные дополнительные фичи. У нас есть % соотношение по регионам и фичам. Благодаря этой самой статистике мы можем сделать первый вывод о приоритетах.
    2. Опыт - сын ошибок трудных - показывает нам, что если затрагивается основная фича (и даже если не затрагиваются дополнительные фичи) все равно нужно в обязательном порядке проверить определенные области.
    3. Пользователям важны не все фичи. Они готовы нам простить например потерю комментария, но изменение цены продукта или валюты выплаты они нам простить не смогут. Отсюда вывод - какие фичи (в некоторых случаях поля в гуе) заслуживают дополнительного внимания при изменениях объектов.

    >сколько дополнительной возни приходится на поддержание

    На самом деле немного. Основная проблема именно создать такую таблицу функционала. В моем случае проект разрабатывался задолго до меня и спросить уже не у кого - основная команда тестеров ушла за несколько месяцев до моего появляения. Остались индусы... сами понимаете. Потрачено суммарно год опыта (до попытки создать таблицу) и наверное часов 16 чистого времени на формирование таблицы.

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

    >Хотя, лучше, приезжайте в Питер на конфу SQA Days 8 и сделайте доклад про это ;)
    Хотел, не пустили ;(((

    ОтветитьУдалить
  10. Идея мне очень понравилась :) Даже если я понял её по-своему, мне понравилась это новое понимание ;) Спасибо автору!

    ОтветитьУдалить
  11. Мало понятно по реализации. Тут без конкретного Excel-файла с таблицей не обойтись.

    Рассмешил автор, что этот лист-карта на некий продукт (никто не знает о чем конкретно идет речь) будет реально кому-то нужен и эти фичи кто-то будет использовать в своих злостных целях. Очень смешно.

    ОтветитьУдалить