А. Н. Ильин - «Информационное тематическое пособие в помощь начинающему QA engineer (Тестировщику ПО)»

требование должно содержать однозначные формулировки.
6

Непротиворечивость — требование не должно содержать внутренних
противоречий и противоречий другим требованиям и документам.
Приоритетность — у каждого требования должен быть приоритет
(количественная оценка степени значимости требования). Этот атрибут позволит грамотно
управлять ресурсами на проекте.
Атомарность — требование нельзя разбить на отдельные части без потери деталей.
Модифицируемость — в каждое требование можно внести изменение.
Прослеживаемость — каждое требование должно иметь уникальный
идентификатор, по которому на него можно сослаться.
МОДЕЛИ РАЗРАБОТКИ:
1. Каскадная (водопадная (Waterfall)) базовым принципом является
последовательный порядок выполнения задач. Это значит, что мы можем переходить к
следующему шагу разработки или тестирования только после того, как предыдущий был
успешно завершен. (Анализ требований, проектирование, разработка, тестирование,
техническая поддержка).
2. V-Model (Модель верификации и валидации) основана на прямой
последовательности шагов, тестирование в данном случае планируется параллельно с
соответствующей стадией разработки. Согласно этой методологии тестирования ПО,
процесс начинается, как только определены требования и становится возможным начать
статическое тестирование, т.е. верификацию и обзор, что позволяет избежать возможных
дефектов ПО на поздних стадиях. Соответствующий план тестирования создается для
каждого уровня разработки ПО, что определяет ожидаемые результаты, а также критерии
входа и выхода для данного продукта.
Основные этапы этой методологии могут изменяться, однако обычно они
включают следующие:
Этап определения требований. Приемочное тестирование относится к этому этапу.
Его основная задача состоит в оценке готовности системы к финальному использованию.
Этап, на котором происходит высокоуровневое проектирование, или High-Level
Design (HDL). Этот этап относится к системному тестированию и включает оценку
соблюдения требований к интегрированным системам.
Фаза детального дизайна (Detailed Design) параллельна фазе интеграционного
тестирования, во время которой происходит проверка взаимодействий между различными
компонентами системы.
После этапа написания кода начинается другой важный шаг — юнит-тестирование.
Очень важно убедиться в том, что поведение отдельных частей и компонентов ПО
корректно и соответствует требованиям.
3. Инкрементная модель:
Данная методология может быть описана, как мультикаскадная модель тестирования
ПО. Рабочий процесс разделяется на некоторое количество циклов, каждый из которых
также делится на модули. Каждая итерация добавляет определенный функционал к ПО.
Инкремент состоит из трех циклов:
- дизайн и разработка;
- тестирование;
- реализация.
В этой модели возможна одновременная разработка разных версий продукта.
Например, первая версия может проходить этап тестирования в то время, как вторая версия
находится на стадии разработки. Третья версия в то же самое время может проходить этап
дизайна. Этот процесс может продолжаться до самого завершения проекта.

7

4. Спиральная модель:
Спиральная модель — это методология тестирования ПО, которая основана на
инкрементном подходе и прототипировании. Она состоит из четырех этапов:
- Планирование;
- Анализ рисков;
- Разработкам
- Оценка;
Сразу после того, как первый цикл завершен, начинается второй. Тестирование ПО
начинается еще на этапе планирования и длится до стадии оценки. Основным
преимуществом спиральное модели является то, что первые результаты тестирования
появляется незамедлительно после появления результатов тестов на третьем этапе каждого
цикла, что помогает гарантировать корректную оценку качества. Тем не менее, важно
помнить о том, что эта модель может быть довольно затратной и не подходит для маленьких
проектов.
5. Agile (SCRUM, CANBAN):
Методология гибкой (Agile) разработки и тестирование ПО может быть описана как
набор подходов, ориентированных на использование интерактивной разработки,
динамического формирования требований и обеспечения их осуществления как результата
постоянного взаимодействия внутри самоорганизующейся рабочей группы. Большинство
гибких методологий разработки ПО нацелены на минимизацию рисков --">