Первое, что должен сделать любой грамотный QA-специалист, при заходе на
новый проект, это попросить к ознакомлению требования проекта. И чем раньше, тем лучше. Однако, не все умеют с этими требованиями работать, тестировать их эффективно и быстро, и эта статья как раз об этом.
Что такое требования и какими они бывают?
Требования – это любое условие, которому должен соответствовать конечный продукт, все его возможности, ограничения и логика системы. Они создаются в процессе проработки задания на разработку/модернизацию программного обеспечения.
Требования делятся на функциональные и нефункциональные, а также на явные и неявные (самые коварные). Причем, неявные требования необходимо переводить в явные, так как определения неявных требований нигде не прописаны, а значит их наличие чревато разночтениями и недопониманиями внутри команды, из-за чего, в будущем разработка может столкнуться с проблемами.
Функциональные требования описывают, что должна делать система. Они включают в
себя:
1. Бизнес-требования;
2. Функциональные требования;
3. Пользовательские требования;
4.Системные требования.
Нефункциональные требования описывают, как именно должна работать система и
почему. Они включают в себя:
1. Бизнес-правила;
2. Правила взаимодействия с внешними интерфейсами;
3. Метрики качества;
4. Ограничения.
Что делать QA-специалисту, если требований нет или почти нет?
В случае если Вам не повезло и требования на проекте не отвечают необходимым
критериям, а может быть их и вовсе нет, то нам необходимо вовремя обнаружить
проблему с требованиями и взяться за ее решение.
Требования можно искать в различных источниках:
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-карты. Графическое представление дает наглядное представление о системе.
На что обращать внимание при тестировании: 11 элементов качества
Есть набор основных характеристик, которыми должна обладать хорошая документация. Характеристики качества требований по-разному определены различными источниками, однако, следующие характеристики являются общепризнанными:
Единичность: одно требование – один функционал.
✅ Пример допустимого требования |
❗️ Пример требования с нарушенной характеристикой |
В требовании обозначено одно действие системы – регистрация пользователей. |
Система должна позволять авторизацию пользователей по данным социальных сетей, запрашивать из социальных сетей и публиковать на стене пользователя в социальной сети определенную информацию. |
Как тестировать требование на единичность?
Задать себе вопрос: “Сколько свойств заложено в требовании?”
Атомарность: требование нельзя разбить на более мелкие части, требование нельзя уточнить.
✅ Пример допустимого требования |
❗️ Пример требования с нарушенной характеристикой |
В поле “Перевести на счет” пользователь может выбрать только рублевые счета. |
Пользователь может выбрать для чтения статью, прокомментировать ее и поставить оценку. |
Как тестировать требование на атомарность?
Разбейте требование на части. Если получилось – требование не обладает атомарностью.
Завершенность: требование целиком приведено в одном месте документации.
✅ Пример допустимого требования |
❗️ Пример требования с нарушенной характеристикой |
В функционале, описывающем регистрацию: “для завершения регистрации пользователь должен ввести капчу”. Больше это требование не встречается нигде в документации. |
В функционале, описывающем регистрацию: “для завершения регистрации пользователь должен ввести капчу”. В функционале, описывающем требования к безопасности: “для регистрации пользователь должен ввести индивидуальную капчу”. |
Как тестировать требование на завершенность?
Внимательно прочитать документацию, отметить повторы требований.
Последовательность: требование не должно противоречить другим требованиям и ограничениям системы.
✅ Пример допустимого требования |
❗️ Пример требования с нарушенной характеристикой |
Когда пользователь снимает трубку, телефон должен издавать гудок. |
Когда пользователь снимает трубку, телефон должен издавать гудок. Когда активен режим «без звука», телефон не должен издавать никаких звуков. |
Как тестировать требование на последовательность?
Поможет прототипирование, составление схем требований, матрица трассировки (связи требований).
Отслеживаемость (трассируемость): требование зафиксировано в документации и можно понять откуда оно взялось.
✅ Пример допустимого требования |
❗️ Пример требования с нарушенной характеристикой |
При открытии каталога алкогольной продукции, на сайте должно открываться всплывающее окно о подтверждении допустимого возраста пользователя 18+ (согласно требованию Российского законодательства). |
Приложение по доставке пиццы не должно быть доступно для скачивания детям до 16 лет. |
Как тестировать требование на трассируемость?
Поможет прототипирование, матрица трассировки (связи требований). Изучение законодательства. Уместно задать вопрос аналитику по поводу возникновения того или иного требования.
Актуальность: требование не устарело, оно соответствует современному законодательству или техническим реалиям.
✅ Пример допустимого требования |
❗️ Пример требования с нарушенной характеристикой |
Приложение должно работать в ОС Windows не ниже 7. |
Приложение должно работать на OC Android 2.0 |
Как тестировать требование на актуальность?
Внимательно читать и задавать вопросы. Такие требования часто имеют ограничительный характер, поэтому думайте и спрашивайте, откуда взялось то или иное ограничение.
7. Выполнимость: требование можно выполнить в рамках существующих технологий.
✅ Пример допустимого требования |
❗️ Пример требования с нарушенной характеристикой |
Приложение должно загружаться на ПК пользователя за 3 секунды. |
Игра должна загружаться за 0,1 миллисекунду. |
Как тестировать требование на выполнимость?
Поставьте себя на место пользователя. Если речь идет о технических, системных или бизнес-требованиях, задавайте вопросы коллегам и аналитикам. Обращайтесь к заданиям и мануалам аппаратной и программной части.
8. Понятность: требование должно пониматься всеми одинаково.
✅ Пример допустимого требования |
❗️ Пример требования с нарушенной характеристикой |
Поле ввода “Номер телефона” имеет маску на ввод, которая позволяет вводить в поле |
Поле ввода заполняется допустимыми символами. |
Как тестировать требование на понятность?
С помощью вопросов, исследования системы. Можно поставить себя на место пользователя и спросить себя: “как я понимаю данный термин или определение?”
9. Проверяемость: выполнение требования можно измерить или проверить, исходя из
определенных и заданных критериев.
✅ Пример допустимого требования |
❗️ Пример требования с нарушенной характеристикой |
Карточки в каталоге товара должны отображаться в виде таблицы. В каждой ячейке таблицы отображается превью товара. |
Сайт должен иметь удобную навигацию. |
Как тестировать требование на проверяемость?
Составьте чек-лист или тест-кейс – какой ожидаемый результат у вас получается, какими средствами вы измерите успешность или провальность тест-кейса?
10. Обязательность: без выполнения этого требования пользователь не сможет в полной мере использовать систему.
✅ Пример допустимого требования |
❗️ Пример требования с нарушенной характеристикой |
В интернет-магазине можно добавить товар |
Отсутствие в требованиях упоминания о том, что купленный товар нужно удалить из каталога. |
Как тестировать требования на обязательность?
Сопоставлять требования, задавать вопросы, строить схемы и проверять связи.
11. Полнота: требования описаны исчерпывающим образом.
✅ Пример допустимого требования |
❗️ Пример требования с нарушенной характеристикой |
Для ввода в поле доступны только буквы русского алфавита и пробел. Остальные символы ввести нельзя. Ввод не может начинаться с пробела, только с буквы. Регистр не имеет значения. Ограничения на ввод: минимум 2 максимум 160 символов. Поле обязательно для заполнения. Приходит в состояние ошибки при потере фокуса без заполнения, при отправке пустого поля и при вводе количества символов меньше минимального. Снятие ошибки происходит |
Для ввода в поле доступны только буквы. Ограничения на ввод: минимум 2 символа. Поле обязательно для заполнения. Приходит в состояние ошибки при потере фокуса без заполнения, при отправке пустого поля и при вводе количества символов меньше минимального. |
Как тестировать требования на полноту?
После ознакомления с требованиями, у вас не должно остаться вопроса “а что если?”. А что по инструментам?
Инструменты для внедрения тестирования требований
1. Стандартный шаблон задачи/ спецификации;
2. Флоу разрешения противоречий в требованиях (Кто хранитель задачи? За кем последнее слово?);
3. Тестирование требований как отдельный этап флоу разработки;
4. Документация/Схема работы;
5. Обсуждение (приложенные задачи, ссылки на обсуждения и т.д.);
6. Макеты на каждое состояние/анимацию;
7. Чек-листы приемки макета/задачи;
8. Публичные чек-листы тестирования для типовых задач;
9. Чек-лист составленный до разработки;
10. Брендбук;
11. Взгляд человека со смежного проекта, опыт коллег;
12. DOD (Definition Of Done).
Надеюсь, что статья помогла Вам ответить на некоторые Ваши вопросы, и тестирование
требований уже не пугает как раньше.