Разработчики продукта, независимая группа тестировщиков или совместно?
Какие компоненты надо тестировать?
Будут ли подвергнуты тестированию все компоненты программного продукта или только компоненты, которые угрожают наибольшими потерями для всего проекта?
Когда надо тестировать?
Будет ли это непрерывный процесс, вид деятельности, выполняемый в специальных контрольных точках, или вид деятельности, выполняемый на завершающей стадии разработки?
Как надо тестировать?
Будет ли тестирование сосредоточено только на проверке того, что данный продукт должен выполнять, или также на том, как это реализовано?
В каком объеме тестировать?
Как определить, в достаточном ли объеме выполнено тестирование, или как распределить ограниченные ресурсы, выделенные под тестирование?
Кто будет тестировать?
Разработчики или Разработчики и Тестировщики или Тестировщики
где
Разработчик:
• Кодирование\программирование
• Создание и выполнение юнит-тестов
• Исправление ошибок
• …
Тестировщик (Тестер\Tester)
• Создание и описание тест-кейсов
• Выполнение тест-кейсов
• Запись отчетов об ошибках и их верификация
• Оценка задач тестирования
• Создание скриптов (test scripts), если есть автоматизация
• …
Ведущий тестировщик (Test Lead)
• Оценка и планирование процесса тестирования
• Создание Тест Плана и другой тестовой докуменации и обеспечение их актуальности
• Внедрение процедуры тестирования и ее выполнение
• Соблюдение графика
• Руководство командой тестирования
• Ревью результатов тестирования
• Отслеживание выполнения задач тестирования
• Сбор метрик
• …
Конкретный исполнитель проекта может выступать как в роли разработчика, так и в роли тестировщика. Момент начала тестирования в проекте можно регулировать
|
|
Что нужно тестировать?
Могут быть варианты, когда ничего не надо тестировать (поскольку все компоненты были протестированы ранее), а может потребоваться тестировать каждый компонент с точностью до строки кода. В объектно- ориентированном порграммирования базовым компонентом является класс. В этом случае область тестирования определяется классами. Область тестирования на уровне классов подлежит выбору. Классы, заимствованные из других проектов или взятые из библиотек, чаще всего в повторном тестировании не нуждаются. Существуют различные стратегии по выбору подмножества классов для тестирования.
Далее определяется необходимость интеграционного тестирования.
Аналогично для системного. Весь ли объем функциональности необходимо тестировать? Какие приоритеты для отдельных функциональных модулей, «фич».
Когда нужно тестировать?
Необходимо определить правила выполнения юнит-тестов – как часто? В какой момент?
Необходимо определить и зафиксировать расписание тестовых билдов для системного тестирования и процедуру приемки билда. Для каждого тестового билда необходимо, помимо дня и времени, определить его содержимой – какая функциональность будет включена в каждый билд (имплементация закончена, юнит-тесты выполнены).
Как нужно тестировать?
При тестировании в соответствии со спецификацией (функциональном тестировании или тестировании "черного ящика") построение тестовых случаев производится в соответствии со спецификацией и не зависит от того, как реализован ПП. Эффективность зависит от качества спецификации и способности тестировщика корректно ее интерпретировать.
|
|
При структурном тестировании (тестировании в соответствии с реализацией или тестировании "белого ящика") построение тестовых случаев производится на основе программного кода, представляющего собой реализацию ПП. Входные данные каждого тестового случая должны быть определены спецификацией ПП, однако они могут быть выбраны на основе анализа самого программного кода для прохождения той или иной ветви программы. При этом покрытие увеличивается.
Наряду с автономным тестированием компонентов (классов) системы (модульным уровнем тестирования), необходимо тестировать взаимодействие между различными компонентами (интеграционный уровень тестирования). Цель интеграционного тестирования заключается в обнаружении отказов, возникающих вследствие ошибок в интерфейсах или в силу неверных предположений относительно интерфейсов. После интеграционного тестирования проводится системное тестирование ПП (системный уровень). На этом уровне тестированию подвергается система как единое целое.
Тестирование следует осуществлять в достаточных объемах, чтобы быть более-менее уверенным в том, что ПП функционирует в соответствии с предъявленными к нему требованиями, т.е. выполняется принцип адекватности тестирования ПП. Адекватность можно измерить, используя понятие покрытия. Покрытие можно измерить двумя способами. Первый заключается в подсчете количества требований, сформулированных в спецификации, которые подверглись тестированию. Второй способ заключается в подсчете выполненных компонентов ПП в результате прогона тестового набора. Набор тестов можно считать адекватным, если определенная часть строк исходного кода или исполняемых ветвей исходного кода была выполнена, по крайней мере, один раз во время прогона тестового набора. Эти два способа измерения отражают два базовых подхода к тестированию:
- при использовании первого подхода проверяется, что должен выполнять ПП;
- при использовании второго подхода проверяется, как фактически работает ПП.