Знакомьтесь, авторы июльской статьи для «Календаря тестировщика» Андрей Марченко и Марина Третьякова, тестировщики-аналитики Контура. В этом месяце ребята расскажут о моделях рабочего процесса по тестированию аналитики, и как они начали тестировать аналитику до стадии разработки. Опыт ребят будет полезен менеджерам, тестировщикам и аналитикам некрупных продуктовых команд, которые не живут в рамках стартапа и для которых качество важнее скорости.
Модели рабочего процесса по тестированию аналитики
Модель 1
Тестировщик работает с аналитикой после того, как ему передали готовую задачу. Он проверяет задачу, читая аналитику, как документацию того, что сделал разработчик. Ошибаются абсолютно все, вне зависимости от уровня профессионализма. Дефекты могут быть в аналитике или в коде разработчика.
Минусы:
- дефекты в аналитике не будут выявлены раньше стадии тестирования,
- есть риск того, что задача из тестирования отправится снова в аналитику на доработку. Как следствие TimeToMarket задачи существенно увеличивается.
Ошибки аналитики, выявленные при тестировании, стоят дорого или очень дорого.
Плюсы:
- сокращается время тестировщика для задач, где не требуется аналитик (инфраструктурные, рефакторинг).
Модель 2
Тестировщик подключается к задаче еще до того, как ее передали в разработку. Он смотрит прототипы по задаче или просто читает документацию. Все вопросы по задаче тестировщик задает аналитику. Аналитик оперативно исправляет замечания. Тестировщик составляет приемочные тесты.
Минусы:
- тестировщику придется учиться смежной области (оформлению аналитики и ТЗ),
- перейдя на эту модель, тестировщику придется сначала потратить больше времени на тестирование, ведь процесс «пришла готовая задача — читаю аналитику — тестирую» растягивается до «пришло описание будущей задачи — читаю аналитику — тестирую аналитику — пришла готовая задача — тестирую».
Плюсы:
- вероятность найти ошибки аналитики после передачи задачи в разработку становится меньше,
- тестировщик уже в контексте задачи, когда она попадет к нему на тестирование, следовательно он быстрее её проверяет,
- тестирование аналитики отлично расширяет кругозор, предоставляя специалисту возможность для будущего перехода в аналитики,
- разработчик повышает качество своего кода и продукта в целом, потому что перед отправкой своего решения в тестирование он проходит приемочные тесты.
Если в команде разработки нет ревью работы аналитиков, тестирование аналитики улучшает качество продукта и уменьшает риск передачи задачи в разработку с ошибками в ТЗ.
Когда мы общались с тестировщиками, работающими по первой модели, мы часто слышали:
- «У нас в очереди и так хватает текущих задач, чтобы брать еще».
- «А поговорите с менеджером».
Перестройка процесса разработки — серьезная менеджерская задача.
Внедрение тестирования аналитики до стадии разработки
Почти год, как в проекте Контур.Норматив в процесс разработки встроен обязательный этап «тестирование аналитики». К этому команда пришла не сразу. Толчком стал рост количества возвратов задачи с тестирования на этап аналитики и дальнейшей доработки.
Особенно больно было при больших задачах с новой функциональностью. Переданные на этап тестирования задачи по front-end были сырыми, нередко ломались на самых простых сценариях, реализовывались по-другому в виду «двоякости» определений и терминов в аналитике.
Процесс тестирования аналитики не появляется по щелчку пальцев или какой-либо магии. Это кропотливая работа, но ее можно разбить на этапы.
Этап 0. Продать команде идею тестирования аналитики
Можно легко представить ситуацию, когда по своей работе внезапно получаешь обратную связь с замечаниями, предложениями и исправлениями. Первая мысль у любого нормального человека будет: «А почему решили меня проверить? Мне не доверяют? Следят за качеством моей работы?». На данном этапе очень важно, чтобы у аналитика не появилось ощущения, что его проверяют на качество, и, в случае неудачной проверки, уволят.
Ряд вопросов можно снять, если преподнести информацию в ключе: «это даст нам возможность раньше узнавать о новой функциональности, ускорит этап тестирования, предотвратит внесение даже небольших дефектов в код».
Когда этап 0 пройден, можно продвигаться дальше.
Этап 1. Внедрение тестирования аналитики в процесс разработки
Убедив команду, приступаем к внедрению тестирования аналитики в ежедневный рабочий процесс. Если изначально рабочий процесс выглядел так:
То после внедрения:
Если в вашей команде несколько аналитиков, которые проводят ревью друг друга перед тем, как отдать задачу в разработку, то приступаем к тестированию более качественного текста. Мы подразумеваем, что ревью аналитики не является ее тестированием, а лишь некоторой его частью.
Этап 2. Тестирование аналитики
Бывают задачи, когда прототипы заменяют текстовый вариант аналитики.
В таком случае прототип проверяем также как текст. Если прототипы дополняют аналитику, то полезно перед чтением документации посмотреть на дизайн-макеты будущей функциональности. Это ваш единственный шанс взглянуть на задачу как пользователь, который не читал ТЗ и не знает, как всё устроено и должно работать.
Что можно проверять в аналитике:
1.Предложенное решение удовлетворяет цели задачи.
Например, если цель задачи — собрать обратную связь с пользователей, то решение должно предполагать запись и хранение ответов пользователей.
2.Однозначность интерпретации.
Например, формулировку «показать информацию за текущий день» можно по-разному интерпретировать. Можно понять как «показать информацию за выбранный в настройках день», а можно как «показать информацию за день равный сегодня».
3.Осуществимость решения.
Осуществимость — это возможность реализовать требования, написанные в аналитике при известных ограничениях среды разработки, языка программирования, алгоритмической сложности. Хорошие аналитики могут держать в уме алгоритм, по которому можно решить написанную ими задачу. Не факт, что разработчики сделают по этому алгоритму (они более осведомлены, найдут способы сделать алгоритм оптимальным и т. д.), но само его наличие говорит об осуществимости задачи.
4.Тестируемость.
Как проверить, что соблюдено условие «улучшить поисковую выдачу» — непонятно. Но если переписать условие на «поисковая выдача должна быть показана пользователю в течение 1 секунды после нажатия контрола «Поиск» — понятно.
5.Наличие альтернативных сценариев.
В формулировке «Если указаны номер и дата, то печатаем номер и дату. Если дата не указана, печатаем только номер» не хватает сценариев:
- нет номера, а есть дата,
- данных нет.
6.Обработка исключений.
В формулировке «Можно загрузить документ только в формате Excel» непонятно, что должно происходить, если мы загрузим файлы других форматов, и какую ошибку при их загрузке мы увидим.
Артефакты при тестировании аналитики
Какие артефакты могут остаться после тестирования аналитики:
- составленные тест-кейсы,
- чек-листы для разработчиков.
Чек-лист для разработчика — необходимые, емкие, базовые проверки основных сценариев, которые должны работать, чтобы можно было тестировать. А еще это инструмент повышения качества кода. Перед тем как отдать задачу в тестирование, разработчик проходит чек-лист, самостоятельно быстро выявляя баги.
Разработчика надо убедить проходить чек-лист тестировщика, снимая внутренние волнения разработчика «меня проверяют», делая акцент на «ускорение процесса, ускорение тестирования, повышение качества». В итоге у нас разработчик проходит данные чек-листы и радуется, что ошибки нашел не тестировщик, а он сам («никто не узнает, что я накосячил в таком ерундовом сценарии»).
Что в итоге
С первого взгляда кажется, что внедрение нового этапа в процесс разработки лишь увеличит TimeToMarket, но это иллюзия. Сначала, конечно, процесс тестирования аналитики будет новым и неопробованным, и тестировщик на него будет тратить больше времени. В дальнейшем, набираясь опыта, он сможет быстрее проводить его. А результаты, полученные на этапе тестирования аналитики, сократят время на этапе непосредственного тестирования и сведут количество возвратов к минимуму.
Такой процесс проведения тестирования аналитики внедрен в нескольких командах Контура. Команды разработки получили ряд неоспоримых преимуществ:
- экономия времени на этапе тестирования: нет затрат на тест-дизайн и тест-аналитику, так как всё уже заранее сделано,
- ускорение обратной связи разработчику через чек-лист, раньше находим критичные баги,
- все заинтересованные лица могут заранее провести ревью чек-листов и добавить некоторые проверки (на этапе тестирования данное действие обходится «дороже»).
Мы верим, что и вы сможете получить эти преимущества, внедрив в своем проекте этап тестирования аналитики.
Автор: ylian_demakova
