Часто в начале спринта у тестировщика нет задач. Ну а что, тестировать еще нечего, приходится ждать готового функционала.
Давайте рассмотрим стандартные этапы разработки новой фичи: создание дизайна, верстка, разработка, тестирование. И всё здесь так, но где-то между ними затесалось создание тестовой документации.
Как выглядит сценарий работы, к которому нужно стремиться:
Начинается обсуждение новой "хотелки" заказчика. PM доставляет команде первичную информацию - заказчик хочет добавить новый раздел в этом меню. Мы представляем себе суть функционала, примерно определяем его сложность.
PM создает документацию с описанием этого функционала, которая, по сути, является описанием стори или эпика. Теперь мы можем детальнее ознакомиться с фичей. Уже на этом этапе тестировщик может приступать к созданию чек-листа (а это самое начало спринта, т.к. описание стори появляется еще раньше).
Запуск спринта, дизайнеры первые приступают к работе над фичей. Как только дизайн готов, у тестировщика появляется полное представление о функционале. И если тестировщик заранее ознакомился с документом от PM, он может указать дизайнерам, каких состояний не хватает (например, пустое состояние, отображение ошибок и др.). На этом этапе мы обладаем достаточным количеством данных для создания тестовых сценариев.
Фронтенд разработчики приступают к верстке, мы параллельно работаем над чек-листом.
Бэкенд разработчики приступают к работе, наш чек-лист готов.
Фича готова, её отправляют на тестирование. И теперь мы не тратим время на придумывание сценариев, мы идем по созданному чек-листу и тестируем особенные кейсы, которые ранее не могли предусмотреть. И каждую последующую проверку после фикса дефектов мы также идем по списку сценариев.
Почему такой поход - это хорошо?
Во-первых, вы упрощаете и ускоряете свою работу. Вы не тратите каждый раз свои ресурсы для придумывания сценариев. Представим, у вас нет никакого заранее подготовленного списка проверок, вы приступаете к тестированию нового функционала: придумали и воспроизвели 10 кейсов. Нашли дефекты в 5 из них, вам прислали правки. Вы идете проверять эти 5 сценариев, всё успешно пофикшено. Но вы забыли, какие остальные 5 кейсов вы изначально тестировали. Естественно, нужно придумать еще другие проверки. Вы придумали еще 10 кейсов, снова нашли дефекты в 4 из них. Проверяете исправленные 4 кейса, забыв о том, какие 20 кейсов вообще вы проверяли. Кажется, что тестирование недостаточно, вы пытаетесь вспомнить и воспроизвести все эти кейсы еще раз.
Во-вторых, вы делаете свою работу прозрачной для всей команды - любой может ознакомиться со списком проверок.
В-третьих, вы будете понимать апдейты по этой задаче и от дизайнеров, и от фронтов, и от бэков.
В-четвертых, такая погружённость в задачу увеличивает качество тестирования. За этот пункт также отвечает процесс планирования спринта. Важно знакомиться с каждой задачей на бэклоге, точно понимать, какую работу предстоит выполнять.
Как происходит обычно и почему это плохо?
В начале спринта у тестировщика остаются задачи на тестирование с прошлого спринта или проверка правок (тоже из прошлого спринта). Времени на тестовую документацию до начала тестирования не остается. Тестировщик только в момент получения задачи приступает к проверке, и хорошо, если он записывает проверяемые кейсы куда-либо. Но чаще всего и на это тоже не хватает времени. Почему?
Потому что тайминг. Потому что заказчику всегда нужно вчера, если фича уже готова к тестированию, с 99% вероятностью никто не захочет ждать, пока вы напишите какие-то сценарии и только потом приступите к тестированию.
В таком подходе только постфактум, когда мы закончили с тестированием фичи, мы создаем задачи на создание чек-листа и тест-кейсов.
Сравнивая с предыдущим подходом к работе, здесь, очевидно, степень погружённости в задачу минимальная. Во время её разработки мы сосредоточены на другом, мы не идем в параллели с девами. Конечно, это понижает качество тестирования.
Как переходить к новому подходу?
Если работа уже выстроена на старом проекте, изменения должны быть постепенные.
Лучше всего для начала создать матрицу трассировки, чтобы понимать, в какой точке существующей тестовой документации мы находимся вообще. Пример матрицы:
Затем решаем, что для вашего проекта приоритетнее - чек-листы или тест-кейсы. Исходя из этого берем и описываем недостающие разделы функционала. От себя скажу, если не планируется в ближайшее время автоматизировать описываемый функционал, остановитесь на чек-листах. Чаще всего этого достаточно для дальнейших смок тестов и регресса.
Когда закончили описывать существующий функционал чек-листами, можно пробовать применять новый подход (с появлением нового функционала). Актуализируйте матрицу по мере добавления функционала, тогда PM и вся команда будут знать, в каком состоянии находится тестовая документация проекта.
По ней проще определять, что именно брать в работу. Начинать стоит с основного функционала и с самого "страшного" - всё что связано с деньгами.
Если проект новый, вы обладаете большой свободой для построения процессов "под себя". После знакомства и исследовательского тестирования также создаём матрицу и начинаем работать по ней с нуля.
