Детали теряются и не отражаются в спеке? Внедрили ревью спецификации всей командой, теперь всё реализуется

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

Добрый день, Павел. Расскажите, пожалуйста, где и кем Вы работаете, как давно в тестировании?
Добрый день, Наталья! Я — QA Lead, банковская сфера, в тестировании 3 года. 


Когда Вы обучались на курсе “Тестирование без требований: выявление и восстановление информации о продукте” и что привело Вас на курс?
Это не первый курс от компании “Лаборатория Качества”, который  прохожу, до этого я закончил курс “Аудит и оптимизация QA-процессов”, после чего, выбирая следующий, меня заинтересовал курс “Тестирование без требований”.

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

Меня зацепила в программе курса тема про рецензирование документации. Например, у нас — у QA, реализовано кросс-ревью чек-листов, кросс-ревью регрессионных чек-листов. А что касается спецификации, то процесс тестирования достаточно сухо выстроен. 

В каждой команде, а у нас один большой продукт и 12 команд тестирования, кто что может, тот это и делает — выстраивает процесс и меняет его у себя как хочет. Каких-то стандартов: что мы делаем и как, у нас нет. Отличная мысль о ревью спецификации, пробежаться обсуждать их, делать это всей командой, если речь идет о важных фичах, и двигаться в этом направлении. 

Также меня заинтересовала такая тема как “Коммуникация по требованиям”. Год назад я стал QA лидом и за это время понял, что эта должность требует и знания психологии, и опыта, и разных софт-скиллов, и вещей абсолютно не технических. Одно дело когда ты просто это понимаешь, а другое когда на “своей шкуре” с этим сталкиваешься. Поскольку я вижу что требования приходится от всех выуживать, всех допрашивать, никто добровольно не делится, поэтому меня заинтересовал и этот аспект — коммуникация: как можно и лучше ее выстраивать.  

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

В среднем в релиз выходит около 250 задач разного качества, разного объема и у нас полтора аналитика, поэтому на каждой задаче он просто физически присутствовать не может. Хорошо, когда в релиз у команды есть хотя бы одна задача с аналитиком. И поскольку большая часть задач ими  не сопровождается, а я вижу, что это нужно, но расширение штата аналитиков не предвидится, необходимо самостоятельно двигаться в этом направлении. 

А как Вы решали эти проблемы раньше, до курса?

Пока петух не клюнет. Есть конкретная задача. Выяснилось что по ней есть проблема, что-то не дошло в спецификации, следовательно оно было не реализовано. Это был постфактум — “разбор полетов”. Это не решало саму проблему, естественно. 

Помог ли курс решить эти проблемы?

Да, безусловно! Я внедрил ревью спецификации не только силами QA, но и всей командой! Сформировал подход к ревью и то, каким оно должно быть.

Павел, а  можете поделиться что еще внедрили из материалов курса?

Да, конечно. Например, у нас есть template чек-листа на функциональность и template чек-листа на задачу, это две сущности, в которых собраны такие вещи, которые необходимо сделать практически в любой задаче. С помощью материалов из первой лекции я расширил секцию, посвященную анализу требований. Требования у нас это такая вещь: не до конца понятно кто за нее отвечает — вроде как вся команда, но в то же время если отвечают все, то никто конкретно. И я решил что QA будут финальным барьером для ревью требований, поэтому расширил в чек-листах секцию как мы их ревьюим, на что больше смотрим. 

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

Еще у нас получается, что на большинстве задач, особенно на задачах с высоким приоритетом, есть порядка 3-4 ответственных людей, а конечную спецификацию оформляет один единственный человек. Поэтому часты ситуации, когда какие-то мелизмы теряются, и в итоге в спеке они не отражены. Посмотрев второй урок курса “Выяснение потерянной информации”, я более осознанно стал подходить к этому вопросу, и теперь мы в ручном режиме ходим и выясняем — ничего ли не потерялось, все ли дошло.

Павел, спасибо за продуктивную беседу, думаю что многим Вашим коллегам она будет полезна!

И Вам спасибо! 



Ознакомиться с программой и условиями прохождения курса «Тестирование без требований: выявление и восстановление информации о продукте»

По промокоду 6QL получите скидку на покупку данного курса в размере 6%



Метки
ISTQB FL (4)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 в тестировании (6)TestSuites (1)XML (1)xpath (1)Анна Палей (1)Исследовательское тестирование (3)История успеха (17)Курс тестирования для начинающих (12)Мнемоники в тестировании (1)Наталья Руколь (1)Нина Агеева (4)Обучение тестированию (13)ПОИНТ (49)Роман Буданов (3)Сессионное тестирование (1)ТЗ (1)Таблица решений (1)Тест-анализ (2)Тест-дизайн (6)Тест-кейс (1)Тест-стратегия (1)Тест-туры (1)Тестирование usability (6)Тестирование ПО (7)Тестирование игр (4)Тестирование мобильных приложений (4)Тест менеджмент (3)Чек-лист в тестировании по (4)Чит-лист в тестировании (2)автоматизация тестирования (2)автотесты (1)английский для тестировщиков (2)аудит проекта (2)баг (1)багнапродакшене (1)введение в тестирование (1)виды тестировния (2)граничные значения (1)декомпозиция (1)инструменты тестирования по (4)как надо тестировать (2)как стать тестировщиком (2)комбинаторика в тестировании (1)метрики тестирования (1)начать карьеру в IT (8)начинающий тестировщик (11)негативное тестирование (2)ограничения (1)оптимизация QA-процессов (1)организация тестирования (1)персонажи (1)планирование тестирования (1)профессия тестировщик (3)резюме (1)сертификация ISTQB FL (3)скринкаст (1)смена работы (2)сопроводительное письмо (1)тест-кейс (1)тест-менеджмент (2)тестирование безопасности (1)тестирование веб (3)тестовая стратегия (1)удаленная работа (1)управление требованиями (6)фреймворк тестирования (1)школа тест-менеджера (2)
С 22.06 по 8.09, ОНЛАЙН Зарегистрироваться