вторник, 29 сентября 2009 г.

Расстановка приоритетов тест кейсов

Процесс тестирования предполагает своевременное донесение до необходимого количества заинтересованных лиц текущего состояния разрабатываемого софта. Я думаю, что всем понятно, что заказчик меньше всего ждет программу с идеальным интерфейсом, бантиками и т.д., но не выполняющую своих прямых обязанностей. Так же как и руководители разработки ожидают, что внедрение нового\ изменение существующего функционала не вредит, не портит основной функционал, ядро системы. Поэтому при составлении тест плана необходимо четко расставлять приоритеты тестирования тех или иных областей тестируемого приложения ввиду ограниченного срока разработки ПО и, соответственно, его тестрования.
В зависимости от вида тестирования (модульное, системное, интеграционное) приоритеты могут изменяться, но суть- есть вещи, которые должны быть протестированы в первую очередь, и есть вещи, тестирование которых может (и должно) быть отложено, остается той же.
Сначала необходимо определить критичные области приложения (такие как, например, ядро системы, основной функционал, ради которого и ведется вся разработка). Эти области должны быть протестированы в первую очередь насколько это представляется возможным. Затем произвести разбивку по важным, средним и маловажным областям. При этом нужно пользоваться набором требований к ПО, которые чаще всего отражают критичные и важные области. Проще всего это сделать, уже имея дерево сгруппированных тест кейсов (расстановка приоритетов упоминалась в "правилах написания тест кейсов"). Достаточно будет пройтись по нему и расставить уровни критичноти "части" приложения, тестируемой\проверяемой тем или иным тест кейсом. Для большей точности это можно сделать с руководителем разработчиков. Который попутно сможет также рассказать о таких моментах, как "в следующий билд должен войти такой-то и такой-то функционал, поэтому это нужно включить в первоочередные проверки." Здесь можно дополнительно проставить такой параметр, как "близость релиза" чтоли. Ведь общая задача- поставить в срок то, что нужно, и заданного качества. Поэтому будет ошибочно тестировать области приложения одинакового уровня критичности, но вперед ту, которая будет релизиться позже.
Таким образом выстраиваем список тест кейсов, в котором будет указано когда (в какой последовательности) будет тестироваться тот или иной функционал. Соответственно, зная "скорость", можно определиться со временем.