Знакомьтесь, авторы июльской статьи для «Календаря тестировщика» Андрей Марченко и Марина Третьякова, тестировщики-аналитики Контура. В этом месяце ребята расскажут о моделях рабочего процесса по тестированию аналитики, и как они начали тестировать аналитику до стадии разработки. Опыт ребят будет полезен менеджерам, тестировщикам и аналитикам некрупных продуктовых команд, которые не живут в рамках стартапа и для которых качество важнее скорости.

Модели рабочего процесса по тестированию аналитики

Модель 1

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

Минусы:

• дефекты в аналитике не будут выявлены раньше стадии тестирования,
• есть риск того, что задача из тестирования отправится снова в аналитику на доработку. Как следствие TimeToMarket задачи существенно увеличивается.

Ошибки аналитики, выявленные при тестировании, стоят дорого или очень дорого.

Плюсы:

• сокращается время тестировщика для задач, где не требуется аналитик (инфраструктурные, рефакторинг).

Модель 2

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

Минусы:

• тестировщику придется учиться смежной области (оформлению аналитики и ТЗ),
• перейдя на эту модель, тестировщику придется сначала потратить больше времени на тестирование, ведь процесс «пришла готовая задача — читаю аналитику — тестирую» растягивается до «пришло описание будущей задачи — читаю аналитику — тестирую аналитику — пришла готовая задача — тестирую».

Плюсы:

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

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

Когда мы рекомендовали вторую модель тестировщикам, работающим по первой модели, мы часто слышали:

• «У нас в очереди и так хватает текущих задач, чтобы брать еще».
• «А поговорите с менеджером».

Перестройка процесса разработки — серьезная менеджерская задача.

Внедрение тестирования аналитики до стадии разработки

Почти год, как в проекте Контур.Норматив в процесс разработки встроен обязательный этап «тестирование аналитики». К этому команда пришла не сразу. Толчком стал рост количества возвратов задачи с тестирования на этап аналитики и дальнейшей доработки.

Особенно больно было при больших задачах с новой функциональностью. Переданные на этап тестирования задачи по front-end были сырыми, нередко ломались на самых простых сценариях, реализовывались по-другому в виду «двоякости» определений и терминов в аналитике.

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

Этап 0. Продать команде идею тестирования аналитики

Можно легко представить ситуацию, когда по своей работе внезапно получаешь обратную связь с замечаниями, предложениями и исправлениями. Первая мысль у любого нормального человека будет: «А почему решили меня проверить? Мне не доверяют? Следят за качеством моей работы?». На данном этапе очень важно, чтобы у аналитика не появилось ощущения, что его проверяют на качество, и, в случае неудачной проверки, уволят.

Ряд вопросов можно снять, если преподнести информацию в ключе: «это даст нам возможность раньше узнавать о новой функциональности, ускорит этап тестирования, предотвратит внесение даже небольших дефектов в код».

Когда этап 0 пройден, можно продвигаться дальше.

Этап 1. Внедрение тестирования аналитики в процесс разработки

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

То после внедрения:

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

Этап 2. Тестирование аналитики

Бывают задачи, когда прототипы заменяют текстовый вариант аналитики.

В таком случае прототип проверяем также как текст. Если прототипы дополняют аналитику, то полезно перед чтением документации посмотреть на дизайн-макеты будущей функциональности. Это ваш единственный шанс взглянуть на задачу как пользователь, который не читал ТЗ и не знает, как всё устроено и должно работать.

Что можно проверять в аналитике:

1.Предложенное решение удовлетворяет цели задачи.

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

2.Однозначность интерпретации.

Например, формулировку «показать информацию за текущий день» можно по-разному интерпретировать. Можно понять как «показать информацию за выбранный в настройках день», а можно как «показать информацию за день равный сегодня».

3.Осуществимость решения.

Осуществимость — это возможность реализовать требования, написанные в аналитике при известных ограничениях среды разработки, языка программирования, алгоритмической сложности. Хорошие аналитики могут держать в уме алгоритм, по которому можно решить написанную ими задачу. Не факт, что разработчики сделают по этому алгоритму (они более осведомлены, найдут способы сделать алгоритм оптимальным и т. д.), но само его наличие говорит об осуществимости задачи.

4.Тестируемость.

Как проверить, что соблюдено условие «улучшить поисковую выдачу» — непонятно. Но если переписать условие на «поисковая выдача должна быть показана пользователю в течение 1 секунды после нажатия контрола «Поиск» — понятно.

5.Наличие альтернативных сценариев.

В формулировке «Если указаны номер и дата, то печатаем номер и дату. Если дата не указана, печатаем только номер» не хватает сценариев:

• нет номера, а есть дата,
• данных нет.

6.Обработка исключений.

В формулировке «Можно загрузить документ только в формате Excel» непонятно, что должно происходить, если мы загрузим файлы других форматов, и какую ошибку при их загрузке мы увидим.

Артефакты при тестировании аналитики

Какие артефакты могут остаться после тестирования аналитики:

• составленные тест-кейсы,
• чек-листы для разработчиков.

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

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

Что в итоге

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

Такой процесс проведения тестирования аналитики внедрен в нескольких командах Контура. Команды разработки получили ряд неоспоримых преимуществ:

• экономия времени на этапе тестирования: нет затрат на тест-дизайн и тест-аналитику, так как всё уже заранее сделано,
• ускорение обратной связи разработчику через чек-лист, раньше находим критичные баги,
• все заинтересованные лица могут заранее провести ревью чек-листов и добавить некоторые проверки (на этапе тестирования данное действие обходится «дороже»).

Мы верим, что и вы сможете получить эти преимущества, внедрив в своем проекте этап тестирования аналитики.