tестирование dot com
Шрифт:
259
Кстати, хорошая традиция — это устроить в конце подготовки к тести-
рованию (или начале исполнения тестирования) совещание, на кото-
ром каждый тестировщик, у которого есть новая фича, сделал бы ее
короткую, например на две минуты, презентацию. Таким образом мы
быстро и эффективно распространяем информацию о новых фича, так,
чтобы
Вопрос: Как мы тестируем новые фича?
Ответ: Все очень просто: берем в зубы тест-кейсы и исполняем
их. Попутно заносим баги. Спорим с программистами о приори-
тетах этих багов. Закрываем эти баги. Одним словом, обычная
суета сует.
Это в общем-то все насчет стадии 1 исполнения тестирования, но,
поскольку нужно чем-то занять время, давайте поговорим о не-
скольких нужных вещах:
• Test Estimation (тест-смета).
• Entry/Exit Criteria (критерий начала/завершения).
• Test Plan (тест-план).
Test Estimation (тест-смета)
Как правило, в интернет-компаниях существует расписание рели-
зов. К этому расписанию привязано расписание тестирования (QA
Schedule), которое определяет сроки каждой стадии процесса тес-
тирования.
"Как правило" было употреблено из-за того, что в некоторых
компаниях такого понятия, как "Расписание", не существует в
принципе.
Итак, допустим, что
• на подготовку к тестированию дается две недели (10 ра-
бочих дней (80 часов) + 4 выходных дня (32 часа), которые
элементарно могут стать рабочими);
• на исполнение тестирования также дается две недели
(10 рабочих дней (80 часов) + 4 дня выходных дня (32 часа),
которые также элементарно могут стать рабочими),
т.е. у нас есть
две недели на написание тест-кейсов (и прочие подготови-
тельные мероприятия) и
260
Тестирование Дот Ком. Часть 3
две недели, в которые нужно уместить:
• тестирование новых фича по созданным тест-кейсам;
• регрессивное тестирование.
Проблема в том, что, как бы ударно мы ни работали, мы можем
выполнить лишь определенный объем работы и возникает кон-
фликт между
• лавиной новых фича, которые могут понадобиться для биз-
неса компании, и
• физическими возможностями продюсера, программиста и
тестировщика.
Чтобы уравновесить желаемое и реальное, используют сметы
(estimation).
Тестировщик готовит тест-смету (Test Estimation), которая
вклю-чает:
• предварительную оценку времени, необходимого на под-
готовку к тестированию;
• предварительную оценку времени, необходимого на тести-
рование новых фича.
Как тестировщик готовит тест-смету? Очень просто:
после того как написан спек, менеджер тестировщика просит по-
следнего прочитать этот спек и оценить, сколько времени займут
написание тест-кейсов по этому спеку и прочие подготовитель-
ные мероприятия и исполнение этих тест-кейсов. Тестировщик
читает спек, предметно общается с продюсером и программистом
и на основе полученной информации и своего опыта предостав-
ляет менеджеру два числа, являющиеся тест-сметой для данного
спека.
Пример
Для создания тест-сметы тестировщику был дан спек #1299 "Новые
функциональности поиска".
Тестировщик предоставил своему менеджеру следующее:
• потребуется 50 часов на написание тест-кейсов и 20 часов на
написание тест-тулов;
• потребуется 60 часов на исполнение этих тест-кейсов.
Таким образом, тестировщик полностью укладывается в график по
подготовке к тестированию (80 - 50-20 >0). Оставшиеся 10 часов
можно будет использовать для помощи своим коллегам и/или как ре-
Исполнение тестирования. Стадия 1: тестирование новых фича
261
зерв на случай, если оценка тестировщика была неверной и на подго-
товку в реальности потребуется больше времени.
Сложнее обстоит дело с исполнением тестирования. На регрессивное
тестирование остается только 20 часов (80 - 60). Будет ли этих 20 ча-
сов достаточно, чтобы закончить регрессивное тестирование в срок?
Это зависит от нескольких факторов, основные из них:
• значительность релиза, например: имело ли место серьезное
изменение архитектуры ПО? На сколько процентов изменилось
количество строк кода? Были ли добавлены новые критические
функциональности, интегрированные со старым кодом? и пр.;
• трудоемкость тест-комплектов, которые нужно исполнить для