1 Роман Савин teстирование или Пособие по жестокому обращению с багами в интернет-стартапах

teстирование
или Пособие по жестокому
обращению с багами
в интернет-стартапах
COM
Роман Савин
Одна из причин, побудивших автора напи-
сать эту книгу, — «осознание собственного
бессилия в поисках сиюминутного практи-
ческого смысла при чтении классических
сочинений по теории тестирования...», в
особенности когда ты в поисках работы и
время дорого. «Наиболее эффективный
подход для тренинга тестировщиков — дать
им практический инструментарий, поставить
в нужную сторону мозги — и в бой...»
Эта книга и есть тот самый практический
инструментарий. Здесь вы найдете прорабо-
танную структуру, профессиональное изло-
жение темы, множество примеров и советов,
а также «...легион того, о чем вам напрямую
не напишут и не скажут, но что может быть не
менее важно для выживания в софтверной
компании, чем профессиональные знания».
Но это не все. Особенность книги в том,
как излагается материал. Роман Савин отка-
зался от традиционных канонов написания
учебных пособий и превратил книгу в живую
непринужденную беседу, насыщенную шут-
кой и иронией, не чуждую отступлений и да-
же воспоминаний, которые тем не менее
встроены в контекст и работают на предмет
как иллюстрационный материал.
Читать книгу интересно и весело. Убеди-
тесь в этом сами.
Роман Савин
tестирование
или Пособие по жестокому
обращению с багами
в интернет-стартапах
ИЗДАТЕЛЬСТВО «ДЕЛО» • МОСКВА • 2007
сом
УДК 004.415.53 ББК
32.973.2-018.2я7 С13
Савин Р.
С13 Тестирование Дот Ком, или Пособие по жестокому обра-
щению с багами в интернет-стартапах. — М.: Дело, 2007. —
312 с.
ISBN 978-5-7749-0460-0
Этот курс лекций создан для тех, кто хочет обучиться тестированию,
получить работу тестировщика в российской или западной интернет-ком-
пании, понять, как вести себя в корпоративном окружении, и добиться
профессионального и личностного роста. Он будет интересен и участни-
кам процесса разработки программного обеспечения, рекрутерам, людям,
связанным с интернетом или пишущим о нем, и просто всем желающим
понять кухню интернет-стартапов.
Книга целиком базируется на личном опыте освоения — с нуля —
профессии тестировщика и многолетней работы автора в этом качестве в
интернет-компаниях США.
УДК 004.415.53 ББК
32.973.2-018.2я7
ISBN 978-5-7749-0460-0 О Савин Р., 2007
© Корсун С.Н., иллюстрации, 2007
© Оформление. Издательство
"Дело", 2007
СОДЕРЖАНИЕ
Введение ........................................................................................10
Ч а с т ь 1
ЧТО ТАКОЕ БАГ ................................................................................... 17
ОПРЕДЕЛЕНИЕ БАГА............................................................................................. 18
ТРИ УСЛОВИЯ ЖИЗНИ И ПРОЦВЕТАНИЯ БАГА ................................................ 18
ЧТО ТАКОЕ ТЕСТИРОВАНИЕ ................................................................................ 19
ИСТОЧНИКИ ОЖИДАЕМОГО РЕЗУЛЬТАТА ........................................................ 20
ФУНКЦИОНАЛЬНЫЕ БАГИ И БАГИ СПЕКА ......................................................... 21
ЦЕЛЬ ТЕСТИРОВАНИЯ DECODED .................................................... 25
ЦЕЛЬ ТЕСТИРОВАНИЯ .......................................................................................... 25
ЧЕРНАЯ МАГИЯ И ЕЕ НЕМЕДЛЕННОЕ РАЗОБЛАЧЕНИЕ................................... 25
Разоблачение концепции о 100%-м тестировании ПО
Разоблачение концепции о количестве багов,
найденных до релиза
ИДЕЯ О СТАТИСТИКЕ ДЛЯ ПОСТРЕЛИЗНЫХ БАГОВ ....................................... 29
ТЕСТИРОВАНИЕ ИОЛ (Quality Assurance) ......................................................... 32
ИСКУССТВО СОЗДАНИЯ ТЕСТ-КЕЙСОВ ......................................... 35
ЧТО ТАКОЕ ТЕСТ-КЕЙС ......................................................................................... 35
СТРУКТУРА ТЕСТ-КЕЙСА... .................................................................................. 37
ИСХОД ИСПОЛНЕНИЯ ТЕСТ-КЕЙСА (test case result) .................................... 39
ПОЛЕЗНЫЕ АТРИБУТЫ ТЕСТ-КЕЙСА ................................................................. 39
ТЕСТ-КЕЙСЫ, УПРАВЛЯЕМЫЕ ДАННЫМИ ......................................................... 43
ПОДДЕРЖИВАЕМОСТЬ ТЕСТ-КЕЙСА ................................................................. 44
СКОЛЬКО ОЖИДАЕМЫХ РЕЗУЛЬТАТОВ МОЖЕТ БЫТЬ
В ОДНОМ ТЕСТ-КЕЙСЕ? ....................................................................................... 47
3
ПРОБЛЕМНЫЕ ТЕСТ-КЕЙСЫ ................................................................................ 50
ТЕСТ-КОМПЛЕКТЫ ................................................................................................55
СОСТОЯНИЯ ТЕСТ-КЕЙСА .................................................................................... 62
А НАПОСЛЕДОК Я СКАЖУ .....................................................................................63
ЦИКЛ РАЗРАБОТКИ ПО .................................................................... 67
ИДЕЯ .........................................................................................................................69
Действующие лица
Документ о требованиях маркетинга (MRD)
РАЗРАБОТКА ДИЗАЙНА ПРОДУКТА И СОЗДАНИЕ СПЕКА .............................. 71
Разница между идеей и дизайном
Действующие лица
Спеки
Болезни спеков
Статусы спека
"Черновик"
"Ожидание утверждения "
"Утверждено "
Борьба с неверными толкованиями спека
Макеты
Блок-схемы
Примеры
КОДИРОВАНИЕ ...................................................................................................... 86
Действующие лица
Документ о внутреннем дизайне кода
Личная версия сайта программиста
Причины появление багов кода
Меры по оздоровлению кода и превентированию багов
Юнит-тестирование
Концепция стоимости бага
Три основных занятия программиста
Необходимость замораживания кода
Виды багов кода Хранение
документации в CVS Обсуждение тест-
кейсов
ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ И РЕМОНТ БАГОВ ......................................... 104
РЕЛИЗ .................................................................................................................... 105
Определение, виды и версии релизов
Действующие лица Создаем
www.testshop.rs
Содержание
Содержание 5
Архитектура www.testshop.rs
CVS
Что такое билд
Первый релиз www.testshop.rs
Бранчи CVS
Бета-тестирование
БОЛЬШАЯ КАРТИНА ЦИКЛА РАЗРАБОТКИ ПО ............................................... 122
Ч а с т ь 2
ЦИКЛ ТЕСТИРОВАНИЯ ПО ............................................................ 131
ИЗУЧЕНИЕ И АНАЛИЗ ПРЕДМЕТА ТЕСТИРОВАНИЯ ...................................... 133
Что такое функциональность Источники
знания о функциональности Эксплоринг
ПЛАНИРОВАНИЕ ТЕСТИРОВАНИЯ .................................................................... 135
ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ ........................................................................ 136
КЛАССИФИКАЦИЯ ВИДОВ ТЕСТИРОВАНИЯ ........................... 139
ПО ЗНАНИЮ ВНУТРЕННОСТЕЙ СИСТЕМЫ ..................................................... 142
Черный ящик (black box testing)
Белый ящик (white box testing)
Серый ящик (grey box testing)
ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ .......................................................................... 151
Функциональное тестирование (functional testing)
Тестирование интерфейса пользователя (UI testing)
Тестирование локализации (localization testing)
Тестирование скорости и надежности
(load/stress/performance testing) Тестирование
безопасности (security testing) Тестирование опыта
пользователя (usability testing) Тестирование
совместимости (compatibility testing)
ПО СУБЪЕКТУ ТЕСТИРОВАНИЯ ........................................................................ 157
Альфа-тестировщик (alpha tester)
Бета-тестировщик (beta tester)
ПО ВРЕМЕНИ ПРОВЕДЕНИЯ ТЕСТИРОВАНИЯ ................................................ 157
До передачи пользователю — альфа-тестирование
(alpha testing)
Тест приемки (smoke test, sanity test или confidence test)
6 Содержание
Тестирование новых фунщиональностей (new feature testing) Регрессивное
тестирование (regression testing) Тест сдачи
(acceptance of certification test)
После передачи пользователю — бета-тестирование
(beta testing)
ПО КРИТЕРИЮ "ПОЗИТИВНОСТИ" СЦЕНАРИЕВ............................................. 158
Позитивное тестирование (positive testing)
Негативное тестирование (negative testing)
ПО СТЕПЕНИ ИЗОЛИРОВАННОСТИ ТЕСТИРУЕМЫХ
КОМПОНЕНТОВ ................................................................................................... 160
Компонентное тестирование (component testing)
Интеграционное тестирование (integration testing)
Системное (или энд-ту-энд) тестирование (system or
end-to-end testing)
ПО СТЕПЕНИ АВТОМАТИЗИРОВАННОСТИ ТЕСТИРОВАНИЯ ........................ 166
Ручное тестирование (manual testing)
Автоматизированное тестирование (automated testing)
Смешанное/полуавтоматизированное тестирование
(semi automated testing)
ПО СТЕПЕНИ ПОДГОТОВКИ К ТЕСТИРОВАНИЮ ............................................. 169
Тестирование по документации (formal/documented
testing) Эд Хок тестирование (Ad
hoc testing)
Ч а с т ь 3
ПОДГОТОВКА К ТЕСТИРОВАНИЮ
НИГИЛИСТИЧЕСКИЙ НАСТРОЙ И ПРАКТИЧЕСКАЯ
МЕТОДОЛОГИЯ................................................................................. 173
МЕНТАЛЬНЫЙ НАСТРОЙ ТЕСТИРОВЩИКА ..................................................... 174
МЕТОДЫ ГЕНЕРИРОВАНИЯ ТЕСТОВ ....... : ...................................................... 178
Черновик—Чистовик (dirty list — white list)
Матричная раскладка (matrices) Блок-схемы
(flowchart)
МЕТОДЫ ОТБОРА ТЕСТОВ ................................................................................ 188
Оценка риска (risk estimate) Эквивалентные
классы (equivalent classes) Пограничные
значения (boundary values)
Содержание 7
ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ
ЖИЗНЬ ЗАМЕЧАТЕЛЬНЫХ БАГОВ .................................................. 205
ЧТО ТАКОЕ СИСТЕМА ТРЭКИНГА БАГОВ ........................................................ 205
АТРИБУТЫ БАГА .................................................................................................. 209
Bug number (номер бага) Summary
(краткое описание) Description and
steps to reproduce
(описание и шаги для воспроизведения проблемы)
Элементы веб-страницы
Текст (text) Линк (link) Картинка (image) Слинкованная картинка (linked image) Однострочное текстовое поле (textbox) Многострочное текстовое поле (text entry area) Поле пароля (password field) Ниспадающее меню (pull down menu) Радио кнопка (radio button) Чекбокс (checkbox) Кнопка (button)
Attachment (приложение)
Submitted by (автор бага)
Date submitted (дата и время рождения бага)
Assigned to (держатель бага)
Assigned by (имя передавшего баг)
Verifier (имя того, кто должен проверить ремонт)
Component (компонент)
Found on (где был найден баг)
Version found (версия, в которой был найден баг)
Build found (билд, в котором был найден баг)
Version fixed (версия с починенным кодом)
Build fixed (билд с починенным кодом)
Comments (комментарии)
Severity (серьезность бага)
Priority (приоритет бага)
Notify list (список для оповещения)
Change history (история изменений)
Туре (тип бага)
Status (статус)
Resolution (резолюция)
Not assigned (не приписан) Assigned (приписан) Fix in progress (баг ремонтируется) Fixed (баг отремонтирован) Build in progress (билд на тест машину в процессе) Verify (проведи регрессивное тестирование)
8 Содержание
Fix is verified (ремонт был успешен) Verification failed (ремонт был неуспешен) Can't reproduce (не могу воспроизвести) Duplicate (дубликат) Not a bug (не баг) 3rd party bug (не наш баг) No longer applicable (поезд ушел)
ПРОЦЕСС ТРЭКИНГА БАГОВ .............................................................................245
Концептуальное рассмотрение процесса
Процесс и атрибуты Конкретный пример
ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ. СТАДИЯ 1:
ТЕСТИРОВАНИЕ НОВЫХ ФИЧА (new feature testing) .................. 257
ТЕСТ-СМЕТА (test estimation) ............................................................................. 259
КРИТЕРИЙ НАЧАЛА/ЗАВЕРШЕНИЯ (entry/exit criteria) ..................................265
ТЕСТ-ПЛАН (test plan) .........................................................................................266
ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ. СТАДИЯ 2:
РЕГРЕССИВНОЕ ТЕСТИРОВАНИЕ (regression testing) ................ 271
ВЫБОР ТЕСТ-КОМПЛЕКТОВ ДЛЯ РЕГРЕССИВНОГО
ТЕСТИРОВАНИЯ ................................................................................................... 273
РЕШЕНИЕ ПРОБЛЕМЫ ПРОТИВОРЕЧИЯ ........................................................277
Приоретизация тест-комплектов и тест-кейсов
Оптимизация тест-комплектов Найм новых
тестировщиков Автоматизация регрессивного
тестирования
Ч а с т ь 4
КАК УСТРОИТЬСЯ НА ПЕРВУЮ РАБОТУ................................... 285
МЕНТАЛЬНЫЙ НАСТРОЙ ................................................................................... 285
ЭТАПЫ ПОИСКА ПЕРВОЙ РАБОТЫ ТЕСТИРОВЩИКОМ ................................ 287
Составление резюме
Работа с агентством по трудоустройству
Компания по рекламе себя
Интервью
Нюансы живого интервью
Список типичных вопросов и правильных ответов
ИСТОРИЯ ОБ ОЛЕ И ДЖОРДЖЕ........................................................................ 306
Послесловие ................................................................................ 308
Моим любимым Маме и Марине посвящается,
чьи любовь и вера — самое драгоценное,
что я получил от жизни...
ВВЕДЕНИЕ
Основа бэкграунда тестировщика — это логика, здравый смысл и жизненный опыт.
Народная мудрость
Дорогие друзья,
я написал эти лекции по практике тестирования, чтобы просто и
задушевно рассказать вам основные вещи, которые понадобятся
для успешного старта и не менее успешной работы в интер-
нет-компании в качестве тестировщика.
Я также уверен, что тихие вечера, проведенные за чтением моего
скромного труда, откроют много полезного любому человеку, имею-
щему отношение к процессу создания программного обеспече-
ния (ПО), так как качество, как тишина в кинозале, — дело общее.
Отдельной группой благодарных читателей, несомненно, выступят
профессиональные рекрутеры, нанимающие народ для удар-
ного труда в интернет-компаниях.
Кроме того, я надеюсь, что материал будет просто интересен всем,
кто пользуется Интернетом и желает узнать, как работают интер-
нет-компании.
Приведя десятки примеров, я попытался максимально проил-
люстрировать материал, так, чтобы даже сугубо технические
детали были понятны самому широкому кругу читателей.
Моя цель — не показать, что я знаю материал (как это делает-
ся при защите диплома), а помочь ВАМ узнать материал, и ил-
люстрации (текстовые и графические) — это лучшее вспомога-
тельное средство, для того чтобы
• легче понять и усвоить смысл сказанного и
• оставить в памяти якорь ассоциации между иллюстра-
цией и проиллюстрированной мыслью.
Идем дальше.
Помимо просьб друзей, требований жены и намечающегося кри-
зиса среднего возраста на подвиг меня толкнуло то, что в начале
10
Введение 11
своей работы не раз и не два я пытался осилить классические со-
чинения по теории тестирования, но каждый раз осознание соб-
ственного бессилия в поисках сиюминутного практического
смысла не давало мне дочитать очередной фолиант.
Пример
Безработная девушка Маша П. захотела стать бухгалтером. Она приходит
на соответствующие курсы, но вместо прикладных, оплачиваемых знаний
по назначению счетов и инструкций МНС ей преподают теорию макроэко-
номики и историю бухгалтерии. Маша думает, что она не сможет осилить
бухгалтерию, и бросает курсы. В итоге Родина теряет потенциально бле-
стящего бухгалтера и обретает реально радикального члена компартии.
Я преклоняюсь перед предметом "история". О пользе Теории (с
большой буквы "Т") и говорить не приходится, но, как я убедился
на своем многолетнем опыте работы и преподавания, наиболее
эффективный подход к тренингу тестировщиков заключается
в том, чтобы дать им практический инструментарий, напра-
вить мозги в нужную сторону — и в бой, а теоретические мета-
ния тридцатилетней давности можно почитать на досуге, после
того как устроился на работу.
Кроме того, есть
• политические нюансы работы;
• распространенные ошибки менеджмента;
• продюсеры, программисты и релиз-инженеры, работу ко-
торых нужно понимать изнутри, — .
в общем легион того, о чем вам напрямую не напишут и не
скажут, но что может быть не менее важно для выживания в соф-
тверной компании, чем профессиональные знания.
Будучи человеком честным и в некоторой степени благородным,
признаюсь, что позаимствую классическое начало книг о тести-
ровании, заключающееся в трусливом: "Не используйте знания
из этой книги, если речь идет о тестировании критического ПО ".
Итак,
я свидетельствую, что все, о чем я расскажу, действительно ра-
ботает, и работает именно так в крупнейших западных интернет-
компаниях;
я также свидетельствую, что все, о чем я расскажу, в силу объ-
ективных причин не может на 100 процентов гарантировать ПО
от наличия проблем.
12 Введение
Поэтому сразу предупреждаю: эта книга не предназначена для
тех, кто собирается тестировать критическое ПО, связанное,
например, с мониторингом работы сердечной мышцы, или
ПО для поражения точечных целей в странах с большими за-
пасами нефти.
Серьезно, если речь идет о жизни людей, лучше скормите эту
книгу своему попугаю-жако (о попугаях позже).
Два важных момента:
1. В отличие от деятельности юридической деятельность тести-
ровочная (для коммерческих проектов) не регулируется нор
мативными актами или другими формальными источниками.
Поэтому нет обязательных для исполнения правил о том, как
эффективно протестировать ПО, какие документы нужно создать
и в какой форме они должны быть.
Никто не возьмет вас за горло из-за того, что ваш тест-план не
соответствует букве некого закона, пролоббированного некой
продажной шкурой из не менее продажной фракции в интересах
всем хорошо известной финансово-промышленной группы N.
В цехе тестировщиков ничто не является догмой (nothing is set in
stone) и построение добротной системы поиска и превентиро-
вания ошибок в ПО полностью отдается на откуп профессиона-
лизму, добросовестности и творчеству тех, кто работает в кон-
кретной интернет-компании.
Поэтому
многие вещи, о которых пойдет речь (подходы, документы, про-
цессы, даже названия),
• с одной стороны, имеют огромное количество вариаций в
существующих интернет-компаниях и,
• с другой — могут практически использоваться в предло-
женной форме или, еще лучше, быть подогнанными вами
под ту компанию, в которой вы работаете или, несомнен-
но, будете работать в ближайшем будущем.
2. "То, что русскому хорошо, — для немца смерть". По аналогии:
• подходы к тестированию,
• степень формализации процессов и
• используемые документы,
Введение 13
которые эффективно работают в крупных устоявшихся интернет-
компаниях, могут быть неприемлемы для интернет-стартапов
(startup — молодая, амбициозная, многообещающая компания,
живущая, как правило, короткую, но яркую жизнь), и наоборот.
Исходя из того что подавляющее большинство интернет-ком-
паний — это стартапы, говорить будем о том, как эффективно
провести тестирование и организовать процессы по улучшению
качества именно в стартапах с прицелом на то, чтобы заложить фун-
дамент департамента качества (QA department) для крупной устояв-
шейся интернет-компании, стать которой мечтает каждый стартап.
Идем дальше.
Вопрос дня: Что самое главное в нашем деле?
Ответ дня: РЕЗУЛЬТАТ!
Человек может быть прекрасным семьянином, увлекаться фото-
графией и превосходно петь арию "Libiamo Amor" из "Травиаты",
но единственная и неповторимая прелесть его как тестиров-щика
— это РЕЗУЛЬТАТ.
К вопросу о постановке мозгов и попугаях:
перед покупкой своего попугая-жако Василия я прочитал кучу
литературы, но лишь одна мысль позволила мне осознать самое
главное (в смысле домашних попугаев):
"У вас есть хобби, друзья и работа. У вашего попугая есть
только вы ".
Так вот по аналогии:
Вы можете быть наделены множеством самых прекрасных и
вечных добродетелей. Но в вашей работе тестировщика есть
единственный смысл — РЕЗУЛЬТАТ.
Каков же этот РЕЗУЛЬТАТ (пишу "РЕЗУЛЬТАТ" заглавными бук-
вами в последний раз)?
Спрашиваете — отвечаем:
результатом работы тестировщика является счастье конеч-
ного пользователя (сказать "удовлетворение клиента" как-то язык
не поворачивается). Причем "счастье" не в глобальном его значе-
нии, а та его часть, которая связана с качеством вашего продукта.
14 Введение
Например,
некто Виктор Буянов бродит по Интернету в поисках диска с москов-
ским концертом Билли Джоела. Вот он наконец находит то, что искал,
заполняет все необходимые формы и нажимает кнопку "Купить". Если
• на следующей странице будет написано: "Дорогой Виктор, мы
получили ваш заказ, ждите посылку" и
• через неделю почтальон принесет сам диск,
то честь и хвала вам как тестировщикам.
Если же на следующей странице красуется "500 — Internal Server Error"
(внутренняя ошибка сервера номер 500)... и тишина,
то пишите объяснительные.
Идем дальше.
Я дам вам знания, с которыми можно пройти интервью, получить
интересную работу и начать новую жизнь, но кроме прикладных
моментов следует твердо знать, что тестировщикам большую
часть заработной платы платят за честность, так как именно
нашему брату оказано доверие сказать "Поехали". И даже абсо-
лютно далекий от тестирования господин Буянов косвенно под-
твердил своим выбором мои слова (дальше поются строчки из
припева песни Билли Джоела "Честность" ("Honesty")):
Honesty is hardly ever heard.
And mostly what I need from you.
(Честность — это 50% + 1 единица того, что я жду от тебя.)
Перевожу тему.
Будет дано множество примеров того, что мы работаем на некий
онлайн-стартап www.testshop.rs (rs — это не глобальный домен,
как com или ru, а мои инициалы).
Многие термины будут написаны по-английски с немедленным
русским переводом и наоборот. Знание родной терминологии по-
может работе в инофирме.
Пользуясь случаем, хочу поблагодарить (в алфавитном порядке):
Алекса Хатилова (Yahoo!) за превосходные лекции, многочасо-
вые консультации по телефону и демонстрацию силы аналогий и
примеров из жизни и
Никиту Тулинова (Sun Microsystems), который принял меня, как
брата, и наставил на путь истинный.
Итак, в путь. Если что, пишите на qatest@gmail.com.

ЧАСТЬ 1
• ЧТО ТАКОЕ БАГ
• ЦЕЛЬ ТЕСТИРОВАНИЯ DECODED
• ИСКУССТВО СОЗДАНИЯ ТЕСТ-КЕЙСОВ
• ЦИКЛ РАЗРАБОТКИ ПО

ЧТО ТАКОЕ БАГ
• ОПРЕДЕЛЕНИЕ БАГА
• ТРИ УСЛОВИЯ ЖИЗНИ И ПРОЦВЕТАНИЯ БАГА
• ЧТО ТАКОЕ ТЕСТИРОВАНИЕ
• ИСТОЧНИКИ ОЖИДАЕМОГО РЕЗУЛЬТАТА
• ФУНКЦИОНАЛЬНЫЕ БАГИ И БАГИ СПЕКА
огический закон исключенного третьего гласит, что любая
вещь — это либо а, либо не-а. Третьего не дано, т.е. если у
вас есть часы "Брегет" за номером 5, то любая вещь в этом мире
будет либо вашими часами "Брегет" за номером 5, либо чем-то
другим.
Представим себе конвейер, в конце которого стоим мы. Лента
конвейера движется, и перед нами по очереди появляется по од-
ному предмету. Задача проста — ожидать появления ваших часов
"Брегет" за номером 5 и говорить "баг" при появлении любого
предмета, отличного от них.
Нетрудно догадаться, что такие предметы, как
• пакет кефира;
• будильник "Слава";
• буклет с предвыборными обещаниями кандидата в прези-
денты Н.,
будут для нас багами.
Далее. Рассмотрим, что объединяет следующие ситуации.
17
Л
18 Тестирование Дот Ком. Часть 1
1. Девушка рекламирует себя как хорошую, на все руки хо-
зяйку, а утром выясняется, что она даже яичницу пожарить
не в состоянии.
2. Вы купили книгу по интернет-тестированию, а в ней рас-
сказывается о приготовлении яичницы.
3. Девушка из пункта 1 прочитала книгу из пункта 2, но яич-
ница пересолена.
Если возвыситься над яичницей, фигурирующей в каждом из
трех пунктов, и абстрагироваться от женщин, карт и вина, то мы
увидим, что общее — это отклонение фактического от ожи-
даемого.
Разбор ситуаций.
1. Ожидаемый результат -— девушка умеет готовить.
Фактический результат — утро без завтрака.
2. Ожидаемый результат — знания по тестированию.
Фактический результат — знания по кулинарии.
3. Ожидаемый результат — яичница будет приготовлена.
Фактический результат — еще одно утро без завтрака.
Определение бага
Итак,
баг (bug) — это отклонение фактического результата (actual
result) от ожидаемого результата (expected result).
В соответствии с законом исключенного третьего у нас есть баг
при наличии любого фактического результата, отличного от
ожидаемого.
Три условия
жизни и процветания бага
Конкретный баг живет и процветает лишь при одновременном
выполнении всех трех условий:
1. Известен фактический результат;
2. Известен ожидаемый результат;
3. Известно, что результат из пункта 1 не равен результату из
пункта 2.
Что такое баг 19
Совет дня: каждый раз, когда возникает ситуация, в которой не
совпадают фактическое и ожидаемое, — мысленно штампуйте
фактическое словом "баг". Постепенно это войдет в привычку и
станет рефлексом. Для ментальной тренировки не имеет значе-
ния, насколько мелочны, низки и сиюминутны ваши ожидания,
главное — приобретение автоматизма.
Примеры багов из жизни:
1. Бутерброд падает маслом вниз.
2. Подхалимы и говоруны имеют намного больше шансов на повыше-
ние, чем скромные честные труженики.
3. Несоответствие миловидной внешности и змеиной сущности.
4. Попугай воспроизводит на людях худшее из словарного запаса хо-
зяина.
5. Автомобили российского производства.
6. Кот Бегемот в фильме В. Бортко "Мастер и Маргарита".
Идем дальше.
Что такое тестирование
Любое тестирование — это поиск багов. Испытываем ли мы
новую соковыжималку, наблюдаем ли за поведением подруги
или занимаемся самокопанием — мы ищем баги. Баги находятся
следующим образом:
1. Мы узнаем (или уже знаем) ожидаемый результат;
2. Мы узнаем (или уже знаем) фактический результат;
3. Мы сравниваем пункт 1 и пункт 2.
Как видно, каждый из нас уже является тестировщиком, так как
разного рода осознанные и неосознанные проверки, осуществ-
ляемые нами и в отношении нас, являются неотъемлемой частью
жизни, просто раньше мы непрофессионально качали головой и
выдавали тирады о несправедливости мира, но зато теперь в слу-
чае несовпадения фактического и ожидаемого мы будем с улыб-
кой мудреца смотреть на дилетантов, хлюпающих носами на мо-
сковском ветру, и тихо, но веско (как дон Карлеоне) говорить:
"Та-а-к, еще один баг".
Для иллюстрации правильного подхода приведу в пример одного
моего друга, который выстроил целую систему доказательств тезиса,
что люди и компьютеры созданы по одному образцу. Основой его аргу-
ментации явился тот факт, что и те и другие имеют физическую обо-
лочку (тело/железо) и неосязаемое составляющее, управляющее ею
20 Тестирование Дот Ком. Часть 1
(душа/ПО). Соответственно болезни тела он называл багами в железе,
а проблемы с головой — багами в ПО и очень сожалел, что ПО людей,
управляющих этим миром, состоит в основном из багов...
Теперь вспомним о том, что есть компьютерное ПО и что нам
нужно научиться его тестировать.
С фактическим результатом здесь более или менее понятно: нужно
заставить систему проявить себя и посмотреть, что произойдет.
Сложнее дело обстоит с ожидаемым результатом.
Источники ожидаемого результата
Основными источниками ожидаемого результата являются:
1. Спецификация.
2. Спецификация.
3. Спецификация.
4. Спецификация.
5. Жизненный опыт, здравый смысл, общение, устоявшиеся
стандарты, статистические данные, авторитетное мнение и др.
Спецификация на первой—четвертой ролях — это не ошибка, а
ударение на то, что спецификация для тестировщика — это:
• мать родная, а также
• Друг,
• товарищ и
• брат.
Спецификация важна для программиста и тестировщика так же,
как постановление пленума ЦК для коммуниста.
Спецификация — это инструмент, с помощью которого вы смо-
жете выпустить качественный продукт и прикрыть свою спину (в
оригинале звучит как CYA или cover your ass).
Итак, что же это за зверь?
Спецификация (или spec — читается "спек". Далее употребляется
в мужском роде) — это детальное описание того, как должно
работать ПО. Вот так, ни много ни мало.
В большинстве случаев баг — это отклонение от специфика-
ции (я говорю о компаниях, в которых спеки в принципе сущест-
вуют и ими пользуются).
Что такое баг 21
Пример
Пункт 19.а спека #8724 "О регистрации нового пользователя" устанав-
ливает:
«Поле "Имя" должно быть обязательным. Страница с ошибкой должна
быть показана, если пользователь посылает регистрационную форму
без заполнения указанного поля».
В общем все просто:
• тестировщик идет на страничку с регистрационной формой;
• кликаетлинк "Регистрация";
• заполняет все обязательные поля, кроме поля "Имя";
• нажимает на кнопку "Зарегистрироваться".
Если ошибка не показана и регистрация подтверждается, то это есть
момент истины и нужно рапортовать баг (file a bug).
Если ошибка показана, то относительно пункта 19.а на некоторое
время можно успокоиться. Мы поймем, почему можно успокоиться
лишь на некоторое время при разговоре о регрессивном тести-
ровании. ..
Функциональные баги и баги спека
Допустим, что ошибка не была показана и мы имеем классиче-
ский случай функционального бага (functional bug, или баг
обыкновенный), т.е. бага, вскормленного на несоответствии
фактической работы кода и функционального спека.
Если вы внимательно читали пункт 19.а, то не могли не заметить
(шутка), что непонятно, какое должно быть сообщение об ошибке
(error message), т.е. фактически решение отдано на откуп про-
граммисту и он может предусмотреть, что при соответствующей
ситуации код выдаст:
• НЕинформативное сообщение "Ошибка" и оставит пользо
вателя ломать голову над тем, что он сделал неправильно,
либо
• информативное сообщение «Пожалуйста, введите ваше имя
и нажмите кнопку "Регистрация"»
и в любом случае формально будет прав, так как спецификация
не детализирует текста ошибки.
Кстати, несколько лет назад был случай, когда программисты в специ-
альном ПО, разработанном для американских тюрем, оставили "рабо-
чее" название кнопки, причем тюремщикам идея так понравилась, что
они просили ничего не исправлять. Надпись на кнопке была: "Освобо-
дить подонка".
22 Тестирование Дот Ком. Часть 1
В общем сложилась ситуация, когда сама спецификация имеет
проблему, так как мы ожидаем (или по крайней мере должны
ожидать), что в спеке будут подробности о тексте ошибки, а в
реальности их там нет. Так и запишем — "баг в спецификации"
(spec bug).
Кстати, вот варианты развития ситуации с проблемным спеком:
а. Скорее всего программист все же напишет информативное сооб
щение об ошибке. Ваше дело послать е-мейл продюсеру (продю
сером в интернет-компании называют товарища, создающего
спеки), чтобы тот внес текст, уже написанный программистом, в
пункт 19. а. б. Если программист написал нечто противоречащее здравому смыслу
или стандарту, принятому в вашей компании, рапортуйте баг. в. Может случиться так, что вы не заметили проблемы в спеке и не заме
тили, как программист написал сообщение об ошибке, противореча
щее здравому смыслу или стандарту, принятому в вашей компании.
Кстати, вот две релевантные политически важные вещи:
1. Как правило, работа в стартапе — это уникальный опыт, когда тяже-
лый труд сочетается с радостью созидания, расслабленной обста-
новкой (я, например, уже многие годы хожу на работу в шортах) и
окружающими вас милыми, веселыми людьми. Но бывают нештат-
ные ситуации (например, работа не сделана в срок или сделана не-
качественно), и, когда дело дойдет до выяснения "кто виноват" и
"что с ним сделать", многие из ваших коллег перестанут быть ми-
лыми, веселыми людьми и активно начнут вешать собак друг на
друга. Так вот, чтобы одну из этих собак не повесили на вас, посы-
лайте е-мейлы, сохраняйте их и ответы на них и при случае пересы-
лайте их заинтересованным сторонам. Пригодятся те е-мейлы в
дальнейшем — хорошо, не пригодятся — еще лучше, тем более что
каши они не просят, а сидят себе тихо и малодушно в своих фолде-
рах и ничего не ждут от этой жизни.
2. Каждый должен заниматься своим делом и отвечать за свой участок
работы. В случае если спек сделан некачественно, то лучше под-
нять тревогу с рассылкой е-мейлов, чем делать допущения относи-
тельно того, как должно работать ваше ПО.
Перед завершением темы об ожидаемом и фактическом результа-
тах рассмотрим примеры других источников ожидаемого резуль-
тата, кроме спеков.
1. ЖИЗНЕННЫЙ ОПЫТ
Как справедливо отметил Борис Слуцкий: "Не только пиво-раки
мы ели и лакали". Мы также учились и работали, любили и нена-
видели, верили политикам и не слушались родителей, в общем
приобретали жизненный опыт (включая опыт работы). Так вот этот
Что такое баг 23
опыт настолько полезен в нашем черном деле, что для демонстра-
ции уважения к идее о его полезности (вместе с логикой и здравым
смыслом) я вынес ее в качестве эпиграфа во Введении. Дело в том,
что тестирование ПО — это то самое тестирование (которое мы
делаем постоянно), но только в отношении ПО. И моя задача
заключается лишь в том, чтобы дать вам основные концепции и
практический инструментарий по интернет-тестированию и помочь
их интеграции с тем, что у вас уже есть, — с жизненным опытом.
2. ЗДРАВЫЙ СМЫСЛ (дитя жизненного опыта и соответственно
внук "ошибок трудных")
Это один из наших главных союзников, порой даже и при нали-
чии спека. Например, вы тестируете веб-сайт, где пользователь
может загрузить (upload) свои цифровые фотографии. Спек гово-
рит, что пользователь может загрузить лишь одну фотографию за
раз. А что, если у него таких фотографий 200? Будет он счастлив?
Что делаем? Правильно: пишем е-мейл ж producers@testshop.rs с
предложением о включении в спек функциональности, позво-
ляющей пользователю загружать цифровые фотографии оптом.
Кстати, баг такого рационализаторского плана лицемерно назы-
вается не багом, a Feature Request ("запрос об улучшении" — пока
остановимся на таком переводе).
3. ОБЩЕНИЕ
Даже самый лучший спек может вызвать необходимость в уточ-
нениях. А что, если спека нет вообще? Наш ответ: общение. Со-
ветуйтесь с коллегами. Уточняйте и обсуждайте. Одна голова хо-
рошо, а две лучше.
4. УСТОЯВШИЕСЯ СТАНДАРТЫ
Как правило, после регистрации, пользователь должен получить
е-мейл с подтверждением. Если спек не упоминает о таком е-мейле,
вы можете потребовать дополнить его на основании сложившей-
ся практики.
5. СТАТИСТИЧЕСКИЕ ДАННЫЕ
Было установлено, что средний пользователь теряет терпение,
если web page (веб-страница) не загружается в течение 5 секунд.
Эти данные можно использовать, проводя performance testing
(тестирование скорости работы всей системы либо ее компонента).
Как говорят американцы: "Your user is just one click away from your
24 Тестирование Дот Ком. Часть 1
competitor" ("Ваш пользователь находится на расстоянии в один
клик от вашего конкурента"). Успех вашего проекта — это счастли-
вые пользователи. Превышение 5 секунд — это превращение веб-
сайта в зал ожиданий, в котором вряд ли кто захочет находиться.
6. АВТОРИТЕТНОЕ МНЕНИЕ
Это может быть, например, мнение вашего начальника.
7. ДР.
Другие.
Отметим, что баг (bug) буквально переводится как "жук" или
"букашка".
Теперь, как я и обещал, немного истории.
Согласно фольклору, баги вошли в лексикон компьютерщиков после
случая, происшедшего в Гарвардском университете в 1947 г. После то-
го как на реле прадедушки ПК Марка II присел отдохнуть мотылек, один
из контактов слегка коротнуло и весь 15-тонный агрегат со скрежетом
остановился. Инженеры проявили милосердие и извлекли мотылька,
после чего аккуратно зафиксировали его скотчем в журнале испытаний
с комментарием "Первый фактический случай найденного жука" ("First
actual case of bug being found").
Итак,
Краткое подведение итогов
1. Баг — это отклонение фактического результата от ожидаемого.
2. Главный источник ожидаемого результата в интернет-компании —
это спецификация.
3. Спецификации сами не без греха, и в этом случае, как и в случае
полного их отсутствия, у нас есть здравый смысл, устоявшиеся
стандарты, опыт работы, статистика, авторитетное мнение и др.
Задания для самопроверки
1. Ищите баги в чем угодно, введите это слово в свой лексикон и
расписывайте самые яркие из них на листе бумаги по схеме:
Ожидаемый результат/Фактический результат.
2. Подумайте, какие еще источники ожидаемого результата могут
быть в работе тестировщика.
3. Побродите по Интернету, порегистрируйтесь (www.yahoo.com,
www.hotmail.com и т.д.) и составьте список обязательных полей
(required fields) на регистрационных формах.
ЦЕЛЬ ТЕСТИРОВАНИЯ
DECODED
• ЦЕЛЬ ТЕСТИРОВАНИЯ
• ЧЕРНАЯ МАГИЯ И ЕЕ НЕМЕДЛЕННОЕ РАЗОБЛАЧЕНИЕ
• ИДЕЯ О СТАТИСТИКЕ ДЛЯ ПОСТРЕЛИЗНЫХ БАГОВ
• ТЕСТИРОВАНИЕ И QA (Quality Assurance)
ез рассусоливаний и теоретизирования я прямо скажу, для
чего все это нужно.
Цель тестирования
Цель тестирования — это нахождение багов до того, как их
найдут пользователи.
Другими словами, вклад тестировщика в счастье пользовате-
ля — это приоритет в нахождении багов.
Пусть в мире, где история искажена, ценности поруганы, а исти-
ны ненадежны, слова, сказанные выше, будут скалой, в прочно-
сти которой вы будете постоянно убеждаться.
А теперь:
Черная магия
и ее немедленное разоблачение
Есть две концепции, о которых необходимо знать, потому что
они распространены и вредят как тестировщикам в частности, так
и компании в целом.
25
Б

Цель тестирования Decoded 27
ПЕРВАЯ КОНЦЕПЦИЯ: цель тестирования — это 100%-я про-
верка ПО.
РАЗОБЛАЧЕНИЕ ПЕРВОЙ КОНЦЕПЦИИ
Вот вам код, написанный на языке программирования Python
(здесь и далее номер является номером строки для удобства ссы-
лок и не принадлежит к коду, за знаком # следует комментарий
для данной строки):
1. user input = raw_input ("What is your totem animal?") #
"Введите название вашего тотемного животного".
2. if user_ input == "frog": # ЕСЛИ пользователь ввел "лягушка",
3. print "You probably like green color" # вывести на
экран "Вероятно, вам нравится зеленый цвет".
4. elif user_input == "owl": # ЕСЛИ пользователь ввел "сова",
5. print "You probably like grey color" # вывести на
экран "Вероятно, вам нравится серый цвет".
6. elif user_input == "bear ": # ЕСЛИ пользователь ввел "медведь",
7. print "You probably like brown color" # вывести на
экран "Вероятно, вам нравится коричневый цвет".
8. elif user_input == "": # ЕСЛИ пользователь не ввел никаких
данных,
9. print "Probably, you don't know what is your totem
animal" # вывести на экран "Вероятно, вы не знаете свое
тотемное животное".
Это маленькая, симпатичная и на первый взгляд никчемная про-
грамма послужит нам для того, чтобы мы увидели 4 условия
(conditions), одно из которых заработает, если мы ее запустим.
Если условие верно, например, пользователь ввел "frog", то, как
за преступлением — наказание (в идеальном случае), наступает
последствие — выполнение условия (конечно, если код
работает) — вывод на экран текста "You probably like green
color". Ежу понятно, что для тестирования нам нужно проверить
все 4 условия.
1. Ввести "frog".
2. Ввести "owl".
3. Ввести "bear".
4. Ничего не вводить, а просто равнодушно нажать Enter.
28 Тестирование Дот Ком.Часть 1
Однако если ввести "hedgehog" ("еж"), то Python по-английски
(т.е. без всякого сообщения) закончит выполнение программы.
Итак, добавим к нашим четырем условиям игольчатое пятое:
5. Любой ввод, отличный от ввода 1—4 включительно.
Постановка мозгов
Везде, где есть ввод (input) данных, у нас есть два пути:
1. Ввод действительных данных (valid input).
2. Ввод недействительных данных (invalid input).
Пустой ввод (Null input) может принадлежать как к действительному,
так и к недействительному вводу в зависимости от спецификации.
Например, при регистрации в поле для Имени буквы (letters) или в со-
четании буквы и пробелы (white space) — это действительный ввод,
цифры (numbers), специальные знаки (special characters, например "&")
и/или пустой ввод — это недействительный ввод. Если спек не делает
уточнений, что есть действительный и недействительный ввод, посы-
лайте е-мейл продюсеру, а если спека нет в принципе, то полагайтесь
на пункт 5 источников из предыдущей лекции.
Итак, у нас есть пять условий, и нам вполне по силам проверить
каждое из них.
Что, если условий у нас 1000?
Пример
1. for line in range( 1000): # для каждого номера от 0 до 999
2. print "My number is "+str(line) # напечатать значение номера.
Первым значением вывода будет "My number is 0 ".
Последним значением вывода будет "My number is 999 ".
Допустим, что мы должны протестировать каждое из 1000 кон-
кретных значений вывода. Ожидаемым результатом первого вит-
ка цикла будет 0, второго — 1, энного — {п - 1).
Если кому-то проверка 1000 ожидаемых результатов покажется
терпимой задачей, то мы можем привести пример со встроенным
циклом:
Пример (do not try it at home — не пытайтесь запустить этот код на
своем компьютере!)
1. for line in range( 1000): #для каждого номера от 0 до 999
2. for item in range( 1000): # для каждого номера от 0 до 999.
3. amount =line + item # сложить два значения.
4. print "Сумма равна "-/-amount # напечатать значение суммы.
Цель тестирования Decoded 29
В итоге получается миллион (1000 х 1000) ожидаемых результатов.
Добавим масла в огонь: в большинстве случаев с реальным ПО
мы интегрируем одни части кода с другими и в итоге получаем
столько вариантов конкретных значений ожидаемых результатов,
что на 100%-ю проверку не хватит и пяти жизней. Шести жизней
хватить должно, но они будут самыми печальными из всех исто-
рий о бессмысленном существовании.
Постановка мозгов
В мире с ограниченными ресурсами (например, время на тестирова-
ние) 100%-е тестирование ПО — это фикция (я говорю о реальном
ПО, а не о программах из наших примеров) и единственное, что мы
можем сделать как тестировщики, — это профессионально, творчески
и добросовестно спланировать и провести наше тестирование. Про-
сочившиеся баги — это неизбежное зло, но свести его к мини-
муму — в наших руках.
ВТОРАЯ КОНЦЕПЦИЯ: критерий эффективности тестирования —
это количество багов, найденных до релиза.
РАЗОБЛАЧЕНИЕ ВТОРОЙ КОНЦЕПЦИИ
Допустим, открывается новый обувной магазин на Кузнецком,
чтобы все развитые личности ходили в лаковых ботинках.
Скажите, имеет ли значение для развитой личности, сколько де-
нег и сил было потрачено на покупку и ремонт помещения? От-
вет отрицательный: единственное, что ее интересует, — это
сходная цена и качество обуви. Так и в нашем интернет-магазин-
ном деле: пользователю все равно (и это правильно), сколько
вы не спали ночей, сколько вы нашли багов и скольких деву-
шек оставили без романтического ужина. Пользователю нуж-
но, чтобы наш онлайн-магазин работал качественно. Точка.
Идем дальше.
Идея о статистике для пострелизных багов
Итогом разработки ПО является передача этого ПО пользовате-
лю, называемая "релиз" (release).
Допустим, что перед первым релизом нашли 50 багов, а перед
вторым — 200. Казалось бы, во втором случае тестирование про-
шло более успешно. Но в реальности вполне может быть, что по-
сле первого релиза пользователи найдут 2 бага, а после второго —
30 Тестирование Дот Ком. Часть 1
22 бага. Тестирование какого релиза было более эффективным?
Очевидно, что первого, так как первый релиз дал возможность
пользователям познакомиться только с двумя багами в отличие
от второго релиза — с 22 багами.
Кроме того, результаты тех же самых усилий, но приложен-
ных для тестирования разных функциональностей могут
серьезно различаться. Это происходит потому, что предмет тес-
тирования, т.е. некая часть нашего ПО, подвергнутая тестирова-
нию, каждый раз уникален. Уникален качеством кода, сложно-
стью и трудоемкостью тестирования и прочими вещами.
Кстати,
один из критериев качества кода — это количество багов на
1000 строк кода.
Почему же так популярно представление количества багов ДО
релиза в качестве цели и критерия эффективности тестирования?
Поставьте себя на место менеджера отдела тестирования. Ему
нужны просто количественные данные, чтобы показать своим
менеджерам, что в коде данного релиза под его чутким руковод-
ством тестировщики нашли столько-то багов.
Еще одной причиной любви к количеству багов, найденных до
релиза, может быть элементарное незнание основ тестирования
(в которые мы, кстати, незаметно, но верно вгрызаемся).
Итак,
количество багов, найденных до релиза, ничего не говорит об
эффективности тестирования.
Баги, найденные после релиза, — вот что нас угнетает и
преследует в бессонные лунные ночи.
Кстати, если уж мы заговорили о статистике и цифрах, давайте
скажем пару слов о том, как мы используем данные о таких вот
пострелизных багах.
Сначала определимся с тем, что баги бывают разных приори-
тетов, которые отражают важность бага. Скажем, если у
машины на дороге отваливается колесо, это Ш (баг высшего
приоритета). Таких приоритетов обычно 4. Соответственно к
П4 относятся самые незначительные баги (как небольшая цара-
пина на боку автомобиля).
Цель тестирования Decoded 31
Итак, после каждого релиза данные о багах, найденных после
релиза, классифицируются по заданным критериям и анали-
зируются на предмет нахождения слабого звена в процессе
разработки ПО.
Критериями могут быть приоритет, функциональность, имя тес-
тИровщика и др.
Пример
После очередного релиза мы совместили статистику по критериям
• функциональность             и
• приоритет.
Функциональность
Приоритет
Регистрация Поиск Корзина Оплата
П1 1 0 0 7
П2 0 1 0 2
ПЗ 2 0 0 0
П4 3 2 4 0
При попытке найти "рекордсменов" можно увидеть, что совсем груст-
ная картина сложилась с оплатой (7 П1).
Еще один пример, чтобы показать, какова польза от сопоставле-
ния статистики от релиза к релизу и что нужно делать с теми, кто
эту статистику портит.
Пример
Допустим, что у нас постоянно возникают проблемы с "Оплатой". После
каждого из релизов в ней находят по несколько П1 и П2, т.е. появился
устойчивый паттерн (pattern — шаблон, тенденция) проблемы. Все спе-
ки по оплате составлены продюсером, весь проблемный код написан
программистом и проверен тестировщиком. Первое, что приходит в
голову, — во всем виноват тестировщик. Но если проявить человеко-
любие и талант руководителя, то может всплыть:
• продюсер пишет совершенно мерзопакостные спеки;
• тестировщик в свое время женился на невесте программиста,
всячески избегает его;
• оба они ненавидят продюсера, так как тот является зятем прези-
дента компании.
32 Тестирование Дот Ком. Часть 1
Дальнейшее расследование показывает, что
• продюсер не имеет ни бэкграунда, ни документации, чтобы
понять все нюансы "Оплаты", связанные с электронными пла-
тежами;
• программист и тестировщик зарекомендовали себя как блестя-
щие профессионалы на всех проектах, когда их пути не пересе-
кались.
А вы говорите "Элементарно, Ватсон"! Вот оно, истинное рас-
следование! А то обидели бы бедного тестировщика, а в следую-
щий раз все повторилось бы.
Заметьте, что ко всему этому мы пришли, начав с анализа стати-
стики, а это уже не тестирование, a QA (Quality Assurance — бук-
вально "обеспечение качества", произносится "кью-эй").
Тестирование и QA (Quality Assurance)
Рассмотрим базовую концепцию QA и то, как оно соотносится с
тестированием.
Пример
Лежит дома на диване некий член правления некого крупного банка.
Весь такой благообразный, вальяжный и циничный, как будто он всегда
был и будет членом правления. Тишину разрывает звонок телефона,
холеные пальцы снимают трубку, и в сознание проникает голос быв-
шей жены, которую он бросил 11 лет назад, сразу после своей первой
сделки с продажей вагона ворованных противогазов. Бывшая жена го-
ворит, мол, твой сын прогуливает уроки математики и рисования, це-
луется в подъезде с соседской Дашкой, которая на два года старше
него, перестал гулять с собакой и начал курить. В общем, дела плохие.
Так вот,
QА-подход — это изначально остаться с женой и воспитывать сына.
Тестирование — это когда после звонка оставленной жены экс-
хузбенд запирает сынишку в своей загородной резиденции, ограничи-
вает его духовную и половую жизнь полным собранием произведений
Ги Де Мопассана, выписывает из Англии учителей, устраивает педсо-
вет и говорит, что у них есть 3 года, чтобы неуч, тунеядец, курильщик и
сексоман стал образованным, трудолюбивым и здоровым членом ци-
вилизованного общества.
Таким образом,
QA — это забота о качестве в виде превентирования появле-
ния багов, тестирование — это забота о качестве в виде обна-
ружения багов до того, как их найдут пользователи.
Цель тестирования Decoded 33
Общее в QA и тестировании заключается в том, что они призваны
улучшить ПО, различие между ними — в том, что
• QA призвано улучшить ПО через улучшение процесса
разработки ПО;
• тестирование — через обнаружение багов.
Несмотря на то что большая часть книги посвящена тестирова-
нию, многие вещи будут рассмотрены именно с точки зрения
Quality Assurance.
В реальных компаниях инженер, который занимается улучшени-
ем процесса разработки ПО, должен иметь очень серьезную под-
держку в менеджменте компании, чтобы быть в состоянии про-
вести свои идеи качества в жизнь. Без такой поддержки никакого
прока от инженера по качеству не будет, каким бы гениальным
специалистом он ни был.
Кстати, западные компании часто нанимают аудиторов для проверки
внутренних процессов. Если ваша компания решит нанять аудитора,
который стоит больших денег, то постарайтесь не заключать договор с
крупной аудиторской компанией, которая элементарно может вам
подсунуть ничего не понимающего в деле товарища с кожаным порт-
фелем, а лучше заключите контракт с конкретным специалистом по ка-
честву, проведя ряд интервью и найдя того, кто действительно разби-
рается в своем деле. Запомните, что аудитом кормятся много парази-
тов, которые напишут вам бессмысленные, но солидно презентован-
ные заключения и рекомендации,, которые вам никогда не пригодятся,
и впоследствии вы будете долго ломать голову, пытаясь понять, ЗА ЧТО
же вы все-таки заплатили.
Кстати, хотя инженер по качеству (QA Engineer) и тестировщик (Test
Engineer) — это разные профессии, тестировщиков часто называют
инженерами по качеству.
Пара мыслей вдогонку к сказанному.
Пример с батькой и сынкой позволяет нам понять и ощутить со
всей болью русской интеллигенции, что тестировщики имеют
Дело с ПО, переданным им программистами уже в кривом и
порочном состоянии. С этим соприкасается правильная, сладкая
и полезная идея, что за качество не могут быть ответственны
только тестировщики.
Качество (как и его отсутствие) — это результат
• деяний всех участников процесса разработки ПО, а также
• отлаженности и настроек самого процесса.
34 Тестирование Дот Ком.Часть 1
Краткое подведение итогов
1. Цель тестирования — это нахождение багов до того, как их най
дут пользователи.
2. Нехватка ресурсов не позволит стопроцентно протестировать
сколько-нибудь сложное ПО.
3. Не имеет никакого значения, сколько багов было найдено до
релиза.
4. Статистика багов, найденных после релиза, и ее последующий
анализ могут помочь идентифицировать проблемные участки
процесса разработки ПО. Сопоставление статистики от релиза к
релизу дает, как правило, устойчивый паттерн проблемы, если
таковая существует.
5. QA направлено на превентирование багов, тестирование — на
поиск багов.
6. Тестировщики одни не могут обеспечить качество ПО. Обеспе-
чение качества — это задача всех участников процесса раз-
работки ПО. Важными факторами, влияющими на качество,
являются отлаженность и настройки самого процесса разработки
ПО.
Вопросы и задания для самопроверки
1. У вас есть 5 функциональностей, и отведенного времени не хва-
тит, чтобы тщательно протестировать их все. На основании чего
вы расставите приоритеты в тестировании? Подсказка: помните
о счастье пользователя.
2. Петров нашел 50 багов до релиза, но пропустил 5 багов, которые
были найдены пользователем. Сидоров нашел 12 багов до
релиза, не пропустив ни одного. Кому дать премию?
3. Как должен поступить менеджер, чтобы решить вопрос с про-
блемой оплаты?
4. Придумайте аналогию, демонстрирующую разницу между ОА и
тестированием.
ИСКУССТВО СОЗДАНИЯ
ТЕСТ-КЕЙСОВ
• ЧТО ТАКОЕ ТЕСТ-КЕЙС
• СТРУКТУРА ТЕСТ- КЕЙСА
• ИСХОД ИСПОЛНЕНИЯ ТЕСТ-КЕЙСА •
ПОЛЕЗНЫЕ АТРИБУТЫ ТЕСТ-КЕЙСА
• ТЕСТ-КЕЙСЫ, УПРАВЛЯЕМЫЕ ДАННЫМИ •
ПОДДЕРЖИВАЕМОСТЬ ТЕСТ-КЕЙСА
• СКОЛЬКО ОЖИДАЕМЫХ РЕЗУЛЬТАТОВ МОЖЕТ БЫТЬ
В ОДНОМ ТЕСТ-КЕЙСЕ?
• ПРОБЛЕМНЫЕ ТЕСТ-КЕЙСЫ
• ТЕСТ-КОМПЛЕКТЫ
• СОСТОЯНИЯ ТЕСТ-КЕЙСА
• А НАПОСЛЕДОК Я СКАЖУ
ы исполняем тестирование, т.е. непосредственно "рвем на
куски" ПО, руководствуясь нашей профессиональной до-
кументацией — тест-кейсами (test case). Поговорим о формаль-
ной стороне эффективного тест-кейса и коснемся объединений
тест-кейсов — тест-комплектов (test suite).
Что такое тест-кейс
Допустим, что перед сборами на рыбалку мы составили следую-
щий список:
1. Удочка.
2. Коробка с запасными поплавками и леской.
3. Банка с червями.
35
М

Искусство создания тест-кейсов 37
4. Стакан граненый.
5. Бутылка "Абсолюта".
6. Огурец соленый.
Затем при деятельном участии жен, детей и котов мы наконец
собрались в дорогу и перед выходом взяли список и проверили
рюкзак на наличие каждого из 6 предметов.
Так вот.
Каждая из 6 строк списка — это и есть тест-кейс (test case).
Сам список является тест-комплектом (test suite).
Процесс придумывания и написания каждой строки списка
называется созданием тест-кейса (test case generation).
Процесс проверки рюкзака на наличие определенного пред-
мета — исполнением тест-кейса (test case execution).
Test case можно перевести как "тестируемая ситуация" и как
"оболочка для теста", оба перевода легитимны и представляют
собой идеальный союз для понимания места и значения тест-кей-
сов в этом жестоком мире.
Главная и неотъемлемая часть тест-кейса — это ожидаемый
результат, например "огурец соленый", т.е. тест-кейс может
полностью состоять только из ожидаемого результата.
Структура тест-кейса
Проблема в том, что для нахождения бага (что является смыслом
любого тестирования) кроме ожидаемого нам нужен и фактиче-
ский результат. В случае с огурцом мы просто заглядываем в
рюкзак и смотрим, на месте ли этот "фрукт". В случае же тести-
рования ПО, как правило, необходима инструкция, как прийти к
фактическому результату.
Пример
Допустим, тестировщику А. Боброву, который только что начал рабо-
тать в нашем стартапе www.testshop.rs, дали для исполнения следую-
щий тест-кейс:
"Оплата может быть произведена картой VISA". Сразу же
возникает по крайней мере две проблемы:
38 Тестирование Дот Ком. Часть 1
• для исполнения тест-кейса нужна тестировочная карта VISA,
которой у него нет;
• он не знает, как проверить, был ли действительно осуще-
ствлен платеж, даже если бы у него была карта.
Единственное, что более или менее понятно, — это процесс по-
купки в интернет-магазине (найти товар, добавить в корзину и
т.д.), что в данной ситуации помогает немного. Естественно, что
никакого тестирования не будет, так как пробиться к фактиче-
скому результату так же трудно, как доказать инспектору ГАИ,
что брать взятки аморально.
Пример
Допустим, тестировщику А. Боброву, который только что начал рабо-
тать в нашем стартапе www.testshop.rs, дали для исполнения следующий
тест-кейс: Шаги:
1. Открой www.main.testshop.rs
2. Введи в поле "Имя пользователя": "testuser1"
3. Введи в поле "Пароль": "pa$$wOrd"
4. Нажми кнопку "Войти"
5. Введи в поле "Поиск": "book117"
6. Нажми кнопку "Найти"
7. Кликни линк "Добавить в корзину"
8. Кликни линк "Корзина"
9. Кликни линк "Оплатить"
10. Выбери из меню "Вид карты": "VISA"
11. Введи в поле "Номер карты": "9999-5148-2222-1277"
12. Введи в поле "Действительна до": "12/07"
13. Введи в поле "CW2": "778"
14. Нажми кнопку "Завершить заказ"
15. Запиши номер заказа __________
16. Запроси базу данных:
select result from cc_transaction where id = <номер заказа >;
Ожидаемый результат: "10"
Очевидно, что тест-кейс из последнего примера вполне может
быть исполнен любым, кто знает, как напечатать "pa$$wOrd".
В последнем примере (который мы назовем тест-кейс с картой) к
ожидаемому результату (ОР) добавились шаги (steps), которые
должны привести нас к фактическому результату (ФР), необ-
ходимому, чтобы узнать, есть баг или нет. Совокупность шагов
называется процедурой (procedure).
Если провести аналогию, то
• шаги — это ступеньки лестницы;
Искусство создания тест-кейсов 39
• ожидаемый результат — это некий предмет, который мы
должны найти, если поднимемся по этим ступенькам;
• фактический результат — это то, что мы реально нашли
после того, как поднялись по этим ступенькам.
Постановка мозгов
ИСХОДЯ ИЗ ОСНОВНОЙ компьютерной концепции ВВОД/ВЫВОД (на языке
оригинала — input/output):
• шаги — это инструкция по вводу;
• исполнение шагов — это ввод;
• ожидаемый результат — это ожидаемый вывод;
• фактический результат — это фактический вывод.
Исполнение тест-кейса завершается сравнением вывода факти-
ческого и вывода ожидаемого.
Исход исполнения тест-кейса (test
case result)
Каждый тест-кейс, исполнение которого завершено, дает нам од-
но из двух:
1. Положительный исход (PASS), если ФР равен ОР,
либо
2. Отрицательный исход (FAIL), если ФР не равен ОР: най
ден баг!
Иногда возникает ситуация, когда мы заблокированы (test case
execution is blocked), так как не можем пройти ВСЕ шаги тест-
кейса. Например, мы не можем продвинуться дальше, если кноп-
ки "Завершить заказ" из шага 14 не существует на соответствую-
щей веб-странице. В таком случае мы рапортуем баг (в данном
случае баг об отсутствии кнопки "Завершить заказ") и отклады-
ваем исполнение тест-кейса до устранения бага.
Полезные атрибуты тест-кейса
УНИКАЛЬНЫЙ ID (Unique ID)
Это необходимая вещь. Тест-кейс без ID — это то же самое, что
квартира без адреса или швейцарские часы без номера. ID должен
быть уникальным в пределах не только документа, содержащего
тест-кейс (об этом документе позже), но и всего департамента
40 Тестирование Дот Ком. Часть 1
качества. Рациональное обоснование: со временем появится не-
обходимость вести статистику по тест-кейсам, обновлять, удалять
или переносить в другой документ некоторые из них, прикрывать
спину и т.д.
ПРИОРИТЕТ ТЕСТ-КЕЙСА (Test Case Priority)
Это важность тест-кейса. Важность отражается по шкале от 1 до п,
где 1 — это высший приоритет, а п — это низший приоритет.
Думаю, что рационально делать п = 4.
Допустим, тест-кейс, проверяющий, работает ли кнопка "Купить",
будет 1-го приоритета, а тест-кейс, проверяющий цвет шрифта
линка "Гостевая книга", будет 4-го приоритета. Концептуально,
думаю, понятно.
Зачем это делается? Допустим, у нас есть два тест-кейса: один 1-
го приоритета и другой — 3-го приоритета, оба тестируют некую
функциональность А, и есть время для исполнения только одного
из них. Естественно, что мы выберем тест-кейс 1-го приоритета.
Приоритезация тест-кейсов особо полезна при регрессивном
тестировании, о котором мы не раз будем говорить.
Вопрос: Как присваиваются приоритеты?
Ответ: Конечно, все зависит от компании, но, как правило, автор
тест-кейса просто решает, насколько жизненно важна, опреде-
ляюща и критична вещь, проверяемая данным тест-кейсом.
ИДЕЯ (IDEA)
Это описание конкретной вещи, проверяемой тест-кейсом (в даль-
нейшем эту конкретную вещь мы также будем называть "идея
тест-кейса").
Пример
В тест-кейсе с картой ожидаемым результатом является значение "10"
в колонке result строки с нашей транзакцией. Поймет ли, ЧТО мы тес-
тируем, человек, который не знает, что программисты www.testshop.rs
обозначают первую цифру результата транзакции индексом кредитной
карты (где "1" — это VISA, "2" — MasterCard, "3" — Switch), а вторую —
флагом успеха (где "О" — это успех, а "1" — ошибка) и соответственно
"10" означает, что транзакция с картой VISA была успешной?
Дело в том, что "непосвященным" может стать даже автор тест-
кейса, скажем, через месяц после написания, так как все в мире
тленно и забываемо (кроме, конечно, первой школьной любви
Искусство создания тест-кейсов 41
Ани В.)- Поэтому в начале тест-кейса следует написать на чело-
веческом языке: "Оплата может быть произведена картой VISA",
чтобы любой, кто возьмет этот тест-кейс в руки, не ломал голову,
а сразу понял, что проверяется этим тест-кейсом.
ПОДГОТОВИТЕЛЬНАЯ ЧАСТЬ (SETUP and ADDITIONAL INFO)
Кулинарный рецепт, как правило, включает две части:
1. Список ингредиентов и количество/вес каждого из них;
2. Инструкция по тому, как жарить, парить и варить несчаст-
ных из пункта 1.
Первая часть рецепта нужна для того, чтобы повар мог знать
заранее, видеть в одном месте все необходимые составляющие
блюда и иметь их под рукой, когда "настанет день и час". В
общем выделение подготовительной части удобно, логично и
практично.
В подготовительную часть тест-кейса могут включаться:
• данные о существующем эккаунте пользователя (legacy user
account) или инструкции по созданию нового эккаунта (new
user account);
• другие данные, используемые в тест-кейсе, например атри-
буты используемой кредитной карты;
• запросы к базе данных (SQL queries), используемые в тест-
кейсе;
• комментарии в помощь тестировщику, например о ню-
ансах, которые могут встретиться при исполнении тест-
кейса;
• другие вещи, облегчающие исполнение и поддержку тест-
кейса (о поддержке мы еще поговорим).
ИСТОРИЯ РЕДАКТИРОВАНИЯ (Revision History)
Очень полезная вещь.
Пример
Допустим, у Макса Крылова живет попугай-жако Вася. Макс учит его
хорошим фразам:
— "Вася хороший";
— "Amicus Plato, sed magis arnica Veritas" ("Платон мне друг, но истина
дороже");
— "Beatles forever" («ВИА "Битлз" будет вечно жить в наших сердцах»).
42 Тестирование Дот Ком. Часть 1
Приходит друг Лежа и, пока Макс на правах радушного хозяина несется
к ларькам станции метро "Юго-Западная" и обратно, учит альтерна-
тивной мудрости честно впитывающего знания Васю:
— "Все козлы";
— "Simia quantum similis turpissima bestia nobis!" ("Как похожа на нас
мерзейшая тварь — обезьяна!");
— "Move bitch, get out the way" ("Уйди с дороги, противная").
В итоге после возвращения домой Макса встречает не добрый, милый
попугайчик, а негативно настроенная машина, и вечером ему (Максу)
придется доказывать своей жене, что это не он, а подлец Леха изменил
лексикон бедолаги Василия.
Для того чтобы иметь сведения о рождении и истории развития
каждого тест-кейса, мы ведем лаконичный журнал изменений,
где отражаем: Кто? Что? Зачем? Когда? Почему?
Атрибуты истории редактирования:
• Created on <date> by <name> — Тест-кейс создан <дата>
<кем>;
• Modified on <date> by <name> — Тест-кейс изменен <да-
та> <кем>;
• Change — Что, зачем и почему было изменено. В наших
примерах мы не печатаем само слово "change", а просто
заполняем значение этого атрибута в поле справа от
"Created on..." или "Modified on...".
Давайте создадим тест-кейс с картой, используя только что полу-
ченные знания по полезным атрибутам тест-кейса:
ТС ID/Priority CCPG0001 1
IDEA: Оплата может быть произведена картой VISA SETUP and
ADDITIONAL INFO:
Эккаунт: testuser1/paSSwOrd Наименование товара: book117 Данные
карты:
Номер: 9999-5148-2222-1277
Окончание действия: 12/07
CVV2: 778
SQL1: select result from cc_transaction where id = <номер заказа>;
Revision History
Created on: 11/17/2003 by О.Тарасов Новый тест-кейс
Искусство создания тест-кейсов 43
Execution part
PROCEDURE EXPECTED RESULT
1. Открой www.main.testshop.rs > "10"
2. Введи имя пользователя. 3. Введи пароль. 4. Нажми кнопку "Войти".
5. Введи наименование товара в поле поиска. 6. Нажми кнопку "Найти".
7. Кликни линк "Добавить в корзину". 8. Кликни линк "Корзина". 9. Кликни линк "Оплатить". 10. Выбери вид карты.
11. Введи номер карты.
12. Введи срок окончания действия. 13. Введи CVV2. 14. Нажми кнопку "Завершить заказ".
15. Запиши номер заказа
16. Запроси базу данных с SQL1
и запиши результат
Идем дальше.
Тест-кейсы, управляемые данными
Основной плюс нового тест-кейса с картой заключается в том, что
нам не нужно вносить изменения в ШАГИ, чтобы протестиро-
вать по тому же сценарию другие карты. Единственное, что
нам нужно, — это модифицировать исходные ДАННЫЕ.
Таким образом, если кроме VISA нам нужно протестировать по
тому же сценарию еще две карты, то мы
• делаем сору один раз;
• paste два раза;
• в каждом из новых тест-кейсов переписываем только пять
подчеркнутых значений, проживающих в шапке тест-кейса и
секции ожидаемого результата (меняем и ID тест-кейса — ТС ID,
который, как мы помним, должен быть всегда уникальным):
VISA
9999-5148-2222-1277
12/07
778
10
44 Тестирование Дот Ком. Часть 1
Такой вид тест-кейса называется data-driven (буквально "управ-
ляемый данными"), т.е. когда данные и инструкции по их при-
менению не смешаны, а разделены и слинкованы.
Поддерживаемость тест-кейса
Новый тест-кейс с картой хорош. Все при нем — и data-driven, и
          удобочитаемый формат, и полезные атрибуты. Проблема в том,
что веб-сайт, а особенно его часть, именующаяся интерфейсом
пользователя {User Interface или просто UI— "ю-ай"), очень часто
меняется.
Пример
Кнопка "Войти" из шага 4 легко может быть переименована во "Вход".
Следовательно, если у нас есть 3 тест-кейса, то нужно внести 3 измене-
ния. А что, если у нас 500 тест-кейсов, где упоминается кнопка "Войти",
и эти тест-кейсы разбросаны по разным документам, как мои одно-
классники по свету? Вносить 500 изменений? Скажете: "Ерунда, можно
догадаться". Но таких маленьких изменений будут десятки!!! И посте-
пенно ваши тест-кейсы будут либо хиреть без поддержки, либо потреб-
лять на поддержку уйму времени.
Пример
А что, если не имя кнопки, а сам путь, по которому вы добираетесь до
фактического результата, претерпел изменения? Например, шаги 7 и 9
станет разделять не линк "Корзина", а еще несколько дополнительных
линков и кнопок, появившихся в новой версии www.testshop.rs.
В общем проблема понятна. И имя ее — maintainability (поддер-
живаемость), т.е. насколько легко и просто можно изменить
тест-кейс при изменениях в ПО. Не думать о поддерживаемо-
сти тест-кейсов — значит не думать о завтрашнем дне, что, не-
смотря на полезность для духовной жизни, все-таки плохо для
бизнеса.
Если мы разобьем шаги нашего нового тест-кейса с картой на ло-
гические модули, получим:
1. Вход в систему (логин — log in).
2. Поиск товара.
3. Добавление товара в корзину.
4. Оплата.
5. Фиксация номера заказа.
6. Запрос базы данных.
Искусство создания тест-кейсов 45
Почему бы нам не выбросить из тест-кейса детали по следующим
позициям?
1. Вход в систему
В общем-то можно догадаться, куда ввести имя пользователя,
куда пароль и на какую кнопку нажать, тем более что в данном
случае мы не тестируем процесс логина, это было или будет сде-
лано при исполнении соответствующего тест-кейса, сейчас мы
просто грубо и бесцеремонно используем логин, легкомысленно
надеясь, подобно покупателю российского автопрома, что все
будет чики-пики.
2. Поиск товара
Все из предыдущего пункта применимо и здесь. Кроме того, до-
пустим, что book117 была удалена из нашей базы данных подлы-
ми завистниками и подхалимами. Что же нам — в отчаянии рвать
на себе волосы и кричать, что мы заблокированы? Нет, мы просто
превентируем такую ситуацию тем, что не будем давать имени
конкретного товара. Что найдется, то найдется (так как то, что
найдется, в данном случае значения не имеет).
3. Добавление товара в корзину
Концепция из "1. Вход в систему" применима и здесь.
4. Оплата
Концепция из "1. Вход в систему" применима и здесь.
О'к, с оплатой я, пожалуй, немного переборщил — не факт, что
будет абсолютно очевидно, как провести ее, и шаги все же потре-
буются.
Здесь появляется другая загвоздка: если мы производим оплату в
сотнях тест-кейсов, т.е. сотни раз включаем в тест-кейс те же
семь шагов (8—14 включительно), то при изменении даже в од-
ном из этих шагов нам придется переписывать эти сотни тест-
кейсов...
Не проще ли вынести шаги, повторяющиеся от тест-кейса к
тест-кейсу, во внешний документ и вместо них включить в
тест-кейс лишь один шаг-ссылку «Произведи ОПЛАТУ
КАРТОЙ из секции "SETUP and ADDITIONAL INFO"»? Поступив
46 Тестирование Дот Ком. Часть 1
таким образом, мы сэкономим громадное количество часов рабо-
чего времени, так как при необходимости менять шаги нужно
будет только в одном месте!
Кстати, "оплата картой" — это линк к страничке в локальной сети с со-
ответствующей инструкцией, называемой, например, "Как произвести
оплату кредитной картой".
Кстати, хорошей идеей является создание в локальной сети вашей
компании мини-веб-сайта департамента качества, где наряду с веб-
страничками с
• контактной информацией работников департамента,
• пинками к файлам с тест-комплектами,
• другой полезной информацией
расположится и внутреннее Пособие для тестировщиков (QA Knowledge
Base), где кроме прочего будут задокументированы повторяю-
щиеся сценарии.
Теперь обобщим уже известные нам мероприятия по улучшению
поддерживаемости тест-кейса:
1. Сделать тест-кейс data-driven.
2. Не описывать шаги по явно очевидным сценариям (напри-
мер, логин).
3. Не давать конкретных деталей, если они не играют роли
при исполнении тест-кейса (например, имя товара).
4. Вынести во внешний документ повторяющиеся сценарии
(например, семь шагов оплаты).
Ну, за поддерживаемость!
ТС ID/Priority CCPG0001 1
IDEA: Оплата может быть произведена картой VISA SETUP and
ADDITIONAL INFO:
Эккаунт: testuser1/paSSwOrd Данные карты:
Номер: 9999-5148-2222-1277
Окончание действия: 12/07
CVV2: 778 SQL1: select result from cc transaction where id
= <номер заказа>;
Revision History
Created on: 11/17/2003 by О.Тарасов Новый тест-кейс
Modified on: 11/26/2003 by И. Новикова Шаги были упрощены, чтобы
сделать тест-кейс более удобным
для поддержки
искусство создания тест-кейсов 47
Execution part
PROCEDURE EXPECTED RESULT
1. Открой www.main.testshop.rs > "10"
2. Войди в систему.
3. Найди любой товар.
4. Добавь товар в корзину.
5. Произведи оплату картой из секции
SETUP and ADDITIONAL INFO
6. Запиши номер заказа
7. Запроси базу данных с SQL1
и запиши результат
Идем дальше.
Сколько ожидаемых результатов
может быть в одном тест-кейсе?
Тест-кейсом проверятся только одна конкретная вещь, и в иде-
альном варианте для проверки этой вещи достаточно предусмот-
реть в тест-кейсе только один ОР, и если бы я был теоретиком, а
не практиком тестирования, то сказал бы, что ни в коем случае
нельзя включать в тест-кейс более одного ОР.
ВОТ вам случай из практики
Допустим, что в соответствии с пунктом 12.6 документа "Дизайн кода
для спека #6522" признаком того, что оплата была успешно прове-
дена картой VISA, будет одновременное наличие не одного, а двух
условий:
1. Значение "10" в соответствующей колонке соответствующей строки в
базе данных.
2. Уменьшение баланса на счете с картой VISA на сумму, равную сумме
оплаты.
То есть получается, что для тестирования одной вещи ("Оплата
может быть произведена картой VISA") нужно проверить соответ-
ствие жизненной реальности двум ожидаемым результатам.
У нас есть два пути:
1. Разложить идею тест-кейса на две идеи и создать два тест-кейса.
2. Оставить идею тест-кейса неприкосновенной и включить в один
тест-кейс два ОР, т.е. у нас складывается ситуация,
48 Тестирование Дот Ком. Часть 1
когда исполнение тест-кейса будет иметь положительный
исход, только если ОБА фактических результата совпадут
с соответствующими им ожидаемыми результатами.
Вот как будет выглядеть визуально путь 2:
ТС ID/Priority CCPG0001 1
IDEA: Оплата может быть произведена картой VISA SETUP and
ADDITIONAL INFO:
Эккаунт: testuser1/paSSwOrd Данные карты:
Номер: 9999-5148-2222-1277
Окончание действия: 12/07
CVV2: 778 SQL1: select result from cc transaction where id
= <номер заказа>; Баланс счета карты можно посмотреть здесь:
www.main.testshop.rs/1277/balance.htm
Revision History
Created on: 11/17/2003 by О.Тарасов Новый тест-кейс
Modified on: 11/26/2003 by И. Новикова Шаги были упрощены, чтобы
сделать тест-кейс более удобным
для поддержки
Modified on: 01/17/2003 by И. Новикова Изменение шагов и второй
ожидаемый результат с целью
удостоверения в снятии денег со счета
Execution part
PROCEDURE EXPECTED RESULT
1. Запиши баланс счета карты
2. Открой www.main.testshop.rs
3. Войди в систему.
4. Найди любой товар.
5. Добавь товар в корзину.
6. Произведи оплату картой из секции
SETUP and ADDITIONAL INFO
(!!! запиши полную сумму заказа:
).
7. Запиши номер заказа
8; Запроси базу данных с SQL1.
S> "10"
9. Запиши баланс счета карты > Шаг 1-Шаг 6
Как будет проходить исполнение этого тест-кейса?
Искусство создания тест-кейсов 49
Прошли восемь шагов. Остановились. Проверили. Затем
прошли девятый шаг. Остановились. Проверили.
Исход исполнения этого тест-кейса будет считаться положитель-
ным только при одновременной истинности двух условий:
1. ФР после исполнения шага 8 = "10" и
2. ФР после исполнения шага 9 = Шаг 1 - Шаг 6 (т.е. значе-
ние из Шага 1 минус значение из Шага 6).
В теории лучше было бы разбить нашу идею тест-кейса на две
части и создать два отдельных тест-кейса:
1. IDEA: "Правильное значение вставляется в базу данных
при использовании VISA".
2. IDEA: "Верная сумма списывается с баланса карты".
И если есть возможность, то ЛУЧШЕ сделать именно два тест-
кейса, НО на практике во многих случаях имеет смысл включить
в тест-кейс 2 или больше ОР, так как:
• у вас может просто не быть времени на написание, испол-
нение и поддержку двух тест-кейсов*;
• сэкономленное время можно потратить на написание, ис-
полнение и поддержку тест-кейса, которым мы бы прове-
рили другую вещь**.
Если у нас есть один случай, когда можно совместить два ОР, то напи-
сание, исполнение и поддержка двух тест-кейсов не представляет труда.
А что, еслиу нас появляются сотни дополнительных тест-кейсов?..
В результате такой экономии мы с течением времени создаем десятки
новых тест-кейсов, которые помогают нам провести более тщательное
тестирование.
Я работал с тест-кейсами, включающими более одного ОР, в
течение многих лет, проводя тестирование сложнейшего ПО,
связанного с финансовыми транзакциями, и могу сказать,
что 2 или больше ОР в одном тест-кейсе — это нормальная
практика.
Идем дальше.
Во многих случаях, когда несколько ожидаемых результатов про-
сятся в один тест-кейс, нужно проверить
• значение(-я) на веб-странице и
• значение(-я) в базе данных,
те. нужна проверка снаружи и изнутри или на front end и back end.
50 Тестирование Дот Ком. Часть 1
Постановка мозгов
Front end (читается как "фронт-энд") — это непосредственный интер-
фейс пользователя, т.е. текст, картинки, кнопки, линки и прочие вещи,
которые пользователь видите окне веб-браузера или е-мейл клиента.
Back end (читается как "бэк-энд") — это ПО и данные, находящиеся за
фасадом фронт-энда: HTML-код веб-страницы, веб-сервер, код при-
ложения, база данных и т.д.
В последнем примере мы непосредственно "разговаривали"
• с фронт-энд ом — в шаге 5, когда добавляли товар в корзину;
• с бэк-эндом — в шаге 8, когда запрашивали базу данных.
Проблемные тест-кейсы
Теперь посмотрим, какие недостатки вы должны выжигать из
своих тест-кейсов каленым железом.
1. Зависимость тест-кейсов друг от друга.
2. Нечеткая формулировка шагов.
3. Нечеткая формулировка идеи и/или ожидаемого результата.
1. ЗАВИСИМОСТЬ ТЕСТ-КЕЙСОВ ДРУГ ОТ ДРУГА
Зависимость — это антоним независимости. Независимость тест-
кейса выражается в том, что он не связан с другими тест-кейсами.
Пример
Тест-кейс 1:
Шаги:
1. Зайти в комнату.
2. Подойти к стулу.
3. Открыть правый внешний карман рюкзака.
4. Засунуть руку в правый внешний карман рюкзака.
Ожидаемый результат: Граненый стакан.
Тест-кейс 2:
Шаги:
1. Зайти в комнату.
2. Подойти к стулу.
3. Открыть левый внешний карман рюкзака.
4. Засунуть руку в левый внешний карман рюкзака.
Ожидаемый результат: Огурец.
Как видно, шаги 1 и 2 сейчас одинаковы и всегда будет искуше-
ние улучшить то, что и так хорошо.
Искусство создания тест-кейсов 51
Пример
Тест-кейс 1:
Шаги:
1. Зайти в комнату.
2. Подойти к стулу.
3. Открыть правый внешний карман рюкзака.
4. Засунуть руку в правый внешний карман рюкзака.
Ожидаемый результат: Граненый стакан.
Тест-кейс 2:
Шаги:
1. Смотри шаги 1 и 2 из тест-кейса 1.
2. Открыть левый внешний карман рюкзака.
3. Засунуть руку в левый внешний карман рюкзака.
Ожидаемый результат: Огурец.
Так вот, таких вещей (имеется в виду шаг 1 тест-кейса 2) нужно
избегать, так как:
• тест-кейс 1 может быть удален из-за ненадобности или
• шаги по тестированию наличия стакана (в тест-кейсе 1)
могут быть изменены (например, стакан лежит в другом
рюкзаке, который находится на кухне).
В обоих случаях будет непонятно, как исполнить тест-кейс 2, так
как
• у нас или нет шагов 1 и 2 из тест-кейса 1, или
• они стали неправильными (с субъективной точки зрения
тест-кейса 2).
Другим распространенным случаем является допущение, что ПО
или база данных уже приведены к нужному состоянию, так как
были исполнены предыдущие тест-кейсы.
Пример
В тест-кейсе X мы создаем транзакцию покупки книги. В тест-кейсе Y
мы, допуская, что тест-кейс X был успешно исполнен, проверяем
атрибут успешности транзакции покупки книги, не создавая саму транз-
акцию ("Зачем напрягаться, когда она уже создана?"). В итоге мо-
жет произойти ситуация, когда транзакция покупки книги не создана,
так как
• тест-кейс X был удален;
• тест-кейс X был модифицирован так, что он создает транзакцию
другого типа;
• тест-кейс X не создал транзакции по объективной причине (на-
пример, не работал соответствующий код).
52 Тестирование Дот Ком. Часть 1
Как результат, во всех трех случаях мы не можем исполнить тест-
кейс Y, так как данных, на которые он опирается, просто не суще-
ствует.
Таким образом, хороший тест-кейс характеризуют:
• отсутствие ссылок на другие тест-кейсы;
• независимость от "следов", оставленных другими тест-
кейсами в нашем ПО или базе данных.
Следовательно, если у нас в документе А есть 10 тест-кейсов:
тест-кейс 1, тест-кейс 2, ..., тест-кейс 10, то доказательством неза-
висимости каждого из тест-кейсов будет тот факт, что их без
ущерба для тестирования можно всегда исполнять в любом
порядке, например, тест-кейс 10, затем тест-кейс 2, затем тест-
кейс 6 и т.д. Принцип, думаю, понятен.
Согласен, что повторение шагов или подготовительной части тест-
кейса кажется порой тупым занятием, но все-таки преимущества
независимого тест-кейса перекрывают напряг операции скопиро-
вал—вставил.
2. НЕЧЕТКАЯ ФОРМУЛИРОВКА ШАГОВ
Пример
"Пойди туда, не знаю куда".
На шаги тест-кейса можно смотреть, как на инструкцию "Как
пройти" (или "Как проехать").
Пример
Если американцу, который в Москве первый раз, сказать (с видом
москвича в пятом колене), что Красная площадь находится "за ГУМом",
то он бессмысленно потратит много времени в поисках "загума" в путе-
водителе. Если же черкнуть ему е-мейльчик с инструкцией:
1. Выйди из "Националя".
2. На улице поверни направо.
3. Не поднимая глаз, пройди мимо первой стайки барышень.
4. Не поднимая глаз, пройди мимо второй стайки барышень.
5. Спустись налево в подземный переход.
6. Следуй указателям на стенах с надписью "Красная площадь",
то он не только найдет Красную площадь и купит там прапорскую
ушанку с гнутой кокардой, но и избежит обвинений в сексуальном хар-
расменте, которые на его родине вещь очень даже серьезная.
Искусство создания тест-кейсов 53
Кстати,
• шаги 1 — 5 включительно — это точные инструкции, а
• шаг 6 — это отсылка к инструкциям, хранящимся в другом месте
(помните, мы говорили о внутреннем Пособии для тестировщи-ков
с шагами для повторяющихся сценариев?).
Итак, перечисляющиеся в тест-кейсе шаги должны быть объ-
ективно четкими и ясными.
Нужно помнить,
• то, что очевидно для вас сейчас, может стать совершен
но непонятным через пару месяцев.
Так, сокращенные шаги с нерасшифрованными аббревиа-
турами и прочими веселыми прибамбасами, понятными
вам сейчас, могут впоследствии стать китайской грамотой
для вас самих, так что проще будет написать тест-кейс за-
ново, чем пробираться через дебри неосмотрительно сде-
ланных описаний;
• тест-кейс, который не может быть исполнен никем,
кроме его автора, должен быть публично сожжен, рас
терт в порошок и развеян по ветру.
Обоснование простое: что, если автор тест-кейса заболеет,
уйдет в отпуск, уйдет из компании или уйдет, извините,
вообще? Любой тест-кейс должен создаваться с мыслью
о коллеге, который однажды возьмет его в руки.
Нужно избегать и другой крайности — когда шаги тест-кейса
настолько детализируются, как будто он пишется для ученой
обезьяны. Излишняя детализация ведет к усложнению поддер-
живаемости тест-кейса, что было нами убедительно доказано
минуту назад.
В общем ищите золотую середину.
3. НЕЧЕТКАЯ ФОРМУЛИРОВКА ИДЕИ ТЕСТ-КЕЙСА
И/ИЛИ ОЖИДАЕМОГО РЕЗУЛЬТАТА
Оба тезиса, о которых мы только что говорили:
• о том, что можно забыть то, что сейчас понятно, и
• писать тест-кейсы нужно не для себя, а для того парня —
применимы и к идее и к ожидаемому результату. Нюансы для
идеи тест-кейса и ожидаемого результата:
54 Тестирование Дот Ком. Часть 1
а. Не рекомендуется отсылка к внешнему документу.
Когда мы говорили о выносе части шагов в Пособие для
тестировщиков, то делали это в случаях многократно по-
вторяющихся сценариев, встречающихся в разных тест-
комплектах, с целью сделать наш тест-кейс более поддер-
живаемым. С идеей же тест-кейса и ожидаемым результа-
том — совсем другая история.
Пример
Подумайте, удобно ли будет исполнять тест-кейс, если в секции IDEA
напечатано:
«В этом тест-кейсе мы проверяем пункт 21.6 спека номер 34 "Сцена-
рий добавления кредитной карточки к счету пользователя"»
или в секции Expected Result:
"Проверь, что значение последнего шага равно значению пересечения
значения шага 5 по оси X и значению шага 23 по оси Y из таблицы 17.0
спека из секции IDEA"?
б. Нужно помнить, что суть секции IDEA — это ОБЪЯСНЕ
НИЕ идеи тест-кейса.
Пример
Если секция IDEA пуста или же в ней скромно напечатано "10", то каж-
дый исполняющий этот тест-кейс каждый раз будет тратить несколько
минут своего времени и/или времени своего коллеги на выяснение того,
что же проверяется этим тест-кейсом.
в. Нужно помнить, что ожидаемый результат — это ин
формация, на основании которой (вкупе с фактическим
результатом) мы принимаем решение об исходе тест-
кейса. Следовательно, точность и четкость в форму
лировке ожидаемого результата играют наиважнейшую
роль.
Пример
Ожидаемый результат гласит: "Проверь, что показана страница с
ошибкой", и страница с ошибкой действительно показывается. Дело в
том, что если показывается не та ошибка, которая положена по специ-
фикации, то будет пропущен баг. Почему он будет пропущен? Пра-
вильно: из-за неточной формулировки ожидаемого результата.
Еще один пример плохого ожидаемого результата:
"Все работает".
Идем дальше.
Искусство создания тест-кейсов 55
Тест-комплекты
С помощью каждого отдельно взятого тест-кейса проверяется
какая-то одна вещь (развернуто сформулированная в секции
IDEA). Каждый спек — это источник для множества идей тести-
рования, и, таким образом, для проверки кода, написанного в со-
ответствии со спеком, нам нужно множество тест-кейсов.
Совокупность тест-кейсов (находящихся, как правило, в одном
документе), которые проверяют
• какую-то определенную часть нашего интернет-проекта
(например, "Оплату") и/или
• определенный спек (например, спек номер 1455 "Рассылка
пользователям е-мейлов на основании истории заказов"),
называют тест-комплектом (test case suite).
Что происходит в жизни?
• получаем новый спек;
• создаем новый файл, в котором создаем новые тест-кейсы
для этого нового спека;
• исполняем новые тест-кейсы с их одновременной модифи-
кацией (об этом через 45 секунд);
• если имеет смысл, то переносим тест-кейсы в основной
тест-комплект, где хранятся тест-кейсы, проверяющие ту
же функциональную часть вашего интернет-проекта.
Создание нового файла с новым тест-комплектом обусловлено
тем, что новые тест-кейсы всегда исполняются в первую оче-
редь и нам просто удобно хранить их отдельно от старых. Как
говорится, "мухи отдельно, котлеты отдельно" (конечно, до тех
пор, пока нам это удобно).
Пример
На www.testshop.rs можно производить оплату картами VISA и Master-
Card. У нас есть тест-комплект, который мы исполняем из релиза в ре-
лиз (это регрессивное тестирование, о котором мы еще будем много
говорить), называемый "Покупка с использованием кредитных карт".
Этот тест-комплект был написан на основании спека #1211 и содержит
тест-кейсы для проверки функциональностей оплаты с использовани-
ем VISA и MasterCard.
Для нового релиза написан спек #1422, согласно которому будет на-
писан код для поддержки новой карты — британской Switch.
56 Тестирование Дот Ком. Часть 1
Сначала создаем новый тест-комплект "Покупка с использованием
Switch", затем исполняем и одновременно модифицируем его. Учиты-
вая, что
• после исполнения содержимое тест-комплекта будет стабили-
зировано и
• в нем проверяется та же функциональная часть веб-сайта ("Оп-
лата"),
в данном случае будет логичным сделать его частью тест-комплекта
"Покупка с использованием кредитных карт".
Постановка мозгов
Никто не ожидает, что тест-кейсы будут на 100% "работать" сразу по-
сле написания. Дело в том, что они создаются на основании опека
(или, как это часто бывает, на основании устного пожелания начальни-
ка), и так как мы физически не видим функциональностей этого опека
(код еще не написан), то многие вещи нужно в буквальном смысле
представить себе. Кроме того, как мы уже видели, сами спеки имеют
баги и спек может быть изменен без ведома тестировщика... (об этом
позже).
В общем вариантов множество, и все ведут к тому, что в первый раз
тест-кейсы должны исполняться их автором, задача которого
• если необходимо, добавить новые тест-кейсы;
• если необходимо, внести изменения по существу, например в
случае, если при создании тест-кейса тестировщик неправильно
понял спек;
• если возможно, удалить лишние тест-кейсы, например, если два
тест-кейса проверяют одну и туже идею, дублируя друг друга;
• сделать тест-кейсы более удобными для поддержки;
• отшлифовать их, что означает сделать формулировки кри-
стально-сверкающе-искристо ясными и точными.
Вот "шапка", которую можно нацепить поверх тест-кейсов.
Author: Spec ID: Priority: Producer: Developer:
OVERVIEW:
GLOBAL SETUP and ADDITIONAL INFO:
Author — автор тест-кейсов.
Spec ID — номер (или иной уникальный ID) спека. Сам ID дол-
жен быть линком к спеку в локальной сети (об этом мы еще
поговорим).
Priority — приоритет тест-комплекта (например, от 1 до 4), обыч-
но соответствующий приоритету спека.
Producer — продюсер, написавший спек.
Developer — программист, пишущий код в соответствии со спеком.
Искусство создания тест-кейсов 57
В секции Overview вкратце рассказывается, чему посвящен этот
тест-комплект.
Предназначение секции GLOBAL SETUP and ADDITIONAL INFO
аналогично секции тест-кейса SETUP and ADDITIONAL INFO, толь-
ко здесь мы говорим о повторяющихся вещах, которые будем ис-
пользовать в более чем одном тест-кейсе, и вообще о любой дру-
гой полезной информации для всего тест-комплекта.
Вот содержимое файла credit_card_payments.doc, включающего
тест-комплект "Покупка с использованием кредитных карт":
Покупка с
использованием кредитных карт (TS7122)*
Author: О. Тарасов
Spec ID:
1211
Priority
1
Producer:
П. Хрипунов
Developer:
Н. Назаров
OVERVIEW:
Данный тест-комплект проверяет оплату картами VISA и MasterCard
GLOBAL SETUP and ADDITIONAL INFO:
1. SQL1: select result from cc_transaction where id = <номер заказа>;
2. Баланс счета карты можно посмотреть здесь:
www.main.testshop.rs/<четыре_последних_цифры_карты>/balance.htm
ТС ID/Priority CCPG0001 1
IDEA: Оплата может быть произведена картой VISA
SETUP and ADDITIONAL INFO:
Эккаунт: testuser1/pa$$wOrd
Данные карты:
Номер: 9999-5148-2222-1277 Окончание действия:
12/07 CVV2: 778
Revision History
Created on: 11/17/2003 by О.Тарасов Новый тест-кейс
Modified on: 11/26/2003 by И. Новикова Шаги были упрощены, чтобы
сделать тест-кейс более удобным
для поддержки
Modified on: 01/17/2003 by И. Новикова Изменение шагов и второй
ожидаемый результат с целью
удостоверения в снятии денег со счета
58 Тестирование Дот Ком. Часть 1
Execution part
PROCEDURE EXPECTED RESULT
1. Запиши баланс счета карты 2. Открой www.main.testshop.rs 3. Войди в систему. 4. Найди любой товар. 5. Добавь товар в корзину. 6. Произведи оплату картой из секции
SETUP and ADDITIONAL INFO (!!! запиши полную сумму заказа:
). 7. Запиши номер заказа 8. Запроси базу данных с SQL1.
> "10"
9. Запиши баланс счета карты > Шаг 1 - Шаг 6
ТС ID/Priority CCPG0002 1
IDEA: Оплата может быть произведена картой MasterCard
SETUP and ADDITIONAL INFO:
Эккаунт: testuser1/pa$$wOrd
Данные карты:
Номер: 3333-7112-4444-7844 Окончание действия: 12/08
CVV2: 676
Revision History
Created on: 11/17/2003 by О.Тарасов Новый тест-кейс
Modified on: 11/26/2003 by И. Новикова Шаги были упрощены, чтобы
сделать тест-кейс более удобным
для поддержки
Modified on: 01/17/2003 by И. Новикова Изменение шагов и второй
ожидаемый результат с целью
удостоверения в снятии денег со счета
Execution part
PROCEDURE EXPECTED RESULT
1. Запиши баланс счета карты 2. Открой www.main.testshop.rs 3. Войди в систему. 4. Найди любой товар.
5. Добавь товар в корзину. 6. Произведи оплату картой из секции
SETUP and ADDITIONAL INFO (!!! запиши полную сумму заказа:
). 7. Запиши номер заказа 8. Запроси базу данных с SQL1.
> "20"
9. Запиши баланс счета карты > Шаг 1 - Шаг 6
(TS7122) — каждый тест-комплект должен иметь свой уникальный ID.
Искусство создания тест-кейсов 59
Прошу обратить внимание на следующее:
1. Вещи, которые у нас повторяются в разных тест-кейсах,
вынесены в секцию GLOBAL SETUP and ADDITIONAL INFO
тест-комплекта:
1. SQL1: select result from cc_transaction where id— <номер заказа>;
2. Баланс счета карты можно посмотреть здесь:
www.main.testshop.rs/<четыре_последних_цифры_карты>/bаlаисе.h tm.
2. Данные, различающиеся между тест-кейсами CCPG0001 и
CCPG0002, выделены жирным с подчеркиванием. В предло
женном тест-комплекте это сделано, чтобы приковать вни
мание исполнителя к различиям в похожих тест-кейсах.
В общем случае хорошая практика — пользоваться ВОЗМОЖНО-
СТЯМИ текстового редактора, чтобы выделить то, на что стоит об-
ратить внимание.
Продолжаем.
Наш менеджер дает нам для проработки и создания тест-кейсов
новый спек продюсера М. Чучикова: #1422 "Покупка с исполь-
зованием Switch". Мы создаем новый файл: switch_payments.doc.
И после того как мы его исполнили и причесали наши новые тест-
кейсы (в данном случае один тест-кейс), получаем:
Покупка с использованием Switch (TS7131)
Author:
И. Новикова
Spec ID:
1422
Priority
1
Producer:
M.Чучиков
Developer:
Н. Назаров
OVERVIEW:
Данный тест-комплект проверяет оплату картой Switch
GLOBAL SETUP and ADDITIONAL INFO:
1. SQL1: select result from cc transaction where id = <номер заказа>;
2. Баланс счета карты можно посмотреть здесь:
www.main.testshop.rs/<четыре_последних_цифры карты>/bа1аncе.htm
ТС ID/Priority SWPL0001 1
IDEA: Оплата может быть произведена картой Switch
SETUP and ADDITIONAL INFO:
Эккаунт: testuser1/pa$$wOrd
Данные карты:
Номер: 3333-1988-4444-5699 Окончание действия:
12/05 CVV2: 451
60 Тестирование Дот Ком. Часть 1
Revision History
Created on: 01/21/2003 by И. Новикова Новый тест-кейс
Execution part
PROCEDURE EXPECTED RESULT
1. Запиши баланс счета карты 2. Открой www.main.testshop.rs 3. Войди в систему. 4. Найди любой товар.
5. Добавь товар в корзину. 6. Произведи оплату картой из секции
SETUP and ADDITIONAL INFO (!!! запиши полную сумму заказа:
). 7. Запиши номер заказа 8. Запроси базу данных с SQL1.
> "30"
9. Запиши баланс счета карты S* Шаг 1-Шаг 6
Теперь нам остается просто объединить оба файла. Таким образом,
у нас получился all new credit_card_payments.doc. Откроем его:
Покупка с использованием кредитных карт
Часть 1 т естирование с VISA и MasterCard
Часть 2: тестирование со Switch
Часть 1
<Шапка, CCPG0001 и
(
2CPG0002 из старого файла credit
card_payments
doc
без изменений>
Часть 2
<Шапка и SWPL0001 из файла
switch_payments
.doc без изменений>
Прошу обратить внимание на следующее:
мы не меняли
• ни содержимое файла switch_payments.doc, которое вста-
вили в основной тест-комплект credit_card_payments.doc,
• ни содержимое старого файла credit_card_payments.doc.
Можно, например, было сделать для них одну общую "шапку" или
заменить SWPL0001 на CCPG0003 (чтобы иметь единую систему
нумерации в одном тест-комплекте), но ни этого, ни других объеди-
нительных мероприятий не было (и не будет) проведено, так как:
• это два независимых модуля и каждый из них прекрас
но исполняем по отдельности (пусть даже они и объеди-
Искусство создания тест-кейсов 61
нены в одном файле (и одном тест-комплекте) из-за того,
что они покрывают ту же функциональную часть нашего
проекта);
• уникальный ID тест-кейса дается последнему один раз и
никогда не меняется. Это как номер налогоплательщика
— нас ведь нужно учитывать, где бы мы ни были, а то
располземся, как тараканы, легкомысленно забыв о том,
что у патрициев тоже есть семьи, которые мы, будучи не
патрициями, должны содержать, платя налоги.
Кстати, генерировать уникальный ID тест-кейса можно
• автоматически (для этого может быть написана простая про-
граммка) или же
• вручную, для чего должна быть заключена конвенция внутри де-
партамента качества.
Пример
Мы договариваемся, что ID состоит из двух частей:
• первая часть — это буквенное обозначение (например, четыре
латинские буквы), а
• вторая часть — это цифровое обозначение (от 0001 до 9999).
ID присваивается автором тест-комплекта, и в случае если новые тест-
кейсы (без ID) добавляются в тест-комплект, то буквенный ID берется из
предшествующих тест-кейсов, а цифровое обозначение = максимальное
цифровое обозначение + 1. Так если мы решим добавить тест-кейс для
тестирования оплаты картой Switch, то как мы его назовем? Правильно!
SWPL0002. А картой VISA или MasterCard? Правильно! CCPG0003.
Кстати, CCPG — это "Credit Cards Payments Global" ("общее по платежам
с кредитными картами"), a SWPL — "SWitch Payments Local" ("локальное по
платежам с картой Switch"). Почему я выбрал ТАКИЕ буквенные
обозначения? Потому что мне так захотелось. Никакого правила здесь
нет, как нравится, так и называйте, но постарайтесь, чтобы не было
двух тест-кейсов с одним ID.
Пример
Процесс присвоения ID идет следующим образом:
1. Пишем тест-кейсы. ID не присваиваем.
2. "Обкатываем" их при первом исполнении с удалением тех из них,
которые недостойны быть частью нашего тест-комплекта, и до-
бавлением тех, которые пришли на ум по мере исполнения.
3. Присваиваем оставшимся тест-кейсам по ID.
Мы продолжим разговор о тест-комплектах на одном из следую-
щих чаепитий.
62 Тестирование Дот Ком. Часть 1
Состояния тест-кейса
У них все, как у людей. Рождаются, изменяются и умирают...
Рождение:
состояние — "Новый" (New).
Это первая редакция тест-кейса: "Created on: 11/17/2003 by
0. Тарасов".
Изменение:
состояние — "Измененный" (Modified). Модификации, как
правило, связаны с изменением спека, затрагивающего этот
тест-кейс, или с улучшением тест-кейса, например, для
удобства в поддержке: "Modified on: 11/26/2003 by И.
Новикова".
Смерть тест-кейса наступает
• вместе со смертью тестируемой вещи (определенной функ-
циональности, элемента интерфейса пользователя и др.),
например www.testshop.rs перестал принимать кредитные
карты либо
• в других случаях, например когда один тест-кейс дублиру-
ет другой, т.е. имеем
состояние — "Более недействителен" (Retired).
Рекомендую не удалять тест-кейсы насовсем, так как
во-первых, всегда возможна ошибка в суждении и нам нужно
предусмотреть обратимость удаления,
во-вторых, тест-кейс, который, по нашему субъективно-несовер-
шенному мнению, перестал быть актуальным, может еще приго-
диться, хотя бы как память о годах жизни, проведенных не за
штурвалом пиратского брига "Черная жемчужина", а за монито-
ром "Хундаи" с неотдирающимся стикером "Моя компания —
мой дом".
В общем:
1. Создаем специальную директорию в том же месте, где хра
ним файлы с тест-комплектами, и называем ее
retired_testcases.
2. Создаем в этой директории файл с тем же именем, что и
файл тест-комплекта, из которого удаляем тест-кейс.
Искусство создания тест-кейсов 63
3. Переносим тест-кейс (cut/paste) из файла, больше не нуж-
дающегося в этих услугах, в одноименный файл директо-
рии retired testcases.
В жизни все выглядит проще, так как обычно пускается в расход
не отдельный тест-кейс, а весь тест-комплект.
Иногда возникает дилемма — что лучше:
• изменить тест-кейс или
• удалить его и придумать новый.
Зсе ситуации уникальны, но, как показывает жизнь, легче возвести
здание на пустом месте, чем делать генеральную реставрацию
старого особняка. Кстати, судя по Москве, этой концепции при-
держиваюсь не я один.
Вот такие дела...
А напоследок я скажу...
Важный момент перед подведением итогов.
Все то, о чем мы говорили в этой беседе, является хорошей прак-
тикой при создании тест-кейсов и тест-комплектов, эта практика
имеет место в реальных и успешных интернет-компаниях Сили-
коновой Долины, и все, включая формат, можно использовать,
как оно было рассказано и показано. Я же хочу, чтобы вы всегда
помнили главное:
тестирование — это процесс творческий и, следовательно,
подразумевает поиск. Ищите, пока не найдете то, что эф-
фективно работает именно в вашей компании и в конкретной
ситуации.
Для иллюстрации творческого подхода те же тест-кейсы, но в
другом виде.
Таблица 1
Test Case
ID
Priority Card Card Number Card Expiration date
Card
CVV2
Expected
Result
CCPG0001 1 VISA 9999-5148-2222-1277 12/07 778 10
CCPG0001 1 MasterCard 3333-7112-4444-7844 12/08 676 20
SWPL0001 1 Switch 3333-1988-4444-5699 12/05 451 30
64 Тестирование Дот Ком. Часть 1
IDEA: Оплата может быть произведена картами из Таблицы 1.
Для каждого тест-кейса из Таблицы 1:
1. Запиши баланс счета карты :
www.main.testshop.rs/<четыре_последних цифры_карты>/balance.htm
2. Открой www.main.testshop.rs.
3. Войди в систему как testuser1/paSSwOrd.
4. Найди любой товар.
5. Добавь товар в корзину.
6. Произведи оплату картой (!! !запиши полную сумму заказа: ).
7. Запиши номер заказа
8. Запроси базу данных:
select result from cc_transaction where id = <номер заказа>;
Сравни с Expected resultl.
9. Запиши баланс счета карты
Шаг 1 - Шаг 6
Прошу считать творческий подход проиллюстрированным.
Краткое подведение итогов
1. Тест-кейс — это инструмент тестировщика, предназначенный
для документирования и проверки одного или более ожи-
даемых результатов.
2. Шаги (procedure) — это часть тест-кейса, ведущая исполнителя
тест-кейса к фактическому результату (выводу). Излишняя
детализация может осложнить поддержку, а излишнее
абстрагирование привести к непониманию того, как исполнить
тест-кейс.
3. Шаги для повторяющихся сценариев можно вынести в отдель-
ный документ в локальной сети, и в тест-кейсе мы даем лишь
ссылку на этот документ.
4. Исполнение тест-кейса завершается либо положительным
(pass), либо отрицательным (fail или баг!!!) результатом. Причем
именно отрицательный результат является желанным, так как
мы нашли баг.
5. Исполнение тест-кейса не является завершенным, если испол-
нитель не смог "пройти" все шаги.
6. Тест-кейс должен быть независим от других тест-кейсов из того
же или любого другого тест-комплекта.
7. Наиполезнейшими вещами являются следующие атрибуты тест-
кейса:
• уникальный ID, который уникален в пределах всех сущест-
вующих в компании тест-кейсов;
Искусство создания тест-кейсов 65
• приоритет, чтобы все знали, кто здесь главный;
• идея, которая на простом языке объясняет предназначение
тест-кейса;
• подготовительная часть, которая... ну, в общем, подго-
тавливает нас к исполнению тест-кейса;
• история редактирования, которая помогает указать на
друзей, испортивших наши идеальные тест-кейсы и наших
легковерных попугаев.
8. Поддерживаемость тест-кейса — это легкость и удобство, с
которыми он может быть изменен. Поддерживаемость тест-
кейса — одна из основных формальных вещей при создании или
модификации тест-кейса.
9. Тест-кейс "проверяет" не более одной идеи. При этом два и
более ожидаемых результата легитимны, если истинность идеи
вытекает из одновременной истинности этих ожидаемых
результатов.
10. К плохому стилю относятся:
а) зависимость тест-кейсов друг от друга;
б) нечеткая формулировка шагов;
в) нечеткая формулировка идеи тест-кейса и/или ожидаемого
результата.
11. Тест-кейсы объединяются в тест-комплекты (как правило, один
тест-комплект — это один файл).
12. Как правило, тест-комплект включает тест-кейсы, родственные
друг другу тем, что они проверяют определенный участок на-
шего интернет-проекта или вещи, описанные в определенном
спеке.
13. Хорошим стилем является создание нового тест-комплекта для
новых тест-кейсов.
14. Тест-кейсы, написанные после проработки спека (до того, как
представилась возможность "пощупать" написанное по нему ПО),
являются сырыми, и никто не посмеет бросить в тестировщика
камень осуждения, если он впоследствии изменит тест-кейсы по
мере их исполнения.
15. Создавая или модифицируя тест-кейсы, мы всегда должны
помнить о том парне, который будет их исполнять после нас.
16. Состояние тест-кейса: "У них все, как у людей. Рождаются,
изменяются и умирают..." — "Новый", "Измененный", "Более
недействителен". Хорошая практика — не удалять (remove)
отжившие свой век тест-кейсы (или целые тест-комплекты), а
переносить их (move) в отдельную директорию, специально
созданную для таких пенсионеров.
17. Важно понять, что в сегодняшнем разговоре речь шла о форме,
а не о содержании тест-кейсов. Содержание конкретного тест-
кейса — это отражение методологии нахождения багов
применительно к конкретной ситуации, и этой методологии
будут посвящены отдельные беседы.
66 Тестирование Дот Ком. Часть 1
Вопросы и задания для самопроверки
1. Без какой части тест-кейс никак не может обойтись?
2. Для чего в тест-кейсе нужны шаги?
3. Два вида исхода исполнения тест-кейса. К какому исходу мы,
как тестировщики, стремимся?
4. Что происходит, если состояние ПО не позволяет исполнить все
шаги тест-кейса? Каковы наши действия?
5. Обоснуйте, почему у тест-кейса должна быть лишь одна тести-
руемая идея?
6. Перечислите полезные атрибуты тест-кейса и причину полез-
ности каждого из них.
7. Изменяется ли ID тест-кейса при изменении самого тест-кейса
или переносе его в другой документ?
8. Придумайте свой способ индексации тест-кейсов, например,
частью ID может быть номер спека.
9. Что такое data-driven тест-кейс? В чем заключается удобство
поддержания такого тест-кейса? 10. Как легкость в поддерживаемое™ тест-кейса позволяет сэко-
номить время?
11. Формальные недостатки, не позволяющие тест-кейсам быть
белыми и пушистыми.
12. В чем удобство написания новых тест-кейсов в отдельный тест-
комплект?
13. Ожидается ли, что тестировщик изменит тест-кейс, написанный
лишь на основании спека, без знакомства с реально напи-
санным ПО?
14. В чем проявляется родственность тест-кейсов, являющихся
частью одного тест-комплекта?
15. Приведите атрибуты шапки тест-комплекта.
16. Состояния тест-кейса.
17. Почему не рекомендуется удалять тест-кейсы?
18. Есть ли стандартная форма тест-кейса, за несоблюдение кото-
рой лишают премий и не приглашают на празднование Нового
года?
19. Разница между идеей тест-кейса и ожидаемым результатом.
20. Напишите тест-кейс с тестируемой идеей "Я могу убедить свою
жену в чем угодно" и ожидаемым результатом "Дорогой, поез-
жайте с Алексеем на рыбалку. Вы так редко с ним видитесь".
21. Напишите тест-кейс с одной идеей и двумя ожидаемыми ре-
зультатами. Используйте пример из жизни.
ЦИКЛ РАЗРАБОТКИ ПО
• ИДЕЯ
• РАЗРАБОТКА ДИЗАЙНА ПРОДУКТА И СОЗДАНИЕ
ОПЕКА
• КОДИРОВАНИЕ
• ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ И РЕМОНТ БАГОВ
• РЕЛИЗ
• БОЛЬШАЯ КАРТИНА ЦИКЛА РАЗРАБОТКИ ПО
икл (процесс) разработки ПО (software development life
cycle) — это путь от идеи до поддержки готового продукта.
Чем более отлажены каждая из стадий цикла и координация меж-
ду ними, тем эффективнее работает интернет-компания, тем вы-
ше качество и тем счастливее пользователи.
Сегодня мы поговорим о модели цикла разработки ПО, называе-
мой "Waterfall" ("Водопад"), которая используется в подавляю-
щем большинстве интернет-стартапов.
Наша цель — понять логику взаимосвязи между стадиями
Цикла и основные моменты каждой из стадий.
Большая картина цикла будет представлена в конце разговора,
когда будет понятно, что уже ничего не понятно.
Постараюсь свести к минимуму вещи типа: "в одних компаниях
Эгпо называется так, а в других — этак", нельзя объять необъ-
ятное, но если будет схвачен принцип, то, несмотря на разницу
67

Ц

Цикл разработки ПО 69
в названиях и нюансах, вы мгновенно свяжете то, о чем я вам
рассказал, с тем, что есть (будет) в компании, где вы работае-
те (несомненно, будете работать).
Итак, поприветствуем участниц и участников нашего шоу. Ими
сегодня будут:
1. Идея.
2. Разработка дизайна продукта и создание документации.
3. Кодирование (в смысле создание кода).
4. Исполнение тестирования и ремонт багов.
5. Релиз.
Идея
Для начала расскажу вам, как образовывались стартапы в США в
конце 90-х гг. прошлого века. И не подумайте, что я утрирую.
Калифорнийская история
СИДЯТ два бывших одноклассника в спорт-баре даунтауна Сан-Фран-
циско и думают, как заработать денег: кругом интернет-бум, некото-
рые друзья стали миллионерами и ездят на сверкающих "Феррари"
между офисами-аквариумами интернет-компаний и своими домами
на холмах Лос-Алтоса.
70 Тестирование Дот Ком. Часть 1
Один из них неожиданно поднимает над барной стойкой голову, переводит озаренный
взгляд на другого, вытягивает вверх указательный палец и говорит: "О!"
Это "О!" означает рождение идеи, например, о создании веб-сайта по продаже
туалетной бумаги.
На следующий день раздается звонок в офисе венчурного капиталиста и назначается
встреча для обсуждения "проекта века".
Кстати,
венчурные капиталисты — это такие непростые товарищи, бизнесом которых
является спонсирование новых компаний.
Встреча проходит в теплой и дружественной обстановке, и под проект "Туалетная
бумага Дот Ком" дается 50 млн долл.
Сказавший "О!" становится CEO (Chief Executive Officer), а егодруган —
соответственно COO (Chief Operating Officer).
Снимается помещение, покупаются ораклы и линуксы, начинается набор народа на
рядовые и руководящие должности, день и ночь кипит работа, пепперони-пицца
становится ежедневной едой даже вегетарианцев, жены программистов изменяют со
страховыми агентами, в общем все "счастливы, влюблены, раздавлены".
Процесс пошел!!!
Слушая эту историю, которая вполне могла быть правдивой, можно
заметить, что все началось с "О!", т.е. с ИДЕИ.
Вопрос: Кто генерирует идеи в действующей интернет-компании? Ответ:
Как правило, это отдел маркетинга. Нередко идеи инициируются службой
поддержки пользователей или новым контрактом, например, с компанией
по процессингу кредитных карт (credit card processor).
В общем вариантов множество.
При разговоре о большой картине сводному персонажу, генерирующему
идеи, будет присвоено имя Маркетолог.
Как правило, идеи компонуются в MRD ("эм-ар-ди" — Marketing
Requirements Document — документ о требованиях маркетинга, суть
которого: "хотелось бы это иметь").
Затем
• менеджмент проворачивает MRDШКИ через жернова анализа,
утверждения и приоритезации, а
• выжившие идеи передаются продюсерам, которые их полоскают,
высушивают и гладят, чтобы получилась спецификация.
Цикл разработки ПО 71
Разработка дизайна продукта и
создание опека
На основании идеи, утвержденной менеджментом, разрабатыва-
ется и документируется ее воплощение, которое называется
дизайном продукта (product design) или, простыми словами, то,
как та или иная часть нашего веб-сайта должна выглядеть и/или
работать.
Концептуальная разница между идеей (продукта) и дизайном
(продукта) заключается в том, что
• идея — это описание ЦЕЛИ, а
• дизайн — это описание ПУТИ к достижению этой цели.
Профессионально весь этот джаз осуществляется менеджерами
продукта (PMs — Product Managers), которые также могут назы-
ваться продюсерами (Producers) или дизайнерами продукта (Product
Designer).
Результатом продюсерских усилий являются спеки, называемые
также PRD (Product Requirements Document — документ о требова-
ниях для продукта) или просто requirements (требования).
Самые эффективные продюсеры в интернет-компаниях — это
профессионалы, имеющие бэкграунд в предмете, на котором они
специализируются, и ненавязчивую техническую подготовку.
Первое необходимо, чтобы детально разбираться в том, что
найдет отражение в спеках (например, это могут быть правила
торгов НАУФОР).
Второе полезно, чтобы говорить на языке программистов и
тестировщиков.
Спеки должны иметь уникальное название и уникальный ID
и внутри разбиваются на логические составляющие (части, пункты),
имеющие индексацию для удобства ссылок.
Каждый спек имеет также обозначение своей важности (при-
оритета). Обычно это цифра по 4-балльной шкале. Так, спек
приоритета 1 (Ш) — это самый приоритетный спек.
Практическая ценность придания спекам приоритетности
состоит в следующем:
72 Тестирование Дот Ком. Часть 1
• если речь идет об исключении каких-либо функционально-
стей из релиза, так как не хватает ресурсов (например,
времени у программиста), то жертвуют функционально
стью из спека с меньшим приоритетом. Так, при наличии
одного спека с Ш и
другого спека с П2,
равноценных по трудоемкости для программиста и тести-
ровщика, отбрасывается П2;
• программист и тестировщик всегда должны начинать (про-
граммирование, подготовку к тестированию и исполнение
тестирования) со спека с большим приоритетом;
• так как мы знаем, что невозможно протестировать все,
приоритет спека для тестировщика — знак, указы-
вающий, чему нужно дать больше любви и заботы.
Как правило, приоритет присваивается спекам менеджером про-
дюсеров.
Идем дальше.
Хороший спек, как и хороший закон, отличают следующие вещи:
1. Акцент на деталях и их четкое определение.
2. Забота о недопущении неверного толкования.
3. Непротиворечивость внутри спека и с другими спеками.
4. Логическая взаимосвязь компонентов.
5. Полнота охвата предмета.
6. Соответствие нормативным актам.
7. Соответствие деловой практике.
Ошибки в спеке появляются в случае отклонения содержания
спека от пунктов 1 —7.
1. АКЦЕНТ НА ДЕТАЛЯХ И ИХ ЧЕТКОЕ ОПРЕДЕЛЕНИЕ
Пример ошибки
"1.5. При регистрации система должна проверить е-мейл на наличие:
"." перед именем глобального домена (например, "ш" или "com")". В
этом спеке пропущено множество вещей. Например:
а. Не указано, что е-мейла с двумя "@" быть не может.
б. Не указаны другие неприемлемые знаки (illegal characters) е-мейл-
адреса. в. Не приведен список существующих глобальных доменов.
Цикл разработки ПО 73
Пример последствий ошибки
Стандартная практика регистрации нового пользователя состоит из
трех этапов:
а. Пользователь заполняет регистрационную форму и нажимает
кнопку "Зарегистрироваться".
б. От веб-сайта приходит е-мейл с липком для подтверждения ре
гистрации. в. Пользователь кликает линк, и регистрация автоматически под
тверждается.
Если пользователь случайно введет неправильный е-мейл (например,
с двумя "@") и сообщение об ошибке сгенерировано не будет, то реги-
страция не будет завершена, так как е-мейл с липком для подтвержде-
ния регистрации не придет. Пользователь будет бесполезно ждать
этого е-мейла, а не дождавшись, скорее всего введет в адресной
строке веб-браузера URL конкурента.
Кстати, URL ("ю-ар-эл" — Uniform Resource Locator) — это просто ад-
рес файла в сети, например "http://www.testshop.rs". URL можно вво-
дить в адресную строку веб-браузера без "http://" (ее добавляет сам
браузер при запросе к веб-серверу). Имя файла может даваться на-
прямую: www.main.testshop.rs/1277/balance.htm, либо веб-сервер сам
найдет для нас нужный файл в соответствии со своими настройками,
например, в случае с нашим проектом набор в адресной строке
браузера "www.main.testshop.rs" или "www.main.testshop.rs/index.htm"
даст нам тот же самый файл index.htm.
2. ЗАБОТА О НЕДОПУЩЕНИИ НЕВЕРНОГО ТОЛКОВАНИЯ
Пример ошибки
Игорь Саруханов. Песня "Скрип колеса". Произнесите вслух название этой песни. Я, например, многие годы
думал, что песня называется "Скрипка лиса", а моя жена была уверена,
что "Скрипка. Леса...".
Пример последствий ошибки
Если для вашей профессиональной деятельности не имеет никакого
значения, как называлась эта песня, то адекватность понимания спека —
это вещь наиважнейшая. Опасность заключается в том, что
программист и/или
тестировщик,
выбрав неправильный смысловой вариант, может быть уверен, что все
понял правильно, и в итоге напортачит
с кодом и/или с
тест-кейсами.
У нас будет отдельное рассмотрение того, как превентировать
возможность неверного толкования спека.
74 Тестирование Дот Ком. Часть 1
3. НЕПРОТИВОРЕЧИВОСТЬ ВНУТРИ СПЕКА И
С ДРУГИМИ СПЕКАМИ
Пример ошибки
"7.3. В целях безопасности доставка может быть осуществлена на
адрес пользователя, по которому зарегистрирована кредитная
карта"
и на следующей странице или в другом спеке:
"8.1.1. Для доставки пользователь может ввести любой адрес в преде-
лах континентальной части США".
Пример последствий ошибки
Один программист может запретить доставку на любой адрес, кроме
адреса регистрации кредитной карты, а другой программист незави-
симо от первого напишет код, позволяющий пользователю ввести лю-
бой адрес, который тот пожелает.
Вследствие этого вполне возможна ситуация, когда пользователь, за-
вершив заказ, будет ждать посылку, которая никогда к нему не придет,
так как система
• позволит сделать заказ (код второго программиста), НО
• не даст команду кладовщику, чтобы тот послал заказ по почте
(код первого программиста).
4. ЛОГИЧЕСКАЯ ВЗАИМОСВЯЗЬ КОМПОНЕНТОВ
Пример ошибки
"1.1. Мои мама и папа, я живу хорошо, просто замечательно. У меня
все есть. Есть свой дом. Он теплый. В нем одна комната и кухня. Я без
вас очень скучаю, особенно по вечерам.
1.2. А здоровье мое не очень. То лапы ломит, то хвост отваливается.
1.3. А на днях я линять начал: старая шерсть с меня сыплется, хоть в
дом не заходи, зато новая растет — чистая, шелковистая. Так что лох-
матость у меня повысилась.
До свидания. Ваш сын, дядя Шарик".
Спасибо Эдуарду Успенскому за иллюстрацию "логической" взаи-
мосвязанности компонентов.
Пример последствий ошибки
Вспомните реакцию мамы, а затем папы дяди Федора после прочтения
письмеца. Примерно то же самое может быть с пользователем, когда
он столкнется с функциональностью, написанной и протестированной
согласно подобному спеку.
Цикл разработки ПО 75
5. ПОЛНОТА ОХВАТА ПРЕДМЕТА
Пример ошибки
В условиях массового интернет-мошенничества с кредитными кар-
тами дополнительной степенью защиты является CVV2 (Card Verification
Value 2) — трех- (для всех карт, кроме Атех) или четырехзначный
(только для Атех) номер, идущий за номером карты на обратной ее
стороне (на полоске с подписью). Продюсер по незнанию или по ха-
латности может не предусмотреть в опеке, что пользователь должен
ввести CVV2 при регистрации карты, что в итоге приведет к большему
числу мошеннических транзакций.
Пример последствий ошибки
Многие интернет-компании, включая платежные системы, закончили
существование из-за огромного количества транзакций с крадеными
картами. Даже если дело не дойдет до закрытия компании, службе
поддержки клиентов, финансовому и правовому департаментам пред-
стоит испытать много чудных мгновений, которых могло не быть, не за-
будь продюсер о CVV2.
6. СООТВЕТСТВИЕ НОРМАТИВНЫМ АКТАМ
Пример ошибки
Здесь, как правило, речь идет о продаже специальных предметов (на-
пример, рецептурных лекарств). В этом случае спек (например, в он-
лайн-аптеке) должен предусматривать, что такие предметы не могут
продаваться.
Еще одним примером являются вещи, связанные с авторским
правом, например распространение аудиофайлов.
Пример последствий ошибки
Возможно судебное преследование. Вспомните историю компании
Napster.
7. СООТВЕТСТВИЕ ДЕЛОВОЙ ПРАКТИКЕ
Пример ошибки
Если денежный перевод обычно занимает 3 — 6 бизнес-дней включи-
тельно, то пользователю не должно сообщаться меньшее или "точное"
количество дней. Нужно так и указать на соответствующей странице
сайта: "Денежный перевод обычно занимает 3 — 6 дней включительно".
Пример последствий ошибки
Пользователь будет уверен, что в конкретный день на его счете будет
определенная сумма. Представьте себе ситуацию, что пользователь,
рассчитывая на эти деньги, поехал в Лондон на аукцион русской живо-
76 Тестирование Дот Ком. Часть 1
ПИСИ, выиграл там картину Айвазовского, за 200 тыс. фунтов, расплачи-
вается своей дебетовой картой, а ему говорят, что на карте нет денег.
Останется ли он клиентом нашей компании?
Идем дальше.
Некоторые продюсеры убеждены, что спеки должны давать про-
граммистам указания по сугубо техническим аспектам кодирова-
ния, как, например, об установлении связей между таблицами в
базе данных или о названиях функций в коде. Если они не пони-
мают всех проблем, вытекающих из этого порочного подхода, и
слушать никого не хотят, предложите им самим написать весь
код. Скорее всего, они откажутся...
Пример
Где-нибудь в городе N в стенах прихватизированного авиационного
завода открывается фирма по отливке золотых унитазов для новых
русских. Жена одного такого приезжает на завод и говорит: "Хочу, что-
бы мой унитаз:
с 00:00 до 5:59:59 проигрывал в стерео сочинения Сибелиуса в испол-
нении оркестра английской Королевской оперы; с 6:00 до 11:59:59 голосом Марчелло Мастроянни читал пелевинскую
"Жизнь насекомых"; с 12:00 до 17:59:59 философски молчал; с 18:00до
23:59:59 транслировал "Народное радио", а для
формы подойдет модель 5 из вашего каталога".
Очень даже приличная спецификация. И на этом неплохо было бы ос-
тановиться, но если эта дама с многокаратными каменьями начнет да-
вать ценные указания о температуре нагревания презренного металла
перед литьем, изоляции контактов или моменте вступления кларнета в
Седьмой симфонии, то будет совсем худо. Давайте уж так: каждый
должен заниматься своим делом.
Итак, после проведения водораздела между работой продюсера и
работой программиста продолжим о спеках.
Спеки имеют следующую очередность статусов:
1. Во время написания они имеют статус Черновик (Draft).
Продюсер пишет спек.
2. После написания и до утверждения — Ожидание утвер-
ждения (Approval Pending).
Спек написан, и назначается совещание (meeting) с про-
граммистами и тестировщиками по его обсуждению или
же просто им посылается е-мейл с приложением.
Цикл разработки ПО 77
3. После утверждения — Утверждено (Approved или Final).
Если на митинге все закричали "Ура!" или получены по-
ложительные отзывы от всех реципиентов, утвержденный
спек немедленно выкладывается на один из серверов в ло-
кальной сети, чтобы быть доступным любому лицу внутри
компании, которому положено его видеть. Если же спек не
принят, то все начинается с пункта 1.
Постановка мозгов
Факт утверждения спека не означает, что тестировщик и программист
объявили спек идеальным. Факт утверждения спека означает, что в
результате первоначального ознакомления со спеком последний
был признан годным для дальнейшей работы. Политический момент:
спек — это ответственность продюсера, и продюсер остается ответ-
ственным за качество спека даже в том случае, если программист
и тестировщик утвердили спек, в котором позднее были найдены
проблемы.
Идем дальше.
Спасский после игры с Фишером неделями ходит и думает: "А вот
здесь нужно было бы его конем пришкварить", но, к сожалению,
исправить ему уже ничего нельзя, "можно только забыть".
Продюсер же может проснуться утром с идеей улучшения спека
или вспомнить какую-нибудь важную вещь, упущенную при соз-
дании спека, и, придя на работу, подредактировать спек и заме-
нить файл со старой редакцией файлом с новой редакцией на
упомянутом внутреннем сервере... И так пять раз.
Далее.
Обычно спек распечатывается непосредственно перед началом
работы по нему. Учитывая, что время начала работы по спеку у
каждого индивидуально (я говорю о минутах), если спек будет
по-тихому изменяться между распечатываниями, наступит ситуа-
ция, когда
программисты и тестировщики хотя и работают над одним
проектом, но руководствуются разными редакциями спека.
Причем даже если у программистов и тестировщиков будут рас-
печатки одной и той же версии спека, то в случае тихого измене-
ния их работа в той или иной части все равно не будет иметь
смысла, так как они руководствовались устаревшей редакцией.
78 Тестирование Дот Ком. Часть 1
Пример
11 ноября. Спек утвержден Ножовым, Ложкиным и Тарелкиным. Про-
дюсер Буханкин.
12 ноября. Спек распечатывает тестировщик Ножов. Работа по спеку
началась. 14 ноября. У Буханкина новая идея. Спек по-тихому изменен.
15 ноября. Спек распечатывает для себя программист Ложкин. Работа
по спеку началась.
16 ноября. У Буханкина новая идея. Спек по-тихому изменен.
17 ноября. Спек распечатывает для себя программистТарелкин. Работа
по спеку началась.
18 ноября. У Буханкина новая идея. Спек по-тихому изменен.
19 ноября. Спек распечатывает для себя программист Салфетка, рабо-
тающий над кодом по интеграции функциональности кода из этого
и своего спека. Работа по спеку началась.
25 декабря. Все выясняется. 30
декабря.
17:00 — начало празднования Нового года в офисе компании.
17:30 — начало избиения Буханкина руками Ножова, Ложкина и Та-
релкина. 18:00 — начало избиения Буханкина ногами Ножова, Ложкина и Та-
релкина. 18:30 — в офис влетает Салфетка, вернувшийся после разговора с
менеджером, разбрасывает в стороны подуставших Ножова,
Ложкина и Тарелкина и добивает Буханкина контрольным
ударом клавой по голове.
Надо отметить, что во многих случаях спек меняется не по воле
продюсера, а по приказу сверху.
Ситуация
25 марта. Менеджер присылает продюсеру е-мейл, что необходимо срочно
изменить спек #8337.
За день до этого, т.е. 24 марта.
Представьте себя на месте продюсера: продюсер уже вовсю работает над новым спеком и надеется, что
релиз функциональностей согласно спеку #8337 пройдет без сучка
без задоринки.
Представьте себя на месте программиста: код для спека
#8337 написан, влегкую протестирован самим программистом,
частично позабыт и уже кажется частью безвозвратно потерянной
юности.
Представьте себя на месте тестировщика: документация для тестирования спека #8337 написана. Новые проекты
бьют в паруса, и настоящее наконец-то стало залечивать раны прошлого.
На следующий день, т.е. 26 марта.
Спек #8337, а также код и тест-кейсы к нему должны быть изменены,
т.е. минимум трое работников должны
Цикл разработки ПО 79
• бросить текущие проекты,
• вспомнить спек #8337, понять изменения к нему и
• потратить время на воплощение изменений.
Эта ситуация является идеальной питательной средой для воз-
никновения багов, так как это будет работа (включая продюсера)
на скорую руку, как правило, без возможности погрузиться в этот
прошлый проект и понять риск внесения изменений. Мало того,
новые проекты также могут
а) пострадать или
б) даже быть отложенными
из-за того, что
а) на них будет потрачено меньше времени или
б) времени может физически не хватить.
Что же нам делать, чтобы избежать кордебалета с изменяю-
щимися спеками?
Если менеджер говорит, что нужно изменить спек, или продюсер
"вспомнил" о реально важной вещи для спека и эти "НУЖНО"
или "ВСПОМНИЛ" приходятся на самое наинеподходящее время,
то никуда не денешься, но все же две очень нехорошие ситуации,
связанные с изменением спека, можно превентировать.
Две нехорошие ситуации:
1. Спек может быть изменен по-тихому.
2. Изменения к спеку не утверждены программистом и тес-
тировщиком.
Вопрос: Как конкретно мы превентируем две нехорошие ситуации?
Ответ: Мы заморозим спек.
В любой интернет-компании существует программа контроля за
версиями. Во многих случаях это старая добрая CVS ("си-ви-эс" —
Concurrent Version System — система по согласованным версиям).
CVS — вещь многофункциональная, и мы о ней еще поговорим,
но сейчас она нам будет полезна для следующего:
1. С помощью CVS продюсер может сохранять версии спека и
всегда вернуться к старым редакциям.
2. С помощью CVS можно "закрыть" директорию так, чтобы
документы из этой директории могли читаться, но не мог-
ли редактироваться.
80 Тестирование Дот Ком. Часть 1
Процессуально все можно сделать так:
1. К определенной дате все спеки должны быть утверждены.
Неутвержденный спек не кодируется, и точка.
2. Директория со всеми утвержденными спеками закрывается,
и никто ничего не может изменить в этой директории...
...если только не будет следовать процедуре изменения спека.
Кстати,
техническую сторону, связанную с заморозкой спеков (spec freeze), обес-
печивают инженеры по релизу.
Процедура включает:
1. Утверждение всех изменений составом лиц, утвердившим
предыдущую редакцию.
2. Посылку е-мейла с перечислением изменений и именами
утвердивших всем департаментам, непосредственно свя-
занным с разработкой ПО (продюсеры, программисты,
тестировщики и инженеры по релизу). Одно из хороших
качеств такого е-мейла — это то, что люди, не участво-
вавшие в пункте 1 и имеющие старую версию спека, тоже
узнают об изменениях.
3. Открытие CVS-директории для закладки файла и ее закрытие.
Конечно, без изменений в спеках не обойтись, но путем
1) замораживания спеков;
2) введения процедуры изменения спека;
3) тщательного рассмотрения необходимости каждого из-
менения спека с участием менеджмента
можно превентировать ряд серьезных проблем с качеством.
Идем дальше.
Одна из частых причин, по которым в ПО появляются баги кода, —
это неверное толкование спека (misinterpretation) — ситуация,
когда программисты и/или тестировщики, работающие со спе-
ком, понимают по-своему то, что пытался донести до них продю-
сер, и при этом
• на 100% уверены, что на 100% понимают то, что имел в
виду продюсер, и,
• имея уверенность, не уточняют, так как не будешь же бе-
гать за уточнениями того, что тебе и так ясно.
Цикл разработки ПО 81
Причина неверного толкования спека может быть связана
• с одной стороны, с возможностью множественного тол-
кования некой части спека и,
• с другой — с тем фактом, что многие вещи в этой жизни,
для того чтобы быть адекватно понятыми разными людь-
ми, нуждаются в многоплановой презентации.
Кстати, именно поэтому на чертеже физического объекта (например,
двигателя мотоцикла) последний обычно изображается с трех сторон:
вид спереди, вид сверху и вид слева.
Тезис
Тестировщики должны настаивать, чтобы спеки по максимуму
иллюстрировались:
• макетами (mock-up),
• блок-схемами (flow chart),
• примерами (example).
Аргументация
С примерами все понятно: написал что-то — придумай пример
для иллюстрации, заодно и сам лучше поймешь, о чем пишешь.
Народная мудрость гласит: "Лучше один раз увидеть, чем сто раз
услышать". Отличной идеей является разработка продюсером
макетов интерфейса пользователя (User Interface или просто UI —
"ю-ай"). Делается это так:
во время (или после) написания спека продюсер берет генератор
веб-страниц типа Microsoft FrontPage и путем нехитрых манипу-
ляций создает веб-страницу с кнопками, полями, картинками и
прочими милыми деталями интерфейса.
Затем эта страничка "подшивается" к спеку и помогает всем за-
интересованным лицам увидеть, ЧТО, по замыслу продюсера,
должен будет увидеть пользователь.
Кстати, если спецификация предусматривает, что пользователь будет
проходить через несколько веб-страниц для совершения какого-либо
действия (например, покупки книги), то макеты этих веб-страниц могут
не только являться частью спека, но и служить в качестве обоев, если
их развесить на стенах офиса в том порядке, в котором их будет видеть
пользователь.
82 Тестирование Дот Ком. Часть 1
Пример
Вольное изложение опека #1023 "Регистрация нового пользователя":
Регистрация пользователя состоит из трех страниц, идущих в следую-
щем порядке:
• первая страница (1) — поле для индекса места жительства
пользователя и кнопка "Продолжить регистрацию";
• вторая страница (2) — поля для имени, фамилии, е-мейла и па-
роля/подтверждения пароля пользователя, кнопка "Зарегистри-
роваться";
• третья страница (3) — текст с подтверждением регистрации.
Все поля обязательны для заполнения, и если на странице (1) или (2)
вводится недействительное либо пустое значение любого поля, то
пользователю показывается та же страница, но с сообщением об
ошибке (error message). (В данном случае мы не будем говорить о том,
какой ввод действителен (легитимен) для каждого из полей, так как это
сейчас неважно.)
Продюсер разрабатывает три страницы, распечатывает их в двух ком-
плектах, один из которых подшивает к спеку, а другой развешивает на
стене в порядке появления перед пользователем: страница (1), стра-
ница (2), страница (3).
Оговорка 1: Макеты могут быть разной степени детализации, и
вполне допустимо, когда элементы интерфейса, не имеющие от-
ношения к иллюстрируемому спеку, не включаются в макет, на-
пример, в случае с макетами для регистрации нас не интересуют
картинки на веб-странице.
Оговорка 2: Понятно, что макеты интерфейса пользователя не
создаются, если спек полностью посвящен бэк-энду веб-сайта
(например, спек "Автоматизация отчетов по продажам"), так как
детали интерфейса пользователя, т.е. фронт-энд, в таком спеке
просто не упоминаются.
Проблема макетов (даже развешанных правильно) заключается в
том, что они позволяют увидеть в первую очередь интерфейс
пользователя, а не логику работы кода позади интерфейса, на-
зываемую алгоритмом программы.
Интерфейс — это то, ЧТО видит пользователь, а алгоритм —
это то, ПОЧЕМУ пользователь видит то, что он видит.
Для графической презентации алгоритмов используются блок-
схемы, так горячо любимые всеми выпускниками математиче-
ского класса выпуска 1990 г. люберецкой школы № 12.
Цикл разработки ПО 83
Пример
Представим предыдущую ситуацию с регистрацией, но в форме блок-
схемы (такая блок-схема называется process flow chart, так как устроена
по схеме ввод->процесс->вывод).
Кстати, блок-схемы могут создаваться как продюсером, так и
тестировщиком, но независимо от составителя, как правило,
прекрасной идеей является включение блок-схемы в секцию тест-
комплекта GLOBAL SETUP and ADDITIONAL INFO.
Блок-схемы, макеты и примеры (вместе именуемые БМП) помо-
гают превентировать появление багов или найти баги на
уровне спека следующими путями:
84 Тестирование Дот Ком. Часть 1
• БМП — это описание предмета с разных сторон, что ведет
к его адекватному толкованию разными людьми;
• создание БМП — это процесс переосмысления написан-
ного, что ведет к нахождению багов в написанном, т.е. в
спеке;
• макеты и блок-схемы наглядны и во многих случаях по-
зволяют в буквальном смысле увидеть баги в отличие от
ситуации, когда есть только текст.
Еще раз: тестировщики должны настаивать, чтобы спеки по
максимуму иллюстрировались макетами (тоск-ир), блок-схе-
мами (flow chart) и примерами (example).
Теперь, после того как вы услышали про макеты и пошли дальше,
не увидев их (что было сделано намеренно — с целью дать вам
прочувствовать контраст между работой без макетов и с ними),
позвольте представить вам макеты "Регистрации":
Макет страницы (1)
Макет страницы (2)
* поле обязательно для заполнения
Цикл разработки ПО 85
Макет страницы (3)
Регистрация завершена,
логина
Нажмите сюда для
Бонус: Макет страницы (2) в случае ошибки пользователя при
заполнении поля "Е-мейл"
Ошибка
I Проверьте правильность заполнения поля:
Е-мейл
2. Заново введите пароль
* поле обязательно для заполнения
Кстати, макет страницы (2) и бонус-макет страницы (2) противоречат
спеку: по спеку поле "Фамилия" является обязательным для заполнения, но
на макетах оно не выделено звездочкой. Противоречие внутри спека —
это баг, так как любая инструкция теряет смысл, если ее указания не
стыкуются друг с другом.
Постановка мозгов
При обнаружении противоречий внутри спека (а БМП — это части спека!)
нужно сделать рапорт о баге против продюсера, чтобы тот настроил в
унисон несогласующиеся части. В нашем случае продюсер должен из-
менить либо текстовую часть спека ("все поля являются обязательными,
кроме поля "Фамилия"), либо соответствующие макеты (добавить
звездочку к полю "Фамилия").
Идем дальше.
86 Тестирование Дот Ком. Часть 1
В заключение краткого экскурса о спеках дам еще одну полезную
идею.
Каждая более или менее уважающая себя компания имеет свой
сайт в локальной сети (intranet), который недоступен внешним
пользователям. На этом сайте можно прочитать тезисы о корпо-
ративной морали, узнать имя любимого лемура президента ком-
пании, посмотреть фотографии тех, кто по-тихому правит утвер-
жденные спеки, и найти много другой полезной информации. Так
вот, все когда-либо утвержденные спеки должны быть выло-
жены на этот сайт. При этом они группируются по номеру релиза
и доступны для просмотра, поиска по директориям (название
директории — номер релиза), ID, ключевым словам в названии и
имени продюсера. Если спек ссылается на внешний документ
(например, на правила расчетов Центрального банка), то спек
должен содержать гиперлинк на адрес такого документа в локаль-
ной сети.
Постановка мозгов
Не стесняйтесь рапортовать баги, которые вы будете находить в
спеках. Если продюсеры не понимают, то объясните им без пере-
водчика, что баги, посеянные в спеке, могут, как зараза, перенестись
в код и тест-кейсы и баг, найденный раньше, стоит компании дешевле
(об этом чуть позже), а посему учет таких багов является не правом,
а обязанностью тестировщиков.
Следующий этап цикла разработки ПО — это кодирование, осу-
ществляемое программистами (в то время как тестировщики
планируют проверку пишущегося кода).
Кодирование
Работа программиста заключается в том, чтобы перевести вещи,
отраженные в спецификации (или словах босса), на язык про-
граммирования.
Перевод осуществляется
• напрямую, т.е. программист берет спек и напрямую кодирует
его предписания (плохая, недальновидная и опасная идея),
• или после создания внутреннего дизайна кода, т.е. сугубо
технической документации, планирующей, как требова-
ния спека будут воплощены в коде (хорошая, дальновидная
и благодарная идея).
Цикл разработки ПО 87
К документам о внутреннем дизайне кода относятся, например,
• документ о дизайне /архитектуре системы (System /Architecture
Design Document);
• документ о дизайне кода (Code Design Document).
развитие культуры создания и поддержания документации о
внутреннем дизайне кода — это один из признаков, что стар-
тап из шарашкиной конторы (пусть даже и с миллионным
финансированием) превращается в серьезную софтверную
компанию.
Идем дальше.
В идеальном случае каждый программист имеет личную версию
сайта (или playground— игровую площадку), в которую входят:
• веб-сервер (web server);
• сервер с приложением (application server);
• база данных (database).
Коротко остановимся на каждом из этих компонентов.
Пример
1. Пользователь набирает в браузере: www.testshop.rs. Через Интернет
запрос идет на веб-сервер, и в ответ на жесткий диск пользователя
сыпятся:
• файл index.htm, содержащий HTML (Hyper Text Markup Language)-код с
инкорпорированным в нем JavaScript (читается как "джава-скрипт")-
кодом;
• файлы-картинки (images), на которые ссылается веб-страница
index.htm. Эти картинки пользователь должен увидеть в веб-брау-
зере на веб-странице index.htm.
Кстати, первая страница веб-сайта, которую мы по умолчанию видим
в веб-браузере после набора URL веб-сайта (например, www.google.com),
называется homepage.
Кстати, коммуникация между веб-браузером и веб-сервером осуще-
ствляется путем обмена сообщениями, основанными на протоколе, т.е.
своде правил, называемом HTTP (Hyper Text Transfer Protocol). Потоки
таких сообщений, передающихся по компьютерной сети, называемой
Интернетом, являются HTTP-трафиком (HTTP traffic).
2. Пользователь кликаетлинк "Регистрация" (веб-сервер присылает в
ответ файл register.htm и слинкованные с ним картинки).
3. На странице register, htm пользователь вводит имя, е-мейл и прочие
данные и отправляет форму, нажав кнопку "Зарегистрироваться".
88 Тестирование Дот Ком. Часть 1
4. Через веб-сервер эта форма, т.е. запрос о регистрации, поступает
на сервер с приложением, которое
• обрабатывает этот запрос;
• запрашивает базу данных, есть ли уже эккаунт с таким е-мейлом;
• обрабатывает ответ от базы данных;
• если е-мейл не найден, посылает запрос к базе данных о созда-
нии записи для нового пользователя;
• формирует ответ для пользователя;
• в виде веб-страницы с подтверждением регистрации или веб-стра-
ницы с ошибкой посылает пользователю ответ через веб-сервер.
Так вот, программисты разрабатывают код вышеупомянутого
приложения, который впоследствии отдается на растерзание тес-
тировщикам, в злорадном предвкушении потирающим ручонки и
знающим, что причинами возникновения багов в коде явля-
ются как возможность программиста полдня бродить по Интер-
нету, так и другие объективные вещи:
а. Некачественные и/или изменяющиеся спецификации
Об этом мы уже говорили.
б. Личностные качества программиста
Такие, как халатность, невнимательность и лень.
в. Отсутствие опыта
Программист может просто не знать, как нужно сделать пра-
вильно.
г. Пренебрежение стандартами кодирования
О стандартах чуть позже.
д. Сложность системы
Современные интернет-проекты отличаются такой сложностью,
что мозг простого смертного порой просто не в состоянии про-
анализировать все последствия создания/изменения/удаления
кода и предугадать появление проблемы.
е. Баги в ПО третьих лиц, т.е. баги
• в операционных системах;
• в компайлерах (compiler — ПО для переведения (напри-
мер, C++) кода в машинный язык и создания исполняе-
мых файлов);
• в веб-серверах;
• в базах данных и др.
Цикл разработки ПО 89
ж. Отсутствие юнит-тестирования,
х.е. тестирования кода самим программистом: "И вообще, почему
я должен искать баги в своем коде, когда есть тестировщики?"
(Поговорим о юнит-тестировании через минуту.)
з. Нереально короткие сроки для разработки
Об этом мы тоже скоро поговорим.
Возможности оздоровления кода и превентирования багов до
передачи кода тестировщикам (иллюстрации последуют не-
медленно) включают:
1. Наличие требований к содержанию спеков и следова-
ние правилам их изменения;
2. Возможность прямой, быстрой и эффективной комму-
никации между программистами и программистами и
продюсерами;
3. Инспекции кода;
4. Стандарты программирования;
5. Реальные сроки;
6. Доступность документации;
7. Требования к проведению юнит-тестирования (о кото-
ром мы поговорим уже через 30 секунд);
8. Реальные финансовые рычаги стимуляции написания
эффективного и "чистого" кода;
9. Наличие понятий "качество" и "счастье пользователя"
как основных составляющих корпоративной философии.
Подробности.
1. НАЛИЧИЕ ТРЕБОВАНИЙ К СОДЕРЖАНИЮ СПЕКОВ
И СЛЕДОВАНИЕ ПРАВИЛАМ ИХ ИЗМЕНЕНИЯ
О спеках мы уже говорили.
2. ВОЗМОЖНОСТЬ ПРЯМОЙ, БЫСТРОЙ И ЭФФЕКТИВНОЙ
КОММУНИКАЦИИ МЕЖДУ ПРОГРАММИСТАМИ
И ПРОГРАММИСТАМИ И ПРОДЮСЕРАМИ
Здесь есть следующие аспекты:
а. Психологические аспекты
Очень важно привить в культуру компании следующее правило:
"Если к тебе обратились — помоги".
90 Тестирование Дот Ком. Часть 1
Пример
Программист приходит к продюсеру с просьбой объяснить некую часть
спека. Продюсер говорит, что он сейчас слишком занят. "Давай завтра,
добро?" Очень часто после пары "давай завтра" программист что делает? Пра-
вильно! Он пишет код так, как его понимает, — без всякой гарантии, что
сей код отразит требуемое.
Следующий аспект:
программист (как и все остальные участники цикла) никогда не
должен стесняться спрашивать (хоть двести раз!) и подтверждать
свое понимание е-мейлами типа: "Просто хотел уточнить, что я
правильно понял, что пункт 12.2 такого-то спека говорит..." Если
же программисту не отвечают, когда он подходит, прекрасно —
нужно послать е-мейл и сохранить этот е-мейл, как и е-мейлы "Я
хотел уточнить". Если снова не отвечают, программист должен
идти к своему менеджеру и просить его принять меры. И это не
стукачество, а деловая практика — business is business.
Следующий аспект:
Менеджмент должен регулярно устраивать так называемые Team
Building Activities (мероприятия по сплочению коллектива) с той
простой целью, чтобы между членами команды кроме профес-
сиональных налаживались и человеческие контакты. Причем, как
показывает опыт, совместный выезд для игры в пейнтбол раз в
месяц гораздо эффективнее для сплочения коллектива, чем со-
вместная проспиртовка мозгов во время пятничных застолий.
б. Технический аспект
Каждый из участников цикла разработки ПО должен быть досту-
пен для контакта: желательно, чтобы все они работали в одном
здании; в локальной сети должны быть доступны служебные, мо-
бильные и домашние телефоны; необходимо согласовать часы
(хотя бы 4 часа в день), когда все (и тот, кто ушел в 6 часов вече-
ра и в 3 утра) находятся в офисе.
3. ИНСПЕКЦИИ КОДА
У некоторых программистов есть такая концепция: "Если я пишу
код, который могу понять только я, то меня не уволят".
Ну, во-первых, при желании можно уволить даже президента
"ЮКОСа", во-вторых, такой подход к работе априори неправи-
Цикл разработки ПО 91
лен: в интернет-компаниях никто никого силком не держит, и
если ты согласился работать на определенных условиях, то будь
добр работать профессионально и добросовестно.
Если же компания не выполняет взятых на себя обязательств
(например, по оплате), то мы просто ищем другую компанию —
ведь никто никому не давал клятву верности.
Постановка мозгов
Компания держит каждого из нас до тех пор, пока мы ей нужны, и если
какая-то конкретная позиция перестает быть необходимой для бизне-
са, то человеку просто говорят: "Гуд бай" независимо от того, сколько у
него
детей плачет по лавкам;
котов мяукает по печкам.
Как поет Тимур Шаов: "Это бизнес, господа..."
Вместе с тем, если вы находите компанию с лучшими для себя усло-
виями и, работая на старом месте, прошли интервью и получили
письменное предложение о работе, то вы просто идете к своему ме-
неджеру и говорите, что собрались уходить, но можете подумать о том,
чтобы остаться, только если компания сделает для вас то-то и то-то,
например повысит заработную плату.
Несмотря на то что бизнес есть бизнес, нужно оставаться профессио-
налом, даже если предложение о новой работе удивительно выгодно и
искушение все бросить велико. Никогда не уходите из компании, не
передав дела и не закончив старые проекты. Ведите себя про-
фессионально !
После небольшого отступления продолжаем основную тему.
В-третьих, чтобы избежать подобных проблем, чреватых багами
и трудностью их фиксирования (fix — починка, ремонт), в ком-
пании должны проходить инспекции кода (code inspection).
Это может быть еженедельное совещание, например, следующего
формата: менеджер программистов распечатывает код любого из
программистов, и последний в присутствии коллег рассказывает,
что, как и почему. Будет ли программист писать код, понятный
только ему, если на совещании его обязательно спросят: "Това-
рищ, а что это вы здесь написали?"
4. СТАНДАРТЫ ПРОГРАММИРОВАНИЯ
С пунктом 3 перекликается идея создания стандартов програм-
мирования.
92 Тестирование Дот Ком. Часть 1
Пример
Вспомним Вавилонскую башню, а вернее, ТОТ момент строительства,
когда все вдруг стали говорить на разных языках (множественность
стандартов). Последствия печальны: проект был начисто заброшен,
название кинокомедии "Some like it hot" перевели как "В джазе только
девушки" и японские фанатки "Тагу" убеждены, что "Мальчигей" — это
название места для романтических свиданий нетрадиционных девушек
на Красной площади.
Такая же катавасия творится в компании, когда программисты
вроде бы и используют тот же язык, например C++, но при напи-
сании кода каждый руководствуется своими привычками.
Пример
Допустим, что отсутствуют стандарты названия новых классов C++.
S этом случае, если Саня любит называть свои классы в формате
"CREDITCARD" (все заглавные и нижнее подчеркивание), а
Леха — "CreditCard" (заглавные только первые буквы каждого слова
и слитное написание),
то, например, Леха, не зная о привычках Сани, но верный своим при-
вычкам, помня лишь "Кредиткард" и желая обратиться к функции из
CREDITCARD, в своем коде так и запишет: "CreditCard". В итоге код не
будет работать, так как C++, ничего не знающий ни о Лехе, ни о Сане, ни о
кредитных картах, думает о CREDITCARD и CreditCard как об
абсолютно разных классах.
Стандарты могут включать:
• правила о комментариях;
• правила об именах таблиц в базе данных, классов, функций
и различных видов переменных;
• правила о максимальной длине строки;
• прочее.
Документ со стандартами должен быть доступен на интранете.
Стандарты программирования — это неотъемлемая часть
процесса, когда в компании работают два программиста и боль-
ше. Они по определению должны быть обязательны для всех.
5. РЕАЛЬНЫЕ СРОКИ
В стартапе изначально и по определению сроки на разработку
нереальны, и приходится балансировать между
• "поспешишь — людей насмешишь" и
• необходимостью закончить кодирование в срок.
Цикл разработки ПО 93
Несмотря на то что стопроцентно действующих рецептов нет, вот
хорошая идея для облегчения нелегкой жизни программистов:
после ознакомления со спеками программисты должны предос-
тавить менеджменту примерные оценки (сметы) сроков для
разработки кода, и исходя из этих смет менеджмент может,
если нужно
• перераспределить нагрузку и
• посмотреть, имеет ли смысл убирать что-то из менее
приоритетных функционалъностей ради того, чтобы
чисто и тщательно написать остальной код.
Единственное утешение состоит в том, что, когда стартап как
бизнес становится более зрелым, сроки и рабочие часы стабили-
зируются во многом потому, что менеджмент понимает, что луч-
ше дать реальный срок (например, перенеся некоторые из спеков
в следующие релизы), чем поступиться качеством.
6. ДОСТУПНОСТЬ ДОКУМЕНТАЦИИ
ВСЕ документы, относящиеся к разработке ПО, включая спеки,
процедуру изменения спека, стандарты программирования, тест-
комплекты, и документы, о которых мы будем говорить в даль-
нейшем, должны быть доступны в локальной сети, и их располо-
жение должно быть максимально оптимизировано для удобства и
быстроты поиска. Все должно быть сделано для того, чтобы за-
интересованный сотрудник быстро нашел нужный документ, а не
тратил свое время и время своих коллег на долгие поиски.
Несмотря на кажущуюся очевидность и легковесность этого мо-
мента, несоблюдение правила о доступности ВСЕХ документов
на практике может принести много проблем.
7. ТРЕБОВАНИЯ
К ПРОВЕДЕНИЮ ЮНИТ-ТЕСТИРОВАНИЯ
Юнит-тестирование (unit testing) — это тестирование, произ-
водимое самим программистом. Здесь нужно подчеркнуть, что
неправильный подход к введению юнит-тестирования вызо-
вет справедливое раздражение программистов, так как за тес-
тирование платят тестировщикам, а отсутствие требований к
юнит-тестированию вообще увеличит стоимость багов.
94 Тестирование Дот Ком. Часть 1
Постановка мозгов
Стоимость бага — это
• расходы компании, чтобы найти баг и исправить его до пе-
редачи кода пользователю. Расходы компании поддаются
приблизительной оценке;
• убытки, которые несет компания, потому что баг не был
найден до передачи кода пользователю. Объективная оценка
убытков в большинстве случаев невозможна.
Подробности:
Стоимость бага в первом случае:
Если баг был допущен на уровне спека и найден во время тестирования
кода, его стоимость вычисляется как
стоимость оплаты продюсера в час, помноженная на количество
часов, потраченных на разработку "неправильной" части спека
(стоимость спека), плюс + стоимость программирования
"неправильной" части спека плюс + стоимость тестирования
"неправильной" части спека плюс + стоимость фиксирования бага и
проблем, из него вытекающих.
Как видно, слагаемые поддаются приблизительной оценке.
Стоимость бага во втором случае:
Если баг был допущен на уровне спека, но не придушен до релиза и найден
пользователем, то к стоимости, вычисляемой по формуле предыдущего
случая, могут прибавиться десятки других убытков (включая упущенную
выгоду), например:
• время службы поддержки;
• компенсации пользователю потерянных денег;
• иски против компании;
• навсегда утраченная потенциальная оплата услуг компании ушед-
шими пользователями и пользователями, которые по рекомендации
ушедших никогда не заглянут на ваш веб-сайт,
а также множество других плохих и неприятных вещей.
Наиболее важное в концепции стоимости бага — это то, что чем раньше
будет найден баг, тем он будет дешевле для компании.
Таким образом, баг (а это, как мы знаем, может быть и отклонение от
здравого смысла), найденный на уровне идеи, — это самый дешевый
баг, соответственно баг, найденный после релиза, — это самый
дорогой баг. Причем убытки от последнего, как правило, не поддаются
объективной оценке.
Как видим, QA и тестирование — это не только обеспечение счастья
пользователей, но и путь САМОСОХРАНЕНИЯ любой интернет-
компании.
Вернемся к юнит-тестированию. Вот две рекомендации:
1. Юнит-тесты должны планироваться в письменной фор-
ме ДО написания кода.
Цикл разработки ПО 95
В таком случае программист после получения спека не бежит
сломя голову писать код, а садится за документацию о дизайне
кода с параллельным созданием юнит-тестов.
Полезность такого подхода заключается в том, что,
во-первых, программист абстрагируется от непосредственного
кодирования и, видя "большую картину", может предугадать прин-
ципиальные ошибки в алгоритмах и,
во-вторых, он сможет заранее представить, КАК он будет тести-
ровать код, это "КАК" занозой засядет у него в голове и при на-
писании кода будет работать по принципу "предупрежден — зна-
чит вооружен".
2. Требования к юнит-тестам должны быть формализованы
в стандартах о юнит-тестировании.
Например, каждая функция должна иметь по крайней мере один
тест-кейс с одним конкретным вводом и одним конкретным вы-
водом (ожидаемым результатом).
Принципиально, думаю, понятно. А так как написание и испол-
нение юнит-тестов — это дело программистов, то мы закончим
рассуждения о нем и пойдем дальше, у нас, тестировщиков, своих
дел по горло.
8. РЕАЛЬНЫЕ ФИНАНСОВЫЕ РЫЧАГИ
СТИМУЛЯЦИИ НАПИСАНИЯ ЭФФЕКТИВНОГО И
"ЧИСТОГО" КОДА
Здесь все элементарно — менеджмент не должен жмотиться, если
люди горбатятся на проект день и ночь, а в итоге не узнают своих
подросших детей и называют своих жен Ленами (по имени колле-
ги, сидящей за соседним компьютером и ставшей почти родной).
• Хорошая заработная плата с возможностью увеличения;
• билеты в "Ленком";
• премии за хорошую работу;
• неограниченные чипсы и диет-кола;
• оплата абонемента в бассейн и гимнастический зал;
• месячные проездные;
• выезды для игры в пейнтбол;
• беспроцентный кредит на машину;
• помощь при первоначальном взносе на квартиру —
96 Тестирование Дот Ком. Часть 1
чем больше заботы проявит компания о сотрудниках (и не только
программистах), тем добросовестнее они будут работать, тем
меньше будут получать втыков от жен — любительниц Louis
Vuitton и тем больше будут радеть за свое место и качество кода,
включая разработку дополнительных (от себя) юнит-тестов.
В общем нужно сделать так, чтобы профессионал не думал о
том, как свести концы с концами, а работал, зная, что его
труд будет достойно оценен, и видел, что компания заботится
о нем.
9. НАЛИЧИЕ ПОНЯТИЙ "КАЧЕСТВО" И "СЧАСТЬЕ
ПОЛЬЗОВАТЕЛЯ" КАК ОСНОВНЫХ СОСТАВЛЯЮЩИХ
КОРПОРАТИВНОЙ ФИЛОСОФИИ
Менеджмент должен сделать так, чтобы персонал понимал, что
"качество" и "счастье пользователя" — это не фикция, а путь к
финансовому успеху компании и соответственно лучшей жизни
каждого, кто работает над проектом. Если менеджеры по-
смеиваются над мерами по улучшению качества и отпускают
шутки о пользователях (даже в курилке!), то это тлетворно
действует на всех сотрудников компании и в конечном счете
негативно скажется на пользователях, а следовательно, по
принципу бумеранга и на самой компании, включая
"юмористов".
Пользователи знают, уважают их или нет, уже после одного
сообщения об ошибке, одного е-мейла от компании или од-
ного звонка в службу поддержки, и если философия компа-
нии — это "тупые юзеры", то, поверьте, она проявится, на
радость конкурентам, во многих вещах.
Теперь поговорим о трех основных занятиях программиста:
1. Написание кода для данного релиза происходит во время
стадии "Кодирование".
2. Интеграция кода для данного релиза происходит по за-
вершении стадии "Кодирование".
3. Ремонт багов для данного релиза происходит во время
стадии "Кодирование" следующего витка цикла разработ-
ки ПО (соответственно в пункте 1 программист ремонти-
ровал баги для предыдущего релиза).
Цикл разработки ПО 97
Техническая версия
1. НАПИСАНИЕ КОДА
Один программист написал: parent_value = 1. Другой програм-
мист написал: child_value = parent_valu + 3.
2. ИНТЕГРАЦИЯ КОДА
а. Пытаемся два куска кода соединить в один:
parent_value = 1,
child_value = parent_valu + 3.
б. Код не компилируется (компайлер выдает ошибку о неоп
ределенной переменной), так как второй программист на
писал parent valu вместо parent value.
в. Код второго программиста фиксируется:
child_value —parent_value + 3.
г. Пытаемся два куска кода соединить в один:
parent_value = 1,
child_value = parent_value + 3.
д. Код компилируется, но первый программист выполняет
юнит-тест, по которому parent_yalue должно быть равно 7.
е. Код первого программиста фиксируется:
parent_value - 1.
ж. Пытаемся два куска кода соединить в один:
parent_value = 7,
child_value = parent_value + 3.
з. Вроде все в порядке, передаем тестировщикам — пусть
они тра... маются.
3. РЕМОНТ БАГОВ
Согласно спецификации должно быть:
child_value - parent_yalue x 3.
Тестировщик рапортует баг, и на основании этого бага програм-
мист меняет код.
98 Тестирование Дот Ком. Часть 1
Лирическая версия
1. НАПИСАНИЕ КОДА
О написании кода мы уже говорили. Один момент:
Качество работы программиста не должно оцениваться по коли-
честву багов, которые он взрастил, так как помимо таких субъек-
тивных вещей, как профессионализм и добросовестность, на на-
личие багов влияет множество других объективных факторов, о
которых мы упоминали (нехватка времени, плохие спеки и т.д.).
2. ИНТЕГРАЦИЯ КОДА
Вариант 1. Неблагодарный
После того как код написан на игровой площадке каждого из
программистов, происходит интеграция кода, когда тысячи строк
кода разных авторов компилируются на одном компьютере, на-
езжают друг на друга, спотыкаются, огрызаются и дарят релиз-
инженерам, производящим интеграцию, сомнения в принципи-
альном наличии вселенской гармонии.
Пример
Собрали четырех отличных художников, причем каждый должен выпол-
нить заказ на куске прозрачной пленки 50x50 см:
• задание первому: нарисовать удрученного, стоящего на коленях
молодого человека;
• задание второму: нарисовать милостиво склонившегося старика;
• задание             третьему: нарисовать фон, вызывающий сострадание;
• задание четвертому: нарисовать группу печальных людей.
"В общем, парни, генеральная идея... эта... типа как у этого... О! У Рем-
браНа: возвращение загулявшего сына". Неудивительно, что мы прочувствуем всю боль релиз-инженеров, ко-
гда соединим четыре рисунка вместе и увидим
• удрученного великана, стоящего на коленях над
• стариком,
• гладящим промокшую болонку
• в окружении заспанных курсантов-суворовцев.
Остается только редактировать картинки каждого из художников и гру-
стить, что их не совмещали по мере написания, используя...
Вариант 2. Благодарный
Чтобы избежать проблем, когда в один момент происходит мас-
сированная интеграция кодов разных авторов, как в Варианте 1,
программисты производят интеграцию постоянно по мере напи-
Цикл разработки ПО 99
сания нового кода (т.е. стадия 1 и стадия 2 цикла разработки кода
сливаются в одну стадию), что дает возможность выявить несты-
ковки между кодами разных авторов на раннем этапе.
3. РЕМОНТ БАГОВ...
происходит во время стадии "Тестирование и ремонт багов", по-
сле того как код для данного релиза был заморожен и програм-
мисты работают над кодом для нового релиза.
Необходимость в замораживании кода вызвана тем, что продукт
(в данном случае код) должен быть в каком-то устойчивом виде,
чтобы его проверили.
Пример
Представьте следующую ситуацию:
1. Программист закончил работу над функциональностью А;
2. Тестировщик проверил, что функциональность А работает, и дал
добро на релиз;
3. За час до релиза программист вносит маленькое изменение в код,
которое в теории ничего не ломает...
а на практике приводит к тому, что функциональность В, связанная с А,
абсолютно перестает работать, т.е. получилось так, что тестировщик
попросту потерял время (а значит, и деньги компании), тестируя не
финальную версию продукта.
Из сказанного вытекают две принципиально важные для тести-
ровщика вещи. Перед началом тестирования нужно убедиться, что
• код заморожен (обычно релиз-инженеры посылают соот-
ветствующий е-мейл);
• версия продукта на внутреннем сайте, на котором вы будете
производить тестирование, является именно той версией,
которую вам нужно протестировать.
Пример
Допустим, что на интранете у нас есть два внутренних тестировочных
веб-сайта, недоступных для пользователей:
• www.everest.testshop.rs и
• www.elbrus.testshop.rs
Допустим также, что сайт
• www.everest.testshop.rs(по-простомуназываемый "Эверест") является
версией 1.0 и содержит функциональность А версии 1.0, а
• www.elbrus.testshop.rs(по-простомуназываемый "Эльбрус") является
версией 2.0 и содержит функциональность А версии 2.0.
100 Тестирование Дот Ком. Часть 1
Так вот в окне веб-браузера функциональность А может выглядеть аб-
солютно одинаково и на Эвересте, и на Эльбрусе, но ее бэк-энд будет
существенно различаться на этих двух сайтах.
Допустим, тестировщик собирается проверить функциональность А
версии 2.0, но ошибочно использует для тестирования Эверест (с вер-
сией 1.0), вследствие чего он не только впустую тратит время, но
и рискует дать добро на релиз непротестированного кода функцио-
нальности А версии 2.0.
Подобные ошибки возникают, как правило, по небрежности или
незнанию тестировщика и из-за "нелогичных" названий внутрен-
них веб-сайтов.
Пути предотвращения ситуации, когда тестировщик тестирует не
ту версию ПО:
1. Узнайте у релиз-инженера, как определить версию кода, и
используйте сие знание перед началом исполнения тести-
рования;
2. Посоветуйте, чтобы внутренние веб-сайты имели логич-
ные имена. Например, версия кода, переданного пользова-
телю, всегда должна быть на внутреннем сайте по адресу
www.old.testshop.rs, а версия для следующего релиза — на
www.main.testshop.rs;
3. Попросите релиз-инженеров, чтобы те создали на интра-
нете динамически обновляемую страничку с информацией
о
• версии и
• подверсии, т.е. билде (об этом позже),
каждого внутреннего тестировочного веб-сайта.
В завершение кодирования поговорим еще о паре вещей.
Хотя и спеки, а иногда даже и сами идеи для спеков — ребятки
не без греха, большинство багов зачинается именно при написа-
нии кода. При кодировании появляется присущий только этой
стадии и одновременно самый простой в нахождении вид бага —
синтаксический баг (syntax bug).
Прелесть синтаксических багов заключается в том, что они, явля-
ясь ошибками в языке программирования, находятся компай-
лером (например, в случае с C++) автоматически. Последний
выдает на экран сообщение об ошибке и принципиально не соз-
Цикл разработки ПО 101
дает исполняемый файл, пока проблема не будет зафиксирована
(в скриптовых языках, таких, как Python, исполняемым файлом
является сам файл с кодом и синтаксические баги находит интер-
претатор языка).
Пример
Вот первая программка любого изучающего C++:
1. #include <iostream.h> 2.
3. voidmain()
4. {
5. cout<< "Hello, World!<< endl;
6. }
Текст этой программки находится в файле syntax_error.cpp. По-
пробуем ее скомпилировать:
~> C++ syntax error, cpp
syntax_error.cpp:5: unterminated string or character constant
syntaxerror.cpp: 5: possible real start of unterminated constant
Последние две строчки — это текст об ошибке, выданный ком-
пайлером из-за того, что мы не закрыли кавычки в строке 5 после
World! Никакого исполняемого файла создано не было. Если мы
исправим эту ошибку, то файл без проблем скомпилируется.
Тестировщики обязаны устройству Вселенной за то, что есть ло-
гические баги (logical bugs). Эти баги, как следует из их назва-
ния, — это ошибки в логике кода, т.е. код компилируется без син-
таксических ошибок, но фактический результат исполнения этого
кода не соответствует ожидаемому результату.
Пример
Спецификация:
"7.2. Пользователь должен ввести два целых числа от 1 до 12,
после чего программа выведет на экран их среднее арифмети-
ческое".
Код:
1. #include <iostream.h> 2.
3. voidmain()
4. {
5. int first number = 0;
6. int secondjnumber = 0;
7. float average = 0.0;
102 Тестирование Дот Ком. Часть 1
8.
9. //get first number
10. cout« "Enter first number:";
11. cin » first_n umber;
12.
13.
14. //get second number
15. cout« "Enter second number:";
16. cin » second number; 17.
18. //calculate average
19. average = firstjiumber+second_number/2.0; 20.
21. //output result
22. cout« "Average = "« average « endl; 23.
24. }
Тестирование:
Enter first number: 9 Enter
second number: 2 Average
=10
Согласно спецификации результатом исполнения программы
должно быть среднее арифметическое двух чисел, т.е. в нашем
случае 5,5 (ожидаемый результат). Фактический же результат
оказался равен 10.
5,5 не равно 10, соответственно у нас есть логический баг.
Проблема, кстати, в строке 19, которая должна была звучать так
(были пропущены скобки):
19. average = (first_number+second_number)/2.0.
Кстати, в приведенном пункте спека есть баг, так как непонятно, какое
максимально допустимое целое число: 11 или 12? Программист, увидев
этот баг, должен был сделать уточнение у продюсера и обязать того
исправить спек. Если максимальное число = 12, то точная формулировка
должна быть следующей: "7.2. Пользователь должен ввести два целых
числа от 1 до 12 включительно, после чего программа выведет на экран
их среднее арифметическое".
Кстати, программист заложил в коде еще один логический баг, так как
согласно спеку код должен принять только действительный ввод, кото-
рым являются целые числа 1 — 1 1 (или 1 — 12).
Кстати, спек имеет еще один баг: не сказано, как должна отреагировать
программа, если пользователь введет недействительный ввод, например
0, 13, "А", "#" или пустое место...
Цикл разработки ПО 103
Две последние вещи в разговоре о стадии кодирования.
Первая вещь
Как мы помним, на этой стадии тестировщики пишут тест-кейсы.
Так вот тест-комплекты необходимо, как и спеки, хранить в CVS
и публиковать линки к ним на интранете для предоставления
возможности свободного ознакомления с ними любому заинтере-
сованному лицу внутри компании. Главные преимущества хране-
ния тест-кейсов в CVS:
• отсутствие возможности случайного удаления файла;
• присутствие возможности возвратиться к предыдущим вер-
сиям файла;
• файл хранится на сервере, и каждый, кому нужно (и кто
имеет право), может взять его для исполнения тестирова-
ния, изменения и удаления существующих или включения
дополнительных тест-кейсов.
Вторая вещь
Хорошая идея для компании в целом и для интересов самого
тестировщика — это провести рассмотрение тест-кейсов (Testcase
Review), когда за несколько дней до начала тестирования со-
бираются
• продюсер, написавший спек,
• программист, написавший по спеку код и
• тестировщик, написавший по спеку тест-кейсы.
Тестировщик раздает присутствующим распечатки этих тест-кей-
сов и подробно рассказывает, как он будет проверять функцио-
нальности, описанные в спеке.
Полезность рассмотрения тест-кейсов заключается в том, что
во многих случаях продюсеры и программисты дают новые
идеи для тестирования и/или корректируют допущенные не-
точности.
Политический момент
Если участники митинга
• не предложили внести в тест-кейсы ничего нового либо
• предложили и вы внесли,
то это формально означает, что они одобрили то, как будет протести-
рован код. А так как все протестировать невозможно и всегда есть веро-
ятность, что мы не проверим какой-либо багосодержащий сценарий,
104 Тестирование Дот Ком. Часть 1
то даже в случае пропущенного бага все будут знать, что вы сделали
все возможное для качественной подготовки к тестированию, т.е. соз-
дали тест-кейсы и получили одобрение их эффективности.
Кстати, после рассмотрения тест-кейсов пошлите е-мейл всем
присутствовавшим на совещании. Перечислите в этом е-мейле все
модификации к тест-кейсам, о которых вы договорились на совеща-
нии. Таким образом, с одной стороны, вы составите памятку для са-
мого себя, а с другой — дадите себе возможность удостовериться (пу-
тем получения ответов на е-мейл), что вы учли все предложенные вам
вещи по модификации тест-кейсов и учли эти вещи правильно. Отсут-
ствие ответа на подобный е-мейл — это знак согласия.
Во многих крупных интернет-компаниях рассмотрение тест-кей-
сов — это обязательная процедура перед переходом к стадии...
Исполнение тестирования и ремонт багов
Так как о тестировании мы будем говорить все остальные томные
вечера, то сейчас будем лаконичны, как спартанцы.
После того как проинтегрирован код, тестировщики проводят
тест приемки (smoke test, sanity test или confidence test), в процессе
которого проверяются основные функциональности.
Пример
Если мы не можем погнуться (log into) в наш эккаунт (account) на
www.main.testshop.rs, то о каком дальнейшем тестировании можно
говорить.
Если тест приемки не пройден, то программисты и релиз-инже-
неры совместно работают над поиском причины. Если проблема
была в коде, то код ремонтируется, интегрируется и над ним сно-
ва производится тест приемки. И так по кругу, пока тест приемки
не будет пройден.
Если же тест приемки пройден, то код замораживается и тести-
ровщики начинают тестирование новых компонентов (new feature
testing), т.е. исполнение своих тест-кейсов, написанных по
спекам данного релиза (более подробно о значении термина feature
поговорим в беседе о системе трэкинга багов).
После того как новые функциональности протестированы, насту-
пает очередь исполнения "старых" тест-кейсов. Этот процесс на-
зывается регрессивным тестированием (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) о шести заплаточных релизах, выпущенных ПОСЛЕ две-
надцатого релиза.
Кстати, о номерах релизов. Некоторые компании в желании поориги-
нальничать дают основным релизам не номера, а названия. Ну, напри-
мер, имя поп-группы или отдельного исполнителя.
Звонит программисту дружок: — Здорово, старик. Слушай, Ленка подружку приводит, так что бери
шампанское и подъезжай к семи.
— Не, я пас. Я тут с "Бритни Спирс" завис. -
О!..
Неудобство такого подхода заключается в том, что непонятно, какой
релиз был раньше — "Пол Маккартни" или "Джон Леннон", и в идиотиз-
ме произнесения названий дополнительных или заплаточных релизов:
звонит контрагент со своей проблемой, а ему говорят: "Да усе будет в
порядке. Мы заутра патч номер 7 кДорз присобачим".
Идем дальше.
Любой из трех релизов для пользователя означает, что наш
www.testshop.rs как-то изменился.
Возможные изменения:
1. Новые функциональности (основной и дополнительный
релизы);
2. Изменение/удаление старых функциональностей (основ-
ной и дополнительный релизы);
3. Починка багов, пропущенных в одном из релизов любого
типа (заплаточный релиз).
Организация упаковки кода в виртуальный мешок и его передача
пользователю осуществляются релиз-инженерами.
Давайте представим, что ЗАО "Тест-шоп", предназначенное,
кстати, для продажи книг, только начинает работу.
Цикл разработки ПО 107
У нас есть
• два программиста (Дима и Митя) и
• хозяин-барин (месье Кукушкин Илья Харитонович),
а также
• два компьютера с "Виндоуз" для программистов (здесь и
далее я не буду давать версий не нашего ПО),
• клевый лэптоп Харитоныча (ОС значения не имеет) и
• машина с Линуксом (далее называемая тест-машина) для
разработки и тестирования ПО.
Проект начинается:
1. Регистрируется домен www.testshop.rs.
2. У интернет-провайдера и по совместительству хостинг-про-
вайдера покупается доступ в Интернет и арендуется сервер,
чтобы весь мир мог зайти на огонек, увидеть и оценить.
3. Программистские компьютеры, лэптоп СЕО и тест-машина
объединяются в локальную сеть с выходом в Интернет.
4. Программисты начинают работать над проектом.
Мы уже говорили о том, что классическая архитектура веб-про-
екта — это
• веб-сервер;
• сервер с приложением;
• база данных.
Так вот, так как мы — интернет-компания молодая, то у нас все
будет по-простому: на тест-машине будут все три компонента.
Архитектура www.testshop.rs
1. Веб-сервер Apache ("апачи", имя которого идет не от названия
американского племени индейцев, издревле промышлявших под-
работками на интернет-проектах, а от patchy (залатанный), как
память о неимоверном количестве заплаток, на него приклеен-
ных, в результате чего он приобрел белизну и пушистость).
В директориях Apache мы храним:
• файлы, содержащие HTML-код С инкорпорированным
JavaScript-кодом. JavaScript-код, вставляется в HTML.-
файлы и может служить, например, для проверки е-мейла
при регистрации на наличие двух @. Достоинство
использования JavaScript-кода, заключается в том, что
проверка осуществ-
108 Тестирование Дот Ком. Часть 1
ляется на компьютере пользователя в отличие от варианта,
когда мы посылаем непроверенную форму с регистрацией
на сервер с приложением, нагружая этот сервер;
• файлы-картинки (images).
2. Приложение на Python и C++. Наше приложение состоит из:
• файлов с Python-скриптами, которые можно использовать,
например, для "перевода" регистрационной формы, от-
правленной пользователем, на язык, понятный базе дан-
ных, и для создания новой строки в таблице для новых
пользователей;
• файлов с C++ кодом. Например, нам нужно вставить новое
значение в определенной колонке определенной таблицы
базы данных для всех пользователей, зарегистрированных
у нас более 1 года. Для этой цели мы можем написать про-
грамму на C++.
Кстати, C++ файлы — это единственные файлы в нашем проекте,
которые мы компилируем перед использованием: каждый из наших
C++ файлов — это простой текстовый файл с кодом, написанным на C++,
и, чтобы он стал исполняемым, его нужно скормить C++ компайлеру,
который проверит код на наличие багов синтаксиса и, если все О'к,
переведет язык, понятный человеку (C++), на язык, понятный тест-ма-
шине (нули и единицы).
3. База данных MySQL ("майсиквел"). Здесь мы будем хранить
данные
• о пользователях (например, день регистрации в системе, е-
мейл, имя, фамилию и пароль);
• о транзакциях пользователя (например, когда и что купил);
• о наименованиях книг и их наличии.
Идем дальше.
Начинаются первые неудобства и проблемы, связанные с отсут-
ствием релиз-инженерных знаний:
1. При каждом сохранении файла в той же директории нужно
давать ему новое имя, чтобы не удалить старый вариант
редакции.
2. При сохранении файла после редактирования нельзя про-
комментировать, что было изменено.
3. Самое главное: постоянно присутствует риск, что один из
программистов удалит свою работу или работу коллеги.
Цикл разработки ПО 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/.
• первый релиз откладывается, так как Митина версия registration.
ру абсолютно "не пашет".
осле разбора полетов принимается решение об установке 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. Почему для бета-тестирования набирают народ из типичных
пользователей?

ЧАСТЬ 2
• ЦИКЛ ТЕСТИРОВАНИЯ ПО
• КЛАССИФИКАЦИЯ ВИДОВ
ТЕСТИРОВАНИЯ

цикл
ТЕСТИРОВАНИЯ ПО
• ИЗУЧЕНИЕ И АНАЛИЗ ПРЕДМЕТА ТЕСТИРОВАНИЯ
• ПЛАНИРОВАНИЕ ТЕСТИРОВАНИЯ
• ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ
ока мы еще не остыли от цикла разработки, предлагаю не-
медленно рассмотреть цикл тестирования.
Поехали.
Отвлечемся от компьютеров и представим ситуацию, когда
нужно проверить, ну, например, свежекупленный десятире-
жимный пылесос. После того как агрегат вытащен из коробки,
берем "Инструкцию по использованию" и мытарим чудо техники,
пока все десять режимов не докажут свою лояльность и пре-
данность.
Если посмотреть на процесс более абстрактно, можно увидеть
три вещи, которые явились моделью пылесосного тестирования:
1. Прочитали, например, пункт 2п инструкции, чтобы понять,
как работает режим влажной уборки.
2. Мгновенно в уме составили план проверки влажной уборки:
а. Налить горячую воду в верхний бачок пылесоса.
б. Нажать на кнопку Power.
в. Нажать на кнопку Pressure.
г. И т.д. и т.п.
3. Осуществили проверку согласно плану.
131

П
132 Тестирование Дот Ком. Часть 2
Перейдем от тестирования пылесосов к тестированию ПО.
Цикл тестирования ПО состоит из трех этапов:
1. Изучение и анализ предмета тестирования.
2. Планирование тестирования.
3. Исполнение тестирования.
На любом из этапов может быть найден баг (как в ПО, так и в
документации), баг должен быть отремонтирован ответственным
товарищем (например, программистом или продюсером), и
качество ремонта должно быть сертифицировано тестиров-
щиком.
Свяжем цикл тестирования с циклом разработки:
1. Изучение и анализ предмета тестирования
начинаются перед утверждением спека (в завершение стадии
"Разработка дизайна продукта и создание документации") и про-
должаются на стадии "Кодирование".
2. Планирование тестирования
происходит на стадии "Кодирование".
3. Исполнение тестирования
происходит на стадии "Исполнение тестирования и ремонт багов".
Важный момент:
показанная связь между циклом разработки ПО и циклом тести-
рования — это всего лишь типичная модель взаимодействия
процессов, в то время как на практике, и особенно в стартапах,
встречается множество ситуаций, когда, например, нет спеков,
код уже написан и его срочно нужно протестировать навскидку,
нет времени на создание тест-документации и пр. Поэтому пред-
лагаю, чтобы мы, изучая цикл тестирования, абстрагирова-
лись от цикла разработки.
Что нам это даст? Гибкость, так как,
зная цикл тестирования как независимый процесс, мы сможем
легко связать его с любым циклом разработки ПО в любой ин-
тернет-компании.
Цикл тестирования ПО 133
Итак, независимый процесс, называемый циклом тестирования
ПО, состоит из трех стадий:
1. Изучение и анализ предмета тестирования.
2. Планирование тестирования.
3. Исполнение тестирования.
1. Изучение и анализ предмета тестирования
Вопрос: что можно протестировать в интернет-проекте?
Легитимные варианты ответа:
• интерфейс пользователя (например, что определенная кноп-
ка называется "Купить", а не "Кипуть");
• скорость работы веб-сайта (например, то, что при одно-
временной работе с сайтом 200 пользователей скорость за-
грузки веб-страницы составляет не более 5 секунд);
• документацию (например, что спек не содержит противо-
речий и неточностей).
Все это правильно, но есть нечто более важное.
Вопрос: для чего пользователи приходят на наш веб-сайт? Ответ:
для удовлетворения своих потребностей — покупка книг, чтение
анекдотов, проверка баланса кредитной карты и т.д. и т.п.
Вопрос: как можно удовлетворить потребности пользователя?
Ответ: нужно
• придумать (продюсер),
• написать (программист),
• протестировать (тестировщик) и
• передать пользователям (релиз-инженер)
средства, которые эти потребности удовлетворят. Этими средст-
вами являются ФУНКЦИОНАЛЬНОСТИ интернет-проекта.
Вот формальное определение:
функциональность (functionality, feature) — это средство для
решения некой задачи.
Примеры из реальной жизни
Функциональность компьютерных колонок "Volume" решает задачу "Как изменить громкость звука". Функциональность "Казино" решает задачу "Как незаметно для себя потратить все отпускные деньги". Функциональность "Принтер" решает задачу "Как распечатать документ".
134 Тестирование Дот Ком. Часть 2
Примеры из виртуальной жизни
Функциональность "Корзина" решает задачу "Как хранить информацию о товаре, выбранном пользователем". Функциональность "Добавление товара в корзину" решает задачу "Как добавить товар в корзину". Функциональность "Удаление товара из корзины" решает задачу "Как удалить товар из корзины".
Проверка работы функциональностей называется функциональ-
ным тестированием (functional testing).
Стратегический момент: так как функциональное тестирова-
ние — это ось, вокруг которой вертится деятельность большин-
ства тестировщиков, то, следовательно, вокруг нее же будет
"вертеться " и большинство наших последующих бесед.
Важность функционального тестирования состоит в том, что
функциональности — это не что иное, как продукт, предос-
тавляемый пользователям интернет-компанией, и если про-
дукт от релиза к релизу кишит багами, то вместе со счастьем
пользователей убывают и прибыли интернет-компании.
Основными источниками знания о функциональностях служат:
• документация...
...в электронном или распечатанном виде — спеки, макеты,
блок-схемы и прочие руководящие документы, на основа-
нии которых программист пишет код, а тестировщик пла-
нирует тестирование. Примером "прочего руководящего
документа" может служить "Инструкция Мастеркард о
формате файлов с транзакциями";
• хомо сапиенс, т.е.
информация постигается через межличностное общение.
Так, в случае возникновения сомнений никогда не мешает
подойти к продюсеру, хлопнуть его по плечу и попросить:
"Старина, будь добр, объясни мне по-простому пункт 146 вот
этого спека". Здоровая дружеская атмосфера в коллек-
тиве — это отличное средство для предотвращения оши-
бок в толковании (идеальной питательной среды для багов);
• сам веб-сайт,
который мы изучаем посредством эксплоринга. Экспло-
ринг (exploring (англ.) — "исследование", "разведка") —
это изучение того, как работает веб-сайт с точки зрения
пользователя.
Цикл тестирования ПО 135
Эксплоринг совершается каждым из нас, когда мы приходим на
некий веб-сайт и истязаем его, заполняя формы, нажимая на
кнопки, кликая на линки и совершая прочие действия для того,
чтобы понять, как работает та или иная функциональность.
В интернет-компаниях эксплоринг, как правило, применяется в
двух случаях:
• когда написан код и отсутствует документация. Подоб-
ная ситуация часто поджидает первого тестировщика, при-
ходящего в работающую интернет-компанию;
• для самообучения. Например, в крупных интернет-компа-
ниях вновь нанятые тестировщики в течение нескольких
недель проходят тренинг, часть которого посвящена экс-
плорингу.
Кстати, при эксплоринге источником ожидаемого результата слу-
жат наши драгоценные жизненный опыт, опыт работы и другие
ранее перечисленные помощники, не относящиеся к спекам.
Кстати, хорошая идея для тестировщика, помогающая лучше понять
функциональности своего проекта, — это стать обычным пользовате-
лем своего и аналогичных веб-сайтов. Выражение "Eat your own dog
food" ("Ешь еду своей собаки") для тестировщика означает "Если ты
тестируешь веб-сайт, продающий книги, то ты должен сам покупать
книги по Интернету".
Идем дальше.
Конечной целью этапа Изучение и анализ предмета тестирова-
ния является получение ответов на два вопроса:
а. Какие функциональности предстоит протестировать?
б. Как эти функциональности работают?
После того как ответы получены, мы переходим к следующему
этапу цикла.
2. Планирование тестирования
Эта стадия требует от тестировщика наибольшего творчества и
профессионализма, так как именно на ней решается множество
головоломок, отвечающих на один простой вопрос: "Как будем
тестировать?", причем качество продукта (а значит, и счастье поль-
зователей) напрямую зависит от, не побоюсь сказать, мудрости
найденных решений.
136 Тестирование Дот Ком. Часть 2
Мудрость найденных решений проявляется в двух вещах:
а) кратких, простых и изящных путях для проверки
функциональностей;
б) компромиссе между
объемом тестирования, который возможен в теории;
объемом тестирования, который возможен на практике.
Ответы на "один простой вопрос" предстают перед
миром в виде тест-документации (test documentation),
ядро которой составляют наши любимые тест-кейсы. Во
многих случаях создание тест-документации
сопровождается написанием тестировщиком вспо-
могательных тулов (tool — компьютерная программа),
которые облегчают исполнение тестирования.
Идем дальше.
3. Исполнение тестирования
Суть исполнения тестирования — это практический
поиск багов в написанном коде с использованием
тест-кейсов, созданных ранее.
Исполнение функционального тестирования выглядит
следующим образом:
сначала идет проверка новых функциональностей по
новым тест-кейсам. Кстати, давайте вспомним, что во
многих случаях новые тест-кейсы редактируются,
проходя обкатку первым исполнением;
затем проверка старых функциональностей по старым
тест-кейсам.
То же самое, но в профессиональной терминологии:
тестирование новых функциональностей (new feature
testing) и соответственно
регрессивное тестирование (regression testing).
Мы исполняем тест-кейсы, рассчитывая найти баги.
Давайте еще раз вспомним, что
после нахождения бага тестировщик заносит запись о
нем в систему трэкинга багов;
после того, как программист починил баг,
тестировшик проверяет:
Цикл тестирования ПО 137
а) действительно ли баг был починен. Проверка
осущест
вляется путем исполнения шагов, которые ранее приве
ли к багу, или, в профессиональной терминологии, пу
тем генерации ввода, который привел к выводу, не со
ответствующему ожидаемому результату;
б) не появились ли новые баги как нечаянное
следствие
изменения кода при починке. Проверка осуществляется
путем тестирования функциональностей, работа кото
рых могла быть затронута починкой.
Тестирование, исполняемое в пунктах а) и б), также
называется регрессивным тестированием (bug regression
testing). Соответственно выражение "regress that bug"
(проведи регрессивное тестирование этого бага)
означает, что нужно последовательно исполнить пункты а)
и б).