Требования к ПО: что проверяет тестировщик

Тестирование требований

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

Требования — это описание того, что должен представлять из себя IT-продукт. Они могут быть изложены в составе Технического задания, а могут – в виде Пользовательских историй (User Story).

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

1. Атрибут «Корректность»

Корректность — это логичное описание запланированных функций или других свойств ПО.

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

Проверяется с помощью формальной логики и/или здравого смысла.

2. Атрибут «Проверяемость»

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

Пример ошибки: Проверить, что к веб-приложению можно подключиться из любой точки Земли – практически невозможно (очень дорого).

Анализируется путем составления пробного тест-плана и оценкой ресурсов на его выполнение.

3. Атрибут «Полнота»

Полнота — это содержание всей необходимой информации, нужной для реализации ПО.

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

Проверяется составлением пробной версии чек-листа.

4. Атрибут «Однозначность»

Однозначность — это единообразное понимание формулировок.

Пример ошибки: Формулировка «Отчет о продажах должен иметь детализацию по календарным периодам» не дает понимания, что за календарные периоды имеются в виду: годы, кварталы, месяцы, недели, дни?

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

5. Атрибут «Непротиворечивость»

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

Пример ошибки: Требования к игре «Персонаж имеет параметр Живучесть, который выражается натуральными числами и на старте игры имеет значение 1» и «Пользователь может надеть на персонаж шлем, который увеличивает его Живучесть на 10%». Что будет, когда персонаж с живучестью 4 наденет шлем? Чему будет равна его живучесть – 4 или 5? В какую сторону следует округлять?

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

6. Атрибут «Приоритетность»

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

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

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

7. Атрибут «Атомарность»

Атомарность — это целиковость требования (нельзя разбить на отдельные элементы без потери важной информации).

Пример ошибки: «Поле Код вмещает 3 символа и может растягиваться, при этом кнопка Старт должна оставаться в прежнем размере» – описаны сразу 2 объекта (и при этом в терминах разных характеристик).

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

8. Атрибут «Модифицируемость»

Модифицируемость — это принципиальная возможность вносить изменения в требования.

Пример ошибки: При заказе мужского варианта одежды в бланке заказа указывается обращение «Г-н», при заказе женского – «Г-жа», это поле затем не меняется. Однако, могут быть женщины, которые считают предпочтительнее мужской вариант. И если производитель выпустит еще один вариант одежды «Унисекс» – то по какому правилу будет работать это требование?

Проверяется анализом возможностей масштабируемости ПО.

9. Атрибут «Прослеживаемость»

Прослеживаемость — это наличие уникального идентификатора у каждого требования.

Пример ошибки: Требования не разбиты на разделы, идут сплошным текстом.

Проверяется визуальной проверкой: каждое требование должно быть с идентификатором.

Резюме

Есть 9 основных атрибутов требований. Тестировщику следует их проанализировать как можно раньше, чтобы предотвратить дефекты ПО, вытекающие из некачественно сформулированных требований.