Автор: Ханиша Арора (Hanisha Arora)
Оригинал статьи
Перевод: Ольга Алифанова

Тестирование программного обеспечения — это не только поиск багов, но и их предотвращение. Случалось ли вам смотреть на требование и думать: «вроде всё нормально»? А затем, спустя несколько недель, наблюдать, как код по этому требованию превращается в баг-репорт, часы доработок или недовольство стейкхолдера? Это знакомо не только вам.

Именно поэтому была создана модель ревью требований (Requirements Review Model, RRM): чтобы дать тестировщикам и командам простой и единый подход к ревью. Это помогает повышать качество ещё до того, как написана хоть одна строка кода.

Модель была создана для сертификата Software Testing Essentials от Ministry of Testing (MoT), чтобы обучать тестировщиков-новичков ревью требований. В MoT решили, что будет полезно поделиться моделью со всеми, за пределами сертификата, и поддержать тестировщиков и их команды. Это соответствует их цели — развивать индустрию любыми позитивными способами. Поэтому и написана эта статья!

Используя эту модель, можно научиться:

• Находить неясные или рискованные требования до того, как они приведут к проблемам
• Задавать правильные вопросы, чтобы повысить ясность и уменьшить количество допущений
• Выявлять риски и возможности для тестирования, чтобы вносить вклад в повышение качества ПО

Будем честны, уточнение требования обычно занимает несколько минут, максимум час. А исправление бага, вызванного размытым требованием? Это уже совсем другая история. Часы? Дни? В любом случае это занимает больше времени, чем улучшение требования. В целом, чем позже в жизненном цикле разработки обнаруживаются баги, тем дороже их исправление.

Модель ревью требований (RRM) в целом

Модель включает четыре шага:

1. Start – читайте с любопытством

Перед тем как углубляться в детали, разберитесь с контекстом. Какую проблему пытается решить это требование? Кого это затрагивает? Если непонятно «почему», невозможно глубоко тестировать или проявлять эмпатию к пользователям.

Читайте требование, включив мышление тестировщика.

• Что бросается в глаза?
• Какие допущения в нём есть?
• Не кажется ли что-то слишком упрощённым?
• Есть ли расплывчатые слова, такие как "может" или "должен"?
• Чётко ли определён и понятен объём требования?

1. Spot – выявляйте пробелы, риски и возможности для тестирования

Теперь углубитесь. Чего не хватает? Что может пойти не так?

• Учитывайте разные точки зрения и потребности пользователей:
  • Позитивный сценарий прост, но что насчёт негативного или граничных случаев?
  • Как с этим будет взаимодействовать новый пользователь, нетерпеливый пользователь или злоумышленник?
• Ищите риски и ограничения
• Задавайте вопросы:
  • Что может сломаться?
  • Может ли пользователь повторно использовать старый пароль?
  • Есть ли ограничение на количество попыток сброса пароля, чтобы предотвратить злоупотребления?
  • Какие меры безопасности предусмотрены при сбросе пароля?
  • А как насчёт производительности, соответствия требованиям, технических ограничений?

1. Turn – превращайте идеи в сценарии и тесты

Возьмите эти вопросы, риски и идеи и преобразуйте их в сценарии и тесты.

• Что можно попробовать?
• Какие тесты можно разработать?
• Какие чартеры тестирования можно создать?
• Есть ли необходимые возможности для выполнения этих тестов?

1. Apply – действуйте

Тестирование — это не одиночная работа. Используйте полученные выводы на практике:

• Поднимайте вопросы на сессиях уточнения требований
• Предлагайте изменения до начала разработки
• Выстраивайте стратегию тестирования на основе найденного

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

Применение модели ревью требований на практике

Это не просто теория. Вот как это работает на практике:

Понимание контекста

Какую проблему должно решить это требование? Кого оно затрагивает? Если непонятно «почему», тестирование идет вслепую.

Пример: «Пользователи могут загружать аватар». Зачем нужна эта функция? Для персонализации? Для идентификации? Цель требования влияет на то, насколько строгими или гибкими должны быть правила.

Поиск неоднозначностей

Размытые требования приводят к размытым реализациям.

«Система должна позволять загружать изображения высокого качества».

Хорошо. Но какое максимальное качество изображения? Какой максимальный размер файла?

Оспаривайте расплывчатые формулировки до того, как они приведут к реальным проблемам.

Думайте как пользователи

Позитивный сценарий прост. А что с граничными случаями?

• Что будет, если пользователь загрузит огромный файл?
• Что будет, если он использует только клавиатуру?
• Что будет, если пользователь с медленным интернетом попытается загрузить файл?
• Что будет, если кто-то попытается загрузить вредоносный файл?

Ищите риски и ограничения

Оцените, добавляет ли требование риск или снижает его. Проверьте, есть ли правила, которые нужно протестировать.

• Нужна ли модерация контента?
• Что произойдёт, если на сервере закончится место?
• Могут ли пользователи удалять или менять свои аватары?

Проверяйте, сотрудничая

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

Если в требовании сказано: «Пользователи могут загружать изображения размером до 5 МБ», обсудите это с командой:

• 5 МБ — это слишком много или слишком мало?
• Нужно ли оптимизировать изображения для производительности?
• Нужен ли запасной вариант, если загрузка не удалась?

Эта модель превращает размытые требования в хорошо протестированные фичи ещё до написания кода.

Типичные сложности при ревью требований

«На это нет времени».

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

«Требование выглядит нормально».

Нормально для кого? Если два человека понимают требование по-разному, значит, оно непонятное.

«Тестировщики не отвечают за требования».

Верно, но именно тестировщики играют ключевую роль в выявлении рисков. Чёткие требования ведут к улучшению тестов. Лучше тесты — лучше покрытие. Лучшее покрытие предотвращает проблемы в продакшене.

«Разработчики разберутся».

Возможно. А возможно — сделают допущение, которое позже приведёт к проблеме. Зачем оставлять это на волю случая?

Заключение

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

• Находить проблемы до того, как они станут багами
• Экономить время, предотвращая дорогостоящие доработки
• Улучшать взаимодействие и стимулировать более качественные вопросы

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

Дополнительная информация

• Learn to do requirement review better, MoT Club post by @amacormack
• Reviewing Requirements Documents, Bob Salmon
• Best Practices QA Managers Should Implement When Reviewing Requirements, Ajay Balamurugadas
• How do you manage testing ambiguity? - LinkedIn community article
• What are the best practices for dealing with ambiguous or incomplete requirements and specifications? - LinkedIn community article