фабпждфуквп. Савин Тестирование dot-com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
 Скачать 5.26 Mb.
|
|
Самое главное: постоянно присутствует риск, что один из программистов удалит свою работу или работу коллеги. Цикл разработки ПО 109 Пример а. После спецификации, пробормоченнои Харитонычем за рюмочкой чая, программисты начинают писать код. б. Частью кода является файл registration.py, который лежит в ди ректории /usr/local/apache/cgi-bin/ и был написан Димой два дня назад. в. Дима копирует этот файл в свою директорию /home/dima и начи нает его редактировать. г. Одновременно с ним без всякого злого умысла этот же файл копи рует и сохраняет в своей директории (/home/mitya) Митя и тоже на чинает его редактировать. д. Дима, дописав и протестировав registration.ру, переносит (move) его обратно в /usr/local/apache/cgi-bin/. е. Вслед за ним туда же переносит свою версию registration.ру и Митя, в результате чего: • в /usr/local/apache/cgi-bin/ лежит Митина редакция; • Дима рвет на себе волосы, так как не сохранил у себя ни копии первоначального файла, ни файла с новым кодом; • Митя рвет на себе волосы, так как в процессе разработки у него была работающая версия, но он ее не сохранил, а, решив, что другой алгоритм будет лучше, написал другую версию, которую, толком не протестировав, перенес в /usr/local/apache/cgi-bin/. • первый релиз откладывается, так как Митина версия registra- tion.ру абсолютно "не пашет". осле разбора полетов принимается решение об установке CVS. VS устанавливается на тест-машину и это дает следующее: Файлы хранятся в репозитарии (repository), ОТКУДА их можно взять для редактирования (checkout) и КУДА их можно положить после редактирования (checkin). При этом а) каждый раз, когда мы кладем файл в репозитарии, • не нужно менять имени файла; • мы можем комментировать, что было изменено в этом файле; • CVS автоматически присваивает файлу номер редакции (версии), уникальный для этого файла; • CVS связывает номер версии файла, комментарий к из- менениям, имя изменившего и время изменения в одну 110 Тестирование Дот Ком. Часть 1 запись (при желании можно увидеть всю историческую последовательность записей); б) если Дима взял из репозитария файл, то Митя не может его оттуда взять, пока Дима не положит его обратно. Итак, поставив старую добрую и бесплатную CVS, мы имеем: • все версии файла, каждая из которых кроме уникального номера версии имеет еще и запись об изменениях; • программистов, которые уже не могут случайно уничто- жить код друг друга; • возможность сравнить содержание файла в разных ре- дакциях. Теперь, когда наш код хранится в CVS, возникает другая задача — как сделать так, чтобы этот код стал доступным на веб-сайте для тестирования — www.main.testshop.rs? Для решения этой задачи нужно, чтобы файлы из CVS были интегрированы и отправлены по назначению в соответствующие директории тест-машины и чтобы у нас было отражение содержимого CVS • по состоянию на данный момент и • для данного релиза. Каждое такое отражение кода веб-сайта называется билдом (build). Иными словами, билд — это версия версии ПО. Билды делаются или вручную, или путем запуска билд-скриптов (build script), т.е. программ, написанных релиз-инженерами для автоматизации процесса. Как правило, билд-скрипты добавляются в сгоп (это расписание запуска программ в Линукс-системах), с тем чтобы создавать новые билды через определенные проме- жутки времени. Цель создания новых билдов заключается в том, чтобы изме- ненный код (сохраненный в CVS) стал доступным для тестиров- щиков: а. После того как программист починил баг, найденный при тестировании, он тестирует починку на своем плэйгра- унде, после чего делает checkin отремонтированного кода в CVS. б. Отремонтированный код становится частью нового билда. в. Новый билд замещает (replace) на тест-машине код преды дущего билда. Цикл разработки ПО 111 Пример Допустим, что время на создание нового билда равно 15 минутам. Билд-скрипты создают новые билды каждые 3 часа в соответствии с расписанием билдов (build schedule): в 12:00, 15:00, 18:00 и т.д. Прак- тическую ценность здесь имеют две вещи: 1. Нет смысла тестировать веб-сайт с 12:00 до 12:15, с 15:00 до 15:15, с 18:00 до 18:15 и т.д., так как билд находится в процессе создания и одна часть файлов может принадлежать старому билду, а другая — новому. 2. Если программист починил ваш баг и сделал checkln изменен- ного кода в CVS, то вы сможете протестировать починку только после следующего билда, т.е. если checkin файла в CVS произо- шел в 16:00, то протестировать починку можно после билда, ко- торый начнется в 18:00. Соответственно иногда в целях экономии времени имеет смысл попросить релиз-инженера, чтобы тот сделал внеочередной билд, причем о последнем должны быть оповещены все остальные тести- ровщики. Итак, перед проверкой починки бага убедитесь не только в том, что вы тестируете нужную версию, но и в том, что тести- руете нужный билд. Номер билда, содержащего отремонтиро- ванный код, включается программистом в запись о баге в СТБ (подробнее об этом в разговоре о СТБ). Кстати, номера билда для данной конкретной версии начинаются с единицы для первого билда (который мы проверяем во время теста приемки) и увеличиваются на единицу с каждым новым билдом. Как узнать номер билда? Спросите об этом своего релиз-инже- нера. В веб-проектах номер билда часто включается в HTML- KOJX каждой страницы веб-сайта и может быть найден, если посмотреть этот код, используя функциональность веб-браузера View source. Итак, Дима написал билд-скрипт, добавил его в сгоп, и новый билд у нас создается каждые 3 часа. С точки зрения конфигурации системы плэйграунд каждого из программистов находится на той же тест-машине. Дело в том, что на одном веб-сервере могут находиться сразу не- сколько веб-сайтов. В нашем случае: • www.mitya.testshop.rs — это адрес Митиного плэйграунда, • www.dima.testshop.rs — это адрес Диминого плэйграунда, а • www.main.testshop.rs — это веб-сайт, на который делается каждый из билдов. 112 Тестирование Дот Ком. Часть 1 Следовательно, тестировщики будут использовать именно www.main.testshop.rs для своего тестирования. Соответствующие • директория с ЯГЖ-файлами и картинками, • директория с приложением (Python и C++ файлы) и • база данных слинкованы с каждым из сайтов, так что у нас есть три конфигу- рации, независимые друг от друга. Кстати, важный нюанс о плэйграундах, билдах и CVS. Основное правило для checkin: сначала сделай быстрый юнит-тест и убедись, что твои файлы компилируются по крайней мере на твоем плэйграунде, и уже после этого делай их "публичными" через checkin в CVS. Рациональное объяснение: билды строятся из кода, хранимого в CVS. Если же код не компилируется, то билд будет сломан (build is broken) и соответственно никакого тестирования не будет. Мы касались этого правила, говоря об идее постоянной интегра- ции кода. Идем дальше. Код написан, тестирование и ремонт багов закончены. Настало время первого релиза www.testshop.rs!!! Первый релиз происходит так: 1. Подготовка машины у хостинг-провайдера (production server, просто production или live machine — машина для пользо- вателей). Когда говорили об аренде сервера хостинг-провайдера, то име- лось в виду, что мы арендовали совершенно конкретный компью- тер, который находится где-то у провайдера и имеет уникальное (в общемировом масштабе) сетевое ID, которое называется IP Address ("ай-пи адрес"). Используя этот IP Address, мы подсое- диняемся к этой машине и настраиваем а) провайдерский Линукс (например, создаем директории, редактируем разрешения и т.д.); б) провайдерский Apache (например, вносим изменения в файл конфигурации и т.д.); в) провайдерскую MySQL (например, определяем максималь ное количество соединений и т.д.). Цикл разработки ПО 113 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. Почему для бета-тестирования набирают народ из типичных пользователей? |