Разберемся в том, в какой момент работы над проектом начинается тестирование. Многие начинающие аналитики думают, что тестирование - это этап жизненного цикла ПО, следующий за разработкой. Нужно сказать, что это и верно и ошибочно одновременно по причине отсутствия контекста.
Если ориентироваться на "водопадную" модель разработки, то ответ практически верный, а если другие методологии, то все иначе - тестирование присутствует на каждом этапе.
Пример на иллюстрациях - "Водопадная" модель и V-образная модель, где видно что в V-образной модели разработки ПО тестирование присутствует на каждом этапе.
У тестирования тоже есть свой жизненный цикл, в общем состоящий из следующих этапов (по ISTQB (International Software Testing Qualifications Board - международная сертификация тестировщиков) с дополнениями Куликова С. в курсе "Тестирование программного обеспечения. Базовый курс")):
- Общее планирование и анализ требований
- Уточнение критериев приёмки
- Уточнение стратегии тестирования
- Разработка тест-кейсов
- Выполнение тест-кейсов
- Фиксация найденных дефектов
- Анализ результатов тестирования
- Отчетность
Из которого видно, что тестирование начинается с анализа требований. Те в моменте, когда аналитик подготовил требования (а в идеале еще раньше), уже начинается тестирование.
"А не рано ли?" - спросит кто-то.
"Не рано!" - независимо от модели разработки ПО, чем позже будет обнаружена проблема, тем сложнее и дороже будет её устранение. Если проблема в требованиях будет выявлена на аналитической стадии, её решение заключается в корректировке требований без ущерба к проекту (по крайней мере ущерб для проекта минимальный), а в финале процесса разработке - потребуются значительные ресурсы и потеря репутации (команды, продукта, проекта).
Так как на данном этапе из артефактов присутствуют только требования, задокументированные в определенном формате (спецификация, SRS, ТЗ и другие документы, являющиеся хранителем требований, включая архитектуру и дизайн), то именно с ними и проводится работа: тестирование требований и документации.
Общий принцип следующий - всё, что создается на стадии анализа, должно быть протестировано (от бизнес правил и требований, до макетов пользовательского интерфейса).
Требования проверяются на соответствие критериям качественных требований:
- непротиворечивость
- прослеживаемость
- модифицируемость
С наиболее полным списком критериев качества требований ПО можно ознакомиться здесь.
Техники, применяемые для тестирования, можно разделить на 2 группы:
1. Статические:
- ревью документации (единичный, парный, командный, с привлечением внешних экспертов)
- описание тест-кейсов (критерий "проверяемость")
- проверка по чек-листу (выявление упущенных требований)
2. Динамические
- прототипирование (все критерии)
- исследование поведения системы TO-BE (анализ не отдельного требования, а всех вместе)
- моделирование (в том числе с использованием разных языков, пример UML)
Больше другой полезной информации в ТГ канале: https://t.me/all_for_analyse
Дополнительные материалы по теме статьи: