Текст книги "tестирование dot com"
Автор книги: Роман Савин
Жанры:
Интернет
,сообщить о нарушении
Текущая страница: 11 (всего у книги 17 страниц)
дороге, ведущей из Сан-Франциско, из-за снегопада уже образо-
вались страшные пробки. Кроме того, скорее всего большинство
членов сан-францисской команды поедут после работы, т.е. в 4
часа, а значит, будут здесь не раньше 8.
Следовательно, нам нужно сначала расчистить дорогу 3 и по-
сле этого заняться дорогой 1.
Кстати, остаются еще двое, едущие из Техаса. Вот их мобильный
телефон. Я собираюсь им позвонить, рассказать о ситуации со
снегом, наших планах по расчистке и скоординироваться с ними,
как им лучше до нас добраться".
Второй вариант разговора
Вопрос: «Что делать, Джеймс?»
Ответ: "Босс, надо сначала расчищать дорогу 2, ведущую к
горнолыжным курортам. Все наши постояльцы – это горнолыж-
ники. Кроме того, оставшиеся 30 человек скорее всего сначала
заедут на курорт, покатаются там до вечера и вечером поедут к
нам – не будут же они терять сегодняшний день, я сам заказывал
им пропуска со скидкой на подъемники, а пропуска начинают
действовать сегодня".
Третий вариант разговора
Вопрос: «Что делать, Джеймс?»
Ответ: "Босс, нет проблем. Нам нужно расчистить и дорогу 1, и
дорогу 2. Я не знаю, что важнее. Но знаю номер телефона моего
приятеля – владельца снегоочистительной компании, он даст
нам хорошую цену, и двумя машинами мы сможем к полудню
расчистить обе дороги. Ну, потратим немного денег, зато сохра-
ним репутацию отеля, ставящего заботу о клиенте выше всего".
Мораль:
субъективные суждения, основанные на тупосамонадеянном
«Абсолютно очевидно», могут элементарно завести нас в си-
туацию, когда ресурсы потрачены впустую, так как не учи-
тывают реальности. В то же время выводы, сделанные исходя
из достоверной информации, ведут к эффективным решениям
даже при нехватке ресурсов.
Нигилистический настрой и практическая методология
191
То, что сделал для нас мистер Джеймс, было оценкой риска. Он
смог сделать оценку риска, так как
• владел информацией и
• знал, как этой информацией распорядиться.
Обратно к тестированию ПО.
Наша задача – это
• получить информацию,
• если возможно, узнать мнение человека, владеющего во-
просом, и
• оценить риск по каждой из функциональностей, которые
предстоит протестировать.
Людьми, которые владеют вопросом, могут быть продюсер, глав-
ный бухгалтер, финансовый директор, бизнес-аналитик. Информа-
цию можно получить также из статистики или других источников.
Поверьте, что такой подход даст удивительные результаты.
Допустим, у нас есть небольшой проектик, где нужно протести-
ровать новый (переписанный и оптимизированный) код для уже
давно существующих функциональностей:
а) сделки купли-продажи между пользователями внутри Аме
рики;
б) сделки купли-продажи между пользователями в Японии;
в) сделки купли-продажи между пользователями в Японии
и США.
Разложим эти функциональности:
Таблица 1
1
2
3
4
0
0
0
0
0
0
0
0
_
_
_
_
эл
эл
эл
эл
с_
с_
с_
с_
ек
ек
ек
ек
д
д
д
д
н
н
н
н
И
И
И
И
Продавец
Американец
X
Японец
X
Покупатель
Американец
X
Японец
X
192
Тестирование Дот Ком. Часть 3
Таблица 2
1
2
3
4
0
0
0
0
0
0
0
0
_
_
_
_
эл
эл
эл
эл
с_
с_
с_
с_
ек
ек
ек
ек
д
д
д
д
н
н
н
н
И
И
И
И
Продавец американец —> Покупатель американец
X
Продавец американец —» Покупатель японец
X
Продавец японец – > Покупатель американец
X
Продавец японец – > Покупатель японец
X
Помните, я говорил, что применение методов генерирования тес-
тов дает вам более глубокое понимание спека? Вот и теперь, де-
лая матричную раскладку, мы увидели, что на самом деле у нас
не три, а четыре направления для тестирования. Разложим их на
блок-схеме.
Блок-схема по спеку #1123
Постановка мозгов
Есть превосходный профессиональный термин flow (течение, процесс)
(будем использовать его в транслите как «флоу»). Флоу – это один или
больше сценариев использования или работы ПО. Например, у нас есть
флоу Американец -> Американец. В данном конкретном случае на это флоу
можно написать множество сценариев (например, с разными суммами
оплаты, транзакции между разными штатами и т.д.).
Итак, у нас есть четыре флоу.
Давайте снова поиграем в "Абсолютно очевидно" и решим во-
прос о приоритетности каждого флоу. Допустим, что покупаются
и продаются запчасти для автомобилей:
Нигилистический настрой и практическая методология
193
а. Скорее всего, самым приоритетным будет флоу Япо
нец – > Американец, так как в США очень много японских
автомобилей, запасные части производятся в Японии и
наш сайт – это очень важный канал для поставок.
б. Ниже идет флоу Американец —> Американец, хотя внут
ренний рынок американских запчастей очень велик, но есть
много других каналов поставок кроме нашего веб-сайта.
в. Далее идет Американец —> Японец, это флоу менее при
оритетное, чем о и б, но более приоритетное, чем г.
г. Самый нижний приоритет у флоу Японец —» Японец, так
как в Японии развита инфраструктура купли-продажи зап
частей и нашим сайтом там почти не пользуются.
Вроде бы все смотрится логично, но до тех пор, пока мы не нач-
нем копать.
Вопрос: Откуда у меня информация, на основании которой я сде-
лал свои выводы? Откуда я знаю, что, например, в случае а (Япо-
нец —» Американец) "наш сайт – это очень важный канал для
поставок"?
Ответ: Я знаю это, так как где-то (может быть, краешком уха)
услышал или прочитал (может быть, в определенном контексте)
эту информацию.
А что, если я неправильно понял эту информацию или она,
подобно постмодернизму, устарела?
Далее.
Вопрос: Что значит, что "внутренний рынок американских зап-
частей очень велик"? Насколько он велик? Ответ: ...
Карточным домиком были наши рассуждения. А ведь все ка-
залось таким логичным...
Давайте лучше пойдем к продюсеру, покажем ему нашу блок-
схему и попросим совета.
Пришли, показали, попросили.
Продюсер делает пару звонков, и мы идем к бизнес-аналитику.
Тот видит нашу блок-схему, поднимает данные по транзакциям
за последние два года, и вот что мы имеем.
194
Тестирование Дот Ком. Часть 3
а. Самое большое количество сделок было между японскими
пользователями (Японец —» Японец). Продюсер добавляет,
что продвижение на японском рынке – это главный при
оритет компании, как было сказано на очередном съезде, в
смысле было сказано на последнем собрании.
б. Вторым по приоритетности идет Американец —» Японец.
Вот данные по сделкам. Продюсер добавляет, что недавно
были заключены контракты с крупными американскими
автозаводами о том, что те будут использовать наш веб-сайт
для продаж за рубеж.
в. Третьим будет Американец – > Американец, так как вот
цифры. Продюсер добавляет, что конкурирующие сайты и
другие каналы поставок завоевали местный рынок.
г. Четвертым будет Японец —» Американец, так как вот циф
ры. Продюсер добавляет, что японские компании распре
деляют запасные части через своих авторизованных аме
риканских дилеров, а американские дилеры японских ино
марок используют наш сайт неохотно.
Затем мы попросили дать процент для каждого флоу относитель-
но общей суммы сделок по всем четырем флоу (это было немного
больше, чем было нужно, так как я уже знал приоритетность ка-
ждого флоу, но, как говорят, "кашу маслом не испортишь" и "куй
железо, пока горячо"):
Блок-схема по спеку #1123
Теперь у нас есть данные, соответствующие реальности и осно-
ванные
• на информации из объективных источников и
• на мнении компетентных лиц.
У нас есть не просто приоритеты, а приоритеты, подкрепленные
цифрами (проценты) и пониманием бизнеса (комментарии про-
дюсера).
Нигилистический настрой и практическая методология
195
И еще мы снова видим, что эти превосходные, проверенные дан-
ные снова абсолютно противоречат нашему, казалось бы, незыб-
лемому, но на поверку очень даже "зыблемому" "Абсолютно
очевидно".
Что делать, если вдруг есть две функциональности с одинако-
вым приоритетом? С чего начать? Начните с той, которая бо-
лее сложная и трудоемкая.
Последний вопрос в отношении оценки риска – это использова-
ние полученной информации. Флоу с более высоким приорите-
том (который мы отражаем в поле тест-кейса "Приоритет") тес-
тируется
• в первую очередь и
• более тщательно.
Кроме того, в дальнейшем у вас всегда будет аргумент, почему
вы тестировали именно это и именно в таком объеме. И этим
аргументом будут данные по оценке риска, которые вы использо-
вали как профессионал-тестировщик, ориентированный на сча-
стье пользователя.
2. ЭКВИВАЛЕНТНЫЕ КЛАССЫ (equivalent classes)
Это суперполезная вещь, которой мы немедленно дадим опре-
деление:
эквивалентный класс – это одно или больше значений ввода,
к которым ПО применяет одинаковую логику.
Предположим, что наш книготорговый веб-сайт запускает новую
кампанию "Больше тратишь – больше скидка". Вот табличка из
спека.
Потраченная сумма,
Скидка,
руб-
%
200 – 500
2
500—1000
3
1000 – 5000
4
5000 и более
5
Мы, конечно, сразу увидели 3 бага спека:
196
Тестирование Дот Ком. Часть 3
Баг1:
Непонятно, по какой ставке рассчитывается скидка, если по-
трачены следующие суммы: ровно 500 руб., ровно 1000 руб.,
ровно 5000 руб., так как каждая из этих сумм находится не в
одной, а в двух корзинах со скидками.
Баг 2:
Что означает "Потраченная сумма"? Это количество дензна-
ков, выплаченных только за книги, или полная сумма к оплате,
включая оплату книг и расходы на доставку?
Баг 3:
Для полноты картины нужно дописать эквивалентный класс
от 0 до 199,99, на значения которого никакая скидка не рас-
пространяется.
Что делаем?
Правильно: идем к продюсеру. Извещаем о баге программиста.
"Размораживаем" спек. Вносим в него изменения.
Вот перед нами уже отредактированная табличка:
Стоимость
Скидка, %
купленных книг, руб.
0—199,99
0
200,00 – 499,99
2
500,00 – 999,99
3
1000,00 – 4999,99
4
5000,00 и более
5
У нас получилось 5 эквивалентных классов:
Класс 1:
0—199,99
Класс 2:
200,00 – 499,99
Класс 3:
500,00 – 999,99
Класс 4:
1000,00 – 4999,99
Класс 5:
5000,00 и более
Нигилистический настрой и практическая методология
197
Каждое значение внутри каждого класса является эквивалентным
всем другим значениям этого класса.
Почему? Потому что ко всем значениям класса должна приме-
няться одинаковая логика кода. Например, при стоимости куп-
ленных книг и 1215,11 руб., и 1745,45 руб., и 2000 руб. (класс 4)
полагается скидка 4%.
Составными частями класса являются:
1. Значение или корзина значений ввода (например, от 500,00
до 999,99) и
2. Логика для вывода, т.е. ожидаемого результата (скидка 3%
в случае с классом 3).
Польза раскладывания значений ввода на эквивалентные клас-
сы состоит в том, что мы отсеиваем огромное количество
значений ввода, использовать которые для тестирования про-
сто бессмысленно.
Отсев происходит путем применения знаний о тестировании по-
граничных значений.
3. ПОГРАНИЧНЫЕ ЗНАЧЕНИЯ (boundary values)
Все очень просто. Давайте представим себе наши эквивалентные
классы из предыдущего примера:
Вертикальная пунктирная линия – это первое возможное значе-
ние класса (нижний предел).
Вертикальная сплошная линия – это последнее возможное зна-
чение класса (верхний предел).
198
Тестирование Дот Ком. Часть 3
Пограничные значения – это конкретные предельные зна-
чения, образующие водораздел между эквивалентными клас-
сами.
Для каждого эквивалентного класса может быть лишь один
из трех вариантов:
а. Есть только нижний предел (класс 5).
б. Есть нижний и верхний пределы (класс 2, класс 3, класс 4).
в. Есть только верхний предел (не рассматриваемый в данном
примере класс, который ограничен только сверху гипотети
ческим отрицательным значением, непосредственно пред
шествующим классу 1).
Пограничным тестированием (boundary testing) называется
применение метода тестирования пограничных значений.
Вот полная версия метода тестирования пограничных значений.
а. Сначала тестируется нижний предел данного класса (если
он имеется).
б. Затем тестируется верхний предел данного класса (если он
имеется).
в. Затем тестируется любое значение внутри данного класса.
г. Затем тестируется верхний предел класса, непосредственно
предшествующего данному классу (если предшествую
щий класс имеется).
д. Затем тестируется нижний предел класса, непосредствен
но следующего за данным классом (если следующий класс
имеется).
а, б, в являются позитивными тестами, гид
– негативными тестами.
Давайте же возьмем и протестируем эквивалентный класс 2. Суть
тестирования заключается в том, чтобы удостовериться, что для
покупок от 200,00 до 499,99 руб. (включительно) будет дана
скидка 2%. Опустим шаги сценариев и поговорим только о дан-
ных для них. Следуем методике тестирования эквивалентного
класса, нам нужно лишь пять вариантов данных:
а. 200,00;
б. 499,99;
в. 315,11;
г. 199,99;
д. 500,00.
Нигилистический настрой и практическая методология
199
Почему нам хватило только 5 сценариев, мы поговорим через
минуту.
А сейчас давайте посмотрим, сколько возможных вариантов
только для позитивных тестов у нас потенциально есть для
класса 2:
30 000 (по количеству копеек в 299,99 руб. плюс один слу-
чай, когда потрачено 200,00 руб.).
Наша методика позволила обойтись лишь 3 тестами (пози-
тивные тесты: а, б, в), которыми мы по сути протестировали
30 000 значений. По-моему, выглядит впечатляюще.
Теперь о 5 сценариях, которых было достаточно для позитивного
и негативного тестирования класса 2.
Представим себе схематично логику кода для решения вопроса о
скидке для класса 2:
ЕСЛИ сумма > 200,00 И сумма < 499,99,
ТО скидка = сумма /100 х 2.
Теперь рассмотрим, как каждый из наших тест-кейсов точечно
бьет по возможным проблемам кода. Прошу особого внимания —
ничего сложного нет, но много нюансов.
Тест-кейс
Код с выделенной жирным шрифтом частью,
которая проверяется данным тестом
Возможная проблема кода, разоблачаемая тестом, и
пример проблемы
Ожидаемый результат
а. Сначала тестируется
ЕСЛИ сумма > 200,00 И сумма < 499,99,
нижний предел данного ТО скидка = сумма/100 х 2
класса (если нижний
предел имеется):
Ошибка в знаке равенства и/или сумме нижнего
200
предела.
Пример (знакравенства перед 200,00 пропущен):
ЕСЛИ сумма > 200,00 И сумма < 499,99,
ТО скидка = сумма/100 х 2
2% от 200
200
Тестирование Дот Ком. Часть 3
б. Затем тестируется
ЕСЛИ сумма > 200,00 И сумма < 499,99,
верхний предел
ТО скидка = сумма/100 х 2
данного класса (если
верхний предел
Ошибка в знаке равенства и/или сумме верхнего
имеется):
предела.
499,99
Пример (499,00 вместо 499,99): ЕСЛИ сумма >
200,00 И CVMMQ < 499,00, ТО скидка = сумма/100
х 2
2% от 499,99
в. Затем тестируется
ЕСЛИ сумма > 200,00 И сумма < 499,99,
любое значение
ТО скидка = сумма/100 х 2
внутри данного
класса:
Ошибка в знаках больше (>) и меньше (<). Пример
315,11
(больше вместо меньше и меньше вместо больше):
ЕСЛИ сумма < 200,00 И сумма > 499,00: ТО скидка
= сумма/100 х 2
2% от 315,11
г. Затем тестируется
ЕСЛИ сумма > 200,00 И сумма < 499,99,
верхний предел класса,
ТО скидка = сумма/100 х 2
непосредственно
предшествующего
Тонкий момент. Здесь мы проверяем две вещи:
данному классу
1. Наличие скачка от верхнего предела предьщущего
(если предшествующий класса к нижнему пределу нашего класса.
класс имеется):
Это делается для следующей ситуации. Допустим,
199,99
программист напечатал 100,00 вместо 200,00: ЕСЛИ
сумма > 100,00 И сумма < 499,99,
ТО скидка = сумма/100 х 2. Если сделана такая
ошибка, то она не будет обнаружена ни тестом а, ни
тестом б, ни тестом е.
2. Логическое "И", так как если бы у нас было "ИЛИ":
ЕСЛИ сумма > 200,00 ИЛИ сумма < 499,99,
ТО скидка = сумма/100 х 2, то к данному классу
принадлежало бы любое в принципе возможное
значение
Скидка не равна 2% от 199,99
д. Затем тестируется
ЕСЛИ сумма > 200,00 И сумма < 499,99,
нижний предел класса,
ТО скидка = сумма/100 х 2
непосредственно
следующего
1. Наличие скачка от верхнего предела нашего класса
за данным классом
к нижнему пределу следующего за ним класса. Это
(если следующий
делается для следующей ситуации. Допустим,
класс имеется):
программист напечатал 599,99 вместо 499,99: ЕСЛИ
500,00
сумма > 200 И сумма < 599,99, ТО скидка =
сумма/100 х 2
Нигилистический настрой и практическая методология
201
Если сделана такая ошибка, то она не будет
обнаружена ни тестом а, ни тестом б, ни тестом в,
ни тестом г.
2. Проверяется логическое "И", так как если бы у
нас было "ИЛИ":
ЕСЛИ сумма > 200,00 ИЛИ сумма < 499,99,
ТО скидка = сумма/100 х 2, то к данному
классу принадлежало бы любое в принципе
возможное значение
Скидка не равна 2% от 500,00
Замечу, что для удобства в понимании мы производили тестиро-
вание класса 2 изолированно от его собратьев.
И теперь, поняв и разобравшись, давайте рассмотрим, как нам про-
тестировать все эквивалентные классы данного спека:
Класс
Значение
Ожидаемая
ставка скидки, %
Класс 1
0
0
100,00
199,99
Класс 2
200,00
2
315,11
499,99
Класс 3
500,00
3
659,23
999,99
Класс 4
1000,00
4
3265,26
4999,99
Класс 5
5000,00
5
5075,00
Итого 14 тест-кейсов для тестирования всех возможных значе-
ний. Неплохо. Очень даже неплохо!
На сером фоне 5 значений ввода, которые мы использовачи для
изолированного тестирования нашего любимого кяасса 2. Прошу
отметить следующую вещь: теперь, когда мы тестируем класс 2
202
Тестирование Дот Ком. Часть 3
вместе с окружающими его собратьями, для класса 2 доста-
точно 3 тест-кейсов, так как случаи г. (199,99) и д. (500,00)
покрываются при тестировании класса 1 и класса 3 соответ-
ственно.
Мы рассмотрели самый сложный вариант пограничного тестиро-
вания, когда мы проверяли эквивалентные классы, включающие
множества значений. Зато теперь, пройдя огонь, воду и медные
трубы, нам ничего не стоит разобраться в более простом случае,
когда эквивалентный класс содержит только одно значение.
Пример
Возьмем индекс, который должен быть равен 6 цифрам (Индекс_эл 005 из
табл. 1, матричной раскладки поля «Индекс»). Применяем метод
тестирования пограничных значений:
а. 6
б. 6
в. 6
г. 5
Д. 7
Таким образом, у нас есть:
•
один позитивный тест 6 и
•
два негативных теста 5 и 7.
Мы применяем метод
• как обособленно (тестирование скидок),
так и
• в сочетании с другими методами генерирования и отбора
тестов (использование пограничных значений на матрич
ной раскладке поля "Индекс").
Идея о возможности обособленного или интегрированного
применения, конечно, относится к каждому из методов гене-
рирования и отбора тестов.
Это все о пограничном тестировании.
Важная мысль перед списком изученных нами вещей о подготовке
к тестированию:
Не методы должны управлять вашей подготовкой, а вы должны
управлять методами так, чтобы с их помощью создать именно
те тест-кейсы, которые с высокой вероятностью могли бы
Нигилистический настрой и практическая методология
203
найти баги. Для этого нужно в совершенстве владеть каждым
из методов. И только практика может отточить ваши навыки.
Практикуйтесь и помните о примере с шахматами, которым
мы поставили себе мозги в начале нашей сегодняшней беседы.
Сегодня мы узнали и изучили:
Краткое подведение итогов
1. Хороший тестировщик – это не просто некий работник компании,
который может порвать код на части своими прикладными
знаниями по тестированию. Хороший тестировщик – это неис-
правимый циник, нигилист и Фома неверующий – все в отно-
шении кода.
2. Код – это убежище багов.
3. Суть тестирования заключается в поиске багов.
4. В отношении методов генерирования тестов:
• при использовании метода Черновик-чистовик: Черновик —
это полет мысли и вдохновения, "мозговой штурм", не огра-
ниченный суетными приличиями бренного света. Чистовик —
это подчищенный, причесанный и классифицированный Чер-
новик;
• матричная раскладка может быть лишь простой классифика-
цией элементов на табл. 1, а может и бесконечно углубляться
в дебри комбинаций и комбинаций. Главное помнить, что
матричная раскладка создается для тестирования, а не тес-
тирование было придумано для матричной раскладки;
• блок-схемы – это дочери добродетели под именем "Нагляд-
ность".
5. В отношении методов отбора тестов:
оценка риска основывается на том, что мы пытаемся влезть в
шкуру наших пользователей и бросить наши ограниченные ре-
сурсы не на бессмысленное кликанье правыми, левыми и даже
средними кнопками наших ошалевших мышек, а на тестирование
вещей, реально приоритетных для пользователей.
6. Методы генерирования тестов и методы отбора тестов –
это ящик с инструментом. Под каждую задачу используется
свой (свои) инструмент (-ты).
Вопросы для самопроверки
1. Какой настрой должен быть у тестировщика?
2. Что такое код?
3. Что такое тестирование?
4. Какие вы знаете методы генерирования тестов?
204
Тестирование Дот Ком. Часть 3
5. Какие вы знаете методы отбора тестов?
6. В чем суть метода Черновик-чистовик?
7. Есть ли ограничение на количество таблиц в матричной рас-
кладке?
8. Каково основное преимущество блок-схем?
9. Кто может помочь тестировщику в оценке риска?
10. Какая практическая польза от приоритезации при оценке риска?
11. Приведите 5 правил тестирования пограничных значений. Какие
из них позитивные, а какие – негативные?
12. Что нам дает комбинирование методов?
ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ
ЖИЗНЬ ЗАМЕЧАТЕЛЬНЫХ
БАГОВ
• ЧТО ТАКОЕ СИСТЕМА ТРЭКИНГА БАГОВ
• АТРИБУТЫ БАГА
• ПРОЦЕССТРЭКИНГА БАГОВ
ак мы знаем, цель исполнения тестирования – поиск багов.
Н
К о на самом деле найти баг – это только часть работы (хотя
и самая сложная). После того как баг обнаружен,
• нужно занести его в систему трэкинга багов и
• после того как он зафиксирован:
а) проверить, на самом ли деле он был зафиксирован и
б) не повредила ли починка этого бага другие части на
шего ПО.
Кстати, как мы помним, а и б называются регрессивным тес-
тированием.
Процесс, который начинается с занесения бага в систему трэкин-
га багов (Bug Tracking System), называется процессом трэкинга
багов (Bug Tracking Procedure), и для удобства понимания всей
стадии исполнения тестирования мы начнем именно с него.
Что такое система трэкинга багов
Важная оговорка: нет двух интернет-компаний, у которых про-
цесс трэкинга багов и все нюансы системы трэкинга багов были
бы идентичны. Каждый, как известно, извращается как хочет.
Моя цель – развить ваше понимание предмета так, чтобы
205
Жизнь замечательных багов
207
вы со спокойной улыбкой мастера смогли адаптировать полу-
ченные знания к любым процессам и системам, которые встре-
тятся вам на пути.
Забудем о тестировании ПО.
Допустим, мы совершаем тест-драйв на автомобиле, который со-
бираемся купить. Проверяем ускорение, вхождение в поворот,
удобство панели управления и сотню других важных вещей. По-
сле этого садимся за стол и записываем вещи, которые обманули
ожидания (т.е. баги), на пронумерованные страницы новой тетради
в клеточку. Один баг на одну страницу.
Например
на странице под номером 1 пишем: "Неудобно пользоваться навигаци-
онной системой";
на странице под номером 2 пишем: "Задержка в ускорении после на-
жатия на педаль акселератора"; на странице под номером 3 пишем:
«Слишком маленький багажник».
Наша ни в чем не повинная тетрадь на самом деле является не
только выброшенными на ветер деньгами, но и простейшей вер-
сией того, что называется системой трэкинга багов (СТБ).
Вспомним о тестировании. Опять же на примитивном уровне СТБ
может представлять собой простой текстовый файл с записями о
багах, который лежит на интранете и доступен участникам цикла
разработки ПО.
Итак, концептуально СТБ – это инфраструктура, позволяющая
• создавать,
• хранить,
• просматривать и
• модифицировать
информацию о багах.
Существует множество профессиональных СТБ – от бесплатной
Багзиллы (Bugzilla) до многотысячедолларового тест-директора (Test
Director by Segue), и естественно, что интернет-компании исполь-
зуют для трэкинга багов не тетрадки или текстовые файлы, а именно
специальное ПО, непосредственно созданное для трэкинга багов.
О таком ПО и процессе трэкинга багов мы и поговорим сегодня.
Каждый баг, занесенный в СТБ, представляет собой вирту-
альную учетную карточку
208
Тестирование Дот Ком. Часть 3
Каждая такая карточка существует не сама по себе, а как часть
процесса трэкинга багов (далее – Процесс).
С каждым багом, занесенным в СТБ, начинается новый Процесс.
Вопрос: Как определить, на какой стадии Процесса находится
каждая конкретная карточка?
Ответ: Ничего нет проще – нужно просто посмотреть на ее ат-
рибуты.
Пример
Одним из атрибутов является статус бага. Статус может принимать
одно из трех значений:
• Open (открыт),
• Closed (закрыт) либо
• Re-open (повторно открыт).
Пример Процесса
После того как баг заносится в СТБ, его статус автоматически стано-
вится «Open»; после того как баг зафиксирован и регрессивное тести-
рование подтвердило успех починки, мы меняем статус на «Closed»;
если же тот же баг, после того как мы его закрыли, был найден снова,
то мы меняем «Closed» на «Re-Open».
Важно понять, что Процесс как формальный свод правил перви-
чен и такой зверь, как СТБ, приобретается именно как инстру-
мент для материализации Процесса.
Другими словами, после инсталляции ответственный товарищ
настраивает СТБ в соответствии с процессом, выбранным компа-
нией, а не наоборот.
В примере со статусом мы взглянули на процесс с высоты птичь-
его полета. Опустимся же на землю и увидим все подробности.
Допустим, мы нашли баг. Сам факт нахождения бага, даже если
это критический дефект, не имеет никакого значения и веса, пока
вы не сообщили об этом баге. Два вопроса:
Кому сообщить?
Как сообщить?
Кому? Программисту, если это баг кода, либо продюсеру, если
это баг спека.
Как? Здесь есть много путей: можно позвонить, послать е-мейл,
сказать пару ласковых при личной встрече и т.д.
Жизнь замечательных багов
209
Стандартный путь, принятый в софтверных компаниях, – это занести
баг в СТБ.
Таким образом, одной из основных функций СТБ является обес-
печение коммуникации между участниками Процесса.
Как фактически происходит занесение бага в СТБ? Например, так: вы
• открываете веб-браузер;
• печатаете в нем URL вашей СТБ в локальной сети и нажимаете
Enter;
• после того как загрузилась страница СТБ, вводите имя
пользователя и пароль;
• нажимаете на кнопку «New bug» (Новый баг);
• на веб-форме "Новый баг" заполняете поля и выбираете
значения;
• нажимаете на кнопку «Submit new bug» (Занести новый баг).
Все очень просто.
Кстати, отныне баг в зависимости от контекста будет иметь одно из
следующих значений или оба значения:
• баг как отклонение фактического результата от ожидаемого ре-
зультата и/или
• баг как созданная в СТБ виртуальная учетная карточка, являю-
щаяся, по чьему-либо субъективному мнению, презентацией не-
кой проблемы.
В чем разница, спросите вы. Отвечаю: проблема, занесенная в СТБ,
может и не являться багом, например господин, опрометчиво занес-
ший баг в СТБ, неправильно понял спек.
Это была ненавязчивая вводная часть, и настоящее веселье только
начинается.
Атрибуты бага
BUG NUMBER (НОМЕР БАГА)
Каждому новому багу СТБ автоматически присваивает уникаль-
ный, следующий по порядку номер. Например, подходите вы к
программисту и спрашиваете: "Слушай, браза, как там 1232 по-
живает?"
210
Тестирование Дот Ком. Часть 3
SUMMARY (КРАТКОЕ ОПИСАНИЕ)
Краткое описание – это максимально информативное и сжатое
описание проблемы.
Как правило, текстовое поле для краткого описания не превышает
100 символов и в эти 100 символов (включая пробелы) нужно
уместить информацию, достаточную для понимания сути проблемы.
Кстати,
то, как тестировщик формулирует краткое описание, наглядно говорит
о его профессионализме.
Пример самого плохого Summary
«Ничего не работает». За такое Summary раньше били по голове канде-
лябром, и хотя сейчас времена другие, но все равно, пожалуйста, ни-
когда, никогда не пишите в кратком описании ничего подобного.
Почему поле для краткого описания такое короткое? Потому что
баги, занесенные в СТБ, выглядят примерно так, списком, на зна-
чения которого можно кликнуть мышкой и получить полную ин-
формацию по конкретным багам:
Bug
Summary
1
Неверное значение колонки result таблицы ее transaction для VISA
2
Неверное значение баланса Switch после покупки
3
Ошибка при логине: «SQL Error»
4
Корзина не сохраняет выбранные книги
Если есть номер спека, то можно давать краткое описание в та-
ком формате:
<номер спека> : <само краткое описание>, например:
7422: неверное значение баланса Switch после покупки.
Если баг начинается с номера спека, то баги
• можно сортировать по колонке Summary, таким образом баги,
принадлежащие к одному спеку, будут кучковаться вместе, и
• можно искать по номеру спека, используя функциональ-
ность СТБ "Поиск". Очень, кстати, удобно и вам, и про-
граммистам, и продюсерам.
Жизнь замечательных багов
211
Итак, в кратком описании сжато и информативно излагаем суть
проблемы.
DESCRIPTION AND STEPS TO REPRODUCE
(ОПИСАНИЕ И ШАГИ ДЛЯ ВОСПРОИЗВЕДЕНИЯ ПРОБЛЕМЫ)
Это многострочное текстовое поле. Я пользуюсь следующим
форматом для заполнения этого атрибута:
Description:
Полезная информация о баге: описание, комментарии, нюансы и т.д.
Steps to reproduce:
Конкретные шаги для воспроизведения проблемы.
Bug: Фактический результат.
Expected: Ожидаемый результат.
Пример для бага 1
Description:
При оплате картой VISA в колонке result таблицы cc_transaction в базе
данных записывается неверное значение.
Используйте следующую информацию для воспроизведения проблемы:
Эккаунт: testuser1/pa$$w0rd
Наименование товара: book117
Данные карты:
Номер: 9999-5148-2222-1277
Окончание действия: 12/07
CW2: 778
SQL1: select result from cc_transaction where id = <номер заказа>;
Steps to reproduce:
1. Открой www.main.testshop.rs
2. Введи имя пользователя.
3. Введи пароль.
4. Нажми кнопку «Войти».
5. Введи наименование товара в поле поиска.
6. Нажми кнопку «Найти».
7. Кликни линк «Добавить в корзину».
8. Кликни линк «Корзина».
9. Кликни линк «Оплатить».
10. Выбери вид карты.
11. Введи номер карты.
12. Введи срок окончания действия.
13. Введи CW2.
14. Нажми кнопку «Завершить заказ».
15. Запиши номер заказа.
16. Запроси базу данных с SQL1.
Bug: 20. Expected:
10.
212
Тестирование Дот Ком. Часть 3
Важный момент:
Steps to reproduce могут использоваться для воспроизведения
проблемы и программистами, и тестировщиками, и продюсе-
рами. В тест-кейсах можно допустить употребление принятых в
отделе качества сокращений и акронимов, а также ссылок к
внешним документам: коллеги-тестировщики поймут и простят,
но многие очевидные для тестировщика вещи совершенно не-
очевидны, например, для продюсера. Поэтому, пожалуйста, пи-
шите четкие и подробные шаги, чтобы ваши коллеги из других
