Детали теряются и не отражаются в спеке? Внедрили ревью спецификации всей командой, теперь всё реализуется
Выпускник курса «Тестирование без требований: выявление и восстановление информации о продукте» Павел Кабанов расскажет, как курс помог справиться с неполными данными в спецификациях в условиях отсутствия наработанных процессов и достаточного количества аналитиков в команде
Добрый день, Павел. Расскажите, пожалуйста, где и кем Вы работаете, как давно в тестировании?
Добрый день, Наталья! Я — QA Lead, банковская сфера, в тестировании 3 года.
Когда Вы обучались на курсе “Тестирование без требований: выявление и восстановление информации о продукте” и что привело Вас на курс?
Это не первый курс от компании “Лаборатория Качества”, который прохожу, до этого я закончил курс “Аудит и оптимизация QA-процессов”, после чего, выбирая следующий, меня заинтересовал курс “Тестирование без требований”.
На том месте, где я сейчас работаю, очень проблемно с формированием требований, их обслуживанием и вообще какой-либо работой с ними. Я подумал — что если у этой проблемы не какие-то сугубо технические решения, а в том числе психологические и другие факторы. Посмотрев программу курса я понял, что он будет мне полезен.
Меня зацепила в программе курса тема про рецензирование документации. Например, у нас — у QA, реализовано кросс-ревью чек-листов, кросс-ревью регрессионных чек-листов. А что касается спецификации, то процесс тестирования достаточно сухо выстроен.
В каждой команде, а у нас один большой продукт и 12 команд тестирования, кто что может, тот это и делает — выстраивает процесс и меняет его у себя как хочет. Каких-то стандартов: что мы делаем и как, у нас нет. Отличная мысль о ревью спецификации, пробежаться обсуждать их, делать это всей командой, если речь идет о важных фичах, и двигаться в этом направлении.
Также меня заинтересовала такая тема как “Коммуникация по требованиям”. Год назад я стал QA лидом и за это время понял, что эта должность требует и знания психологии, и опыта, и разных софт-скиллов, и вещей абсолютно не технических. Одно дело когда ты просто это понимаешь, а другое когда на “своей шкуре” с этим сталкиваешься. Поскольку я вижу что требования приходится от всех выуживать, всех допрашивать, никто добровольно не делится, поэтому меня заинтересовал и этот аспект — коммуникация: как можно и лучше ее выстраивать.
Павел, а какая проблема, с которой Вы пришли на курс, была самая острая?
В среднем в релиз выходит около 250 задач разного качества, разного объема и у нас полтора аналитика, поэтому на каждой задаче он просто физически присутствовать не может. Хорошо, когда в релиз у команды есть хотя бы одна задача с аналитиком. И поскольку большая часть задач ими не сопровождается, а я вижу, что это нужно, но расширение штата аналитиков не предвидится, необходимо самостоятельно двигаться в этом направлении.
А как Вы решали эти проблемы раньше, до курса?
Пока петух не клюнет. Есть конкретная задача. Выяснилось что по ней есть проблема, что-то не дошло в спецификации, следовательно оно было не реализовано. Это был постфактум — “разбор полетов”. Это не решало саму проблему, естественно.
Помог ли курс решить эти проблемы?
Да, безусловно! Я внедрил ревью спецификации не только силами QA, но и всей командой! Сформировал подход к ревью и то, каким оно должно быть.
Павел, а можете поделиться что еще внедрили из материалов курса?
Да, конечно. Например, у нас есть template чек-листа на функциональность и template чек-листа на задачу, это две сущности, в которых собраны такие вещи, которые необходимо сделать практически в любой задаче. С помощью материалов из первой лекции я расширил секцию, посвященную анализу требований. Требования у нас это такая вещь: не до конца понятно кто за нее отвечает — вроде как вся команда, но в то же время если отвечают все, то никто конкретно. И я решил что QA будут финальным барьером для ревью требований, поэтому расширил в чек-листах секцию как мы их ревьюим, на что больше смотрим.
Еще пример. В первой лекции курса поэтапно рассказывается, на что стоит обращать внимание и практически в каждом этапе есть вещи, которые мне показались интересными. Не то чтобы это прямо радикально новое, но иногда в рутине, в повседневности, забываешь о тривиальных вещах и иногда полезно возвращаться назад и начинать с базы. Также у нас есть шаблон регрессионных чек-листов, удалось его оптимизировать.
Еще у нас получается, что на большинстве задач, особенно на задачах с высоким приоритетом, есть порядка 3-4 ответственных людей, а конечную спецификацию оформляет один единственный человек. Поэтому часты ситуации, когда какие-то мелизмы теряются, и в итоге в спеке они не отражены. Посмотрев второй урок курса “Выяснение потерянной информации”, я более осознанно стал подходить к этому вопросу, и теперь мы в ручном режиме ходим и выясняем — ничего ли не потерялось, все ли дошло.
Павел, спасибо за продуктивную беседу, думаю что многим Вашим коллегам она будет полезна!
И Вам спасибо!
Ознакомиться с программой и условиями прохождения курса «Тестирование без требований: выявление и восстановление информации о продукте»
По промокоду 6QL получите скидку на покупку данного курса в размере 6%