tестирование dot com
Шрифт:
жат наши драгоценные жизненный опыт, опыт работы и другие
ранее перечисленные помощники, не относящиеся к спекам.
Кстати, хорошая идея для тестировщика, помогающая лучше понять
функциональности своего проекта, — это стать обычным пользовате-
лем своего и аналогичных веб-сайтов. Выражение "Eat your own dog
food" ("Ешь
тестируешь веб-сайт, продающий книги, то ты должен сам покупать
книги по Интернету".
Идем дальше.
Конечной целью этапа Изучение и анализ предмета тестирова-
ния является получение ответов на два вопроса:
а. Какие функциональности предстоит протестировать?
б. Как эти функциональности работают?
После того как ответы получены, мы переходим к следующему
этапу цикла.
2. Планирование тестирования
Эта стадия требует от тестировщика наибольшего творчества и
профессионализма, так как именно на ней решается множество
головоломок, отвечающих на один простой вопрос: "Как будем
тестировать?", причем качество продукта (а значит, и счастье поль-
зователей) напрямую зависит от, не побоюсь сказать, мудрости
найденных решений.
136
Тестирование Дот Ком. Часть 2
Мудрость найденных решений проявляется в двух вещах:
а)
кратких, простых и изящных путях для проверки
функциональностей;
б)
компромиссе между
объемом тестирования, который возможен в теории;
объемом тестирования, который возможен на практике.
Ответы на "один простой вопрос" предстают перед
миром в виде тест-документации (test documentation),
ядро которой составляют наши любимые тест-кейсы. Во
многих случаях создание тест-документации
сопровождается написанием тестировщиком вспо-
могательных тулов (tool — компьютерная программа),
которые облегчают исполнение тестирования.
Идем дальше.
3. Исполнение тестирования
Суть исполнения тестирования — это практический
поиск багов в написанном коде с использованием
тест-кейсов, созданных ранее.
Исполнение функционального тестирования выглядит
следующим образом:
сначала идет проверка новых функциональностей по
новым
многих случаях новые тест-кейсы редактируются,
проходя обкатку первым исполнением;
затем проверка старых функциональностей по старым
тест-кейсам.
То же самое, но в профессиональной терминологии:
тестирование новых функциональностей (new feature
testing) и соответственно
регрессивное тестирование (regression testing).
Мы исполняем тест-кейсы, рассчитывая найти баги.
Давайте еще раз вспомним, что
после нахождения бага тестировщик заносит запись о
нем в систему трэкинга багов;
после того, как программист починил баг,
тестировшик проверяет:
Цикл тестирования ПО
137
а)
действительно ли баг был починен. Проверка
осущест
вляется путем исполнения шагов, которые ранее приве
ли к багу, или, в профессиональной терминологии, пу
тем генерации ввода, который привел к выводу, не со
ответствующему ожидаемому результату;
б)
не появились ли новые баги как нечаянное
следствие
изменения кода при починке. Проверка осуществляется
путем тестирования функциональностей, работа кото
рых могла быть затронута починкой.
Тестирование, исполняемое в пунктах а) и б), также
называется регрессивным тестированием (bug regression
testing). Соответственно выражение "regress that bug"
(проведи регрессивное тестирование этого бага)
означает, что нужно последовательно исполнить пункты а)
и б).
Идем дальше.
Давайте сделаем небольшое обобщение.
Так как этапы 1. Изучение и анализ предмета
тестирования и
2. Планирование тестирования переплетены между собой, мы
объединим их в контейнер знания, который называется
подготовка к тестированию (test preparation или, по-