Home

Оригинальная публикация

Как быть тестировщику, если на проекте нет аналитика и спецификации? Маша Кузнецова, младший QA-инженер red_mad_robot, рассказывает о трёх возможных вариантах действия — осторожном, умеренно рискованном и максимально упоротом. Будет особенно полезно QA начального и среднего уровня — чтобы не растеряться, попав в похожую ситуацию.

Что может быть не так со спецификацией

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

Спеки — spec, от сокращённого английского specification — так называют технические требования на внутреннем сленге разработчики и тестировщики. Они могут включать варианты пользовательских сценариев, требования к производительности, стандарты качества и проектные ограничения. Обычно спецификацию составляет заказчик и/или исполнитель.

Проект проекту рознь, и в идеальном мире разработки тестировщик на проекте руководствуется полноценной спецификацией. Такого почти никогда не случается. Бывает, что она устаревшая или в ней есть пробелы. А иногда QA попадает на новый проект, который не имеет спецификации вообще. По внутренней статистике, которую мы собрали, с этим сталкиваются 78% специалистов.

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

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

Такое часто происходит в стартапах или низкобюджетных проектах, а также в случае, когда разработка ведётся в таком высоком темпе, что аналитик просто не успевает писать документацию на стремительно появляющиеся фичи. Или аналитика вовсе нет в компании.

Это сильно затрудняет, а иногда блокирует создание тестовой документации и тестирование продукта.

Если документации нет, жить очень грустно. Личное наблюдение: скорость разработки и тестирования без неё падает в пять раз.

Коля Абашидзе, QA-инженер red_mad_robot

Как обстоят дела со спеками

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

Чаще всего, по опыту респондентов, в работе не хватало функциональных и нефункциональных требований, описания API/Swagger и макетов.

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

Поделимся своим опытом и тремя рабочими подходами — что делать и к кому обращаться в таких ситуациях.

Подход первый. Осторожный

Самый простой, при этом самый редкий подход из тех, которые мы используем. Если QA берёт на себя восстановление или создание спецификации, у него есть риск стать точкой входа информации о продукте. Кроме того, может случиться (а скорее всего, так и будет), что работа по написанию функциональных требований окажется недостаточно качественной — и тестировщик столкнётся с критикой в свой адрес. Этого не хочется никому.

При осторожном подходе действуем так:

1. Тестовую документацию для нужд тестирования создаём исходя из опыта тестировщиков и результатов исследовательского тестирования, когда мы пробуем узнать, для чего предназначена та или иная кнопка, нажав на неё.

2. На командных встречах настойчиво подсвечиваем недостатки спецификации и необходимость её восстановить или создать.

3. Находим людей из других практик (frontend- и backend-разработчиков, менеджеров и других специалистов), которые могут взять на себя задачу, — чтобы распределить ответственность.

4. При таком подходе QA избегает общения с владельцем продукта. QA не всегда умеют получать от людей информацию в формате, пригодном для использования в качестве документации, а продакт оунер может не понять, что именно от него нужно.

Идти к продакт оунеру за требованиями обычно плохая идея. Часто это мечтатели, которые помимо ответа на твой вопрос накидают ещё несколько фич сверху. Но любая идея должна пройти через аналитика, поэтому QA придётся нести ему эти идеи на проверку. Мечтателей больше, чем владельцев с аналитическим складом ума, которые четко сформулируют ответ, не перегружая его информацией.

Оля Никитина, старший QA-инженер red_mad_robot

Подход второй. Обычный для робота

У нас не принято искать крайних, если что-то пошло не так. Если QA взялись писать спецификацию, но итоговое качество оставляет желать лучшего, то негатива они не получат — просто потому, что они QA, а не аналитики.

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

1. Если есть устаревшие фрагменты спецификации, то проводим их ревью и указываем на необходимость обновить и исправить недочёты.

2. Параллельно пишем тестовую документацию. Стараемся опираться в ней не только на опыт тестировщиков, но и на фрагменты информации, которые могут помочь обнаружить неучтённые белые пятна в спецификации.

3. К продакт оунеру здесь тоже стараемся не обращаться, так как не хотим стать точкой входа информации о проекте.

Если документация неполная, это не так страшно — нужно создать алгоритм по дополнению и восстановлению. А все дополнения заносить в виде сносок в Confluence либо в другом инструменте хранения документации.

Коля Абашидзе, QA-инженер red_mad_robot

Подход третий. Робот на максималках

При таком подходе QA принимают максимально активное участие в написании спецификации — фактически пишут её сами.

1. Эту задачу включают в график работ, выделяя на неё от получаса до двух часов в день. На тест-кейсы «из головы» время при таком подходе не тратится, так как они в итоге сформируются по ходу восстановления документации.

2. Ключевые методы и функциональность описывает QA-лид. Тем не менее не оставляем попытки заполучить на проект аналитика, напоминая о потребности менеджеру проекта и подсвечивая проблемы на встречах.

3. При таком подходе мы не избегаем общения с продакт оунером. Просто фиксируем всё услышанное и передаём на оценку менеджеру проекта. Главное, чтобы сам продакт оунер был согласен на общение с QA без аналитика.

После ознакомления с продуктом QA составляет чек-лист его проверки. За основу берёт здравый смысл и набор критичной функциональности — этот список помогает составить продакт-менеджер. Обкатали чек-лист на тестировании, продакт-менеджер сделал ревью — QA начинает писать тест-кейсы с более подробными сценариями. Подключает разработчиков — как консультантов и источник информации. Составляет подробный тест-кейс для проведения регресса.

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

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

Настя Корень, QA-инженер red_mad_robot

А какой подход в работе используете вы? Расскажите в комментариях. 

Над материалом работали:
текст — Маша Кузнецова,
редактор — Виталик Балашов,
иллюстрации — Юля Ефимова.

Делимся железной экспертизой в телеграм-канале red_mad_dev. 

Обсудить в форуме