Как без паники работать на проектах с неидеальными требованиями?!

Соковикова Виктория, тренер курса «Тестирование без требований: выявление и восстановление информации о продукте», в своем интервью расскажет, что делать в условиях отсутствия идеальных требований, а также поделится своим опытом работы в качестве аналитика в сфере QA.

Виктория, расскажите, как давно Вы начали заниматься аналитикой и как Вам работается среди тестировщиков? 

В этой сфере я 7 лет. На первую работу устроилась на последнем курсе университета, до конца не понимая, чем придется заниматься. Тогда профессия аналитика в нашем городе еще не была мейнстримом 🙂 Но каждая новая задача, каждый новый проект давали столько вдохновения, что не возникало даже  мысли сменить сферу деятельности.

Тестировщики были на всех проектах, в которых я участвовала. Но до Лаборатории Качества мне, во-первых, не удавалось сотрудничать с таким количеством специалистов по тестированию.:)

Во-вторых, я никогда не разрабатывала для них проекты. Поэтому «по-настоящему» среди тестировщиков я четвертый год.

Это ежедневный вызов, когда твоим продуктом пользуются более 100 специалистов по качеству. Было время, когда большую часть рабочего дня я посвящала поддержке: работала с замечаниями, баг-репортами, вопросами коллег. Но это и отличная мотивация – постоянно совершенствовать процессы и продукт, учиться думать «как тестировщик».

Как Вам пришла идея создать курс для тестировщиков?

Меня заставили вдохновили 🙂 Текущая версия курса – вторая. Первая попытка разработать курс по требованиям для тестировщиков была около двух лет назад и тогда, к счастью, окончилась неуспешно. «К счастью» потому, что если бы Наталья Руколь не остановила процесс, был бы очередной теоретический курс от аналитика для аналитика с пересказом К.Вигерса.

Но опыт тренерской работы в ПОИНТ, где мы постоянно сталкивались с вопросами студентов, совместно решали сложные ситуации, а также постоянное общение с коллегами-тестировщиками показали, что не на всех проектах есть качественные требования, профессиональные аналитики и тех. писатели. Зачастую отсутствуют и грамотно выстроенные процессы. Регулярно встречались одни и те же проблемы:

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

В итоге тратится время на выяснение информации, оформление неактуальных баг-репортов, коммуникации, исправление тестовой документации. А команда тестирования остается виноватой за пропуск ошибок на прод.

Когда эти «боли» были собраны, поняты и пережиты, структура курса сформировалась сама собой.

Кто приходит к Вам на курс?

На курсе обучаются как аналитики, так и тестировщики, в команде которых нет или не хватает аналитиков: инженеры по тестированию уровня Middle и Senior. Также наши студенты – тест-лиды, технические писатели, работающие в веб-студиях полного цикла, продуктовых компаниях, ИТ-подразделениях организаций, не разрабатывающих софт.

С какими проблемами они сталкиваются в работе? 

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

В итоге тестировщикам приходится либо додумывать поведение системы, либо постоянно обращаться к разработчику или менеджеру с вопросами: «Как это должно работать? Что делать в этом случае? А что, если ввести такое значение?». 

В первом случае можно столкнуться с неверным предположением и пропущенными дорогими ошибками бизнес-логики, во втором – укреплению позиции некоторых разработчиков в том, что команда тестирования только отвлекает и мешает работать. Все это зачастую ведет к конфликтам и выгоранию команды.

Как обучение на курсе помогает тестировщикам? 

На курсе мы проходим несколько этапов:

  1. Понимаем, что на проекте недостаточно какой-то информации, необходимой для тестирования. Так как мы привыкаем к процессам, необходим свежий взгляд на проект – как бы со стороны, комплексно, чтобы понять, что что-то не так.
  2. Выясняем, какой именно информации не хватает. Имеющуюся – проверяем на ошибки.
  3. Определяем, где и как получить нужную информацию. Что-то мы будем искать в документации, а что-то – запрашивать у заинтересованных лиц. Для каждого пути есть свои инструменты и правила.
  4. Чтобы не повторять эти действия каждый раз заново, выстраиваем процесс работы с требованиями – но не идеальный процесс по книжкам, а подходящий именно вашему проекту и команде.

Виктория, слышала про бонусы в Вашем курсе. Поделитесь?

Да, конечно, это не тайна 😉 Бонус – урок Натальи Руколь по внедрению процесса на проекте и его «продаже» команде и другими заинтересованным лицам. Самое «ужасное», что может произойти после любого обучения, когда вдохновение и желание внедрять лучшие практики разбиваются о «у нас так принято, ничего менять не будем». Наша задача – дать на курсе такие инструменты и методы, которые студент сразу после обучения сможет использовать даже на самом «консервативном» проекте.

Как проходит обучение? Сколько длится и сколько времени необходимо посвящать учебе студентам?

Курс длится 6 недель. Раз в неделю открывается доступ к записи лекции. Студенты могут изучить ее в любое удобное время. Лекции длятся в среднем 40-45 минут + остановки на практические мини-задания.

Сколько времени на курсе уделяется практической работе? Как она проводится?

Практическое задание предусмотрено для каждого урока. Задания сквозные – на реальном проекте студента (или учебном, при невозможности работать с реальным) мы проходим все этапы построения процесса выявления необходимой информации о продукте.

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

В среднем на выполнение заданий надо заложить от 1 до 2,5 часов на каждый урок (в зависимости от вашего проекта).

Могут ли студенты внедрять новые знания уже в ходе обучения? 

Да, конечно. Если студент работает со своим проектом, то каждая домашняя работа – это внедрение того или иного инструмента. На выходе студенты имеют полностью настроенный процесс управления информацией о продукте. У них выявлены все «белые пятна» проекта, есть четкий алгоритм действий – куда, к кому и как обращаться, какой инструмент использовать, какие вопросы задавать.

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

Помимо теоретической информации и практических занятий,  получат ли студенты какие-то инструменты, которые облегчат их работу?

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

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

Предусмотрена ли обратная связь с преподавателем? 

Обратная связь на курсе есть в нескольких форматах:

  • ОС по домашней работе: детально разбираем все возникшие вопросы, ошибки, неучтенные детали;
  • Ответы на вопросы в чате группы и лично.

Общаются ли студенты друг с другом?

Да, общение также ведется в чате группы – мы совместно обсуждаем спорные вопросы, делимся лайфхаками и опытом.

И напоследок, какой небольшой полезный совет Вы бы дали читателям? 

Если вы чувствуете, что на проекте с требованиями что-то не так (или их вообще нет), и это мешает вашей работе, есть 3 варианта:

  1. Поднять руки, сдаться и занять позицию «будут хорошие требования, будем хорошо тестировать, а пока – скажите «спасибо» и за такие результаты».
  2. Эти же самые руки поднять, выдохнуть, опустить их резко с фразой «да пошло оно все» и уйти «туда, где не надо думать о пользовательских болях или требованиях законодательства, которое не учли в разработке». 
  3. И пока тема рук не раскрыта полностью – третий вариант. Засучить рукава и начать погружаться в вопросы, ответы на которые раньше ждали только от аналитиков. Этот подход подойдет тем, кто, независимо от наличия и качества требований к нему, готов отвечать за качество продукта, кто не боится отстаивать интересы пользователей, кто хочет налаживать процессы работы с требованиями.

 Именно тех, кто готов разбираться и работать, мы приглашаем на  наш курс

Хотите прямо сейчас проверить насколько полной информацией о проекте владеет ваша команда? Заполните небольшую анкету и получите наш Чек-лист проверки полноты информации о продукте.

Метки
ISTQB FL (1)IT (1)Java для тестировщиков (1)Jedi Point (12)JSON (1)kaizen (2)Pairwise Testing (1)QA (25)QualityLab (1)REST API (1)selenium (1)SOAP UI (1)softskills тестировщика (7)SQA Days-25 (1)Sql в тестировании (5)TestSuites (1)XML (1)xpath (1)Анна Палей (1)Исследовательское тестирование (3)История успеха (12)Курс тестирования для начинающих (4)Мнемоники в тестировании (1)Наталья Руколь (1)Нина Агеева (4)Обучение тестированию (13)ПОИНТ (44)Роман Буданов (3)Сессионное тестирование (1)ТЗ (1)Таблица решений (1)Тест-анализ (1)Тест-дизайн (4)Тест-кейс (1)Тест-стратегия (1)Тест-туры (1)Тестирование usability (3)Тестирование ПО (7)Тестирование игр (4)Тестирование мобильных приложений (4)Тест менеджмент (2)Чек-лист в тестировании по (4)Чит-лист в тестировании (2)автоматизация тестирования (2)автотесты (1)баг (1)багнапродакшене (1)введение в тестирование (1)виды тестировния (2)граничные значения (1)декомпозиция (1)инструменты тестирования по (4)как надо тестировать (2)как стать тестировщиком (2)комбинаторика в тестировании (1)начать карьеру в IT (6)начинающий тестировщик (11)негативное тестирование (2)ограничения (1)организация тестирования (1)персонажи (1)планирование тестирования (1)профессия тестировщик (3)резюме (1)сертификация ISTQB FL (1)скринкаст (1)смена работы (2)сопроводительное письмо (1)тест-кейс (1)тестирование безопасности (1)тестирование веб (3)удаленная работа (1)управление требованиями (2)фреймворк тестирования (1)
С 16.03 по 2.06, ОНЛАЙН Зарегистрироваться