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

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

Сперва определитесь точно, нужно ли что-то менять в вашем проекте. Ведь все проекты разные, и единого пути нет. Как это сделать? Воспользуйтесь нашим чек-листом!  Если совпадет хотя бы 3 пункта, пора действовать.

Чек-лист возможных проблем на проекте по тестированию:

1.     У заказчика никогда нет времени, чтобы сформулировать или согласовать требования.

2.      Команда не может напрямую взаимодействовать с пользователями.

3.     Нет приоритетов у требований. Для заказчика одинаково важно всё.

4.     У команды тестировщиков много вопросов по требованию в процессе работы. Приходится много раз переписывать тестовые сценарии и код, тратить на это время.

5.     Заказчики придумывают задачи в отрыве от потребностей пользователя.

6.    Заказчик вносит изменения в требования после их согласования.

7.     Постоянно откладываются сроки релиза – добавляют новые требования.

8.     Функции, которые попросил заказчик, конечному пользователю не нужны, и поэтому не используются.

9.     Пользователи не удовлетворены функционалом ПО.

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

Плюсы этого варианта:

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

2.     Можно погрузиться глубже и учесть неявные требования, потому что весь фокус будет только на рецензировании.

3.     Стабильность позволяет лучше контролировать сроки и бюджеты.

Минусы:

1.     Высокая степень ответственности тех, кто проверяет (рецензентов). Если в процессе работы найдут ошибки, то спрашивать будут с вас.

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

3.     Нужно выделять время и бюджет на эту задачу. Заказчикам будет сложно объяснить, зачем им тратить все это на рецензирование.

Поэтому многие выбирают второй вариант – рецензировать требования в процессе разработки.

Плюсы:

1.     Не надо отдельно выделять время на рецензирование. Вся команда работает над одним блоком функциональности, и вопросы решаются быстро.

2.     К рецензированию меньше требований – все равно бОльшая часть ошибок будет найдена разработчиками и тестировщиками.

Минусы:

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

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

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

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

Нужен простой пример? Возьмем путешествие. Сначала вы планируете шаги: сделать загранпаспорт, получить визу, прививку, купить билеты, забронировать жилье. Потом увеличиваете количество задач: сделать загранпаспорт – это заполнить заявление, оплатить пошлину, съездить в такое-то учреждение или зарегистрироваться на определенном сайте. Получить визу – это также заполнить заявление, сделать фото, выписки по счету, сдать биометрию и т. д.

Так же переходить к задачам нужно будет и на проекте в тестировании.

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

Остались вопросы? Чувствуете, что вашей команде не хватает структурированной информации? Интересно узнать весь процесс работы с требованиями от начала до конца?