Как MoSCoW помогает в тестировании. Что случится, если мы это не проверим?

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

Статья будет интересна тестировщикам тем что поможет научиться расставлять приоритеты в тест-кейсах. Продуктовые менеджеры и владельцы продуктов (РО) поймут, как согласовывать с QA приоритеты фич. Разработчики узнают какие части системы требуют особого внимания QA. Scrum-мастера увидят, как интегрировать MoSCoW в спринты, чтобы балансировать между скоростью и качеством. 

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

________________________________

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

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

Мы попробуем разобрать такие ситуации и посмотреть, как тестировщику не стать крайним при сдаче проекта в сжатые сроки.

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

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

Глубинные причины сжатия сроков, условно, можно разделить на 2 типа: внешние и внутренние. 

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

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

Внутренние — причины, которые повлияли на разработку внутри конкретной команды.

• Ошибки планирования. Задача: на разработку было запланировано 2 недели. на тестирование - 2 недели, на аналитику - 2 недели. Вопрос: сколько времени на самом деле останется на тестирование ? Ответ: на сколько сможет договориться тестировщик. Потому что аналитик оценил правильно. А разработка сделала код за 3.5 недели. Остается 0.5 недели на тестирование. Но здесь есть нюанс: сколько времени на тестирование - такое и качество продукта.  
• Человеческий фактор. Дизайнер неожиданно ушел в декрет. И теперь в команде новый дизайнер, который вместо 1 недели, делает макет за 2 недели.
• Agile-подходы. Спринты сокращаются ради «быстрых побед», но тестирование остается за кадром. Команды смещают фокус на скорость, а не качество («выпустим сейчас, пофиксим потом»).

Последствия для тестирования

• Риск пропуска критических багов из-за сокращения времени на проверку. В условиях сокращения времени на проверки тестировщик вынужден ограничиваться проверкой по чек-листу.
• Рост нагрузки на QA: необходимость работать в режиме «тушения пожаров». Для такого сценария характерен отказ от документирования тест-кейсов (под предлогом «Нет времени»), что впоследствии приведет к потере базы знаний для последующих релизов.
• Конфликты между командами: разработчики vs тестировщики («Вы тормозите релиз!»). Команда разработчиков требует закрыть глаза на мелкие баги, хотя  QA настаивает на качестве. Это ведет к росту напряжения между членамии команды.
• Эмоциональное выгорание из-за постоянного давления. «Режим тушения пожаров» и многозадачности ведет к снижению концентрации тестировщика.

Как побороться за качество продукта ?

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

Метод MoSCoW.

Метод MoSCoW разработан в 1994 году британским экспертом в области управления проектами Дай Клеггом в рамках методологии DSDM (Dynamic Systems Development Method) — одного из ранних Agile подходов к разработке. Изначально он создавался для IT-проектов с жесткими сроками, но позже стал универсальным инструментом приоритизации.

MoSCoW — это техника категоризации задач по приоритетам. Название — акроним четырех категорий:

• Must have — обязательно к реализации (без этого проект провалится).
• Should have — важно, но не критично (можно отложить, если не хватает времени).
• Could have — желательно, но не обязательно (улучшения, которые не влияют на базовую функциональность).
• Won’t have — не входит в текущий релиз (откладывается на будущее).

Для просмотра категорий будем опираться на условную фичу «Покупки ценных бумаг». 

К категорий Must have (обязательно к реализации) относят сценарии и функциональность, без которых разрабатываемое ПО не будет работать в принципе. Реализация функционала напрямую зависит и влияет на достижение цели проекта. Или дефект в этой части приложения приведет к блокировке релиза и/или потере денег.  Проще всего определить такие сценарии, легко задав вопрос: «Что случится, если это не будет готово?» Если ответ: «Проект провалится» → Must have. Для нашей условной фичи такими сценариями могут быть то, без чего покупка бумаги невозможна: например выбор ценной бумаги, ввод суммы/количества денег, интеграция с биржами. Без этих элементов пользователь не сможет купить желаемые бумаги.

К категорий Should have (важно, но не критично) можно отнести функциональность, которая существенно улучшает пользовательский опыт для клиента, но при этом для клиента есть обходные пути. По сути проблема в этой части ПО вызовет неудобства, но не остановит работу системы. Спросите: «Можно ли выпустить продукт без этого, но с временными ограничениями?» Если «Да» → Should have. Для фичи с покупкой ценных бумаг к такому функционалу относится: Уведомления о статусе (например нет пуш-уведомления при успехе), аналитика перед покупкой (нет данных о бумагах для пользователя, графиков например).

К категорий  Could have (желательно, но не обязательно) выбирают функциональность, отсутствие которой не заметит большинство пользователей. Удобство или «фишки», которые не повлияют на базовую функциональность. Определить такое просто, задайте вопрос: «Что произойдет, если мы добавим это позже?» Если ответ: «Ничего критичного» → Could have. В рамках покупки бумаг такими особенностями могут быть: рекомендации, справочная информация, какие-нибудь социальные фичи.

Категория Won’t have (не входит в текущий релиз) относят фичи в ПО, которые не соответствуют текущим целям или требуют слишком много ресурсов. Или «хотелки» отдельных членов команды без четкой ценности для бизнеса. Спросите: «Есть ли у этого функционала измеримая польза прямо сейчас?» Если «Нет» → Won’t have. Для покупки бумаг: советы AI, мультиязычная поддержка. Подводя итог можно собрать все воедино:

Метод MoSCoW стал особенно популярен в Scrum и Agile-практиках благодаря своей гибкости. Например, в спринте команда берет задачи из «Must have» и «Should have», а «Could have» — только если останется время.

Итог

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

Тестировщик начинает с совместной с командой декомпозиции фич, выделяя ключевые сценарии, которые напрямую влияют на работоспособность продукта. Каждый тест-кейс категоризируется на основе бизнес-рисков: если баг в определенной части системы может заблокировать релиз или навредить репутации компании — это однозначно Must have. 

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

Однако MoSCoW не лишён недостатков. Субъективность в оценке приоритетов может привести к разногласиям: например, разработчики считают валидацию полей Should have, а тестировщики настаивают на Must have. Кроме того, метод слабо учитывает нефункциональные аспекты, такие как производительность или безопасность, которые иногда оказываются критичными.

Несмотря на ограничения, MoSCoW остаётся эффективным способом управления тестированием в условиях сжатых сроков. Его сила — в гибкости: категории можно пересматривать после обратной связи пользователей или изменений в требованиях. Главное — помнить, что цель метода не в строгой классификации, а в умении отвечать на вопрос: «Что сломает продукт, если мы это не проверим?».