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

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

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

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

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

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

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

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

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

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

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

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

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

105

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

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

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

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

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

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

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

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

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

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

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

чтобы они передали плод наших терзаний кликам (от англ. click)

пользователей.

Релиз

Release (англ.) — "выпуск, освобождение".

Пример

Герой романа Стивена Кинга — ботаник, чудик и домосед — подверга-

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

ных прохожих. В один день он вдруг говорит себе "Хватит" и начинает

колоть, резать и душить подлых обидчиков, а также в превентивных

целях и всех остальных. Этот выпуск пара и есть "релиз" в его обыден-

ном понимании.

До этого мы употребляли слово "релиз" в значении "основной

релиз" (так будем поступать и дальше), но у нас есть и его "род-

ственники".

Вот полная классификация "релизообразных":

1. Релиз (он же основной релиз) (major release) — стадия в

цикле разработки ПО, идущая за стадией тестирование и

ремонт багов, т.е. передача пользователям кода новой вер-

сии нашего ПО. Как правило, обозначается целыми

числами, например 7.0.

2. Дополнительный релиз (minor release) — ситуация, когда

после основного релиза планово выпускается новая функ-

циональность или изменяется/удаляется старая. Дополни-

тельный релиз не связан в багами. Как правило,

обозначается десятыми, например 7.1.

106

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

3. Заплаточный релиз (patch release), когда после обнаруже-

ния и ремонта бага выпускается исправленный код. Как

правило, обозначается сотыми, например 7.11.

О чем говорит версия 12.46 нашего www.testshop.rs? А говорит

она о трех вещах:

1) о том, что последний основной релиз является двенадца-

тым по счету;

2) о четырех дополнительных релизах, выпущенных ПОСЛЕ

двенадцатого релиза;

3) о шести заплаточных релизах, выпущенных ПОСЛЕ две-

надцатого релиза.

Кстати, о номерах релизов. Некоторые компании в желании поориги-

нальничать дают основным релизам не номера, а названия. Ну, напри-

мер, имя поп-группы или отдельного исполнителя.

Звонит программисту дружок:

— Здорово, старик. Слушай, Ленка подружку приводит, так что бери

шампанское и подъезжай к семи.

— Не, я пас. Я тут с "Бритни Спирс" завис. -

О!..

Неудобство такого подхода заключается в том, что непонятно, какой

релиз был раньше — "Пол Маккартни" или "Джон Леннон", и в идиотиз-

ме произнесения названий дополнительных или заплаточных релизов:

звонит контрагент со своей проблемой, а ему говорят: "Да усе будет в