tестирование dot com

Так вот тест-комплекты необходимо, как и спеки, хранить в CVS

и публиковать линки к ним на интранете для предоставления

возможности свободного ознакомления с ними любому заинтере-

сованному лицу внутри компании. Главные преимущества хране-

ния тест-кейсов в CVS:

• отсутствие возможности случайного удаления файла;

• присутствие возможности возвратиться к предыдущим вер-

сиям файла;

• файл хранится на сервере, и каждый, кому нужно (и кто

имеет право), может взять его для исполнения тестирова-

ния, изменения и удаления существующих или включения

дополнительных тест-кейсов.

Вторая вещь

Хорошая идея для компании в целом и для интересов самого

тестировщика — это провести рассмотрение тест-кейсов (Test-

case Review), когда за несколько дней до начала тестирования со-

бираются

• продюсер, написавший спек,

• программист, написавший по спеку код и

• тестировщик, написавший по спеку тест-кейсы.

Тестировщик раздает присутствующим распечатки этих тест-кей-

сов и подробно рассказывает, как он будет проверять функцио-

нальности, описанные в спеке.

Полезность рассмотрения тест-кейсов заключается в том, что

во многих случаях продюсеры и программисты дают новые

идеи для тестирования и/или корректируют допущенные не-

точности.

Политический момент

Если участники митинга

• не предложили внести в тест-кейсы ничего нового либо

• предложили и вы внесли,

то это формально означает, что они одобрили то, как будет протести-

рован код. А так как все протестировать невозможно и всегда есть веро-

ятность, что мы не проверим какой-либо багосодержащий сценарий,

104

Тестирование Дот Ком. Часть 1

то даже в случае пропущенного бага все будут знать, что вы сделали

все возможное для качественной подготовки к тестированию, т.е. соз-

дали тест-кейсы и получили одобрение их эффективности.

Кстати, после рассмотрения тест-кейсов пошлите е-мейл всем

присутствовавшим на совещании. Перечислите в этом е-мейле все

модификации к тест-кейсам, о которых вы договорились на совеща-

нии. Таким образом, с одной стороны, вы составите памятку для са-

мого себя, а с другой — дадите себе возможность удостовериться (пу-

тем получения ответов на е-мейл), что вы учли все предложенные вам

вещи по модификации тест-кейсов и учли эти вещи правильно. Отсут-

ствие ответа на подобный е-мейл — это знак согласия.

Во многих крупных интернет-компаниях рассмотрение тест-кей-

сов — это обязательная процедура перед переходом к стадии...

Исполнение тестирования и ремонт багов

Так как о тестировании мы будем говорить все остальные томные

вечера, то сейчас будем лаконичны, как спартанцы.

После того как проинтегрирован код, тестировщики проводят

тест приемки (smoke test, sanity test или confidence test), в процессе

которого проверяются основные функциональности.

Пример

Если мы не можем погнуться (log into) в наш эккаунт (account) на

www.main.testshop.rs, то о каком дальнейшем тестировании можно

говорить.

Если тест приемки не пройден, то программисты и релиз-инже-

неры совместно работают над поиском причины. Если проблема

была в коде, то код ремонтируется, интегрируется и над ним сно-

ва производится тест приемки. И так по кругу, пока тест приемки

не будет пройден.

Если же тест приемки пройден, то код замораживается и тести-

ровщики начинают тестирование новых компонентов (new fea-

ture testing), т.е. исполнение своих тест-кейсов, написанных по

спекам данного релиза (более подробно о значении термина fea-

ture поговорим в беседе о системе трэкинга багов).

После того как новые функциональности протестированы, насту-

пает очередь исполнения "старых" тест-кейсов. Этот процесс на-

зывается регрессивным тестированием (regression testing), ко-

Цикл разработки ПО

105

торое проводится для того, чтобы удостовериться, что компонен-

ты ПО, которые работали раньше, все еще работают.

Баги заносятся в систему трэкинга багов (Bug Tracking System,

далее — СТБ, о ней у нас будет отдельный разговор), программи-

сты их ремонтируют, и затем тестировщики проверяют, насколь-

ко качественным был ремонт.

Допустим, мы все, что хотели и как смогли, протестировали. Про-

граммисты залатали дыры в коде, что мы тоже протестировали, и

у нас есть версия нашего проекта, готовая для релиза. Эту версию

мы мурыжим еще пару деньков, проводя тест сдачи (Acceptance

or Certification Test), и включаем зеленый свет релиз-инженерам,