tестирование dot com
Шрифт:
дальнейшее продолжение тестирования не имеет смысла (например,
7 П1). Соответственно условием возобновления должно быть количе-
ство оставшихся П1 багов (после ремонта и регрессивного тестирова-
ния), которое позволяет возобновить тестирование (например, 2 П1).
15. Ответственные лица — подробный список товарищей (про-
дюсеров,
формация и обязанности каждого из них. Такой список может
включать лиц со стороны вендора.
16. Тренинг — тренинг, необходимый для данного проекта.
Например,
при соответствующей ситуации нужно указать, что для создания тест-
кейсов тестировщику необходимо прослушать семинар "Банковская
система США".
17. Расписание — сроки, имеющие отношение к тестированию
данного проекта:
• дата замораживания спеков;
• дата начала подготовки к тестированию;
• дата завершения подготовки к тестированию;
• дата интеграции и замораживания кода;
• дата начала тестирования новых фича;
• дата завершения тестирования новых фича;
• дата начала регрессивного тестирования;
• дата завершения регрессивного тестирования.
18. Оценка риска — предположение о том, как и что может пой
ти по неправильному пути и что мы в этом случае предпримем.
Например,
если мы не успеваем закончить тестирование (не выполняем требова-
ние "Условия завершения", например, "все тест-кейсы исполнены") в
срок, то придется задерживаться на работе и приходить в офис в вы-
ходные и праздники.
Кстати, если народ приходит в выходные и праздники, то компания
должна, по крайней мере, кормить его обедом.
270
Тестирование Дот Ком. Часть 3
19. Прочие положения — вещи, не вошедшие в тест-план, о ко-
торых неплохо было бы упомянуть.
20. Утверждения — это подписи лиц, которые утвердили тест-
план. Чем больше будет таких подписей, тем лучше. По крайней
мере, нужны подписи менеджера тестировщика, составившего
план, самого тестировщика, продюсера и программиста.
21. Приложения — например, расшифровка терминов и аббре-
виатур, используемых в тест-плане.
Это все о тест-планах и о первой стадии исполнения тестирова-
ния.
ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ.
СТАДИЯ 2:
РЕГРЕССИВНОЕ ТЕСТИРОВАНИЕ
• ВЫБОР ТЕСТ-КОМПЛЕКТОВ ДЛЯ РЕГРЕССИВНОГО
ТЕСТИРОВАНИЯ
• РЕШЕНИЕ ПРОБЛЕМЫ ПРОТИВОРЕЧИЯ
егрессивное тестирование как второй этап исполнения тес-
Ртирования — это проверка того, что изменения, сделан-
ные в ПО (для того, чтобы мир увидел новые фича), не поло-
мали старые фича.
Допустим, у нас есть 5 тест-комплектов с тест-кейсами для новых
фича, а также 21 тест-комплект с тест-кейсами для старых фича.
Ситуация эта рождает как минимум два вопроса:
1. Какие из этих 21 тест-комплекта выбрать, чтобы:
• проверить именно те части ПО, которые могли быть по-
ломаны?
• уложиться в срок, выделенный для регрессивного тести-
рования (например, 5 рабочих дней + два выходных дня,
которые вполне могут стать рабочими)?
2. Что делать с регрессивным тестированием дальше, ко
гда после релиза к 21 тест-комплекту прибавятся еще 5
(тест-комплекты, которые проверяли новые фича, прим
кнут к остальным тест-комплектам и станут кандидатами
для регрессивного тестирования) и еще, скажем, 10 после
следующего релиза и т.д. (постоянно нарастающий снеж
ный ком)?
271
Исполнение тестирования. Стадия 2: регрессивное тестирование
273
Итак, две темы:
1. Выбор тест-комплектов для регрессивного тестирования.
2. Решение проблемы противоречия между ограничен-
ными ресурсами (например, время на регрессивное тес-
тирование) и перманентно увеличивающимся количест-
вом тест-комплектов.
Кстати, как обычно, я излагаю личное видение предмета. В разных
компаниях поступают по-разному, но, после того как вы поймете, что я
вам расскажу, вы сможете немедленно адаптировать свои знания к ре-