«Одна из причин, побудивших автора написать эту книгу, — осознание собственного бессилия в поисках сиюминутного практического смысла при чтении классических сочинений по теории тестирования., в особенности когда ты в ...»

Роман Савин

teстирование COM

или Пособие по жестокому

обращению с б а г а м и

в интернет-стартапах

Роман Савин

Одна из причин, побудивших автора написать эту книгу, — «осознание собственного

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

сочинений по теории тестирования...», в

особенности когда ты в поисках работы и

время дорого. «Наиболее эффективный

подход для тренинга тестировщиков — дать им практический инструментарий, поставить в нужную сторону мозги — и в бой...»

Эта книга и есть тот самый практический инструментарий. Здесь вы найдете проработанную структуру, профессиональное изложение темы, множество примеров и советов, а также «...легион того, о чем вам напрямую не напишут и не скажут, но что может быть не менее важно для выживания в софтверной компании, чем профессиональные знания».

Но это не все. Особенность книги в том, как излагается материал. Роман Савин отказался от традиционных канонов написания учебных пособий и превратил книгу в живую непринужденную беседу, насыщенную шуткой и иронией, не чуждую отступлений и даже воспоминаний, которые тем не менее встроены в контекст и работают на предмет как иллюстрационный материал.

Читать книгу интересно и весело. Убедитесь в этом сами.

Роман Савин сом tестирование или Пособие по жестокому обращению с багами в интернет-стартапах ИЗДАТЕЛЬСТВО «ДЕЛО» • МОСКВА • УДК 004.415.53 ББК 32.973.2-018.2я7 С Савин Р.

С13 Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах. — М.: Дело, 2007. — 312 с.

ISBN 978-5-7749-0460- Этот курс лекций создан для тех, кто хочет обучиться тестированию, получить работу тестировщика в российской или западной интернет-компании, понять, как вести себя в корпоративном окружении, и добиться профессионального и личностного роста. Он будет интересен и участникам процесса разработки программного обеспечения, рекрутерам, людям, связанным с интернетом или пишущим о нем, и просто всем желающим понять кухню интернет-стартапов.

Книга целиком базируется на личном опыте освоения — с нуля — профессии тестировщика и многолетней работы автора в этом качестве в интернет-компаниях США.

УДК 004.415.53 ББК 32.973.2-018.2я О Савин Р., ISBN 978-5-7749-0460- © Корсун С.Н., иллюстрации, © Оформление. Издательство "Дело",

СОДЕРЖАНИЕ

Введение

Час ть ЧТО ТАКОЕ БАГ

ОПРЕДЕЛЕНИЕ БАГА

ТРИ УСЛОВИЯ ЖИЗНИ И ПРОЦВЕТАНИЯ БАГА

ЧТО ТАКОЕ ТЕСТИРОВАНИЕ

ИСТОЧНИКИ ОЖИДАЕМОГО РЕЗУЛЬТАТА

ФУНКЦИОНАЛЬНЫЕ БАГИ И БАГИ СПЕКА

ЦЕЛЬ ТЕСТИРОВАНИЯ DECODED

ЦЕЛЬ ТЕСТИРОВАНИЯ

ЧЕРНАЯ МАГИЯ И ЕЕ НЕМЕДЛЕННОЕ РАЗОБЛАЧЕНИЕ

Разоблачение концепции о 100%-м тестировании ПО Разоблачение концепции о количестве багов, найденных до релиза ИДЕЯ О СТАТИСТИКЕ ДЛЯ ПОСТРЕЛИЗНЫХ БАГОВ

ТЕСТИРОВАНИЕ ИОЛ (Quality Assurance)

ИСКУССТВО СОЗДАНИЯ ТЕСТ-КЕЙСОВ

ЧТО ТАКОЕ ТЕСТ-КЕЙС

СТРУКТУРА ТЕСТ-КЕЙСА...

ИСХОД ИСПОЛНЕНИЯ ТЕСТ-КЕЙСА (test case result)

ПОЛЕЗНЫЕ АТРИБУТЫ ТЕСТ-КЕЙСА

ТЕСТ-КЕЙСЫ, УПРАВЛЯЕМЫЕ ДАННЫМИ

ПОДДЕРЖИВАЕМОСТЬ ТЕСТ-КЕЙСА

СКОЛЬКО ОЖИДАЕМЫХ РЕЗУЛЬТАТОВ МОЖЕТ БЫТЬ

В ОДНОМ ТЕСТ-КЕЙСЕ?

ПРОБЛЕМНЫЕ ТЕСТ-КЕЙСЫ

ТЕСТ-КОМПЛЕКТЫ

СОСТОЯНИЯ ТЕСТ-КЕЙСА

А НАПОСЛЕДОК Я СКАЖУ

ЦИКЛ РАЗРАБОТКИ ПО

ИДЕЯ

Документ о требованиях маркетинга (MRD) РАЗРАБОТКА ДИЗАЙНА ПРОДУКТА И СОЗДАНИЕ СПЕКА

Борьба с неверными толкованиями спека КОДИРОВАНИЕ

Документ о внутреннем дизайне кода Личная версия сайта программиста Причины появление багов кода Меры по оздоровлению кода и превентированию багов Три основных занятия программиста Необходимость замораживания кода документации в CVS Обсуждение тесткейсов ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ И РЕМОНТ БАГОВ

РЕЛИЗ

Определение, виды и версии релизов Архитектура www.testshop.rs Первый релиз www.testshop.rs Бета-тестирование БОЛЬШАЯ КАРТИНА ЦИКЛА РАЗРАБОТКИ ПО

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

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

Что такое функциональность Источники знания о функциональности Эксплоринг ПЛАНИРОВАНИЕ ТЕСТИРОВАНИЯ

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

КЛАССИФИКАЦИЯ ВИДОВ ТЕСТИРОВАНИЯ

ПО ЗНАНИЮ ВНУТРЕННОСТЕЙ СИСТЕМЫ

Черный ящик (black box testing) Белый ящик (white box testing) Серый ящик (grey box testing) ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ

Функциональное тестирование (functional testing) Тестирование интерфейса пользователя (UI testing) Тестирование локализации (localization testing) Тестирование скорости и надежности (load/stress/performance testing) Тестирование безопасности (security testing) Тестирование опыта пользователя (usability testing) Тестирование совместимости (compatibility testing) ПО СУБЪЕКТУ ТЕСТИРОВАНИЯ

Альфа-тестировщик (alpha tester) Бета-тестировщик (beta tester) ПО ВРЕМЕНИ ПРОВЕДЕНИЯ ТЕСТИРОВАНИЯ

До передачи пользователю — альфа-тестирование Тест приемки (smoke test, sanity test или confidence test) Тестирование новых фунщиональностей тестирование (regression testing) Тест сдачи (acceptance of certification test) После передачи пользователю — бета-тестирование ПО КРИТЕРИЮ "ПОЗИТИВНОСТИ" СЦЕНАРИЕВ

Позитивное тестирование (positive testing) Негативное тестирование (negative testing)

ПО СТЕПЕНИ ИЗОЛИРОВАННОСТИ ТЕСТИРУЕМЫХ

КОМПОНЕНТОВ

Компонентное тестирование (component testing) Интеграционное тестирование (integration testing) Системное (или энд-ту-энд) тестирование (system or ПО СТЕПЕНИ АВТОМАТИЗИРОВАННОСТИ ТЕСТИРОВАНИЯ

Ручное тестирование (manual testing) Автоматизированное тестирование (automated testing) Смешанное/полуавтоматизированное тестирование ПО СТЕПЕНИ ПОДГОТОВКИ К ТЕСТИРОВАНИЮ

Тестирование по документации (formal/documented

ПОДГОТОВКА К ТЕСТИРОВАНИЮ

НИГИЛИСТИЧЕСКИЙ НАСТРОЙ И ПРАКТИЧЕСКАЯ

МЕТОДОЛОГИЯ

МЕНТАЛЬНЫЙ НАСТРОЙ ТЕСТИРОВЩИКА

МЕТОДЫ ГЕНЕРИРОВАНИЯ ТЕСТОВ.......:

Черновик—Чистовик (dirty list — white list) Матричная раскладка (matrices) Блок-схемы МЕТОДЫ ОТБОРА ТЕСТОВ

Оценка риска (risk estimate) Эквивалентные классы (equivalent classes) Пограничные значения (boundary values)

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

ЖИЗНЬ ЗАМЕЧАТЕЛЬНЫХ БАГОВ

ЧТО ТАКОЕ СИСТЕМА ТРЭКИНГА БАГОВ

АТРИБУТЫ БАГА

Bug number (номер бага) Summary (краткое описание) Description and (описание и шаги для воспроизведения проблемы) Attachment (приложение) Date submitted (дата и время рождения бага) Assigned to (держатель бага) Assigned by (имя передавшего баг) Verifier (имя того, кто должен проверить ремонт) Component (компонент) Version found (версия, в которой был найден баг) Build found (билд, в котором был найден баг) Version fixed (версия с починенным кодом) Build fixed (билд с починенным кодом) Comments (комментарии) Severity (серьезность бага) Priority (приоритет бага) Notify list (список для оповещения) Change history (история изменений) Resolution (резолюция) Build in progress (билд на тест машину в процессе) Verify (проведи регрессивное тестирование) ПРОЦЕСС ТРЭКИНГА БАГОВ

Концептуальное рассмотрение процесса Процесс и атрибуты Конкретный пример

ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ. СТАДИЯ 1:

ТЕСТИРОВАНИЕ НОВЫХ ФИЧА (new feature testing).................. ТЕСТ-СМЕТА (test estimation)

КРИТЕРИЙ НАЧАЛА/ЗАВЕРШЕНИЯ (entry/exit criteria)

ТЕСТ-ПЛАН (test plan)

ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ. СТАДИЯ 2:

РЕГРЕССИВНОЕ ТЕСТИРОВАНИЕ (regression testing)................

ВЫБОР ТЕСТ-КОМПЛЕКТОВ ДЛЯ РЕГРЕССИВНОГО

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

РЕШЕНИЕ ПРОБЛЕМЫ ПРОТИВОРЕЧИЯ

Приоретизация тест-комплектов и тест-кейсов Оптимизация тест-комплектов Найм новых тестировщиков Автоматизация регрессивного КАК УСТРОИТЬСЯ НА ПЕРВУЮ РАБОТУ

МЕНТАЛЬНЫЙ НАСТРОЙ

ЭТАПЫ ПОИСКА ПЕРВОЙ РАБОТЫ ТЕСТИРОВЩИКОМ

Работа с агентством по трудоустройству Список типичных вопросов и правильных ответов ИСТОРИЯ ОБ ОЛЕ И ДЖОРДЖЕ

Послесловие

Моим любимым Маме и Марине посвящается, чьи любовь и вера — самое драгоценное,

ВВЕДЕНИЕ

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

Я также уверен, что тихие вечера, проведенные за чтением моего скромного труда, откроют много полезного любому человеку, имеющему отношение к процессу создания программного обеспечения (ПО), так как качество, как тишина в кинозале, — дело общее.

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

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

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

Моя цель — не показать, что я знаю материал (как это делается при защите диплома), а помочь ВАМ узнать материал, и иллюстрации (текстовые и графические) — это лучшее вспомогательное средство, для того чтобы • легче понять и усвоить смысл сказанного и • оставить в памяти якорь ассоциации между иллюстрацией и проиллюстрированной мыслью.

Идем дальше.

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

Пример Безработная девушка Маша П. захотела стать бухгалтером. Она приходит на соответствующие курсы, но вместо прикладных, оплачиваемых знаний по назначению счетов и инструкций МНС ей преподают теорию макроэкономики и историю бухгалтерии. Маша думает, что она не сможет осилить бухгалтерию, и бросает курсы. В итоге Родина теряет потенциально блестящего бухгалтера и обретает реально радикального члена компартии.

Я преклоняюсь перед предметом "история". О пользе Теории (с большой буквы "Т") и говорить не приходится, но, как я убедился на своем многолетнем опыте работы и преподавания, наиболее эффективный подход к тренингу тестировщиков заключается в том, чтобы дать им практический инструментарий, направить мозги в нужную сторону — и в бой, а теоретические метания тридцатилетней давности можно почитать на досуге, после того как устроился на работу.

Кроме того, есть • политические нюансы работы;

• распространенные ошибки менеджмента;

• продюсеры, программисты и релиз-инженеры, работу которых нужно понимать изнутри, —.

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

Будучи человеком честным и в некоторой степени благородным, признаюсь, что позаимствую классическое начало книг о тестировании, заключающееся в трусливом: "Не используйте знания из этой книги, если речь идет о тестировании критического ПО ".

Итак, я свидетельствую, что все, о чем я расскажу, действительно работает, и работает именно так в крупнейших западных интернеткомпаниях;

я также свидетельствую, что все, о чем я расскажу, в силу объективных причин не может на 100 процентов гарантировать ПО от наличия проблем.

Поэтому сразу предупреждаю: эта книга не предназначена для тех, кто собирается тестировать критическое ПО, связанное, например, с мониторингом работы сердечной мышцы, или ПО для поражения точечных целей в странах с большими запасами нефти.

Серьезно, если речь идет о жизни людей, лучше скормите эту книгу своему попугаю-жако (о попугаях позже).

Два важных момента:

1. В отличие от деятельности юридической деятельность тестировочная (для коммерческих проектов) не регулируется нор мативными актами или другими формальными источниками.

Поэтому нет обязательных для исполнения правил о том, как эффективно протестировать ПО, какие документы нужно создать и в какой форме они должны быть.

Никто не возьмет вас за горло из-за того, что ваш тест-план не соответствует букве некого закона, пролоббированного некой продажной шкурой из не менее продажной фракции в интересах всем хорошо известной финансово-промышленной группы N.

В цехе тестировщиков ничто не является догмой (nothing is set in stone) и построение добротной системы поиска и превентирования ошибок в ПО полностью отдается на откуп профессионализму, добросовестности и творчеству тех, кто работает в конкретной интернет-компании.

Поэтому многие вещи, о которых пойдет речь (подходы, документы, процессы, даже названия), • с одной стороны, имеют огромное количество вариаций в существующих интернет-компаниях и, • с другой — могут практически использоваться в предложенной форме или, еще лучше, быть подогнанными вами под ту компанию, в которой вы работаете или, несомненно, будете работать в ближайшем будущем.

2. "То, что русскому хорошо, — для немца смерть". По аналогии:

• подходы к тестированию, • степень формализации процессов и • используемые документы, которые эффективно работают в крупных устоявшихся интернеткомпаниях, могут быть неприемлемы для интернет-стартапов (startup — молодая, амбициозная, многообещающая компания, живущая, как правило, короткую, но яркую жизнь), и наоборот.

Исходя из того что подавляющее большинство интернет-компаний — это стартапы, говорить будем о том, как эффективно провести тестирование и организовать процессы по улучшению качества именно в стартапах с прицелом на то, чтобы заложить фундамент департамента качества (QA department) для крупной устоявшейся интернет-компании, стать которой мечтает каждый стартап.

Идем дальше.

Вопрос дня: Что самое главное в нашем деле?

Ответ дня: РЕЗУЛЬТАТ!

Человек может быть прекрасным семьянином, увлекаться фотографией и превосходно петь арию "Libiamo Amor" из "Травиаты", но единственная и неповторимая прелесть его как тестиров-щика — это РЕЗУЛЬТАТ.

К вопросу о постановке мозгов и попугаях:

перед покупкой своего попугая-жако Василия я прочитал кучу литературы, но лишь одна мысль позволила мне осознать самое главное (в смысле домашних попугаев):

"У вас есть хобби, друзья и работа. У вашего попугая есть только вы ".

Так вот по аналогии:

Вы можете быть наделены множеством самых прекрасных и вечных добродетелей. Но в вашей работе тестировщика есть единственный смысл — РЕЗУЛЬТАТ.

Каков же этот РЕЗУЛЬТАТ (пишу "РЕЗУЛЬТАТ" заглавными буквами в последний раз)?

Спрашиваете — отвечаем:

результатом работы тестировщика является счастье конечного пользователя (сказать "удовлетворение клиента" как-то язык не поворачивается). Причем "счастье" не в глобальном его значении, а та его часть, которая связана с качеством вашего продукта.

Например, некто Виктор Буянов бродит по Интернету в поисках диска с московским концертом Билли Джоела. Вот он наконец находит то, что искал, заполняет все необходимые формы и нажимает кнопку "Купить". Если • на следующей странице будет написано: "Дорогой Виктор, мы получили ваш заказ, ждите посылку" и • через неделю почтальон принесет сам диск, то честь и хвала вам как тестировщикам.

на следующей странице красуется "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), который принял меня, как брата, и наставил на путь истинный.

Итак, в путь. Если что, пишите на [email protected].

ЧАСТЬ

• ЧТО ТАКОЕ БАГ

• ЦЕЛЬ ТЕСТИРОВАНИЯ DECODED

• ИСКУССТВО СОЗДАНИЯ ТЕСТ-КЕЙСОВ

• ЦИКЛ РАЗРАБОТКИ ПО

ЧТО ТАКОЕ БАГ

• ОПРЕДЕЛЕНИЕ БАГА

• ТРИ УСЛОВИЯ ЖИЗНИ И ПРОЦВЕТАНИЯ БАГА

• ЧТО ТАКОЕ ТЕСТИРОВАНИЕ

• ИСТОЧНИКИ ОЖИДАЕМОГО РЕЗУЛЬТАТА

• ФУНКЦИОНАЛЬНЫЕ БАГИ И БАГИ СПЕКА

Л огический закон исключенного третьего гласит, что любая вещь — это либо а, либо не-а. Третьего не дано, т.е. если у вас есть часы "Брегет" за номером 5, то любая вещь в этом мире будет либо вашими часами "Брегет" за номером 5, либо чем-то другим.

Представим себе конвейер, в конце которого стоим мы. Лента конвейера движется, и перед нами по очереди появляется по одному предмету. Задача проста — ожидать появления ваших часов "Брегет" за номером 5 и говорить "баг" при появлении любого предмета, отличного от них.

Нетрудно догадаться, что такие предметы, как • пакет кефира;

• будильник "Слава";

• буклет с предвыборными обещаниями кандидата в президенты Н., будут для нас багами.

Далее. Рассмотрим, что объединяет следующие ситуации.

1. Девушка рекламирует себя как хорошую, на все руки хозяйку, а утром выясняется, что она даже яичницу пожарить 2. Вы купили книгу по интернет-тестированию, а в ней рассказывается о приготовлении яичницы.

3. Девушка из пункта 1 прочитала книгу из пункта 2, но яичница пересолена.

Если возвыситься над яичницей, фигурирующей в каждом из трех пунктов, и абстрагироваться от женщин, карт и вина, то мы увидим, что общее — это отклонение фактического от ожидаемого.

Разбор ситуаций.

1. Ожидаемый результат -— девушка умеет готовить.

Фактический результат — утро без завтрака.

2. Ожидаемый результат — знания по тестированию.

Фактический результат — знания по кулинарии.

3. Ожидаемый результат — яичница будет приготовлена.

Фактический результат — еще одно утро без завтрака.

Определение бага Итак, баг (bug) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result).

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

Три условия жизни и процветания бага Конкретный баг живет и процветает лишь при одновременном выполнении всех трех условий:

1. Известен фактический результат;

2. Известен ожидаемый результат;

3. Известно, что результат из пункта 1 не равен результату из Совет дня: каждый раз, когда возникает ситуация, в которой не совпадают фактическое и ожидаемое, — мысленно штампуйте фактическое словом "баг". Постепенно это войдет в привычку и станет рефлексом. Для ментальной тренировки не имеет значения, насколько мелочны, низки и сиюминутны ваши ожидания, главное — приобретение автоматизма.

Примеры багов из жизни:

1. Бутерброд падает маслом вниз.

2. Подхалимы и говоруны имеют намного больше шансов на повышение, чем скромные честные труженики.

3. Несоответствие миловидной внешности и змеиной сущности.

4. Попугай воспроизводит на людях худшее из словарного запаса хозяина.

5. Автомобили российского производства.

6. Кот Бегемот в фильме В. Бортко "Мастер и Маргарита".

Идем дальше.

Что такое тестирование Любое тестирование — это поиск багов. Испытываем ли мы новую соковыжималку, наблюдаем ли за поведением подруги или занимаемся самокопанием — мы ищем баги. Баги находятся следующим образом:

1. Мы узнаем (или уже знаем) ожидаемый результат;

2. Мы узнаем (или уже знаем) фактический результат;

3. Мы сравниваем пункт 1 и пункт 2.

Как видно, каждый из нас уже является тестировщиком, так как разного рода осознанные и неосознанные проверки, осуществляемые нами и в отношении нас, являются неотъемлемой частью жизни, просто раньше мы непрофессионально качали головой и выдавали тирады о несправедливости мира, но зато теперь в случае несовпадения фактического и ожидаемого мы будем с улыбкой мудреца смотреть на дилетантов, хлюпающих носами на московском ветру, и тихо, но веско (как дон Карлеоне) говорить:

"Та-а-к, еще один баг".

Для иллюстрации правильного подхода приведу в пример одного моего друга, который выстроил целую систему доказательств тезиса, что люди и компьютеры созданы по одному образцу. Основой его аргументации явился тот факт, что и те и другие имеют физическую оболочку (тело/железо) и неосязаемое составляющее, управляющее ею (душа/ПО). Соответственно болезни тела он называл багами в железе, а проблемы с головой — багами в ПО и очень сожалел, что ПО людей, управляющих этим миром, состоит в основном из багов...

Теперь вспомним о том, что есть компьютерное ПО и что нам нужно научиться его тестировать.

С фактическим результатом здесь более или менее понятно: нужно заставить систему проявить себя и посмотреть, что произойдет.

Сложнее дело обстоит с ожидаемым результатом.

Источники ожидаемого результата Основными источниками ожидаемого результата являются:

1. Спецификация.

2. Спецификация.

3. Спецификация.

4. Спецификация.

5. Жизненный опыт, здравый смысл, общение, устоявшиеся стандарты, статистические данные, авторитетное мнение и др.

Спецификация на первой—четвертой ролях — это не ошибка, а ударение на то, что спецификация для тестировщика — это:

• мать родная, а также • товарищ и Спецификация важна для программиста и тестировщика так же, как постановление пленума ЦК для коммуниста.

Спецификация — это инструмент, с помощью которого вы сможете выпустить качественный продукт и прикрыть свою спину (в оригинале звучит как CYA или cover your ass).

Итак, что же это за зверь?

Спецификация (или spec — читается "спек". Далее употребляется в мужском роде) — это детальное описание того, как должно работать ПО. Вот так, ни много ни мало.

В большинстве случаев баг — это отклонение от спецификации (я говорю о компаниях, в которых спеки в принципе существуют и ими пользуются).

Пример Пункт 19.а спека #8724 "О регистрации нового пользователя" устанавливает:

«Поле "Имя" должно быть обязательным. Страница с ошибкой должна быть показана, если пользователь посылает регистрационную форму без заполнения указанного поля».

В общем все просто:

• тестировщик идет на страничку с регистрационной формой;

• кликаетлинк "Регистрация";

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

• нажимает на кнопку "Зарегистрироваться".

Если ошибка не показана и регистрация подтверждается, то это есть момент истины и нужно рапортовать баг (file a bug).

Если ошибка показана, то относительно пункта 19.а на некоторое время можно успокоиться. Мы поймем, почему можно успокоиться лишь на некоторое время при разговоре о регрессивном тестировании...

Функциональные баги и баги спека Допустим, что ошибка не была показана и мы имеем классический случай функционального бага (functional bug, или баг обыкновенный), т.е. бага, вскормленного на несоответствии фактической работы кода и функционального спека.

Если вы внимательно читали пункт 19.а, то не могли не заметить (шутка), что непонятно, какое должно быть сообщение об ошибке (error message), т.е. фактически решение отдано на откуп программисту и он может предусмотреть, что при соответствующей ситуации код выдаст:

• НЕинформативное сообщение "Ошибка" и оставит пользо вателя ломать голову над тем, что он сделал неправильно, • информативное сообщение «Пожалуйста, введите ваше имя и нажмите кнопку "Регистрация"»

и в любом случае формально будет прав, так как спецификация не детализирует текста ошибки.

Кстати, несколько лет назад был случай, когда программисты в специальном ПО, разработанном для американских тюрем, оставили "рабочее" название кнопки, причем тюремщикам идея так понравилась, что они просили ничего не исправлять. Надпись на кнопке была: "Освободить подонка".

В общем сложилась ситуация, когда сама спецификация имеет проблему, так как мы ожидаем (или по крайней мере должны ожидать), что в спеке будут подробности о тексте ошибки, а в реальности их там нет. Так и запишем — "баг в спецификации" (spec bug).

Кстати, вот варианты развития ситуации с проблемным спеком:

а. Скорее всего программист все же напишет информативное сооб щение об ошибке. Ваше дело послать е-мейл продюсеру (продю сером в интернет-компании называют товарища, создающего спеки), чтобы тот внес текст, уже написанный программистом, в б. Если программист написал нечто противоречащее здравому смыслу или стандарту, принятому в вашей компании, рапортуйте баг.

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

Кстати, вот две релевантные политически важные вещи:

1. Как правило, работа в стартапе — это уникальный опыт, когда тяжелый труд сочетается с радостью созидания, расслабленной обстановкой (я, например, уже многие годы хожу на работу в шортах) и окружающими вас милыми, веселыми людьми. Но бывают нештатные ситуации (например, работа не сделана в срок или сделана некачественно), и, когда дело дойдет до выяснения "кто виноват" и "что с ним сделать", многие из ваших коллег перестанут быть милыми, веселыми людьми и активно начнут вешать собак друг на друга. Так вот, чтобы одну из этих собак не повесили на вас, посылайте е-мейлы, сохраняйте их и ответы на них и при случае пересылайте их заинтересованным сторонам. Пригодятся те е-мейлы в дальнейшем — хорошо, не пригодятся — еще лучше, тем более что каши они не просят, а сидят себе тихо и малодушно в своих фолдерах и ничего не ждут от этой жизни.

2. Каждый должен заниматься своим делом и отвечать за свой участок работы. В случае если спек сделан некачественно, то лучше поднять тревогу с рассылкой е-мейлов, чем делать допущения относительно того, как должно работать ваше ПО.

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

1. ЖИЗНЕННЫЙ ОПЫТ Как справедливо отметил Борис Слуцкий: "Не только пиво-раки мы ели и лакали". Мы также учились и работали, любили и ненавидели, верили политикам и не слушались родителей, в общем приобретали жизненный опыт (включая опыт работы). Так вот этот опыт настолько полезен в нашем черном деле, что для демонстрации уважения к идее о его полезности (вместе с логикой и здравым смыслом) я вынес ее в качестве эпиграфа во Введении. Дело в том, что тестирование ПО — это то самое тестирование (которое мы делаем постоянно), но только в отношении ПО. И моя задача заключается лишь в том, чтобы дать вам основные концепции и практический инструментарий по интернет-тестированию и помочь их интеграции с тем, что у вас уже есть, — с жизненным опытом.

2. ЗДРАВЫЙ СМЫСЛ (дитя жизненного опыта и соответственно внук "ошибок трудных") Это один из наших главных союзников, порой даже и при наличии спека. Например, вы тестируете веб-сайт, где пользователь может загрузить (upload) свои цифровые фотографии. Спек говорит, что пользователь может загрузить лишь одну фотографию за раз. А что, если у него таких фотографий 200? Будет он счастлив?

Что делаем? Правильно: пишем е-мейл ж [email protected] с предложением о включении в спек функциональности, позволяющей пользователю загружать цифровые фотографии оптом.

Кстати, баг такого рационализаторского плана лицемерно называется не багом, a Feature Request ("запрос об улучшении" — пока остановимся на таком переводе).

3. ОБЩЕНИЕ Даже самый лучший спек может вызвать необходимость в уточнениях. А что, если спека нет вообще? Наш ответ: общение. Советуйтесь с коллегами. Уточняйте и обсуждайте. Одна голова хорошо, а две лучше.

4. УСТОЯВШИЕСЯ СТАНДАРТЫ

Как правило, после регистрации, пользователь должен получить е-мейл с подтверждением. Если спек не упоминает о таком е-мейле, вы можете потребовать дополнить его на основании сложившейся практики.

5. СТАТИСТИЧЕСКИЕ ДАННЫЕ

Было установлено, что средний пользователь теряет терпение, если web page (веб-страница) не загружается в течение 5 секунд.

Эти данные можно использовать, проводя performance testing (тестирование скорости работы всей системы либо ее компонента).

Как говорят американцы: "Your user is just one click away from your 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) Б ез рассусоливаний и теоретизирования я прямо скажу, для чего все это нужно.

Цель тестирования Цель тестирования — это нахождение багов до того, как их найдут пользователи.

Другими словами, вклад тестировщика в счастье пользователя — это приоритет в нахождении багов.

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

А теперь:

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

ПЕРВАЯ КОНЦЕПЦИЯ: цель тестирования — это 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 условия.

2. Ввести "owl".

Ничего не вводить, а просто равнодушно нажать Enter.

Однако если ввести "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 до 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 до 2. for item in range( 1000): # для каждого номера от 0 до 999.

4. print "Сумма равна "-/-amount # напечатать значение суммы.

В итоге получается миллион (1000 х 1000) ожидаемых результатов.

Добавим масла в огонь: в большинстве случаев с реальным ПО мы интегрируем одни части кода с другими и в итоге получаем столько вариантов конкретных значений ожидаемых результатов, что на 100%-ю проверку не хватит и пяти жизней. Шести жизней хватить должно, но они будут самыми печальными из всех историй о бессмысленном существовании.

Постановка мозгов В мире с ограниченными ресурсами (например, время на тестирование) 100%-е тестирование ПО — это фикция (я говорю о реальном ПО, а не о программах из наших примеров) и единственное, что мы можем сделать как тестировщики, — это профессионально, творчески и добросовестно спланировать и провести наше тестирование. Просочившиеся баги — это неизбежное зло, но свести его к минимуму — в наших руках.

ВТОРАЯ КОНЦЕПЦИЯ: критерий эффективности тестирования — это количество багов, найденных до релиза.

РАЗОБЛАЧЕНИЕВТОРОЙКОНЦЕПЦИИ

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

Скажите, имеет ли значение для развитой личности, сколько денег и сил было потрачено на покупку и ремонт помещения? Ответ отрицательный: единственное, что ее интересует, — это сходная цена и качество обуви. Так и в нашем интернет-магазинном деле: пользователю все равно (и это правильно), сколько вы не спали ночей, сколько вы нашли багов и скольких девушек оставили без романтического ужина. Пользователю нужно, чтобы наш онлайн-магазин работал качественно. Точка.

Идем дальше.

Идея о статистике для пострелизных багов Итогом разработки ПО является передача этого ПО пользователю, называемая "релиз" (release).

Допустим, что перед первым релизом нашли 50 багов, а перед вторым — 200. Казалось бы, во втором случае тестирование прошло более успешно. Но в реальности вполне может быть, что после первого релиза пользователи найдут 2 бага, а после второго — 22 бага. Тестирование какого релиза было более эффективным?

Очевидно, что первого, так как первый релиз дал возможность пользователям познакомиться только с двумя багами в отличие от второго релиза — с 22 багами.

Кроме того, результаты тех же самых усилий, но приложенных для тестирования разных функциональностей могут серьезно различаться. Это происходит потому, что предмет тестирования, т.е. некая часть нашего ПО, подвергнутая тестированию, каждый раз уникален. Уникален качеством кода, сложностью и трудоемкостью тестирования и прочими вещами.

один из критериев качества кода — это количество багов на 1000 строк кода.

Почему же так популярно представление количества багов ДО релиза в качестве цели и критерия эффективности тестирования?

Поставьте себя на место менеджера отдела тестирования. Ему нужны просто количественные данные, чтобы показать своим менеджерам, что в коде данного релиза под его чутким руководством тестировщики нашли столько-то багов.

Еще одной причиной любви к количеству багов, найденных до релиза, может быть элементарное незнание основ тестирования (в которые мы, кстати, незаметно, но верно вгрызаемся).

Итак, количество багов, найденных до релиза, ничего не говорит об эффективности тестирования.

Баги, найденные после релиза, — вот что нас угнетает и преследует в бессонные лунные ночи.

Кстати, если уж мы заговорили о статистике и цифрах, давайте скажем пару слов о том, как мы используем данные о таких вот пострелизных багах.

Сначала определимся с тем, что баги бывают разных приоритетов, которые отражают важность бага. Скажем, если у машины на дороге отваливается колесо, это Ш (баг высшего приоритета). Таких приоритетов обычно 4. Соответственно к П4 относятся самые незначительные баги (как небольшая царапина на боку автомобиля).

Итак, после каждого релиза данные о багах, найденных после релиза, классифицируются по заданным критериям и анализируются на предмет нахождения слабого звена в процессе разработки ПО.

Критериями могут быть приоритет, функциональность, имя тестИровщика и др.

Пример После очередного релиза мы совместили статистику по критериям • функциональность и Приоритет При попытке найти "рекордсменов" можно увидеть, что совсем грустная картина сложилась с оплатой (7 П1).

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

Пример Допустим, что у нас постоянно возникают проблемы с "Оплатой". После каждого из релизов в ней находят по несколько П1 и П2, т.е. появился устойчивый паттерн (pattern — шаблон, тенденция) проблемы. Все спеки по оплате составлены продюсером, весь проблемный код написан программистом и проверен тестировщиком. Первое, что приходит в голову, — во всем виноват тестировщик. Но если проявить человеколюбие и талант руководителя, то может всплыть:

• продюсер пишет совершенно мерзопакостные спеки;

• тестировщик в свое время женился на невесте программиста, всячески избегает его;

• оба они ненавидят продюсера, так как тот является зятем президента компании.

Дальнейшее расследование показывает, что • продюсер не имеет ни бэкграунда, ни документации, чтобы понять все нюансы "Оплаты", связанные с электронными платежами;

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

А вы говорите "Элементарно, Ватсон"! Вот оно, истинное расследование! А то обидели бы бедного тестировщика, а в следующий раз все повторилось бы.

Заметьте, что ко всему этому мы пришли, начав с анализа статистики, а это уже не тестирование, a QA (Quality Assurance — буквально "обеспечение качества", произносится "кью-эй").

Тестирование и QA (Quality Assurance) Рассмотрим базовую концепцию QA и то, как оно соотносится с тестированием.

Лежит дома на диване некий член правления некого крупного банка.

Весь такой благообразный, вальяжный и циничный, как будто он всегда был и будет членом правления. Тишину разрывает звонок телефона, холеные пальцы снимают трубку, и в сознание проникает голос бывшей жены, которую он бросил 11 лет назад, сразу после своей первой сделки с продажей вагона ворованных противогазов. Бывшая жена говорит, мол, твой сын прогуливает уроки математики и рисования, целуется в подъезде с соседской Дашкой, которая на два года старше него, перестал гулять с собакой и начал курить. В общем, дела плохие.

QА-подход — это изначально остаться с женой и воспитывать сына.

Тестирование — это когда после звонка оставленной жены эксхузбенд запирает сынишку в своей загородной резиденции, ограничивает его духовную и половую жизнь полным собранием произведений Ги Де Мопассана, выписывает из Англии учителей, устраивает педсовет и говорит, что у них есть 3 года, чтобы неуч, тунеядец, курильщик и сексоман стал образованным, трудолюбивым и здоровым членом цивилизованного общества.

Таким образом, QA — это забота о качестве в виде превентирования появления багов, тестирование — это забота о качестве в виде обнаружения багов до того, как их найдут пользователи.

Общее в QA и тестировании заключается в том, что они призваны улучшить ПО, различие между ними — в том, что • QA призвано улучшить ПО через улучшение процесса разработки ПО;

• тестирование — через обнаружение багов.

Несмотря на то что большая часть книги посвящена тестированию, многие вещи будут рассмотрены именно с точки зрения Quality Assurance.

В реальных компаниях инженер, который занимается улучшением процесса разработки ПО, должен иметь очень серьезную поддержку в менеджменте компании, чтобы быть в состоянии провести свои идеи качества в жизнь. Без такой поддержки никакого прока от инженера по качеству не будет, каким бы гениальным специалистом он ни был.

Кстати, западные компании часто нанимают аудиторов для проверки внутренних процессов. Если ваша компания решит нанять аудитора, который стоит больших денег, то постарайтесь не заключать договор с крупной аудиторской компанией, которая элементарно может вам подсунуть ничего не понимающего в деле товарища с кожаным портфелем, а лучше заключите контракт с конкретным специалистом по качеству, проведя ряд интервью и найдя того, кто действительно разбирается в своем деле. Запомните, что аудитом кормятся много паразитов, которые напишут вам бессмысленные, но солидно презентованные заключения и рекомендации,, которые вам никогда не пригодятся, и впоследствии вы будете долго ломать голову, пытаясь понять, ЗА ЧТО же вы все-таки заплатили.

Кстати, хотя инженер по качеству (QA Engineer) и тестировщик (Test Engineer) — это разные профессии, тестировщиков часто называют инженерами по качеству.

Пара мыслей вдогонку к сказанному.

Пример с батькой и сынкой позволяет нам понять и ощутить со всей болью русской интеллигенции, что тестировщики имеют Дело с ПО, переданным им программистами уже в кривом и порочном состоянии. С этим соприкасается правильная, сладкая и полезная идея, что за качество не могут быть ответственны только тестировщики.

Качество (как и его отсутствие) — это результат • деяний всех участников процесса разработки ПО, а также • отлаженности и настроек самого процесса.

Краткое подведение итогов 1. Цель тестирования — это нахождение багов до того, как их най дут пользователи.

2. Нехватка ресурсов не позволит стопроцентно протестировать сколько-нибудь сложное ПО.

3. Не имеет никакого значения, сколько багов было найдено до 4. Статистика багов, найденных после релиза, и ее последующий анализ могут помочь идентифицировать проблемные участки процесса разработки ПО. Сопоставление статистики от релиза к релизу дает, как правило, устойчивый паттерн проблемы, если таковая существует.

5. QA направлено на превентирование багов, тестирование — на 6. Тестировщики одни не могут обеспечить качество ПО. Обеспечение качества — это задача всех участников процесса разработки ПО. Важными факторами, влияющими на качество, являются отлаженность и настройки самого процесса разработки Вопросы и задания для самопроверки 1. У вас есть 5 функциональностей, и отведенного времени не хватит, чтобы тщательно протестировать их все. На основании чего вы расставите приоритеты в тестировании? Подсказка: помните о счастье пользователя.

2. Петров нашел 50 багов до релиза, но пропустил 5 багов, которые были найдены пользователем. Сидоров нашел 12 багов до релиза, не пропустив ни одного. Кому дать премию?

3. Как должен поступить менеджер, чтобы решить вопрос с проблемой оплаты?

4. Придумайте аналогию, демонстрирующую разницу между ОА и тестированием.

ИСКУССТВО СОЗДАНИЯ

• ЧТО ТАКОЕ ТЕСТ-КЕЙС

• СТРУКТУРА ТЕСТ- КЕЙСА

• ИСХОД ИСПОЛНЕНИЯ ТЕСТ-КЕЙСА •

ПОЛЕЗНЫЕ АТРИБУТЫ ТЕСТ-КЕЙСА

• ТЕСТ-КЕЙСЫ, УПРАВЛЯЕМЫЕ ДАННЫМИ •

ПОДДЕРЖИВАЕМОСТЬ ТЕСТ-КЕЙСА

• СКОЛЬКО ОЖИДАЕМЫХ РЕЗУЛЬТАТОВ МОЖЕТ БЫТЬ

• ПРОБЛЕМНЫЕ ТЕСТ-КЕЙСЫ

• СОСТОЯНИЯ ТЕСТ-КЕЙСА

• А НАПОСЛЕДОК Я СКАЖУ

М ы исполняем тестирование, т.е. непосредственно "рвем на куски" ПО, руководствуясь нашей профессиональной документацией — тест-кейсами (test case). Поговорим о формальной стороне эффективного тест-кейса и коснемся объединений тест-кейсов — тест-комплектов (test suite).

Что такое тест-кейс Допустим, что перед сборами на рыбалку мы составили следующий список:

1. Удочка.

2. Коробка с запасными поплавками и леской.

3. Банка с червями.

4. Стакан граненый.

5. Бутылка "Абсолюта".

6. Огурец соленый.

Затем при деятельном участии жен, детей и котов мы наконец собрались в дорогу и перед выходом взяли список и проверили рюкзак на наличие каждого из 6 предметов.

Так вот.

Каждая из 6 строк списка — это и есть тест-кейс (test case).

Сам список является тест-комплектом (test suite).

Процесс придумывания и написания каждой строки списка называется созданием тест-кейса (test case generation).

Процесс проверки рюкзака на наличие определенного предмета — исполнением тест-кейса (test case execution).

Test case можно перевести как "тестируемая ситуация" и как "оболочка для теста", оба перевода легитимны и представляют собой идеальный союз для понимания места и значения тест-кейсов в этом жестоком мире.

Главная и неотъемлемая часть тест-кейса — это ожидаемый результат, например "огурец соленый", т.е. тест-кейс может полностью состоять только из ожидаемого результата.

Структура тест-кейса Проблема в том, что для нахождения бага (что является смыслом любого тестирования) кроме ожидаемого нам нужен и фактический результат. В случае с огурцом мы просто заглядываем в рюкзак и смотрим, на месте ли этот "фрукт". В случае же тестирования ПО, как правило, необходима инструкция, как прийти к фактическому результату.

Пример Допустим, тестировщику А. Боброву, который только что начал работать в нашем стартапе www.testshop.rs, дали для исполнения следующий тест-кейс:

"Оплата может быть произведена картой VISA". Сразу же возникает по крайней мере две проблемы:

• для исполнения тест-кейса нужна тестировочная карта VISA, • он не знает, как проверить, был ли действительно осуществлен платеж, даже если бы у него была карта.

Единственное, что более или менее понятно, — это процесс покупки в интернет-магазине (найти товар, добавить в корзину и т.д.), что в данной ситуации помогает немного. Естественно, что никакого тестирования не будет, так как пробиться к фактическому результату так же трудно, как доказать инспектору ГАИ, что брать взятки аморально.

Допустим, тестировщику А. Боброву, который только что начал работать в нашем стартапе www.testshop.rs, дали для исполнения следующий тест-кейс: Шаги:

1. Открой www.main.testshop.rs 2. Введи в поле "Имя пользователя": "testuser1" 3. Введи в поле "Пароль": "pa$$wOrd" 5. Введи в поле "Поиск": "book117" 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).

Если провести аналогию, то • шаги — это ступеньки лестницы;

• ожидаемый результат — это некий предмет, который мы должны найти, если поднимемся по этим ступенькам;

• фактический результат — это то, что мы реально нашли после того, как поднялись по этим ступенькам.

Постановка мозгов ИСХОДЯ ИЗ ОСНОВНОЙ компьютерной концепции ВВОД/ВЫВОД (на языке оригинала — input/output):

• шаги — это инструкция по вводу;

• исполнение шагов — это ввод;

• ожидаемый результат — это ожидаемый вывод;

• фактический результат — это фактический вывод.

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

Исход исполнения тест-кейса (test case result) Каждый тест-кейс, исполнение которого завершено, дает нам одно из двух:

1. Положительный исход (PASS), если ФР равен ОР, 2. Отрицательный исход (FAIL), если ФР не равен ОР: най Иногда возникает ситуация, когда мы заблокированы (test case execution is blocked), так как не можем пройти ВСЕ шаги тесткейса. Например, мы не можем продвинуться дальше, если кнопки "Завершить заказ" из шага 14 не существует на соответствующей веб-странице. В таком случае мы рапортуем баг (в данном случае баг об отсутствии кнопки "Завершить заказ") и откладываем исполнение тест-кейса до устранения бага.

Полезные атрибуты тест-кейса УНИКАЛЬНЫЙ ID (Unique ID) Это необходимая вещь. Тест-кейс без ID — это то же самое, что квартира без адреса или швейцарские часы без номера. ID должен быть уникальным в пределах не только документа, содержащего тест-кейс (об этом документе позже), но и всего департамента качества. Рациональное обоснование: со временем появится необходимость вести статистику по тест-кейсам, обновлять, удалять или переносить в другой документ некоторые из них, прикрывать спину и т.д.

ПРИОРИТЕТ ТЕСТ-КЕЙСА (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 была успешной?

Дело в том, что "непосвященным" может стать даже автор тесткейса, скажем, через месяц после написания, так как все в мире тленно и забываемо (кроме, конечно, первой школьной любви Ани В.)- Поэтому в начале тест-кейса следует написать на человеческом языке: "Оплата может быть произведена картой 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" («ВИА "Битлз" будет вечно жить в наших сердцах»).

Приходит друг Лежа и, пока Макс на правах радушного хозяина несется к ларькам станции метро "Юго-Западная" и обратно, учит альтернативной мудрости честно впитывающего знания Васю:

— "Все козлы";

— "Simia quantum similis turpissima bestia nobis!" ("Как похожа на нас мерзейшая тварь — обезьяна!");

— "Move bitch, get out the way" ("Уйди с дороги, противная").

В итоге после возвращения домой Макса встречает не добрый, милый попугайчик, а негативно настроенная машина, и вечером ему (Максу) придется доказывать своей жене, что это не он, а подлец Леха изменил лексикон бедолаги Василия.

Для того чтобы иметь сведения о рождении и истории развития каждого тест-кейса, мы ведем лаконичный журнал изменений, где отражаем: Кто? Что? Зачем? Когда? Почему?

Атрибуты истории редактирования:

• Created on by — Тест-кейс создан • Modified on by — Тест-кейс изменен ;

• Change — Что, зачем и почему было изменено. В наших примерах мы не печатаем само слово "change", а просто заполняем значение этого атрибута в поле справа от "Created on..." или "Modified on...".

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

ТС ID/Priority IDEA: Оплата может быть произведена картой VISA SETUP and

ADDITIONAL INFO:

Эккаунт: testuser1/paSSwOrd Наименование товара: book117 Данные карты:

Номер: 9999-5148-2222- Окончание действия: 12/ CVV2: SQL1: select result from cc_transaction where id = ;

Created on: 11/17/2003 by О.Тарасов Новый тест-кейс

PROCEDURE EXPECTED RESULT

2. Введи имя пользователя.

3. Введи пароль.

4. Нажми кнопку "Войти".

5. Введи наименование товара в поле поиска.

6. Нажми кнопку "Найти".

7. Кликни линк "Добавить в корзину".

8. Кликни линк "Корзина".

9. Кликни линк "Оплатить".

10. Выбери вид карты.

11. Введи номер карты.

12. Введи срок окончания действия.

13. Введи CVV2.

14. Нажми кнопку "Завершить заказ".

15. Запиши номер заказа 16. Запроси базу данных с SQL и запиши результат Идем дальше.

Тест-кейсы, управляемые данными Основной плюс нового тест-кейса с картой заключается в том, что нам не нужно вносить изменения в ШАГИ, чтобы протестировать по тому же сценарию другие карты. Единственное, что нам нужно, — это модифицировать исходные ДАННЫЕ.

Таким образом, если кроме VISA нам нужно протестировать по тому же сценарию еще две карты, то мы • делаем сору один раз;

• paste два раза;

• в каждом из новых тест-кейсов переписываем только пять подчеркнутых значений, проживающих в шапке тест-кейса и секции ожидаемого результата (меняем и ID тест-кейса — ТС ID, который, как мы помним, должен быть всегда уникальным):

9999-5148-2222- Такой вид тест-кейса называется data-driven (буквально "управляемый данными"), т.е. когда данные и инструкции по их применению не смешаны, а разделены и слинкованы.

Поддерживаемость тест-кейса Новый тест-кейс с картой хорош. Все при нем — и data-driven, и удобочитаемый формат, и полезные атрибуты. Проблема в том, что веб-сайт, а особенно его часть, именующаяся интерфейсом пользователя {User Interface или просто UI— "ю-ай"), очень часто меняется.

Кнопка "Войти" из шага 4 легко может быть переименована во "Вход".

Следовательно, если у нас есть 3 тест-кейса, то нужно внести 3 изменения. А что, если у нас 500 тест-кейсов, где упоминается кнопка "Войти", и эти тест-кейсы разбросаны по разным документам, как мои одноклассники по свету? Вносить 500 изменений? Скажете: "Ерунда, можно догадаться". Но таких маленьких изменений будут десятки!!! И постепенно ваши тест-кейсы будут либо хиреть без поддержки, либо потреблять на поддержку уйму времени.

А что, если не имя кнопки, а сам путь, по которому вы добираетесь до фактического результата, претерпел изменения? Например, шаги 7 и станет разделять не линк "Корзина", а еще несколько дополнительных линков и кнопок, появившихся в новой версии www.testshop.rs.

В общем проблема понятна. И имя ее — maintainability (поддерживаемость), т.е. насколько легко и просто можно изменить тест-кейс при изменениях в ПО. Не думать о поддерживаемости тест-кейсов — значит не думать о завтрашнем дне, что, несмотря на полезность для духовной жизни, все-таки плохо для бизнеса.

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

Добавление товара в корзину.

Фиксация номера заказа.

Почему бы нам не выбросить из тест-кейса детали по следующим позициям?

1. Вход в систему В общем-то можно догадаться, куда ввести имя пользователя, куда пароль и на какую кнопку нажать, тем более что в данном случае мы не тестируем процесс логина, это было или будет сделано при исполнении соответствующего тест-кейса, сейчас мы просто грубо и бесцеремонно используем логин, легкомысленно надеясь, подобно покупателю российского автопрома, что все будет чики-пики.

2. Поиск товара Все из предыдущего пункта применимо и здесь. Кроме того, допустим, что book117 была удалена из нашей базы данных подлыми завистниками и подхалимами. Что же нам — в отчаянии рвать на себе волосы и кричать, что мы заблокированы? Нет, мы просто превентируем такую ситуацию тем, что не будем давать имени конкретного товара. Что найдется, то найдется (так как то, что найдется, в данном случае значения не имеет).

3. Добавление товара в корзину Концепция из "1. Вход в систему" применима и здесь.

4. Оплата Концепция из "1. Вход в систему" применима и здесь.

О'к, с оплатой я, пожалуй, немного переборщил — не факт, что будет абсолютно очевидно, как провести ее, и шаги все же потребуются.

Здесь появляется другая загвоздка: если мы производим оплату в сотнях тест-кейсов, т.е. сотни раз включаем в тест-кейс те же семь шагов (8—14 включительно), то при изменении даже в одном из этих шагов нам придется переписывать эти сотни тесткейсов...

Не проще ли вынести шаги, повторяющиеся от тест-кейса к тест-кейсу, во внешний документ и вместо них включить в тест-кейс лишь один шаг-ссылку «Произведи ОПЛАТУ КАРТОЙ из секции "SETUP and ADDITIONAL INFO"»? Поступив таким образом, мы сэкономим громадное количество часов рабочего времени, так как при необходимости менять шаги нужно будет только в одном месте!

Кстати, "оплата картой" — это линк к страничке в локальной сети с соответствующей инструкцией, называемой, например, "Как произвести оплату кредитной картой".

Кстати, хорошей идеей является создание в локальной сети вашей компании мини-веб-сайта департамента качества, где наряду с вебстраничками с • контактной информацией работников департамента, • пинками к файлам с тест-комплектами, • другой полезной информацией расположится и внутреннее Пособие для тестировщиков (QA Knowledge Base), где кроме прочего будут задокументированы повторяющиеся сценарии.

Теперь обобщим уже известные нам мероприятия по улучшению поддерживаемости тест-кейса:

1. Сделать тест-кейс data-driven.

2. Не описывать шаги по явно очевидным сценариям (например, логин).

3. Не давать конкретных деталей, если они не играют роли при исполнении тест-кейса (например, имя товара).

4. Вынести во внешний документ повторяющиеся сценарии (например, семь шагов оплаты).

Ну, за поддерживаемость!

IDEA: Оплата может быть произведена картой VISA SETUP and

ADDITIONAL INFO:

Эккаунт: testuser1/paSSwOrd Данные карты:

Номер: 9999-5148-2222- Окончание действия: 12/ CVV2: 778 SQL1: select result from cc transaction where id Created on: 11/17/2003 by О.Тарасов Новый тест-кейс Modified on: 11/26/2003 by И. Новикова Шаги были упрощены, чтобы

PROCEDURE EXPECTED RESULT

2. Войди в систему.

3. Найди любой товар.

4. Добавь товар в корзину.

5. Произведи оплату картой из секции SETUP and ADDITIONAL INFO 6. Запиши номер заказа 7. Запроси базу данных с SQL и запиши результат Идем дальше.

Сколько ожидаемых результатов может быть в одном тест-кейсе?

Тест-кейсом проверятся только одна конкретная вещь, и в идеальном варианте для проверки этой вещи достаточно предусмотреть в тест-кейсе только один ОР, и если бы я был теоретиком, а не практиком тестирования, то сказал бы, что ни в коем случае нельзя включать в тест-кейс более одного ОР.

ВОТ вам случай из практики Допустим, что в соответствии с пунктом 12.6 документа "Дизайн кода для спека #6522" признаком того, что оплата была успешно проведена картой VISA, будет одновременное наличие не одного, а двух условий:

1. Значение "10" в соответствующей колонке соответствующей строки в 2. Уменьшение баланса на счете с картой VISA на сумму, равную сумме То есть получается, что для тестирования одной вещи ("Оплата может быть произведена картой VISA") нужно проверить соответствие жизненной реальности двум ожидаемым результатам.

У нас есть два пути:

1. Разложить идею тест-кейса на две идеи и создать два тест-кейса.

2. Оставить идею тест-кейса неприкосновенной и включить в один тест-кейс два ОР, т.е. у нас складывается ситуация, когда исполнение тест-кейса будет иметь положительный исход, только если ОБА фактических результата совпадут с соответствующими им ожидаемыми результатами.

Вот как будет выглядеть визуально путь 2:

IDEA: Оплата может быть произведена картой VISA SETUP and

ADDITIONAL INFO:

Эккаунт: testuser1/paSSwOrd Данные карты:

Номер: 9999-5148-2222- Окончание действия: 12/ CVV2: 778 SQL1: select result from cc transaction where id = ; Баланс счета карты можно посмотреть здесь:

www.main.testshop.rs/1277/balance.htm Created on: 11/17/2003 by О.Тарасов Новый тест-кейс Modified on: 11/26/2003 by И. Новикова Шаги были упрощены, чтобы Modified on: 01/17/2003 by И. Новикова

PROCEDURE EXPECTED RESULT

2. Открой www.main.testshop.rs 3. Войди в систему.

4. Найди любой товар.

5. Добавь товар в корзину.

6. Произведи оплату картой из секции SETUP and ADDITIONAL INFO (!!! запиши полную сумму заказа:

7. Запиши номер заказа 8; Запроси базу данных с SQL1.

Как будет проходить исполнение этого тест-кейса?

Прошли восемь шагов. Остановились. Проверили. Затем прошли девятый шаг. Остановились. Проверили.

Исход исполнения этого тест-кейса будет считаться положительным только при одновременной истинности двух условий:

1. ФР после исполнения шага 8 = "10" и 2. ФР после исполнения шага 9 = Шаг 1 - Шаг 6 (т.е. значение из Шага 1 минус значение из Шага 6).

В теории лучше было бы разбить нашу идею тест-кейса на две части и создать два отдельных тест-кейса:

1. IDEA: "Правильное значение вставляется в базу данных при использовании VISA".

2. IDEA: "Верная сумма списывается с баланса карты".

И если есть возможность, то ЛУЧШЕ сделать именно два тесткейса, НО на практике во многих случаях имеет смысл включить в тест-кейс 2 или больше ОР, так как:

• у вас может просто не быть времени на написание, исполнение и поддержку двух тест-кейсов*;

• сэкономленное время можно потратить на написание, исполнение и поддержку тест-кейса, которым мы бы проверили другую вещь**.

Если у нас есть один случай, когда можно совместить два ОР, то написание, исполнение и поддержка двух тест-кейсов не представляет труда.

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

В результате такой экономии мы с течением времени создаем десятки новых тест-кейсов, которые помогают нам провести более тщательное тестирование.

Я работал с тест-кейсами, включающими более одного ОР, в течение многих лет, проводя тестирование сложнейшего ПО, связанного с финансовыми транзакциями, и могу сказать, что 2 или больше ОР в одном тест-кейсе — это нормальная практика.

Идем дальше.

Во многих случаях, когда несколько ожидаемых результатов просятся в один тест-кейс, нужно проверить • значение(-я) на веб-странице и • значение(-я) в базе данных, е. нужна проверка снаружи и изнутри или на front end и back end.

Постановка мозгов Front end (читается как "фронт-энд") — это непосредственный интерфейс пользователя, т.е. текст, картинки, кнопки, линки и прочие вещи, которые пользователь видите окне веб-браузера или е-мейл клиента.

Back end (читается как "бэк-энд") — это ПО и данные, находящиеся за фасадом фронт-энда: HTML-код веб-страницы, веб-сервер, код приложения, база данных и т.д.

В последнем примере мы непосредственно "разговаривали" • с фронт-энд ом — в шаге 5, когда добавляли товар в корзину;

• с бэк-эндом — в шаге 8, когда запрашивали базу данных.

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

1. Зависимость тест-кейсов друг от друга.

2. Нечеткая формулировка шагов.

3. Нечеткая формулировка идеи и/или ожидаемого результата.

1. ЗАВИСИМОСТЬ ТЕСТ-КЕЙСОВ ДРУГ ОТ ДРУГА

Зависимость — это антоним независимости. Независимость тесткейса выражается в том, что он не связан с другими тест-кейсами.

Тест-кейс 1:

3. Открыть правый внешний карман рюкзака.

4. Засунуть руку в правый внешний карман рюкзака.

Ожидаемый результат: Граненый стакан.

Тест-кейс 2:

3. Открыть левый внешний карман рюкзака.

4. Засунуть руку в левый внешний карман рюкзака.

Ожидаемый результат: Огурец.

Как видно, шаги 1 и 2 сейчас одинаковы и всегда будет искушение улучшить то, что и так хорошо.

Пример Тест-кейс 1:

3. Открыть правый внешний карман рюкзака.

4. Засунуть руку в правый внешний карман рюкзака.

Ожидаемый результат: Граненый стакан.

Тест-кейс 2:

2. Открыть левый внешний карман рюкзака.

3. Засунуть руку в левый внешний карман рюкзака.

Ожидаемый результат: Огурец.

Так вот, таких вещей (имеется в виду шаг 1 тест-кейса 2) нужно избегать, так как:

• тест-кейс 1 может быть удален из-за ненадобности или • шаги по тестированию наличия стакана (в тест-кейсе 1) могут быть изменены (например, стакан лежит в другом рюкзаке, который находится на кухне).

В обоих случаях будет непонятно, как исполнить тест-кейс 2, так как • у нас или нет шагов 1 и 2 из тест-кейса 1, или • они стали неправильными (с субъективной точки зрения тест-кейса 2).

Другим распространенным случаем является допущение, что ПО или база данных уже приведены к нужному состоянию, так как были исполнены предыдущие тест-кейсы.

Пример В тест-кейсе X мы создаем транзакцию покупки книги. В тест-кейсе Y мы, допуская, что тест-кейс X был успешно исполнен, проверяем атрибут успешности транзакции покупки книги, не создавая саму транзакцию ("Зачем напрягаться, когда она уже создана?"). В итоге может произойти ситуация, когда транзакция покупки книги не создана, • тест-кейс X был удален;

• тест-кейс X был модифицирован так, что он создает транзакцию • тест-кейс X не создал транзакции по объективной причине (например, не работал соответствующий код).

Как результат, во всех трех случаях мы не можем исполнить тесткейс Y, так как данных, на которые он опирается, просто не существует.

Таким образом, хороший тест-кейс характеризуют:

• отсутствие ссылок на другие тест-кейсы;

• независимость от "следов", оставленных другими тесткейсами в нашем ПО или базе данных.

Следовательно, если у нас в документе А есть 10 тест-кейсов:

тест-кейс 1, тест-кейс 2,..., тест-кейс 10, то доказательством независимости каждого из тест-кейсов будет тот факт, что их без ущерба для тестирования можно всегда исполнять в любом порядке, например, тест-кейс 10, затем тест-кейс 2, затем тесткейс 6 и т.д. Принцип, думаю, понятен.

Согласен, что повторение шагов или подготовительной части тесткейса кажется порой тупым занятием, но все-таки преимущества независимого тест-кейса перекрывают напряг операции скопировал—вставил.

2. НЕЧЕТКАЯ ФОРМУЛИРОВКА ШАГОВ

"Пойди туда, не знаю куда".

На шаги тест-кейса можно смотреть, как на инструкцию "Как пройти" (или "Как проехать").

Если американцу, который в Москве первый раз, сказать (с видом москвича в пятом колене), что Красная площадь находится "за ГУМом", то он бессмысленно потратит много времени в поисках "загума" в путеводителе. Если же черкнуть ему е-мейльчик с инструкцией:

1. Выйди из "Националя".

2. На улице поверни направо.

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

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

5. Спустись налево в подземный переход.

6. Следуй указателям на стенах с надписью "Красная площадь", то он не только найдет Красную площадь и купит там прапорскую ушанку с гнутой кокардой, но и избежит обвинений в сексуальном харрасменте, которые на его родине вещь очень даже серьезная.

Кстати, • шаги 1 — 5 включительно — это точные инструкции, а • шаг 6 — это отсылка к инструкциям, хранящимся в другом месте (помните, мы говорили о внутреннем Пособии для тестировщи-ков с шагами для повторяющихся сценариев?).

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

Нужно помнить, • то, что очевидно для вас сейчас, может стать совершен но непонятным через пару месяцев.

Так, сокращенные шаги с нерасшифрованными аббревиатурами и прочими веселыми прибамбасами, понятными вам сейчас, могут впоследствии стать китайской грамотой для вас самих, так что проще будет написать тест-кейс заново, чем пробираться через дебри неосмотрительно сделанных описаний;

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

Обоснование простое: что, если автор тест-кейса заболеет, уйдет в отпуск, уйдет из компании или уйдет, извините, вообще? Любой тест-кейс должен создаваться с мыслью о коллеге, который однажды возьмет его в руки.

Нужно избегать и другой крайности — когда шаги тест-кейса настолько детализируются, как будто он пишется для ученой обезьяны. Излишняя детализация ведет к усложнению поддерживаемости тест-кейса, что было нами убедительно доказано минуту назад.

В общем ищите золотую середину.

3. НЕЧЕТКАЯ ФОРМУЛИРОВКА ИДЕИ ТЕСТ-КЕЙСА

И/ИЛИ ОЖИДАЕМОГО РЕЗУЛЬТАТА

Оба тезиса, о которых мы только что говорили:

• о том, что можно забыть то, что сейчас понятно, и • писать тест-кейсы нужно не для себя, а для того парня — применимы и к идее и к ожидаемому результату. Нюансы для идеи тест-кейса и ожидаемого результата:

а. Не рекомендуется отсылка к внешнему документу.

Когда мы говорили о выносе части шагов в Пособие для тестировщиков, то делали это в случаях многократно повторяющихся сценариев, встречающихся в разных тесткомплектах, с целью сделать наш тест-кейс более поддерживаемым. С идеей же тест-кейса и ожидаемым результатом — совсем другая история.

Подумайте, удобно ли будет исполнять тест-кейс, если в секции IDEA напечатано:

«В этом тест-кейсе мы проверяем пункт 21.6 спека номер 34 "Сценарий добавления кредитной карточки к счету пользователя"»

или в секции Expected Result:

"Проверь, что значение последнего шага равно значению пересечения значения шага 5 по оси X и значению шага 23 по оси Y из таблицы 17. спека из секции IDEA"?

б. Нужно помнить, что суть секции IDEA — это ОБЪЯСНЕ НИЕ идеи тест-кейса.

Если секция IDEA пуста или же в ней скромно напечатано "10", то каждый исполняющий этот тест-кейс каждый раз будет тратить несколько минут своего времени и/или времени своего коллеги на выяснение того, что же проверяется этим тест-кейсом.

в. Нужно помнить, что ожидаемый результат — это ин формация, на основании которой (вкупе с фактическим результатом) мы принимаем решение об исходе тесткейса. Следовательно, точность и четкость в форму лировке ожидаемого результата играют наиважнейшую Ожидаемый результат гласит: "Проверь, что показана страница с ошибкой", и страница с ошибкой действительно показывается. Дело в том, что если показывается не та ошибка, которая положена по спецификации, то будет пропущен баг. Почему он будет пропущен? Правильно: из-за неточной формулировки ожидаемого результата.

Еще один пример плохого ожидаемого результата:

"Все работает".

Идем дальше.

Тест-комплекты С помощью каждого отдельно взятого тест-кейса проверяется какая-то одна вещь (развернуто сформулированная в секции IDEA). Каждый спек — это источник для множества идей тестирования, и, таким образом, для проверки кода, написанного в соответствии со спеком, нам нужно множество тест-кейсов.

Совокупность тест-кейсов (находящихся, как правило, в одном документе), которые проверяют • какую-то определенную часть нашего интернет-проекта (например, "Оплату") и/или • определенный спек (например, спек номер 1455 "Рассылка пользователям е-мейлов на основании истории заказов"), называют тест-комплектом (test case suite).

Что происходит в жизни?

• получаем новый спек;

• создаем новый файл, в котором создаем новые тест-кейсы для этого нового спека;

• исполняем новые тест-кейсы с их одновременной модификацией (об этом через 45 секунд);

• если имеет смысл, то переносим тест-кейсы в основной тест-комплект, где хранятся тест-кейсы, проверяющие ту же функциональную часть вашего интернет-проекта.

Создание нового файла с новым тест-комплектом обусловлено тем, что новые тест-кейсы всегда исполняются в первую очередь и нам просто удобно хранить их отдельно от старых. Как говорится, "мухи отдельно, котлеты отдельно" (конечно, до тех пор, пока нам это удобно).

Пример На www.testshop.rs можно производить оплату картами VISA и MasterCard. У нас есть тест-комплект, который мы исполняем из релиза в релиз (это регрессивное тестирование, о котором мы еще будем много говорить), называемый "Покупка с использованием кредитных карт".

Этот тест-комплект был написан на основании спека #1211 и содержит тест-кейсы для проверки функциональностей оплаты с использованием VISA и MasterCard.

Для нового релиза написан спек #1422, согласно которому будет написан код для поддержки новой карты — британской Switch.

Сначала создаем новый тест-комплект "Покупка с использованием Switch", затем исполняем и одновременно модифицируем его. Учитывая, что • после исполнения содержимое тест-комплекта будет стабилизировано и • в нем проверяется та же функциональная часть веб-сайта ("Оплата"), в данном случае будет логичным сделать его частью тест-комплекта "Покупка с использованием кредитных карт".

Постановка мозгов Никто не ожидает, что тест-кейсы будут на 100% "работать" сразу после написания. Дело в том, что они создаются на основании опека (или, как это часто бывает, на основании устного пожелания начальника), и так как мы физически не видим функциональностей этого опека (код еще не написан), то многие вещи нужно в буквальном смысле представить себе. Кроме того, как мы уже видели, сами спеки имеют баги и спек может быть изменен без ведома тестировщика... (об этом В общем вариантов множество, и все ведут к тому, что в первый раз тест-кейсы должны исполняться их автором, задача которого • если необходимо, добавить новые тест-кейсы;

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

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

• отшлифовать их, что означает сделать формулировки кристально-сверкающе-искристо ясными и точными.

Вот "шапка", которую можно нацепить поверх тест-кейсов.

OVERVIEW:

GLOBAL SETUP and ADDITIONAL INFO:

Author — автор тест-кейсов.

Spec ID — номер (или иной уникальный ID) спека. Сам ID должен быть линком к спеку в локальной сети (об этом мы еще поговорим).

Priority — приоритет тест-комплекта (например, от 1 до 4), обычно соответствующий приоритету спека.

Producer — продюсер, написавший спек.

Developer — программист, пишущий код в соответствии со спеком.

В секции Overview вкратце рассказывается, чему посвящен этот тест-комплект.

Предназначение секции GLOBAL SETUP and ADDITIONAL INFO аналогично секции тест-кейса SETUP and ADDITIONAL INFO, только здесь мы говорим о повторяющихся вещах, которые будем использовать в более чем одном тест-кейсе, и вообще о любой другой полезной информации для всего тест-комплекта.

Вот содержимое файла credit_card_payments.doc, включающего тест-комплект "Покупка с использованием кредитных карт":

использованием кредитных карт (TS7122)* OVERVIEW:

Данный тест-комплект проверяет оплату картами VISA и MasterCard GLOBAL SETUP and ADDITIONAL INFO:

1. SQL1: select result from cc_transaction where id = ;

2. Баланс счета карты можно посмотреть здесь:

www.main.testshop.rs//balance.htm IDEA: Оплата может быть произведена картой VISA SETUP and ADDITIONAL INFO:

Эккаунт: testuser1/pa$$wOrd Данные карты:

Номер: 9999-5148-2222-1277 Окончание действия:

12/07 CVV2: Created on: 11/17/2003 by О.Тарасов Новый тест-кейс Modified on: 11/26/2003 by И. Новикова Modified on: 01/17/2003 by И. Новикова

PROCEDURE EXPECTED RESULT

2. Открой www.main.testshop.rs 3. Войди в систему.

4. Найди любой товар.

5. Добавь товар в корзину.

6. Произведи оплату картой из секции SETUP and ADDITIONAL INFO (!!! запиши полную сумму заказа:

7. Запиши номер заказа 8. Запроси базу данных с SQL1.

IDEA: Оплата может быть произведена картой MasterCard SETUP and ADDITIONAL INFO:

Эккаунт: testuser1/pa$$wOrd Данные карты:

Номер: 3333-7112-4444-7844 Окончание действия: 12/ CVV2: Created on: 11/17/2003 by О.Тарасов Новый тест-кейс Modified on: 11/26/2003 by И. Новикова Шаги были упрощены, чтобы Modified on: 01/17/2003 by И. Новикова Изменение шагов и второй

PROCEDURE EXPECTED RESULT

2. Открой www.main.testshop.rs 3. Войди в систему.

4. Найди любой товар.

5. Добавь товар в корзину.

6. Произведи оплату картой из секции SETUP and ADDITIONAL INFO (!!! запиши полную сумму заказа:

7. Запиши номер заказа 8. Запроси базу данных с SQL1.

(TS7122) — каждый тест-комплект должен иметь свой уникальный ID.

Прошу обратить внимание на следующее:

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.

И после того как мы его исполнили и причесали наши новые тесткейсы (в данном случае один тест-кейс), получаем:

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 IDEA: Оплата может быть произведена картой Switch SETUP and ADDITIONAL INFO:

Эккаунт: testuser1/pa$$wOrd Данные карты:

Номер: 3333-1988-4444-5699 Окончание действия:

12/05 CVV2: Created on: 01/21/2003 by И. Новикова Новый тест-кейс

PROCEDURE EXPECTED RESULT

2. Открой www.main.testshop.rs 3. Войди в систему.

4. Найди любой товар.

5. Добавь товар в корзину.

6. Произведи оплату картой из секции SETUP and ADDITIONAL INFO (!!! запиши полную сумму заказа:

7. Запиши номер заказа 8. Запроси базу данных с SQL1.

Теперь нам остается просто объединить оба файла. Таким образом, у нас получился all new credit_card_payments.doc. Откроем его:

Покупка с использованием кредитных карт Часть 1 тестирование с VISA и MasterCard Часть 2: тестирование со Switch switch_payments Прошу обратить внимание на следующее:

мы не меняли • ни содержимое файла switch_payments.doc, которое вставили в основной тест-комплект credit_card_payments.doc, • ни содержимое старого файла credit_card_payments.doc.

Можно, например, было сделать для них одну общую "шапку" или заменить SWPL0001 на CCPG0003 (чтобы иметь единую систему нумерации в одном тест-комплекте), но ни этого, ни других объединительных мероприятий не было (и не будет) проведено, так как:

• это два независимых модуля и каждый из них прекрас нены в одном файле (и одном тест-комплекте) из-за того, что они покрывают ту же функциональную часть нашего • уникальный 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.

Мы продолжим разговор о тест-комплектах на одном из следующих чаепитий.

Состояния тест-кейса У них все, как у людей. Рождаются, изменяются и умирают...

Рождение:

состояние — "Новый" (New).

Это первая редакция тест-кейса: "Created on: 11/17/2003 by 0. Тарасов".

Изменение:

состояние — "Измененный" (Modified). Модификации, как правило, связаны с изменением спека, затрагивающего этот тест-кейс, или с улучшением тест-кейса, например, для удобства в поддержке: "Modified on: 11/26/2003 by И.

Новикова".

Смерть тест-кейса наступает • вместе со смертью тестируемой вещи (определенной функциональности, элемента интерфейса пользователя и др.), например www.testshop.rs перестал принимать кредитные • в других случаях, например когда один тест-кейс дублирует другой, т.е. имеем состояние — "Более недействителен" (Retired).

Рекомендую не удалять тест-кейсы насовсем, так как во-первых, всегда возможна ошибка в суждении и нам нужно предусмотреть обратимость удаления, во-вторых, тест-кейс, который, по нашему субъективно-несовершенному мнению, перестал быть актуальным, может еще пригодиться, хотя бы как память о годах жизни, проведенных не за штурвалом пиратского брига "Черная жемчужина", а за монитором "Хундаи" с неотдирающимся стикером "Моя компания — мой дом".

В общем:

1. Создаем специальную директорию в том же месте, где хра ним файлы с тест-комплектами, и называем ее retired_testcases.

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

3. Переносим тест-кейс (cut/paste) из файла, больше не нуждающегося в этих услугах, в одноименный файл директории retired testcases.

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

Иногда возникает дилемма — что лучше: