В аутсорс-разработке встречаются проекты, где вместо чётких требований у заказчика есть только идея и описание того, как должны работать основные бизнес-процессы. А ещё «горящие» сроки. И вообще зарелизить всё нужно было «ещё вчера». Выдержать высокое качество продукта в таких условиях непросто, но возможно.

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

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

Почему отсутствие чётких требований к продукту — проблема

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

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

Неэффективное использование ресурсов. Представления о конечном продукте со временем меняются. Команда может реализовать и полностью проверить модуль, от которого заказчик впоследствии откажется.

Неопределённость критериев качества и трудности в его оценке. Без чётких требований у QA-команды нет представления, какие критерии должны быть соблюдены, чтобы продукт считался качественным. При тестировании она будет исходить из своей логики и экспертизы, которые могут отличаться от логики и экспертизы заказчика. Впоследствии это затруднит оценку, насколько продукт соответствует ожиданиями.

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

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

Как снизить неопределённость: погружаемся в цели и контекст

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

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

Анализируем целевой аудитории. Изучение ЦА нужно, чтобы понять, как будет мыслить человек при использовании приложения. Это поможет выстроить основные пользовательские сценарии и предугадать негативные кейсы. А также узнать, какими девайсами в основном пользуются юзеры, и сфокусировать силы отдела тестирования на конкретных устройствах. При анализе можно опираться на приложения конкурентов, так как делить аудиторию предстоит именно с ними.

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

Как тестировать: внедряем гибкие методологии

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

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

Исследовательское тестирование

Исследовательское тестирование (Exploratory Testing) — это творческий подход к тестированию программного обеспечения, при котором тестировщик одновременно разрабатывает, выполняет и анализирует тесты. Метод не требует предварительного создания формализованных тестовых сценариев, что позволяет быстро адаптироваться к изменениям и обнаруживать дефекты, которые могут быть пропущены при использовании традиционных методик.

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

Основные плюсы подхода:

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

• Быстрое начало тестирования. Подход не предполагает предварительную подготовку документации или тестовых сценариев. Увеличивает скорость работы.

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

• Повышение мотивации QA-команды. Подход не сковывает тестировщиков документацией — специалисты предоставлены себе, пробуют и реализуют больше идей. Это повышает мотивацию и вовлечённость в проект.

• Экономия ресурсов и ускорение разработки. Время, которое могло быть потрачено на составление документации, идёт на непосредственное тестирование продукта. В условиях сжатых сроков это особенно важно.

Lean testing

Lean testing — системный подход к тестированию продукта, который фокусируется на оптимизации процессов тестирования. В его основе лежит принцип «делать больше с меньшим», который подразумевает устранение ненужных шагов и постоянное улучшение рабочего процесса тестирования.

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

Основные плюсы подхода:

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

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

Снижение затрат. Благодаря устранению неинформативных или нерезультативных частей документации Lean Testing снижает общую стоимость разработки продукта.

Как выстроить работу с другими командами: налаживаем взаимодействие

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

Регулярные встречи. Например, в формате ежедневных стендапов, на которых команда делится прогрессом и обсуждает основные сложности. Это помогает добиться единого понимания задач всеми участниками команды и расставить приоритеты. При работе по Agile важны встречи в начале и в конце спринтов. Они позволяют обсудить планы на ближайшие итерации и проанализировать прошедшие этапы, выявить зоны для улучшения.

Использование общих инструментов. Применение общих инструментов вроде JIRA или Asana позволяет всем участникам видеть текущие задачи, статусы и прогресс. Это уменьшает количество недопонимания и облегчает взаимодействие.

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

Коротко о главном

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