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

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

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

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

дить подонка".

22

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

В общем сложилась ситуация, когда сама спецификация имеет

проблему, так как мы ожидаем (или по крайней мере должны

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

реальности их там нет. Так и запишем – «баг в спецификации»

(spec bug).

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

а. Скорее всего программист все же напишет информативное сооб

щение об ошибке. Ваше дело послать е-мейл продюсеру (продю

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

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

пункт 19. а.

б. Если программист написал нечто противоречащее здравому смыслу

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

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

тили, как программист написал сообщение об ошибке, противореча

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

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

1. Как правило, работа в стартапе – это уникальный опыт, когда тяже-

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

новкой (я, например, уже многие годы хожу на работу в шортах) и

окружающими вас милыми, веселыми людьми. Но бывают нештат-

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

качественно), и, когда дело дойдет до выяснения «кто виноват» и

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

лыми, веселыми людьми и активно начнут вешать собак друг на

друга. Так вот, чтобы одну из этих собак не повесили на вас, посы-

лайте е-мейлы, сохраняйте их и ответы на них и при случае пересы-

лайте их заинтересованным сторонам. Пригодятся те е-мейлы в

дальнейшем – хорошо, не пригодятся – еще лучше, тем более что

каши они не просят, а сидят себе тихо и малодушно в своих фолде-

рах и ничего не ждут от этой жизни.

2. Каждый должен заниматься своим делом и отвечать за свой участок

работы. В случае если спек сделан некачественно, то лучше под-

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

тельно того, как должно работать ваше ПО.

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

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

тата, кроме спеков.

1. ЖИЗНЕННЫЙ ОПЫТ

Как справедливо отметил Борис Слуцкий: "Не только пиво-раки

мы ели и лакали". Мы также учились и работали, любили и нена-

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

приобретали жизненный опыт (включая опыт работы). Так вот этот

Что такое баг

23

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

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

смыслом) я вынес ее в качестве эпиграфа во Введении. Дело в том,

что тестирование ПО – это то самое тестирование (которое мы

делаем постоянно), но только в отношении ПО. И моя задача

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

практический инструментарий по интернет-тестированию и помочь

их интеграции с тем, что у вас уже есть, – с жизненным опытом.

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

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).

Пустой ввод (Nul 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. Список ингредиентов и количество/вес каждого из них;