Процесс работы с требованиями в тестировании: чек-лист, когда пора что-то менять

Вы тестировщик и чувствуете, как страдает работа на проекте? Понимаете, что неразбериха наступает из-за хаотичного отношения к требованиям? В этой небольшой статье мы собрали несколько советов о том, как правильно работать с требованиями, а также чек-лист проверки того, пора ли что-то менять.
Сперва определитесь точно, нужно ли что-то менять в вашем проекте. Ведь все проекты разные, и единого пути нет. Как это сделать? Воспользуйтесь нашим чек-листом! Если совпадет хотя бы 3 пункта, пора действовать.
Чек-лист возможных проблем на проекте по тестированию:
1. У заказчика никогда нет времени, чтобы сформулировать или согласовать требования.
2. Команда не может напрямую взаимодействовать с пользователями.
3. Нет приоритетов у требований. Для заказчика одинаково важно всё.
4. У команды тестировщиков много вопросов по требованию в процессе работы. Приходится много раз переписывать тестовые сценарии и код, тратить на это время.
5. Заказчики придумывают задачи в отрыве от потребностей пользователя.
6. Заказчик вносит изменения в требования после их согласования.
7. Постоянно откладываются сроки релиза – добавляют новые требования.
8. Функции, которые попросил заказчик, конечному пользователю не нужны, и поэтому не используются.
9. Пользователи не удовлетворены функционалом ПО.
Что же делать, если вы узнали в этих пунктах свой случай? Наладить процесс рецензирования требований до старта проекта. Для этого есть два варианта.
Первый: как только спецификация написана, ее передают на проверку экспертам, чтобы пункты из чек-листа выше не появлялись в процессе работы.
Плюсы этого варианта:
1. Можете быть уверены, что в процесс разработки и тестирования выйдет уже проверенная, «стабильная» версия документа.
2. Можно погрузиться глубже и учесть неявные требования, потому что весь фокус будет только на рецензировании.
3. Стабильность позволяет лучше контролировать сроки и бюджеты.
Минусы:
1. Высокая степень ответственности тех, кто проверяет (рецензентов). Если в процессе работы найдут ошибки, то спрашивать будут с вас.
2. Нужно очень хорошо разбираться в предметной области, технических аспектах.
3. Нужно выделять время и бюджет на эту задачу. Заказчикам будет сложно объяснить, зачем им тратить все это на рецензирование.
Поэтому многие выбирают второй вариант – рецензировать требования в процессе разработки.
Плюсы:
1. Не надо отдельно выделять время на рецензирование. Вся команда работает над одним блоком функциональности, и вопросы решаются быстро.
2. К рецензированию меньше требований – все равно бОльшая часть ошибок будет найдена разработчиками и тестировщиками.
Минусы:
1. Приходится запоминать много информации, например, как что работает в чужом модуле.
2. Частые переключения между видами активностей: то писать тесты, то прочитать документацию, с кем-то связаться и т.п.
3. Очень высокая стоимость внесения изменений. Когда ошибка только найдена, нужно просто ее исправить. Но если какая-то функциональность уже выпущена на прод, то исправлять придется все этапы.
Что ж, есть ли метод, который объединит плюсы рецензирования до разработки и после начала процесса разработки? Да! И это «метод набегающей волны»
(Rolling Wave Planning).
Чем волна дальше, тем она меньше. Чем ближе, тем больше. Так и в этом методе: перед началом разработки мы делаем высокоуровневую проверку, не углубленную. А вот перед началом проверки какого-либо конкретного модуля уже проводим анализ моделей, ищем ошибки в требованиях. То есть больше детализируем. И в конце, перед началом итерации, тестируем требования через разработку тестовой документации. Так мы снижаем риск ошибок и уменьшаем затраченное время.
Нужен простой пример? Возьмем путешествие. Сначала вы планируете шаги: сделать загранпаспорт, получить визу, прививку, купить билеты, забронировать жилье. Потом увеличиваете количество задач: сделать загранпаспорт – это заполнить заявление, оплатить пошлину, съездить в такое-то учреждение или зарегистрироваться на определенном сайте. Получить визу – это также заполнить заявление, сделать фото, выписки по счету, сдать биометрию и т. д.
Так же переходить к задачам нужно будет и на проекте в тестировании.
Надеемся, что вам помог наш чек-лист, а перечисленные методы подтолкнули к тому, чтобы изменить процессы к лучшему. И пускай каждая команда тестировщиков выстроит идеальный процесс работы с требованиями!
Остались вопросы? Чувствуете, что вашей команде не хватает структурированной информации? Интересно узнать весь процесс работы с требованиями от начала до конца?
Записывайтесь на наш курс Тестирование без требований: выявление и восстановление информации о продукте. Старт 21 марта!