Савин Роман. Тестирование dot com

Подождите немного. Документ загружается.

ЧАСТЬ 2

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

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

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

цикл

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

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

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

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

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

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

Поехали.

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

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

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

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

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

данность.

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

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

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

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

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

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

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

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

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

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

131

132

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

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

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

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

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

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

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

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

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

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

щиком.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ: нужно

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

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

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

• передать пользователям (релиз-инженер)

средства, которые эти потребности удовлетворят. Этими средст-

вами являются ФУНКЦИОНАЛЬНОСТИ интернет-проекта.

Вот формальное определение:

функциональность (functionality, feature) — это средство для

решения некой задачи.

Примеры из реальной жизни

Функциональность компьютерных колонок "Volume" решает задачу

"Как изменить громкость звука".

Функциональность "Казино" решает задачу "Как незаметно для себя

потратить все отпускные деньги".

Функциональность "Принтер" решает задачу "Как распечатать документ".

134

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

Примеры из виртуальной жизни

Функциональность "Корзина" решает задачу "Как хранить информацию

о товаре, выбранном пользователем".

Функциональность "Добавление товара в корзину" решает задачу "Как

добавить товар в корзину".

Функциональность "Удаление товара из корзины" решает задачу "Как

удалить товар из корзины".

Проверка работы функциональностей называется функциональ-

ным тестированием (functional testing).

Стратегический момент: так как функциональное тестирова-

ние — это ось, вокруг которой вертится деятельность большин-

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

"вертеться " и большинство наших последующих бесед.

Важность функционального тестирования состоит в том, что

функциональности — это не что иное, как продукт, предос-

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

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

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

Основными источниками знания о функциональностях служат:

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

...в электронном или распечатанном виде — спеки, макеты,

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

нии которых программист пишет код, а тестировщик пла-

нирует тестирование. Примером "прочего руководящего

документа" может служить "Инструкция Мастеркард о

формате файлов с транзакциями";

• хомо сапиенс, т.е.

информация постигается через межличностное общение.

Так, в случае возникновения сомнений никогда не мешает

подойти к продюсеру, хлопнуть его по плечу и попросить:

"Старина, будь добр, объясни мне по-простому пункт 146 вот

этого спека". Здоровая дружеская атмосфера в коллек-

тиве — это отличное средство для предотвращения оши-

бок в толковании (идеальной питательной среды для багов);

• сам веб-сайт,

который мы изучаем посредством эксплоринга. Экспло-

ринг (exploring (англ.) — "исследование", "разведка") —

это изучение того, как работает веб-сайт с точки зрения

пользователя.

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

135

Эксплоринг совершается каждым из нас, когда мы приходим на

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

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

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

В интернет-компаниях эксплоринг, как правило, применяется в

двух случаях:

• когда написан код и отсутствует документация. Подоб-

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

ходящего в работающую интернет-компанию;

• для самообучения. Например, в крупных интернет-компа-

ниях вновь нанятые тестировщики в течение нескольких

недель проходят тренинг, часть которого посвящена экс-

плорингу.

Кстати, при эксплоринге источником ожидаемого результата слу-

жат наши драгоценные жизненный опыт, опыт работы и другие

ранее перечисленные помощники, не относящиеся к спекам.

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

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

лем своего и аналогичных веб-сайтов. Выражение "Eat your own dog

food" ("Ешь еду своей собаки") для тестировщика означает "Если ты

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

книги по Интернету".

Идем дальше.

Конечной целью этапа Изучение и анализ предмета тестирова-

ния является получение ответов на два вопроса:

а. Какие функциональности предстоит протестировать?

б. Как эти функциональности работают?

После того как ответы получены, мы переходим к следующему

этапу цикла.

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

Эта стадия требует от тестировщика наибольшего творчества и

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

головоломок, отвечающих на один простой вопрос: "Как будем

тестировать?", причем качество продукта (а значит, и счастье поль-

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

найденных решений.

136

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

Мудрость найденных решений проявляется в двух вещах:

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

функциональностей;

б) компромиссе между

объемом тестирования, который возможен в теории;

объемом тестирования, который возможен на практике.

Ответы на "один простой вопрос" предстают перед

миром в виде тест-документации (test documentation),

ядро которой составляют наши любимые тест-кейсы. Во

многих случаях создание тест-документации

сопровождается написанием тестировщиком вспо-

могательных тулов (tool — компьютерная программа),

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

Идем дальше.

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

Суть исполнения тестирования — это практический

поиск багов в написанном коде с использованием

тест-кейсов, созданных ранее.

Исполнение функционального тестирования выглядит

следующим образом:

сначала идет проверка новых функциональностей по

новым тест-кейсам. Кстати, давайте вспомним, что во

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

проходя обкатку первым исполнением;

затем проверка старых функциональностей по старым

тест-кейсам.

То же самое, но в профессиональной терминологии:

тестирование новых функциональностей (new feature

testing) и соответственно

регрессивное тестирование (regression testing).

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

Давайте еще раз вспомним, что

после нахождения бага тестировщик заносит запись о

нем в систему трэкинга багов;

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

тестировшик проверяет:

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

137

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

осущест

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

ли к багу, или, в профессиональной терминологии, пу

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

ответствующему ожидаемому результату;

б) не появились ли новые баги как нечаянное

следствие

изменения кода при починке. Проверка осуществляется

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

рых могла быть затронута починкой.

Тестирование, исполняемое в пунктах а) и б), также

называется регрессивным тестированием (bug regression

testing). Соответственно выражение "regress that bug"

(проведи регрессивное тестирование этого бага)

означает, что нужно последовательно исполнить пункты а)

и б).

Идем дальше.

Давайте сделаем небольшое обобщение.

Так как этапы 1. Изучение и анализ предмета

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

2. Планирование тестирования переплетены между собой, мы

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

подготовка к тестированию (test preparation или, по-

простому, test preps).

Итак, большая часть нашего дальнейшего общения будет

посвящена двум вещам:

Подготовка к тестированию (testpreparation);

Исполнение тестирования (test execution).

Краткое подведение итогов

Функциональность — это средство для решения некой задачи.

Проверка работы функциональностей называется функциональным

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

Эксплоринг — это изучение того, как работает веб-сайт с точки зрения

пользователя.

Ядро тест-документации составляют наши любимые тест-кейсы.

Вспомогательные программы ("тулы") пишутся для облегчения исполнения

тест-кейсов.

Мы выделили два основных этапа цикла:

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

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

138

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

7. Исполнение тестирования идет в два этапа:

• тестирование новых функциональностей и

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

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

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

висимым от цикла разработки ПО?

2. Назовите источники информации о функциональностях.

3. Что такое эксплоринг и как он помогает в состоянии документа-

ционного вакуума?

4. Назовите два основных элемента стадии подготовка к тестиро-

ванию.

5. Что такое регрессивное тестирование? Назовите две ситуации,

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

6. Почему сначала тестируются новые функциональности?