Pull to refresh
133.64
Контур
Делаем сервисы для бизнеса

«Календарь тестировщика» за июль. Тестирование аналитики

Reading time 6 min
Views 8.4K

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





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


Модель 1


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


Минусы:


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

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

Плюсы:


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

Модель 2


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


Минусы:


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

Плюсы:


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

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


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


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

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

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


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


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


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


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


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


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


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


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


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



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



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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

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


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


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


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


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

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


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


Что в итоге


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


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


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

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


Список статей календаря:
Попробуй другой подход
Разумное парное тестирование
Обратная связь: как это бывает
Оптимизируй тесты
Прочти книгу
Тестирование аналитики
Тестировщик должен поймать баг, прочитать Канера и организовать движуху
Нагрузи сервис
Метрики на службе у QA
Протестируй безопасность
Узнай своего клиента
Разбери бэклог

Tags:
Hubs:
+12
Comments 5
Comments Comments 5

Articles

Information

Website
tech.kontur.ru
Registered
Founded
Employees
5,001–10,000 employees
Location
Россия