Часто в начале спринта у тестировщика нет задач. Ну а что, тестировать еще нечего, приходится ждать готового функционала.
Давайте рассмотрим стандартные этапы разработки новой фичи: создание дизайна, верстка, разработка, тестирование. И всё здесь так, но где-то между ними затесалось создание тестовой документации.
Как выглядит сценарий работы, к которому нужно стремиться:
Начинается обсуждение новой "хотелки" заказчика. PM доставляет команде первичную информацию - заказчик хочет добавить новый раздел в этом меню. Мы представляем себе суть функционала, примерно определяем его сложность.
PM создает документацию с описанием этого функционала, которая, по сути, является описанием стори или эпика. Теперь мы можем детальнее ознакомиться с фичей. Уже на этом этапе тестировщик может приступать к созданию чек-листа (а это самое начало спринта, т.к. описание стори появляется еще раньше).
Запуск спринта, дизайнеры первые приступают к работе над фичей. Как только дизайн готов, у тестировщика появляется полное представление о функционале. И если тестировщик заранее ознакомился с документом от PM, он может указать дизайнерам, каких состояний не хватает (например, пустое состояние, отображение ошибок и др.). На этом этапе мы обладаем достаточным количеством данных для создания тестовых сценариев.
Фронтенд разработчики приступают к верстке, мы параллельно работаем над чек-листом.
Бэкенд разработчики приступают к работе, наш чек-лист готов.
Фича готова, её отправляют на тестирование. И теперь мы не тратим время на придумывание сценариев, мы идем по созданному чек-листу и тестируем особенные кейсы, которые ранее не могли предусмотреть. И каждую последующую проверку после фикса дефектов мы также идем по списку сценариев.
Почему такой поход - это хорошо?
Во-первых, вы упрощаете и ускоряете свою работу. Вы не тратите каждый раз свои ресурсы для придумывания сценариев. Представим, у вас нет никакого заранее подготовленного списка проверок, вы приступаете к тестированию нового функционала: придумали и воспроизвели 10 кейсов. Нашли дефекты в 5 из них, вам прислали правки. Вы идете проверять эти 5 сценариев, всё успешно пофикшено. Но вы забыли, какие остальные 5 кейсов вы изначально тестировали. Естественно, нужно придумать еще другие проверки. Вы придумали еще 10 кейсов, снова нашли дефекты в 4 из них. Проверяете исправленные 4 кейса, забыв о том, какие 20 кейсов вообще вы проверяли. Кажется, что тестирование недостаточно, вы пытаетесь вспомнить и воспроизвести все эти кейсы еще раз.
Во-вторых, вы делаете свою работу прозрачной для всей команды - любой может ознакомиться со списком проверок.
В-третьих, вы будете понимать апдейты по этой задаче и от дизайнеров, и от фронтов, и от бэков.
В-четвертых, такая погружённость в задачу увеличивает качество тестирования. За этот пункт также отвечает процесс планирования спринта. Важно знакомиться с каждой задачей на бэклоге, точно понимать, какую работу предстоит выполнять.
Как происходит обычно и почему это плохо?
В начале спринта у тестировщика остаются задачи на тестирование с прошлого спринта или проверка правок (тоже из прошлого спринта). Времени на тестовую документацию до начала тестирования не остается. Тестировщик только в момент получения задачи приступает к проверке, и хорошо, если он записывает проверяемые кейсы куда-либо. Но чаще всего и на это тоже не хватает времени. Почему?
Потому что тайминг. Потому что заказчику всегда нужно вчера, если фича уже готова к тестированию, с 99% вероятностью никто не захочет ждать, пока вы напишите какие-то сценарии и только потом приступите к тестированию.
В таком подходе только постфактум, когда мы закончили с тестированием фичи, мы создаем задачи на создание чек-листа и тест-кейсов.
Сравнивая с предыдущим подходом к работе, здесь, очевидно, степень погружённости в задачу минимальная. Во время её разработки мы сосредоточены на другом, мы не идем в параллели с девами. Конечно, это понижает качество тестирования.
Как переходить к новому подходу?
Если работа уже выстроена на старом проекте, изменения должны быть постепенные.
Лучше всего для начала создать матрицу трассировки, чтобы понимать, в какой точке существующей тестовой документации мы находимся вообще. Пример матрицы:
Затем решаем, что для вашего проекта приоритетнее - чек-листы или тест-кейсы. Исходя из этого берем и описываем недостающие разделы функционала. От себя скажу, если не планируется в ближайшее время автоматизировать описываемый функционал, остановитесь на чек-листах. Чаще всего этого достаточно для дальнейших смок тестов и регресса.
Когда закончили описывать существующий функционал чек-листами, можно пробовать применять новый подход (с появлением нового функционала). Актуализируйте матрицу по мере добавления функционала, тогда PM и вся команда будут знать, в каком состоянии находится тестовая документация проекта.
По ней проще определять, что именно брать в работу. Начинать стоит с основного функционала и с самого "страшного" - всё что связано с деньгами.
Если проект новый, вы обладаете большой свободой для построения процессов "под себя". После знакомства и исследовательского тестирования также создаём матрицу и начинаем работать по ней с нуля.
Комментарии (12)
Darth_Anjan
31.01.2023 20:21+9Не претендую на истину в последней инстанции, но на мой взгляд вот чем должен заниматься тестировщик в начале спринта:
— ревью аналитики/прототипов. Бывает так, что маленький вопрос, нюанс от тестировщика ломает к чертям всё, что было придумано и надо придумывать что-то новое;
— составление кейсов для тестов. Не важно, кто пишет тесты, какие-то тесты всё-равно должны/будут написаны разработчиком. Набор хороших сценариев для функциональных тестов, переданный разработчику, серьёзно уменьшает количество переоткрытий задачи по результатам тестирования;
— планирование тестирования интеграций. Если у нас фича такая, что задевает несколько модулей (которые могут разрабатываться разными командами), надо договориться с другими сторонами об объемах интеграционного тестирования (разделить ответственность за контракты и использование контрактов);
— карты/чеклисты/тестпланы (кому что нравится) — для каких-то сложных фич, где сложно всё учесть и уместить в голове.
smple
31.01.2023 23:12+1я бы добавил сюда еще то что тестировщика надо как можно раньше подключать к ознакомлению фитчи, от поставноки задачи аналитиком, чтобы он понимал какой именно результат нужен в итоге.
В идеале аналитик = тестировщик, чтобы кто ставил задачи он их и принимал.
funca
31.01.2023 23:40+4Проблема в желании вогнать в границы спринта работу на принципиально разных стадиях, устроив команде микроводопад со всеми его недостатками. В начале спринта BA рискуют не успеть наделать задач, а QA в конце - недотестировать.
Сдвиньте декомпозицию и анализ сторей на полспринта до начала нового, а тестирование с релизом на полспринта после - и не будет ни у кого ни каких простоев.
У разработчиков в начале спринта появится время на багфикс и возможность знакомиться новыми задачами, собирая PoC на уровне happy path и обратную связь. QA в это время тестируют результаты предыдущей итерации, и готовят отчёты к релизу. Во второй половине - дев команда доводит код до продакшн состояния, реализуя сценарии отработки сбоев, покрывая юнит тестами. QA вместе с PO и TL прорабатывают сценарии и тесткейсы на следующий спринт.
Merrynose
01.02.2023 08:21+2Проблема зиждется на скрам-методологии, которая декларирует необходимость выпуска готовой протестированной фичи в конце спринта. Все пытаются в это прокрустово ложе поместиться, но я ни разу не видел, чтобы у кого-то это получилось.
funca
02.02.2023 00:39Скорее в части ее трактовок. Почему-то некоторые считают, дескать раз спринты по 2 недели, то в таком скрам-роддоме теперь нужно и детей вынашивать за это же время, а не 9 месяцев как обычно. В результате начинают выдавать если и живых, то сильно недоношенных.
Нет, чтобы релизить каждые 2 недели детей вам нужно не это. А нужен буфер из почти (без двух недель) готовой работы.
Просто разбейте работу на двухнедельные этапы и определите критерии качества в конце каждого из них, чтобы можно было оценить завершенность. Если все в пределах нормы - идете дальше. Если заметите, что-то не так, вы можете скорректировать или прервать и взяться за другое. В этом и состоит гибкость если сравнивать с классическим водопадом.
ngekht
01.02.2023 05:24+1В чем смысл называть итерацию, построенную по принципам последовательной разработки - спринтом? Возможно куда проще будет и команде и заказчику - если работать по принципам предсказательного управления проектами (в простонародье - водопада) в рамках процесса, разработанного именно для этой модели. MSF там или RUP. Тем более что когда нет непредсказуемости в требованиях и условиях выполнения - эти модели дают результат быстрее и дешевле. Да и изобретать ничего не надо будет - тестовые сценарии скажем всегда были неотъемлимой частью варианта использования в RUP, а тест-дизайнер был вовлечен в процесс управления требованиями и изменениями.
altocodes
01.02.2023 11:11+1Как выше отметили — самое лучшее, это либо дотестировать функционал с прошлых спринтов, либо провести ревью аналитики / дизайна.
Есть вероятность, что другие действия пойдут во вред. Так как пропистаь на уровне прототипов тест-кейсы скорее всего получится только очевидные. Что и так делается быстро. Неочевидные либо будут с высокой долей предположения и часть работы пойдет в стол.
Могут быть исключения, если у вас на проекте сработанная команда, долгий горизонт планирования и все предсказуемо.
Ekaterina_Dmitrieva_QA Автор
01.02.2023 12:55Даже очевидные вещи лучше записать/прописать, чтобы ничего не потерять/забыть.
В нашей команде стремятся до начала спринта предоставить достаточно данных, чтобы каждый понимал, зачем и как мы разрабатываем фичу.
Это бывает сложно с быстро меняющимися запросами клиента, но все равно выполнимо (:
Boethiah
02.02.2023 05:47+1Прям все так идеально, а по факту тестировщики вступают в работу в основном, когда тикеты уже готовы для тестирования в спринте. Что "будем делать" настолько сырое, что можно создать лишь базовые проверки, которые в последствии нужно будет апдейтить, потому что недалеко от ready for testing в тикете появляются новые дополнения.
Alexeyjke
А что делать, если фичи типовые, дока написана за пол дня, а до 1 задачи на тест еще день-два? ☺️
Ksoo
Радоватся, и потратить время с пользой. Закрыть техдолг по тестам, попробовать что то новое, автоматизировать что еще не автоматизировано.