Как без паники работать на проектах с неидеальными требованиями?!
Соковикова Виктория, тренер курса «Тестирование без требований: выявление и восстановление информации о продукте», в своем интервью расскажет, что делать в условиях отсутствия идеальных требований, а также поделится своим опытом работы в качестве аналитика в сфере QA.
Виктория, расскажите, как давно Вы начали заниматься аналитикой и как Вам работается среди тестировщиков?
В этой сфере я 7 лет. На первую работу устроилась на последнем курсе университета, до конца не понимая, чем придется заниматься. Тогда профессия аналитика в нашем городе еще не была мейнстримом 🙂 Но каждая новая задача, каждый новый проект давали столько вдохновения, что не возникало даже мысли сменить сферу деятельности.
Тестировщики были на всех проектах, в которых я участвовала. Но до Лаборатории Качества мне, во-первых, не удавалось сотрудничать с таким количеством специалистов по тестированию.:)
Во-вторых, я никогда не разрабатывала для них проекты. Поэтому «по-настоящему» среди тестировщиков я четвертый год.
Это ежедневный вызов, когда твоим продуктом пользуются более 100 специалистов по качеству. Было время, когда большую часть рабочего дня я посвящала поддержке: работала с замечаниями, баг-репортами, вопросами коллег. Но это и отличная мотивация – постоянно совершенствовать процессы и продукт, учиться думать «как тестировщик».
Как Вам пришла идея создать курс для тестировщиков?
Меня заставили вдохновили 🙂 Текущая версия курса – вторая. Первая попытка разработать курс по требованиям для тестировщиков была около двух лет назад и тогда, к счастью, окончилась неуспешно. «К счастью» потому, что если бы Наталья Руколь не остановила процесс, был бы очередной теоретический курс от аналитика для аналитика с пересказом К.Вигерса.
Но опыт тренерской работы в ПОИНТ, где мы постоянно сталкивались с вопросами студентов, совместно решали сложные ситуации, а также постоянное общение с коллегами-тестировщиками показали, что не на всех проектах есть качественные требования, профессиональные аналитики и тех. писатели. Зачастую отсутствуют и грамотно выстроенные процессы. Регулярно встречались одни и те же проблемы:
- требований нет вообще: «тестируйте по реализованной функциональности»;
- требования меняются, но изменения не отражаются в документации: «а это уже год неактуально, мы реализовали по-другому»;
- существуют внутренние договоренности, о которых не сообщают команде тестирования: «это не баг, мы с менеджером договорились в личке»;
- требования есть, но в них много пропусков, противоречий, неоднозначных формулировок.
В итоге тратится время на выяснение информации, оформление неактуальных баг-репортов, коммуникации, исправление тестовой документации. А команда тестирования остается виноватой за пропуск ошибок на прод.
Когда эти «боли» были собраны, поняты и пережиты, структура курса сформировалась сама собой.
Кто приходит к Вам на курс?
На курсе обучаются как аналитики, так и тестировщики, в команде которых нет или не хватает аналитиков: инженеры по тестированию уровня Middle и Senior. Также наши студенты – тест-лиды, технические писатели, работающие в веб-студиях полного цикла, продуктовых компаниях, ИТ-подразделениях организаций, не разрабатывающих софт.
С какими проблемами они сталкиваются в работе?
У большей части коллег на проекте нет аналитиков, а требования либо фиксируются уже после релиза, либо неполные: не описаны исключения, все входные и выходные параметры, влияние на другие модули и функции.
В итоге тестировщикам приходится либо додумывать поведение системы, либо постоянно обращаться к разработчику или менеджеру с вопросами: «Как это должно работать? Что делать в этом случае? А что, если ввести такое значение?».
В первом случае можно столкнуться с неверным предположением и пропущенными дорогими ошибками бизнес-логики, во втором – укреплению позиции некоторых разработчиков в том, что команда тестирования только отвлекает и мешает работать. Все это зачастую ведет к конфликтам и выгоранию команды.
Как обучение на курсе помогает тестировщикам?
На курсе мы проходим несколько этапов:
- Понимаем, что на проекте недостаточно какой-то информации, необходимой для тестирования. Так как мы привыкаем к процессам, необходим свежий взгляд на проект – как бы со стороны, комплексно, чтобы понять, что что-то не так.
- Выясняем, какой именно информации не хватает. Имеющуюся – проверяем на ошибки.
- Определяем, где и как получить нужную информацию. Что-то мы будем искать в документации, а что-то – запрашивать у заинтересованных лиц. Для каждого пути есть свои инструменты и правила.
- Чтобы не повторять эти действия каждый раз заново, выстраиваем процесс работы с требованиями – но не идеальный процесс по книжкам, а подходящий именно вашему проекту и команде.
Виктория, слышала про бонусы в Вашем курсе. Поделитесь?
Да, конечно, это не тайна 😉 Бонус – урок Натальи Руколь по внедрению процесса на проекте и его «продаже» команде и другими заинтересованным лицам. Самое «ужасное», что может произойти после любого обучения, когда вдохновение и желание внедрять лучшие практики разбиваются о «у нас так принято, ничего менять не будем». Наша задача – дать на курсе такие инструменты и методы, которые студент сразу после обучения сможет использовать даже на самом «консервативном» проекте.
Как проходит обучение? Сколько длится и сколько времени необходимо посвящать учебе студентам?
Курс длится 6 недель. Раз в неделю открывается доступ к записи лекции. Студенты могут изучить ее в любое удобное время. Лекции длятся в среднем 40-45 минут + остановки на практические мини-задания.
Сколько времени на курсе уделяется практической работе? Как она проводится?
Практическое задание предусмотрено для каждого урока. Задания сквозные – на реальном проекте студента (или учебном, при невозможности работать с реальным) мы проходим все этапы построения процесса выявления необходимой информации о продукте.
Для всех заданий выдаются шаблоны, которые проверяются в индивидуальном порядке.
В среднем на выполнение заданий надо заложить от 1 до 2,5 часов на каждый урок (в зависимости от вашего проекта).
Могут ли студенты внедрять новые знания уже в ходе обучения?
Да, конечно. Если студент работает со своим проектом, то каждая домашняя работа – это внедрение того или иного инструмента. На выходе студенты имеют полностью настроенный процесс управления информацией о продукте. У них выявлены все «белые пятна» проекта, есть четкий алгоритм действий – куда, к кому и как обращаться, какой инструмент использовать, какие вопросы задавать.
А один из студентов даже написал, что после прохождения курса смог внедрить полученные инструменты не только на своем внутреннем проекте, а еще и для внешнего заказчика.
Помимо теоретической информации и практических занятий, получат ли студенты какие-то инструменты, которые облегчат их работу?
Все шаблоны, используемые на курсе, остаются у студентов навсегда – они могут в любой момент, придя но новый проект, проанализировать текущую обстановку, выявить проблемные зоны и настроить процессы в соответствии с нуждами команды.
Кроме «методологических» инструментов – шаблонов, памяток и алгоритмов – мы используем программные продукты для совместной работы, построения схем, рассматриваем системы управления требованиями.
Предусмотрена ли обратная связь с преподавателем?
Обратная связь на курсе есть в нескольких форматах:
- ОС по домашней работе: детально разбираем все возникшие вопросы, ошибки, неучтенные детали;
- Ответы на вопросы в чате группы и лично.
Общаются ли студенты друг с другом?
Да, общение также ведется в чате группы – мы совместно обсуждаем спорные вопросы, делимся лайфхаками и опытом.
И напоследок, какой небольшой полезный совет Вы бы дали читателям?
Если вы чувствуете, что на проекте с требованиями что-то не так (или их вообще нет), и это мешает вашей работе, есть 3 варианта:
- Поднять руки, сдаться и занять позицию «будут хорошие требования, будем хорошо тестировать, а пока – скажите «спасибо» и за такие результаты».
- Эти же самые руки поднять, выдохнуть, опустить их резко с фразой «да пошло оно все» и уйти «туда, где не надо думать о пользовательских болях или требованиях законодательства, которое не учли в разработке».
- И пока тема рук не раскрыта полностью – третий вариант. Засучить рукава и начать погружаться в вопросы, ответы на которые раньше ждали только от аналитиков. Этот подход подойдет тем, кто, независимо от наличия и качества требований к нему, готов отвечать за качество продукта, кто не боится отстаивать интересы пользователей, кто хочет налаживать процессы работы с требованиями.
Именно тех, кто готов разбираться и работать, мы приглашаем на наш курс!
Хотите прямо сейчас проверить насколько полной информацией о проекте владеет ваша команда? Заполните небольшую анкету и получите наш Чек-лист проверки полноты информации о продукте.
