Текст книги "tестирование dot com"

Автор книги: Роман Савин

сообщить о нарушении

Текущая страница: 7 (всего у книги 17 страниц)

2. Подготовка релиз-скрипта (release script) – программы, кото-

рая автоматизирует процесс релиза на машину для пользователей.

3. Исполнение релиз-скрипта:

а) релиз-скрипт запускает билд-скрипт, чтобы на тест-маши

не создался новый билд;

б) релиз-скрипт берет файлы этого нового билда и по прото

колу FTP («эф-ти-пи» – File Transfer Protocol) пересылает

их в машину для пользователей;

в) релиз-скрипт:

• копирует из CVS на машину для пользователя скрипты

для базы данных (DB-scripts) и

• запускает эти скрипты.

Скрипты для базы данных создают или модифицируют схему

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

только создается, а именно создаются три таблицы:

• user_info (для данных о пользователях);

• user_transaction (для данных о транзакциях пользователя);

• book_vault (для данных о наименованиях книг и их наличии).

Кстати, нужно различать

• схему базы данных (database, или просто DB, schema) и

• сами данные.

Схема базы данных – это совокупность виртуальных контейнеров

(над БД работают программисты и администраторы БД).

Данные – это начинка этих виртуальных контейнеров, которую своими

действиями на www.testshop.rs, например регистрацией, создают/из-

меняют пользователи (user_info и user_transaction) или другие лица

(например, Харитоныч, который через специальную программу, напи-

санную Митей, может добавить новые названия книг и их количество

в book_vault).

Небольшое отступление

По мере развития проекта машина для пользователей превратится в

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

и серверов с базами данных, образующих production pool, т.е. сово-

купность компьютеров, обслуживающих наших пользователей. Но это

будет потом. А пока...

Welcome to www.testshop.rs!!! Наш первый релиз состоялся!!!

Книги продаются, к проекту примкнули кореша Харитоныча, в

результате чего появились деньги, чтобы нанять новых людей и

вообще начать активно расширяться.

114

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

Над проектом уже работают 2 продюсера, 7 программистов и 1

тестировщик. Долго ли, коротко ли, а уже и второй релиз (версия

2.0) состоялся.

На следующий день после выпуска версии 2.0 лавина жалоб от поль-

зователей дает основания полагать, что версия 2.0 www.testshop.rs

так же насыщена багами, как версия-2004 Государственной думы

единороссами.

Компания превращается в форпост по борьбе с последствиями

релиза версии 2.0:

• месье Кукушкин носится между столами программистов

и тестировщика, давая ценные указания и оперируя сло-

варным запасом, приобретенным на раннем (колымском)

этапе своей карьеры;

• программисты, которые не чинят баги версии 2.0, не мо-

гут сохранить файлы для версии 3.0 в CVS, так как в CVS

решением руководства можно сохранять только код с от-

ремонтированными багами для релиза 2.0;

• программисты, которые чинят баги, естественно, не мо-

гут работать над версией 3.0;

• тестировщик проверяет отремонтированный код для вер-

сии 2.0 вместо подготовки к тестированию версии 3.0;

• продюсеры отвечают на е-мейлы разгневанных пользова-

телей, которые, несмотря на биографии менее яркие, чем

биография Харитоныча, тем не менее с легкостью опери-

руют тем же словарным запасом.

Кстати, справедливости ради стоит отметить, что по идее к версии 1.0

вернуться можно, но это займет время и чревато ошибками, так как

основной объем работы будет делаться вручную. Понадобится:

• найти версии файлов в CVS на день первого релиза*,

• изменить и протестировать билд– и релиз-скрипты,

• запустить релиз-скрипты и проверить, насколько правильно они

сработали.

• Если в первом релизе у нас были десятки файлов, то с течением времени

их будут сотни!!!

В таком бедламе проходит двое безвылазных суток, и наконец

баги придушены, билд протестирован на тест-машине и срочно

организуется патч-релиз 2.01 на машину для пользователей.

После разбора полетов Митей, как одним из старожилов компа-

нии, вносится предложение о создании бранчей (branch – ветвь)

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

115

в CVS. Предложение принимается единогласно (тем более что от-

вечать в случае провала будет инициатор), и Митя рассказывает,

в чем суть этого подхода.

РАССКАЗ МИТИ

'В общем так, други. Допустим, у нас есть ребенок и его фото-

графии нужно раз в месяц по е-мейлу посылать теще. Если при-

сылается фотография ребенка в недовольном состоянии, то теща

приезжает и устраивает дома такой шухер, как будто она по-

пользовалась нашей версией 2.0. Соответственно нужно сохранить

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

графия теще не нравится, то нужно просто послать ей старую

фотографию с улыбкой и сказать, что ошибка вышла".

Харитоныч:

– Да вот я помню... (далее следует 30-минутный рассказ о его

тещах с постепенным переходом к обобщениям и, наконец, дек-

ларативному изложению отношения ко всему прекрасному полу).

Да-а-а, вот так-то. Что ты там говорил про версию 2.0?

ПРОДОЛЖЕНИЕ МИТИНОГО РАССКАЗА

«Да, вот. Как я и говорил о хорошем и улыбающемся билде. Вот

мини-история нашего проекта со стороны релиз-инженера:

В один прекрасный день мы начали работать над кодом ПО, и по

мере написания этого кода стали добавлять в CVS новые файлы

,и изменять файлы, уже существующие в ней. В определенный

момент мы сказали «Стоп» и назвали совокупность файлов в

CVS «версия 1.0». Затем мы продолжили работу над кодом и

снова стали добавлять в CVS новые файлы и изменять файлы,

существующие в ней. В определенный момент мы снова сказали

«Стоп» и назвали совокупность файлов в CVS «версия 2.0».

Основной проблемой, которую мы взрастили, стала мешанина,

начавшаяся в тот момент, когда мы не разделили файлы версии

1.0 и версии 2.0.

Идем дальше.

Представьте себе дерево, т.е.

ствол, и

ветви, растущие из ствола.

116

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

Вот как мы должны были поступить с самого начала:

• файлы, созданные вплоть до момента релиза версии 1.0,

были основой, т.е. виртуальным стволом (trunk), нашего ПО;

• из этого ствола мы могли создать виртуальную ветвь

(или бранч, от англ. branch) под названием «версия 1.0»,

которая включала бы все файлы версии 1.0 в редакциях

(версиях) на момент, когда мы сказали "Стоп " для версии

1.0. Мы говорим «Стоп» после того, как код написан и

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

• таким образом, у нас появились бы ствол и одна ветвь;

• программисты, пишущие код для версии 2.0, должны были

модифицировать код ствола (нарисунке – пунктиром);

• и когда код версии 2.0 был бы дописан, мы создали бы еще

одну ветвь и назвали ее "версия 2.0 ";

• таким образом, у нас был бы ствол, из которого сначала

рос бы бранч версии 1.0 и затем бранч версии 2.0;

• начиная работать над кодом релиза версии 3.0, мы снова

работаем со стволом (на рисунке – пунктиром);

• и т.д.

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

117

Таким образом, код каждой версии живет в CVS в виде отдель-

ного бранча или ствола.

Кстати, есть множество нюансов, например слияние бранча и

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

вями и прочее, но я не буду вас этим загружать. Сейчас мне нуж-

<:но, чтобы вы поняли главное.

Теперь вернемся к нашим баранам. Что сделано – то сделано.

Сейчас в CVS y нас есть

• весь код версии 1.0;

• весь код версии 2.0;

• часть кода версии 3.0.

Пусть все это содержимое CVS будет нашим стволом. Я берусь

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

мент релиза 2.0, и обратным числом создать из них бранч 2.0, что-

бы в случае фиаско с версией 3.0 мы могли быстро вернуться к коду

версии 2.0 и вообще начали хорошую традицию создания бранчей».

Выслушав Митю и мысленно поаплодировав ему, разберемся,

что даст реализация Митиного предложения:

Во-первых, мы всегда сможем вернуться к предыдущей версии,

если новая версия окажется некачественной.

Во-вторых, программисты

• смогут работать одновременно над различными версиями,

например ремонтировать баги для 2.0 (бранч 2.0) и писать

код для 3.0 (ствол) и

• результаты их работы над каждой из версий будут в CVS

отделены друг от друга.

В этом случае www.main.testshop.rs будет веб-сайтом с кодом для

3.0 и вообще площадкой для билдов каждого нового релиза, а,

скажем, www.old.testshop.rs будет веб-сайтом с кодом для 2.0 и

вообще площадкой с кодом каждого предыдущего релиза.

В-третьих, мы сможем руководить состоянием бранчей.

У бранча есть три состояния:

1) открытый, т.е. в нем можно сохранять файлы;

2) условно открытый, в нем можно сохранять файлы, НО

при определенном условии, например, программист дол-

118

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

жен написать номер реального бага в комментарии при со-

хранении файла; 3) закрытый. В этом случае файл может

быть сохранен в соответствии с процедурой о неотложном

ремонте багов (о процедуре через минуту).

Кстати, когда мы говорили о замораживании спеков, используя CVS,

нужно понимать, что бранчи, в которых сохраняются спеки, не имеют

никакой связи с бранчами, в которых сохраняется код. Как правило, это

даже две CVS, установленные на двух разных машинах, но если даже

используется одна и та же CVS на одной и той же машине, то бранчи

для спеков и бранчи для кода – это как два сына одной женщины

(т.е. CVS), один из которых мочит одноклассников в сортирах, а другой

в это время читает Артура Шопенгауэра.

Кстати, часто возникает ситуация, когда программист сохранил код в

бранче для патч-релиза и забыл сохранить исправленный код в стволе,

т.е. в коде, из которого будет сделан бранч для следующего релиза.

Таким образом, может получиться ситуация, когда баг, патч для кото-

рого уже был выпущен на машину для пользователей в предыдущем

релизе, вновь появляется в следующем релизе. Чтобы избежать таких

казусов, тестировщики придерживаются железного правила: на каж-

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

написан тест-кейс приоритета 1. Этот тест-кейс добавляется к группе

тест-кейсов для регрессивного тестирования соответствующей функ-

циональности.

Совместим наш цикл разработки ПО с открытостью бранчей.

1. Во время стадии кодирование, например, для версии 3.0

бранч с версией 3.0 является открытым.

2. Во время стадии тестирование и ремонт багов бранч явля-

ется условно закрытым – никакой код не может сохра-

няться в таком бранче, за исключением кода с починкой

для конкретного бага, при сохранении кода в CVS програм-

мист обязан указать номер открытого бага в СТБ, иначе CVS

не разрешит checkin. Именно такой статус у бранча после

заморозки кода и передачи кода тестировщикам.

3. После того как произошел релиз на машину для пользова-

телей и в этом релизе найден баг, у нас есть два варианта:

а) если баг некритический (например, отсутствует проверка

е-мейла пользователя на два "@"), то его можно отре

монтировать в следующем релизе, т.е. мы фиксируем код

только в стволе;

б) если баг критический (например, невозможно совершить

покупку), то нужно отремонтировать его и выпустить патч-

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

119

релиз как можно быстрее. Для такого срочного ремонта

нужен формальный документ: процедура о неотложном

ремонте багов (Emergency Bug Fix Procedure).

Кстати, не хочу вас путать, но есть одна важная для понимания вещь:

иногда нужно незамедлительно изменить код приложения на машине

для пользователей, и это изменение не связано с багами. В таком

случае тоже заносится запись в СТБ, но с типом «Feature Request» –

запрос о новой функциональности (подробнее об этом в разговоре

о СТБ), и релиз такого кода регулируется этой же процедурой.

Примером, в котором нужен быстрый, не связанный с багами

релиз, может послужить ситуация, когда у нас есть решение суда

(например, о нарушении патента), которое обязывает срочно из-

менить код.

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

Вопрос: В чем отличие такого патч-релиза от дополнительного

релиза?

Ответ: В том, что дополнительный релиз – это плановый релиз,

когда было заранее решено, что такие-то функциональности уви-

дят свет, но включены они будут не в основной, а в дополнитель-

ный релиз.

Процедура о неотложном ремонте багов должна содержать:

• приоритет багов, которые подлежат НРБ. Например, это

могут быть только П1 баги;

• список лиц, имеющих право инициировать процесс НРБ;

• последовательность действий между лицами, участвую-

щими в НРБ, например:

1) программист, извещенный о проблеме, фиксирует баг;

2) исправление кода заверяется одним из его коллег через

рассмотрение кода (code review);

3) релиз-инженер делает билд для регрессивного тести-

рования;

4) тестировщик производит тестирование;

5) релиз-инженер делает патч-релиз на машину для поль-

зователей;

• коммуникацию между лицами, участвующими в НРБ. На

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

лицо отвечает всем на последний е-мейл этой цепочки.

Причем в начале этапа посылается е-мейл типа "Начал де

лать билд для регрессивного тестирования. Примерный

120

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

срок до завершения операции – 30 минут". В конце этапа

посылается е-мейл типа "Билд для регрессивного тестиро-

вания завершен. Тестировщики. Ау!".

Во многих компаниях для быстрого и эффективного исправления

проблем после основного релиза по примеру полицейских созда-

ются SWAT-команды (Special Weapons and Tactics teams – под-

разделения оперативного реагирования), по минимуму состоящие

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

Допустим, у нас есть четыре такие команды. Для каждой их

них устанавливается расписание на каждый день (по шесть

часов каждая) на 10 дней после релиза, так чтобы по звонку в

любое время дня и ночи головорезы соответствующего под-

разделения были готовы сорваться, приехать в офис и сидеть до

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

зователей.

В начале завершения разговора о релизах поговорим о бета-

тестировании.

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

"бэта") (beta release). Идея бета-релиза заключается в следую-

щем: перед тем как мы сделаем основной "официальный" релиз,

т.е. откроем новый код всем пользователям, мы откроем новый

код лишь ограниченной группе пользователей, которые нам его и

протестируют. Эти пользователи (или "бета-тестировщики" —

beta testers) должны являться представителями целевой аудито-

рии (target group), для удовлетворения потребностей которой и

был затеян весь сыр-бор от идеи до поддержки. Бета-тестиров-

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

чается в том, что они, являясь типичными пользователями, будут

делать с бета-версией веб-сайта те же вещи, что и остальные

пользователи после официального релиза, и, следовательно, зара-

нее столкнутся с непойманными (нами) багами, о которых они и

сообщат в нашу компанию. Наша интернет-компания отремонти-

рует эти баги и выпустит официальный релиз, более качествен-

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

рование (beta testing), может послужить сервис Gmail компании

Google (кстати, основанной москвичом Сергеем Брином).

В некоторых случаях компания не организует бета-тестирова-

ние с ограниченным числом пользователей, а производит основной

релиз и помещает картинку или текст со словом «Beta», что

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

121

означает "Пользуйтесь на свой страх и риск. Код свежий. Вполне

возможны баги ". Так как данная ситуация не укладывается в идею

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

Истинные и псевдобета-релизы, как правило, имеют место в двух

случаях:

1. Первый релиз в жизни интернет-компании, например ре-

лиз версии 1.0 сайта www.testshop.rs.

2. Релиз большого и важного подпроекта, являющегося ча-

стью основного проекта, например сервис Gmail, являю-

щийся частью проекта Google.

Логичным будет вопрос: "Если есть бета-тестирование, должно

быть и альфа-тестирование?" Ответ: «Правильно».

Рассказываю:

Альфа-тестированием называется любое тестирование кода ДО

передачи его пользователям (включая бета-пользователей).

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

альфа-тестирования. Продюсер может попросить у программиста

покопаться на плэйграунде последнего, когда код уже работает, и

проверить, как были воплощены в жизнь его (продюсера) мечты

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

Родственное в альфа– и бета-тестировании – это то, что цель

каждого из них – поиск багов.

Чуждое в альфа– и бета-тестировании – это то, что в подавляю-

щем большинстве случаев альфа-тестирование исполняется внут-

ренними ресурсами компании, а бета-тестирование – внешними.

В продолжение завершения разговора о релизе

подчеркнем, что тестировщики интернет-компаний находятся в

привилегированном положении по сравнению с их коллегами из

всех других сфер бизнеса. В случае пропуска серьезного бага на

машину для пользователей этот баг можно устранить в течение

получаса, иногда даже с минимальной стоимостью и без ведома боль-

шинства пользователей о том, что баг вообще когда-то существовал.

А что, если баг обнаружен в подвеске автомобиля? Из-за отзыва

целого модельного ряда (нормальная деловая практика западных

автокомпаний) и негативной рекламы бренда убытки будут про-

сто неизбежны!

122

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

В завершение завершения разговора о релизе:

• Релиз проводится в то время, когда большинство пользова-

телей неактивны. Как правило, это ночь. Время подберете

сами исходя из того, в каком часовом поясе находится

большинство ваших пользователей.

• Во время релиза на www.testshop.rs вывешивается таблич-

ка, что, мол, "Производим техническую поддержку, не от-

чаивайтесь, примерно в 6.00 по Москве все вернется на

круги своя. Просим извинить за временные неудобства".

Пример

Пользователь, первый раз сделавший покупку на www.testshop.rs, про-

снулся в час ночи и хочет проверить статус своего заказа. Он набирает

в браузере www.testshop.rs и видит «404 file not found». Конечно, он

проведет остаток ночи в терзаниях, а потом эмоционально расскажет

всем своим друзьям (и правильно сделает), какие редиски работают в

www.testshop.rs, что вот полночи не спал из-за того, что мысленно

прощался с честно заработанными 300 рублей.

Обратная же ситуация будет, когда опять же в час ночи пользователь

увидит на www.testshop.rs сообщение, подробно объясняющее обычную

для on-line-бизнеса ситуацию, завершающееся вежливым «Извините».

В бизнесе любой интернет-компании наступают сезонные вспле-

ски активности пользователей, например, в США это канун като-

лического Рождества и Нового года. В такие периоды на все ре-

лизы, кроме патч-релизов, фиксирующих серьезные баги, должен

быть введен мораторий. Логика тут проста: любой релиз – это

риск. И мы не хотим идти на этот риск в то время, как

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

бойной работе нашего веб-сайта и

• наш бизнес делает наибольшие деньги.

Как и было обещано, переходим к следующей стадии, а перед

переходом запомним, что часто наряду со словом "релиз" или

вместо него употребляется равнозначное push – «толчок».

Большая картина цикла разработки ПО

Пример

Допустим, у нас есть

• мама (продюсер),

• сын 7 лет (программист, тестировщик, релиз-инженер и

служба поддержки),

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

123

• папа (пользователь) и

• неограниченное количество разнообразных деталей конструктора

для строительства игрушечного дома.

Мама говорит сыну: "Давай сделаем папе приятное и построим для него

одноэтажный дом (идея), который должен выглядеть вот так и вот так

(дизайн продукта)".

Сын собирает отдельно

крышу,

стены,

двери и

окна (кодирование).

Потом происходит соединение всех частей (интеграция), в результате

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

совпадают с выпуклостями стен, а окна не подходят по цвету. Сын

переделывает компоненты, успешно соединяет и начинает пинать домик

ногами, бросать вниз с семнадцатого этажа и оставлять на ночь в

наполненной ванной (тестирование). В результате обнаруживаются

некоторые недоработки (баги), которые постепенно устраняются

(фиксирование багов). Когда все нормально, домик передается папе

(релиз), который иногда просит (е-мейл/звонок в службу поддержки

пользователей), чтобы некоторые проблемы, такие, как неровности

крыши, с которой падает кружка с пивом (пострелиз-баги), были

немедленно исправлены (фиксирование пострелиз-багов).

Вернемся к нашему www.testshop.rs.

Давайте рассмотрим большую картину цикла разработки ПО в

динамике.

Сначала обобщим знания об игроках, их ролях и стадиях цикла с

их участием.

Игрок

Роль

Стадия

Маркетолог

Генерирует идеи и составляет MRD

Идея

Продюсер

Разрабатывает и документирует

Дизайн

дизайн продукта

и документация

Программист

Переводит дизайн продукта на язык

Кодирование

программирования

Ремонтирует баги

Тест и ремонт

Тестировщик

Готовится к исполнению

Кодирование

тестирования

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

Тест и ремонт

124

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

1. Итак, начнем с бара, вернее, с идеи версии 1.0, которая в

этом баре пришла.

2. После того как идея v. 1.0 была принята за путеводную звезду

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

v. 1.0 этой идеи. Основное действующее лицо – продюсер.

А в это время

• маркетолог тоже не сидит без дела, а генерирует идеи для

следующего релиза на стадии идея v. 2.O.

3. После того как дизайн и документация v. 1.0 завершены,

наступает стадия кодирование v. 1.0. Основное дейст-

вующее лицо – программист.

А в это время

• тестировщик планирует, как он будет тестировать код,

разрабатываемый сейчас программистом;

• продюсер работает уже над стадией дизайн и документа-

ция v. 2.0, переданной после стадии идея v. 2.0;

• маркетолог работает над стадией идея v. 3.0.

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

125

4. После того как кодирование v. 1.0 завершено, наступает

стадия тестирование и ремонт v. 1.0. Основное дейст-

вующее лицо – тестировщик. После завершения стадии

тестирование и ремонт v. 1.0 в одну из лунных ночей

происходит релиз v. 1.0, после чего тестировщик броса-

ется на v. 2.0, начав подготовку к тестированию кода, раз-

рабатываемого сейчас программистом на стадии кодиро-

вание v. 2.0.

А в это время

• программист пишет код на стадии кодирование v. 2.0;

• продюсер разрабатывает дизайн продукта на стадии ди-

зайн и документация v. 3.0;

• маркетолог, идущий, как всегда, в авангарде, обдумывает

идеи на стадии идея v. 4.O.

Таким образом, мы рассмотрели полностью цикл разработки

версии 1.0 проекта www.testshop.rs. Дальше все идет по ана-

логии.

126

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

Итак, большая картина цикла разработки ПО.

Большая картина – это всего лишь модель, и в реальной

жизни все так гладко, красиво и гармонично не бывает. На-

пример, во время стадии идея v. 2.0 маркетолог может генери-

ровать как краткосрочные идеи цикла v. 2.0, так и долгосрочные

цикла v. 4.0 и v. 5.0.

В завершение беседы о цикле разработки ПО давайте •

поставим акцент на паре важных моментов,

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

127

• сделаем одну оговорку,

• остановимся на одной ценной мысли и

• ответим на практические вопросы.

Пара важных моментов:

1. Процедуры, стандарты, спеки, тест-кейсы и контактная

информация должны быть задокументированы (пусть даже

в электронном виде) и доступны на интранете.

2. Такие вещи, как утверждение спека, рассмотрение тест-

кейсов или инспекция кода, – это не какие-то полицей-

ские мероприятия, призванные подрезать крылышки твор-

ческим и свободным личностям. Совершенно наоборот —

это средства, позволяющие

• улучшить качество,

• прикрыть спину,

• стать хорошим людям еще лучше.

Оговорка:

В аквариумах интернет-компаний кроме продюсеров, програм-

мистов, тестировщиков и начальников обитает еще много других

разновидностей не менее полезных особей, таких, как

• веб-дизайнеры;

• системные администраторы и администраторы баз данных;

• народ из службы поддержки и маркетинга;

• бухгалтеры (хлещущие чай);

• спецы по железу (хлещущие пиво) и др.

Мы их всех любим, ценим и, как видите, не забываем. Просто

нужно было сделать допустимое упрощение для удобства вос-

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

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

пишется веб-дизайнерами.

Ценная мысль:

Акт планирования, будь то спек, дизайн кода, тест-кейс или до-

кумент о неотложном ремонте бага, – это возможность посмот-

реть в будущее, предугадать и предотвратить возможные про-

блемы и/или баги.

Эффективное планирование – это одна из важнейших со-

ставляющих процесса разработки ПО.

128

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

Вопросы и задания для самопроверки

1. Перечислите стадии цикла разработки ПО.

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

во время тестирования?

3. Перечислите болезни спеков.

4. Почему продюсер не должен давать в спеке технических инст-

рукций?

5. Для чего нужно утверждение спека?

6. Для чего нужно замораживание спека?

7. Почему спеки нужно хранить в CVS?

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

9. Что такое юнит-тест?

10. Что такое инспекция кода и как она помогает вывести на чистую воду

подлецов, которые считают, что чем запутаннее код, тем лучше?

11. Для чего нужно замораживание кода?

12. Каковы преимущества постоянной интеграции кода?

13. Какие баги ловятся компайлером (интерпретатором)?

14. Какие баги НЕ ловятся компайлером (интерпретатором)?

15. Почему файлы с тест-комплектами нужно хранить в CVS?

16. Почему рассмотрение тест-кейсов выгодно не только компании,

но и самому тестировщику?

17. Что такое тест приемки?

18. Что случается, если тест приемки не пройден?

19. В чем отличия тестирования новых функциональностей от рег-

рессивного тестирования?

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

должны исполнять в последующих релизах для регрессивного

тестирования. Соответственно наступает момент, когда столько

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

можности их исполнить в пределах временных рамок без ущерба

для исполнения тест-кейсов для новых функциональностей. Что

делать? (Ответ будет в одном из следующих разговоров.)

21. Придумайте аналогию из жизни, чтобы проиллюстрировать

слово "релиз".

22. Перечислите виды релизов.

23. Может ли быть в основном релизе код с зафиксированными

багами предыдущего релиза?

24. Если ответ на предыдущий вопрос положительный, то почему

мы не выпустили патч-релиз, а ждали следующего релиза?

25. Что означает номер релиза 11.44?

26. Обоснуйте необходимость CVS для процесса разработки ПО и

релиза.

27. Что такое бранч CVS и для чего он нужен?

28. Назовите состояния бранча и условия для этих состояний.

29. Что такое процедура о неотложном ремонте багов и зачем она нужна?

30. Почему для бета-тестирования набирают народ из типичных

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

ЧАСТЬ 2

• ЦИКЛ ТЕСТИРОВАНИЯ ПО

• КЛАССИФИКАЦИЯ ВИДОВ

ТЕСТИРОВАНИЯ

цикл

ТЕСТИРОВАНИЯ ПО

• ИЗУЧЕНИЕ И АНАЛИЗ ПРЕДМЕТА ТЕСТИРОВАНИЯ

• ПЛАНИРОВАНИЕ ТЕСТИРОВАНИЯ

• ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ

ока мы еще не остыли от цикла разработки, предлагаю не-

медленно рассмотреть цикл тестирования.

П

Поехали.

Отвлечемся от компьютеров и представим ситуацию, когда

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

жимный пылесос. После того как агрегат вытащен из коробки,

берем "Инструкцию по использованию" и мытарим чудо техники,

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

данность.

Если посмотреть на процесс более абстрактно, можно увидеть

три вещи, которые явились моделью пылесосного тестирования:

1. Прочитали, например, пункт 2п инструкции, чтобы понять,

как работает режим влажной уборки.

2. Мгновенно в уме составили план проверки влажной уборки:

а. Налить горячую воду в верхний бачок пылесоса.

б. Нажать на кнопку Power.

в. Нажать на кнопку Pressure.

г. И т.д. и т.п.

3. Осуществили проверку согласно плану.

131

132

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

Перейдем от тестирования пылесосов к тестированию ПО.

Цикл тестирования ПО состоит из трех этапов:

1. Изучение и анализ предмета тестирования.

2. Планирование тестирования.

3. Исполнение тестирования.

На любом из этапов может быть найден баг (как в ПО, так и в

документации), баг должен быть отремонтирован ответственным

товарищем (например, программистом или продюсером), и

качество ремонта должно быть сертифицировано тестиров-

щиком.

Свяжем цикл тестирования с циклом разработки:

1. Изучение и анализ предмета тестирования

начинаются перед утверждением спека (в завершение стадии

"Разработка дизайна продукта и создание документации") и про-

должаются на стадии "Кодирование".

2. Планирование тестирования

происходит на стадии "Кодирование".

3. Исполнение тестирования

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

Важный момент:

показанная связь между циклом разработки ПО и циклом тести-

рования – это всего лишь типичная модель взаимодействия

процессов, в то время как на практике, и особенно в стартапах,

встречается множество ситуаций, когда, например, нет спеков,

код уже написан и его срочно нужно протестировать навскидку,

нет времени на создание тест-документации и пр. Поэтому пред-

лагаю, чтобы мы, изучая цикл тестирования, абстрагирова-

лись от цикла разработки.

Что нам это даст? Гибкость, так как,

зная цикл тестирования как независимый процесс, мы сможем

легко связать его с любым циклом разработки ПО в любой ин-

тернет-компании.

Цикл тестирования ПО

133

Итак, независимый процесс, называемый циклом тестирования

ПО, состоит из трех стадий:

1. Изучение и анализ предмета тестирования.

2. Планирование тестирования.

3. Исполнение тестирования.

1. Изучение и анализ предмета тестирования

Вопрос: что можно протестировать в интернет-проекте?

Легитимные варианты ответа:

• интерфейс пользователя (например, что определенная кноп-

ка называется "Купить", а не "Кипуть");

• скорость работы веб-сайта (например, то, что при одно-

временной работе с сайтом 200 пользователей скорость за-

грузки веб-страницы составляет не более 5 секунд);

• документацию (например, что спек не содержит противо-

речий и неточностей).

Все это правильно, но есть нечто более важное.

Вопрос: для чего пользователи приходят на наш веб-сайт? Ответ:

для удовлетворения своих потребностей – покупка книг, чтение

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

Вопрос: как можно удовлетворить потребности пользователя?

Ответ: нужно

• придумать (продюсер),

• написать (программист),

• протестировать (тестировщик) и