Мне нужна твоя одежда, сапоги и требования к проекту. Тестирование требований для начинающих

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

Требования – это любое условие, которому должен соответствовать конечный продукт, все его возможности, ограничения и логика системы. Они создаются в процессе проработки задания на разработку/модернизацию программного обеспечения.

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

Функциональные требования описывают, что должна делать система. Они включают в себя:

1. Бизнес-требования;
2. Функциональные требования;
   
3. Пользовательские требования;
   
4. Системные требования.
   

Нефункциональные требования описывают, как именно должна работать система и почему. Они включают в себя:

1. Бизнес-правила;
2. Правила взаимодействия с внешними интерфейсами;
   
3. Метрики качества;
   
4. Ограничения.
   

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

Требования можно искать в различных источниках:

1. Проектная документация;
2. Заказчик и Заинтересованные лица;
   
3. Сегмент рынка бизнеса, схожие проекты;
   
4. Эксперты в отрасли;
   
5. Интернет и СМИ;
   
6. Законодательство;
   
7. Логика и здравый смысл;
   
8. Жизненный и профессиональный опыт;
   
9. Коллеги и профессиональное комьюнити.

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

Варианты фиксации требований:

1. ТЗ, спецификации;
2. Схемы, прототипы, макеты, матрицы, mind-карты;
   

3. Записи разговоров в Skype или другом мессенджере;

4. E-mail, сообщения;
5. Тест-кейсы, юзер-стори;
   
6. Confluence, Wiki или другие базы знаний;
   
7. Задачи в трекере, в котором работает команда;
   
8. Системы TestLink, TestRail и другие.
   

Ура! Требования собраны, что дальше? Требованиями необходимо управлять, для того, чтобы получить от них максимальную пользу для проекта.

Управление требованиями - процесс, включающий в себя:

1. Управление версиями (идентификация версий, отслеживание версий отдельных требований, отслеживание версий наборов требований);

2. Управление изменениями (предложение изменений, анализ влияния изменений на систему, принятие решений, обновление отдельных требований, обновление набора требований, обновление планов, оценка изменчивости требований);

3. Отслеживание состояния требований (определение возможных состояний требований, фиксирование состояний каждого требования, отслеживание состояния распределения требований);

4. Отслеживание связей требований (определение связей с другими требованиями, определение связей с другими элементами системы).

Очень интересно, конечно, но каким образом проводить это тестирование требований? Ниже я приведу примерный план тестирования, старайтесь работать с каждым из пунктов максимально глубоко.

План тестирования требований:

1. Погружение в задачу/предметную область. Просмотр макетов, дизайна, вычитка пунктов ТЗ, сбор информации по задаче.
2. Задавайте вопросы. Задавайте их коллегам, представителям заказчика, членам своей команды, всем, кто причастен к системе.
   
3. Декомпозируйте требования и составляйте чек-листы, тест-кейсы, юзер-стори. Это позволит выявить упущения в требованиях.
   
4. Исследуйте поведение системы.
   
5. Составляйте схемы, mind-карты. Графическое представление дает наглядное представление о системе.
   

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

1. Единичность: одно требование – один функционал.

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

Как тестировать требование на единичность? Задать себе вопрос: “Сколько свойств заложено в требовании?”

2. Атомарность: требование нельзя разбить на более мелкие части, требование нельзя уточнить.

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

Как тестировать требование на атомарность? Разбейте требование на части. Если получилось – требование не обладает атомарностью.

3. Завершенность: требование целиком приведено в одном месте документации.

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

Как тестировать требование на завершенность? Внимательно прочитать документацию, отметить повторы требований.

4. Последовательность: требование не должно противоречить другим требованиям и ограничениям системы.

Пример допустимого требования: когда пользователь снимает трубку, телефон должен издавать гудок. Пример требования с нарушенной характеристикой: Когда пользователь снимает трубку, телефон должен издавать гудок. Когда активен режим «без звука», телефон не должен издавать никаких звуков.

Как тестировать требование на последовательность? Поможет прототипирование, составление схем требований, матрица трассировки (связи требований).

5. Отслеживаемость (трассируемость): требование зафиксировано в документации и можно понять откуда оно взялось.

Пример допустимого требования: при открытии каталога алкогольной продукции, на сайте должно открываться всплывающее окно о подтверждении допустимого возраста пользователя 18+ (согласно требованию Российского законодательства).
Пример требования с нарушенной характеристикой: приложение по доставке пиццы не должно быть доступно для скачивания детям до 16 лет.

Как тестировать требование на трассируемость? Поможет прототипирование, матрица трассировки (связи требований). Изучение законодательства. Уместно задать вопрос аналитику по поводу возникновения того или иного требования.

6. Актуальность: требование не устарело, оно соответствует современному законодательству или техническим реалиям.

Пример допустимого требования: приложение должно работать в ОС Windows не ниже 7.
Пример требования с нарушенной характеристикой: приложение должно работать на OC Android 2.0

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

7. Выполнимость: требование можно выполнить в рамках существующих технологий.

Пример допустимого требования: приложение должно загружаться на ПК пользователя за 3 секунды. Пример требования с нарушенной характеристикой: игра должна загружаться за 0,1 миллисекунду.

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

8. Понятность: требование должно пониматься всеми одинаково.

Пример допустимого требования: поле ввода “Номер телефона” имеет маску на ввод, которая позволяет вводить в поле только цифры от 0 до 9. Пример требования с нарушенной характеристикой: поле заполняется допустимыми символами.

Как тестировать требование на понятность? С помощью вопросов, исследования системы. Можно поставить себя на место пользователя и спросить себя: “как я понимаю данный термин или определение?”

9. Проверяемость: выполнение требования можно измерить или проверить, исходя из определенных и заданных критериев.

Пример допустимого требования: карточки в каталоге товара должны отображаться в виде таблицы. В каждой ячейке таблицы отображается превью товара. Пример требования с нарушенной характеристикой: сайт должен иметь удобную навигацию. Как тестировать требование на проверяемость?

Составьте чек-лист или тест-кейс – какой ожидаемый результат у вас получается, какими средствами вы измерите успешность или провальность тест-кейса?

10. Обязательность: без выполнения этого требования пользователь не сможет в полной мере использовать систему.

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

Как тестировать требования на обязательность? Сопоставлять требования, задавать вопросы, строить схемы и проверять связи.

11. Полнота: требования описаны исчерпывающим образом.

Пример допустимого требования: для ввода в поле доступны только буквы русского алфавита и пробел. Остальные символы ввести нельзя. Ввод не может начинаться с пробела, только с буквы. Регистр не имеет значения. Ограничения на ввод: минимум 2 максимум 160 символов. Поле обязательно для заполнения. Приходит в состояние ошибки при потере фокуса без заполнения, при отправке пустого поля и при вводе количества символов меньше минимального. Снятие ошибки происходит при вводе значения, соответствующего маске ввода и валидации.

Пример требования с нарушенной характеристикой: для ввода в поле доступны только буквы. Ограничения на ввод: минимум 2 символа. Поле обязательно для заполнения. Приходит в состояние ошибки при потере фокуса без заполнения, при отправке пустого поля и при вводе количества символов меньше минимального.

Как тестировать требования на полноту? После ознакомления с требованиями, у вас не должно остаться вопроса “а что если?”.

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

1. Стандартный шаблон задачи/спецификации;
2. Флоу разрешения противоречий в требованиях (Кто хранитель задачи? За кем последнее слово?);
   
3. Тестирование требований как отдельный этап флоу разработки;
   
4. Документация/Схема работы;
   
5. Обсуждение (приложенные задачи, ссылки на обсуждения и т.д.);
   
6. Макеты на каждое состояние/анимацию;
   
7. Чек-листы приемки макета/задачи;
   
8. Публичные чек-листы тестирования для типовых задач;
   
9. Чек-лист составленный до разработки;
   
10. Брендбук;
    
11. Взгляд человека со смежного проекта, опыт коллег;
    
12. DOD (Definition Of Done).
    

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