Давайте сделаем небольшое обобщение.
Так как этапы 1. Изучение и анализ предмета
тестирования и
2. Планирование тестирования переплетены между собой, мы
объединим их в контейнер знания, который называется
подготовка к тестированию (test preparation или, по-
простому, test preps).
Итак, большая часть нашего дальнейшего общения будет
посвящена двум вещам:
Подготовка к тестированию (testpreparation);
Исполнение тестирования (test execution).
Краткое подведение итогов
Функциональность — это средство для решения некой задачи.
Проверка работы функциональностей называется функциональным
тестированием.
Эксплоринг — это изучение того, как работает веб-сайт с точки зрения
пользователя.
Ядро тест-документации составляют наши любимые тест-кейсы.
Вспомогательные программы ("тулы") пишутся для облегчения исполнения
тест-кейсов.
Мы выделили два основных этапа цикла:
подготовка к тестированию;
исполнение тестирования.
138 Тестирование Дот Ком. Часть 2
7. Исполнение тестирования идет в два этапа:
• тестирование новых функциональностей и
• регрессивное тестирование.
Вопросы для самопроверки
1. Почему полезно представлять себе цикл тестирования ПО неза-
висимым от цикла разработки ПО?
2. Назовите источники информации о функциональностях.
3. Что такое эксплоринг и как он помогает в состоянии документа-
ционного вакуума?
4. Назовите два основных элемента стадии подготовка к тестиро-
ванию.
5. Что такое регрессивное тестирование? Назовите две ситуации,
при которых проводится регрессивное тестирование.
6. Почему сначала тестируются новые функциональности?
КЛАССИФИКАЦИЯ ВИДОВ
ТЕСТИРОВАНИЯ
• ПО ЗНАНИЮ ВНУТРЕННОСТЕЙ СИСТЕМЫ
• ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ
• ПО СУБЪЕКТУ ТЕСТИРОВАНИЯ
• ПО ВРЕМЕНИ ПРОВЕДЕНИЯ ТЕСТИРОВАНИЯ
• ПО КРИТЕРИЮ "ПОЗИТИВНОСТИ" СЦЕНАРИЕВ
• ПО СТЕПЕНИ ИЗОЛИРОВАННОСТИ ТЕСТИРУЕМЫХ
КОМПОНЕНТОВ
• ПО СТЕПЕНИ АВТОМАТИЗИРОВАННОСТИ ТЕСТИРОВАНИЯ
• ПО СТЕПЕНИ ПОДГОТОВКИ К ТЕСТИРОВАНИЮ
юбая классификация составляется по определенному при-
знаку, например:
• по полу люди делятся (классифицируются) на мужчин и
женщин;
• по наличию кошки люди делятся на тех, у кого кошка
есть, и тех, у кого ее нет;
• по росту люди делятся на группы в зависимости от коли-
чества сантиметров от земли до макушки (например, один
будет в группе "181 см", а другой — в группе "185 см").
Один и тот же субъект может быть одновременно элементом бес-
численного количества классификаций, при этом прекрасно себя
чувствовать и не испытывать никаких угрызений совести. На-
пример, дебошир и романтик Сева Б. может одновременно
• быть мужчиной,
• иметь кошку и
• вырасти до 175 см.
139
Л
Классификация видов тестирования 141
Немедленная польза от классификаций в отношении видов тести-
рования заключается в том, что упорядоченная и обобщенная
информация легче воспринимается, усваивается и запоминается.
Замечу, что видов тестирования существует огромное количе-
ство и мы не будем пытаться объять необъятное, а поговорим
об основных видах, которых, впрочем, и так хватит с лихвой для
любого интернет-проекта.
Сначала перечислим, потом объясним. Объяснения призваны
дать общее понимание каждого из элементов, в то время как по-
следующие разговоры это понимание расширят и углубят.
Формат изложения:
Классификация по этому признаку
состоит из следующих элементов.
Перечисляем:
1. По знанию внутренностей системы:
• черный ящик (black box testing);
• серый ящик (grey box testing);
• белый ящик (white box testing).
2. По объекту тестирования:
• функциональное тестирование (functional testing);
• тестирование интерфейса пользователя (UI testing);
• тестирование локализации (localization testing);
• тестирование скорости и надежности (load/stress/performance
testing);
• тестирование безопасности (security testing);
• тестирование опыта пользователя (usability testing);
• тестирование совместимости (compatibility testing).
3. По субъекту тестирования:
• альфа-тестировщик (alpha tester);
• бета-тестировщик (beta tester).
4. По времени проведения тестирования:
• до передачи пользователю — альфа-тестирование (alphatesting);
- тест приемки (smoke test, sanity test или confidence test);
- тестирование новых функциональностей (new feature
testing);
142 Тестирование Дот Ком. Часть 2
- регрессивное тестирование (regression testing);
- тест сдачи (acceptance or certification test);
• после передачи пользователю — бета-тестирование (beta
testing).
5. По критерию "позитивности" сценариев:
• позитивное тестирование (positive testing);
• негативное тестирование (negative testing).
6. По степени изолированности тестируемых компонентов:
• компонентное тестирование (component testing);
• интеграционное тестирование (integration testing);
• системное (или энд-ту-энд) тестирование (system or endto-
end testing).
7. По степени автоматизированности тестирования:
• ручное тестирование (manual testing);
• автоматизированное тестирование (automated testing);
• смешанное/полуавтоматизированное тестирование (semi
automated testing).
8. По степени подготовки к тестированию:
• тестирование по документации (formal/documented testing);
• эд хок-тестирование (ad hoc testing).
Объясняем:
1. По знанию внутренностей системы
• черноящичное тестирование (black box testing);
• белоящичное тестирование (white box testing);
• сероящичное тестирование (grey box testing).
Кстати, в отношении четких дефиниций, водоразделов и прочих
академических штучек до сих пор идут споры.
ЧЕРНЫЙ ЯЩИК (black box)
Должен признаться, что лучшие мгновения моего студенчества
прошли не в аудиториях моей альма-матер, не в залах библиотек,
а в пивной Коптевского рынка, куда мы с Балмашновым, Гнезди-
ловым, Дебдой, Ермохиным, Илюхиным, Карповым, Назаровым,
Классификация видов тестирования 143
Осмоловским, Сапачевым и Тарасовым вламывались с тубусами
наперевес и за вечер выполняли недельный план по продажам.
Основным элементом Коптевской пивной того времени была так
называемая автопоилка, т.е. аппарат, принимающий жетон и вы-
дающий пол-литра того, что мы тогда считали пивом.
Так вот если перевести манипуляции с автопоилкой на компью-
терный язык, то
• жетон был вводом,
• пиво — выводом,
• щель для жетона и носик для пива — интерфейсом поль-
зователя, а
• механизм автопоилки, обменивающий жетон на пиво, —
черным ящиком, так как мы не знали (и для сохранения
аппетита не хотели знать), как был устроен изнутри тот
столь необходимый для студента аппарат.
В отношении ПО черный ящик, т.е. область незнания, — это не
что иное, как тестируемые части бэк-энда (например, код про-
граммиста, схема базы данных), составляющие невидимый поль-
зователю виртуальный мост, который соединяет
• фактический ввод (шаги) и
• фактический вывод (фактический результат).
Признаки подхода "Черный ящик":
1. Тестировщик не знает, как устроен виртуальный мост.
2. ИДЕИ для тестирования идут от предполагаемых паттер-
нов (pattern — образец) поведения пользователей. Поэтому
подход "Черный ящик" также называют поведенческим.
Разберем первый признак.
1. ТЕСТИРОВЩИК НЕ ЗНАЕТ, КАК УСТРОЕН
ВИРТУАЛЬНЫЙ МОСТ
С одной стороны,
тестировщик имеет преимущество перед программистом, т.е. авто-
ром кода. Давайте будем честны перед собой: мы часто прини-
маем желаемое за действительное. Особенно это касается того,
что мы создали сами, например воображаемого образа любимого
человека. Сколько раз каждый из нас заводил романы с абсолют-
но неправильными, несовместимыми и нередко вредными для нас
144 Тестирование Дот Ком. Часть 2
людьми и утешал себя, что it's o'k — притрется, пригладится и
поймется. Как показывает жизнь, притирки, пригладки и понима-
ния ни к чему хорошему не приводят, как и попытки заставить
программиста произвести функциональное тестирование.
Вот перевод постинга на одном из форумов по тестированию:
"Программист не должен проводить тестирование, и давать
релизу зеленый свет. Нужно, чтобы кто-то независимый (чело-
век/отдел) был ответствен за поиск багов и уполномочен "дос-
тавать " программиста до тех пор, пока баг не будет починен.
Дело в том, что я как программист знаю свой код, и если я сам
провожу тестирование, то обязательно буду делать допущения,
что какие-либо части кода работают по умолчанию и их можно
не проверять. С другой стороны, мои тесты основаны на моем
понимании того, как работает код, и не учитывают реальных и
порой абсолютно нелогичных вещей, которые будут делаться поль-
зователями с моим кодом. С третьей стороны, у меня на тес-
тирование нет времени, и я не понимаю, почему должен проводить
тестирование, если за него платят тестировщикам ".
Реальность — это мир, пропущенный через призму субъективно-
го восприятия. Например, каждый родитель свято верит, что его
ребенок самый умный, талантливый и перспективный. Код — это
дитя программиста, и в своей реальности программист нередко
воспринимает код как априорно непогрешимый.
Вот вам легенда про призму восприятия:
Когда на пути в Индию корабли Колумба остановились перед од-
ним из Карибских островов, индейцы... этих кораблей не увидели,
потому что их призмы восприятия не пропускали образы, абсо-
лютно чуждые тем предметам и явлениям, с которыми они и их
предки существовали бок о бок на протяжении тысячелетий. И
лишь шаман, учуяв что-то неладное, несколько дней пристально
всматривался в горизонт, пока наконец не отделил романтические
силуэты испанских фрегатов от привычных океана и неба и не ска-
зал своей пастве: "Опа! Корабли Колумба " (тут, конечно, все сразу
настроили свои призмы, увидели не замеченные раньше корабли,
деловито погрузили в лодки свиней и поехали менять их на бусы).
Идея, думаю, понятна. Программист пишет, тестировщик тести-
рует, Филипп Филиппыч оперирует, Айседора Дункан танцует, и
никаких разрух.
Классификация видов тестирования 145
Итак, блэк бокс-тестировщику, знающему лишь то, для чего был
написан код (т.е. функциональности), а не как он был написан, легче
смотреть на тестирование с точки зрения пользователя, для удов-
летворения чаяний которого весь софтверный сыр-бор и начался.
С другой стороны,
блэк бокс-тестирование ведется вслепую, так как ни одна из час-
тей виртуального моста неизвестна. Следствием этого может
стать ситуация, когда для вещи, проверяемой одним тест-кейсом,
пишется несколько тест-кейсов.
Итак, в случае с черным ящиком тестировщик не знает, как
устроен виртуальный мост, и это может быть как полезно, так и
вредно для дела.
Разберем второй признак.
2. ИДЕИ ДЛЯ ТЕСТИРОВАНИЯ ИДУТ ОТ ПРЕДПОЛАГАЕМЫХ
ПАТТЕРНОВ (pattern — образец) ПОВЕДЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
То, что мы называли вводом (шагами), на самом деле является
двумя вещами, которые так же неотрывно связаны, как судьбы
Ромео и Джульетты. Речь идет о
сценариях и
данных для сценариев.
Исполнение тестирования может проходить как при наличии, так
и без тест-кейсов. Так вот в обоих случаях сценарий (scenario) —
это последовательность ДЕЙСТВИЙ для достижения фактиче-
ского результата.
Пример сценария
1. Открой www.main.testshop.rs.
2. Кликни линк "contact us".
Если исполнение тестирования идет по тест-кейсам, то можно ска-
зать, что сценарий тест-кейса — это совокупность шагов тест-кейса.
Данные для сценариев, или просто "данные", — это конкрет-
ные ЗНАЧЕНИЯ ВВОДА, используемые для достижения факти-
ческого результата.
Пример данных
1. Открой www.main.testshop.rs.
2. Введи текст "Затоваренная бочкотара" в поле поиска.
3. Нажми кнопку "Искать".
146 Тестирование Дот Ком. Часть 2
В последнем примере шаги 1 —3 (включительно) были сценарием,
а "Затоваренная бочкотара" — данными.
Еще один пример данных
При закрытии счета в одном из интернет-магазинов на последней
странице пользователь должен ответить, почему он закрывает счет.
Ему дается список из 20 вопросов, и напротив каждого вопроса раз-
мещен квадрат, куда можно поставить галочку (checkbox). Так вот если
пользователь поставит галочку напротив строк "Служба поддержки" и
"Медленная доставка" и нажмет на кнопку "Закрыть счет", то данными
будет текст "Служба поддержки " и " Медленная доставка".
Совместим знания о сценариях и данных со вторым признаком
подхода "Черный ящик".
Предполагаемые паттерны поведения пользователей — это те
сценарии и данные, которые, как мы ожидаем, будут реализо-
вываться и вводиться пользователями.
Основные источники предполагаемых паттернов поведения поль-
зователей могут быть:
а) напрямую взяты из спека.
Пример
Пункт 12 спека #9548 говорит: "Если на странице с регистрационной
формой пользователь не указал свой е-мейл, то после нажатия на
кнопку "Зарегистрироваться" показывается та же страница, но с сооб-
щением об ошибке: "Пожалуйста, введите ваш е-мейл" и с изменением
шрифта имени текстового поля "Е-мейл:" на красный цвет".
Напишем тест-кейс.
ИДЕЯ: "Сообщение об ошибке, если при регистрации не указан е-мейл".
Сценарий:
1. Открой wvwv.main.testshop.rs/register.htm.
2. Заполни все текстовые поля кроме "Е-мейл:" действительными
данными (поле "Е-мейл:"должно быть пустым).
3. Нажми на кнопку "Зарегистрироваться".
Ожидаемый результат 1:
Страница регистрации.
Ожидаемый результат 2:
Сообщение об ошибке "Пожалуйста, введите ваш е-мейл".
Ожидаемый результат 3:
Шрифт имени поля "Е-мейл:" изменен на красный цвет.
Кстати, данными для сценария из последнего примера послужили две
вещи: 1) действительный ввод всех полей, кроме е-мейла (мы предпола-
гаем, что лицо, исполняющее тест-кейс, знает легитимные значения ввода),
и 2) пустое поле для е-мейла. Значение ввода "" — это тоже вид данных.
Классификация видов тестирования 147
Давайте для простоты в дальнейшем использовать термин "сце-
нарий" в качестве собирательного образа, т.е. самого сценария
и данных, используемых в нем;
б) найдены путем эксплоринга.
Иногда "брожение" по сайту является лучшим источником для
понимания того, как реальный пользователь будет с ним обра-
щаться;
в) получены путем применения методики черноящичного
тестирования (black box testing methodology).
Примеры: впереди будет много примеров;
г) подарены интуицией.
Помните, как у Конан Дойля было сказано об инспекторе Лест-
рейде? Примерно так: "Но была единственная вещь, которая ме-
шала ему стать настоящим сыщиком, — у него не было чутья".
А чем мы не сыщики? Интуиция не менее важна для настоя-
щего профессионала-тестировщика, чем прикладные знания
и опыт работы;
д) присоветованы программистом или продюсером.
Общение, общение и еще раз общение. Самое дорогое — это ин-
формация, и общение — один из главных ее источников. Продю-
сер, программист и тестировщик дают путевку в жизнь одной и
той же функциональности, но каждый смотрит на нее со своей
колокольни, и если нам, тестировщикам, получить мнения това-
рищей с двух других колоколен, то можно узнать потрясающе
полезные вещи;
е) др.
Например, мы прочитали статью в Интернете, давшую классную
идею для сценария.
Итак, мы разобрались со вторым признаком подхода "Черный ящик".
Обобщаем.
При подходе "Черный ящик" тестировщик не основывает
идеи для тестирования на знании об устройстве и логике тес-
тируемой части бэк-энда. Идеи формируются путем предпо-
148 Тестирование Дот Ком. Часть 2
ложений о сценариях, которые будут реализовываться и при-
меняться пользователями. Такие сценарии называются пат-
тернами поведения пользователей.
БЕЛЫЙ ЯЩИК (white box)
также известен под именами Стеклянный ящик (glass/clear box),
Открытый ящик (open box) и даже Никакой ящик (по box).
В отличие от "Черного ящика" при подходе "Белый ящик" тес-
тировщик основывает идеи для тестирования на знании об
устройстве и логике тестируемой части бэк-энда.
Таким образом, при белоящичном тестировании сценарии созда-
ются с мыслью о том, чтобы протестировать определенную часть
бэк-энда, а не определенный паттерн поведения пользователя.
Пример из жизни
Допустим, нужно протестировать проходимость нового российского
внедорожника.
При подходе "Черный ящик" тестировщик садится за руль, выезжает за
кольцевую — в объятия подмосковной осени, находит непролазную ка-
наву, заезжает в нее и пытается выбраться, т.е. он проделывает вещи,
которые с большой вероятностью будут проделаны основными пользо-
вателями таких машин — охотниками, рыболовами и рэкетирами.
При подходе "Белый ящик" тестировщик открывает капот и видит, что
установлена система полного привода фирмы "Джапан моторз", мо-
дель RT6511. Тестировщик знает, что проходимость внедорожника
зависит именно от RT6511 и ее слабое место — это эффективность
при езде по снегу. Что делает тестировщик? Правильно! Выезжает
на белую сверкающую гладь русского поля и насилует джип в свое удо-
вольствие.
Последний пример не только служит иллюстрацией разницы в
подходах, но и показывает, что использование методик обоих
подходов количественно и качественно увеличивает покрытие
возможных сценариев.
Идем дальше.
Постановка мозгов
Покрытие возможных сценариев — это одна из частей архиважнейшей
концепции, называемой тестировочное покрытие.
Забудем на минуту о ПО вообще и о тестировании в частности.
Представим себе шахматную доску, состоящую из 64 клеток. Единст-
венная фигура, присутствующая на доске, — белый король. Допустим,
Классификация видов тестирования 149
каждая возможная ПОЗИЦИЯ короля записана на отдельной карточке:
"Поставь белого короля на такую-то клетку". Следовательно, у нас есть
64 карточки, или 100% теоретически возможных вариантов располо-
жения короля. Если мы будем перемещать короля в соответствии с по-
зициями на карточках, то, последовательно перелистав все карточки,
добьемся 100%-й практической реализации предписаний, указанных
на карточках.
Теперь усложним задачу и представим, что у нас есть шахматная доска,
количество клеток на которой так велико, что не поддается подсчету.
Допустим, что, согласно лишь нам известной логике, в голову нам уда-
рило выбрать лишь 20 позиций, которые мы опять же зафиксировали
на карточках. Теперь вопрос: покрывают ли 20 карточек 100% теорети-
чески возможных вариантов расположения короля? Нет. Можем ли мы
на 100%о практически реализовать предписания, указанные на 20 кар-
точках? Да.
Обратно к тестированию ПО.
Тестировочное покрытие (test coverage) состоит из двух вещей:
а. Покрытие возможных сценариев.
б. Покрытие исполнения тест-кейсов.
Покрытие возможных сценариев — это в большинстве случаев абст-
рактная величина, так как в большинстве же случаев невозможно даже
подсчитать, сколько понадобится тест-кейсов, чтобы обеспечить
100%-ю проверку ПО (например, попробуйте подсчитать количество
всех теоретически возможных тест-кейсов для тестирования Майкро-
софт Ворда-2003).
Другими словами, в большинстве случаев покрытие возможных сце-
нариев нельзя представить как процентное отношение сценариев, за-
фиксированных в тест-кейсах, ко всем теоретически возможным сце-
нариям.
Покрытие возможных сценариев может увеличиться либо уменьшиться
путем прибавления либо отнятия уникального тест-кейса, т.е. тест-
кейса,
• который тестирует реальный сценарий использования ПО и
• который не является дубликатом другого тест-кейса.
Покрытие исполнения тест-кейсов — это всегда величина кон-
кретная, и выражается она процентным отношением исполненных тест-
кейсов к общему количеству тест-кейсов. Допустим, тест-комплект для
тестирования функциональностей спека #1243 "Новые функциональ-
ности корзины" состоит из 14 тест-кейсов, и если 7 из них исполнены,
то покрытие исполнения тест-кейсов равно 50%>.
Возвращаемся к нашим ящикам.
Симбиоз использования подходов "Черный ящик" и "Белый ящик"
увеличивает покрытие возможных сценариев
• количественно, потому что появляется большее количест-
во тест-кейсов;
150 Тестирование Дот Ком. Часть 2
• качественно, потому что ПО тестируется принципиаль
но разными подходами: с точки зрения пользователя
("Черный ящик") и с точки зрения внутренностей бэк-энда
("Белый ящик").
В реальной жизни белоящичное тестирование проводится либо
самими программистами, написавшими код, либо их коллегами с
программистской квалификацией того же уровня. Кстати, юнит-
тестирование, о котором мы говорили, — это часть white box-тес-
тирования.
СЕРЫЙ ЯЩИК (gray/grey box)
Это подход, сочетающий элементы двух предыдущих подходов, это
• с одной стороны, тестирование, ориентированное на поль-
зователя, а значит, мы используем паттерны поведения поль-
зователя, т.е. применяем методику "Черного ящика";
• с другой — информированное тестирование, т.е. мы знаем,
как устроена хотя бы часть тестируемого бэк-энда, и активно
используем это знание.
Ярчайший пример
Допустим, мы тестируем функциональность "регистрация":
• заполняем все поля (имя, адрес, е-мейл и т.д.) и
• нажимаем кнопку "Зарегистрироваться".
Следующая страница — подтверждение, мол, дорогой Иван Иваныч,
поздравляем, вы зарегистрированы.
Теперь вопрос: если мы видим страницу с подтверждением регистра-
ции, то значит ли это, что регистрация была успешной? Ответ: нет,
так как процесс регистрации с точки зрения нашей системы включает
не только подтверждение на веб-странице, но и создание записи в
базе данных,
т. е. вывод, который стоит проверить, состоит из
• страницы с подтверждением и
• новой записи в базе данных.
Откуда мы почерпнем знание о логике создания записей в базе данных
при регистрации? Например, из технической документации (документ
о дизайне/архитектуре системы, документ о дизайне кода), общения с
программистом, самого кода.
Как видно из последнего примера, подход "Серый ящик" — это
дело хорошее, жизненное и эффективное. Деятельность боль-
шинства профессиональных тестировщиков интернет-проектов
протекает именно в разрезе сероящичного тестирования.
Классификация видов тестирования 151
Пара мыслей вдогонку.
1. Когда мы говорим о поведенческом тестировании, то это не
значит, что тестировщик ограничен набором действий, совер-
шаемых пользователем. Во многих случаях специально написан-
ный код используется для облегчения тестирования или для того,
чтобы вообще сделать его возможным.
Пример
При разговоре о формальной стороне тест-кейса мы проверяли баланс
кредитной карты до и после покупки на странице www.main.testshop.rs
/<четыре_последних_цифры_карты>/balance.htm. В реальности поль-
зователь проверяет баланс кредитной карты на сайте кредитной
организации, выдавшей эту карту (например, www.wellsfargo.com),
а страница balance.htm является специальным кодом, написан-
ным для тестирования с использованием несуществующих кредит-
ных карт.
Кстати, тот факт, что тестировщик использует информацию веб-стра-
ницы balance.htm, не означает, что он понимает логику работы кода,
отвечающего за списание денег со счета.
2. Как мы видели на примере с регистрацией, выводом, который
нужно было проверить для реального тестирования, послужила
не только страница с подтверждением, но и запись в базе данных.
Так как ожидаемый вывод — это ожидаемый результат на-
ших тест-кейсов, то огромное значение для эффективности
тестирования имеет поиск именно того ожидаемого результа-
та, который реально подтвердит, что код работает. Так, если
бы в том же самом примере ожидаемым результатом была только
страница с подтверждением, то проверка базы данных была бы
лишь тратой времени.
2. По объекту тестирования
• Функциональное тестирование (functional testing);
• Тестирование интерфейса пользователя (UI testing);
• Тестирование локализации (localization testing);
• Тестирование скорости и надежности (load/stress/ performance
testing);
• Тестирование безопасности (security testing);
• Тестирование опыта пользователя (usability testing);
• Тестирование совместимости (compatibility testing).
152 Тестирование Дот Ком. Часть 2
ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ (functional testing)
Уже говорили и еще будем много говорить.
ТЕСТИРОВАНИЕ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ
(UI (читается как "ю-ай") testing)
Это тестирование, при котором проверяются элементы интерфей-
са пользователя. Мы рассмотрим все основные элементы веб-
интерфейса при разговоре о системе трэкинга багов.
Важно понимать разницу между
тестированием интерфейса пользователя и
тестированием с помощью интерфейса пользователя.
Пример первого
Проверяем максимальное количество символов, которые можно напе-
чатать в поле "Имя" на странице "Регистрация", т.е. проверяем, отве-
чает ли конкретный элемент интерфейса, называющийся "одностроч-
ное текстовое поле" (textbox), требованию спецификации, которая ука-
зывает на максимальное количество символов, которое в этом поле
можно напечатать.
Пример второго
Тестируем бэк-энд и с помощью интерфейса создаем транзакцию по-
купки, т.е. мы использовали интерфейс пользователя как инструмент
для создания транзакции.
ТЕСТИРОВАНИЕ ЛОКАЛИЗАЦИИ
(localization testing)
Многогранная вещь, подразумевающая проверку множества ас-
пектов, связанных с адаптацией сайта для пользователей из
других стран. Например, тестирование локализации для поль-
зователей из Японии может заключаться в проверке того, не вы-
даст ли система ошибку, если этот пользователь на сайте зна-
комств введет рассказ о себе символами Kanji, а не английским
шрифтом.
ТЕСТИРОВАНИЕ СКОРОСТИ И НАДЕЖНОСТИ
(load/stress/performance testing)
Это проверка поведения веб-сайта (или его отдельных частей)
при одновременном наплыве множества пользователей.
Классификация видов тестирования 153
У каждого, кто пользуется Интернетом, есть опыт ожидания,
когда, например, кликаешь на линк и следующая страница
медленно высасывает из тебя душу, загружаясь ну оче-е-е-е-нь
долго.
Плохой перформанс (скорость работы) — это основная беда
российских интернет-проектов.
Менеджмент, который экономит на подобном тестировании, в
итоге, как правило, глубоко сожалеет об этом, так как современ-
ный интернет-пользователь — это существо ранимое и нервное,
если сайт работает медленно, с перебоями или не работает со-
всем, так как не справляется с наплывом посетителей, то совре-
менный интернет-пользователь идет куда? Правильно, на сайт
конкурента, тем более что физически никуда идти или ехать не
надо, а надо лишь набрать "даблюдаблюдаблю точка адрес кон-
курента точка ком ".
Тестирование скорости и надежности — это отдельная техниче-
ская дисциплина, за хорошее знание которой получают очень
большие деньги в иностранной валюте.
Как правило, целью такого тестирования является обнаружение
слабого места (bottleneck) в системе. Под системой подразумева-
ются все компоненты веб-сайта, включая код, базу данных, "же-
лезо" и т.д.
В моей практике был случай, когда из-за того, что один из за-
просов к базе данных был составлен громоздко (с точки зрения
обработки этого запроса системой), одна интернет-компания
потеряла много пользователей, так как в течение нескольких
дней сайт то работал, то не работал, и никто не мог понять,
what the heck is going on ("что за фигня "), пока один из програм-
мистов не встрепенулся и не исправил код. Прошу заметить,
что функционально старый код работал прекрасно, но с точки
зрения перформанса он никуда не годился.
Скорость и надежность веб-сайта профессионально проверяется
специальным ПО, которое легко может стоить под 100 тыс. долл.
(например, Silk Performer от Segue или Load Runner от Mercury
Interactive).
Упомянутое ПО служит:
с одной стороны, для генерации наплыва пользователей,
154 Тестирование Дот Ком. Часть 2
с другой — для измерения скорости, с какой веб-сайт в сред-
нем отвечает каждому из "наплывших" и с третьей — для
последующего анализа полученных данных.
ТЕСТИРОВАНИЕ БЕЗОПАСНОСТИ (security testing)
Одна из знакомых моего друга несколько лет назад наотрез от-
казывалась пользоваться Интернетом. На вопрос "почему? " она
неизменно отвечала, что боится хукеров, чем неизменно вызывала
у окружающих смех до икоты, так как на самом деле она имела
в виду хакеров (hacker — в современном значении киберпреступ-
ник, hooker — девушка легкого поведения).
Шутки шутками, а киберпреступность (cyber crime) — это целая
криминальная индустрия, доходы ежегодно измеряются милли-
ардами долларов, которые соответственно теряют корпорации и
честные каптруженики.
Тестирование безопасности — это множество вещей, суть кото-
рых заключается в том, чтобы усложнить условия для кражи —
кражи данных, денег и информации.
Например, в одной из систем интернет-платежей есть специальный
отдел, который профессионально занимается взламыванием... своего
же веб-сайта и получает премии за каждую найденную ошибку в сис-
теме обеспечения безопасности.
ТЕСТИРОВАНИЕ ОПЫТА ПОЛЬЗОВАТЕЛЯ
(usability testing)
Призвано объективно оценить опыт пользователя (user experience),
который будет работать с разрабатываемым интерфейсом.
Каждый из нас иногда ломает голову над тем, как исполнить же-
лаемое на том или ином сайте. Поясню.
Допустим, вы идете на сайт сети пиццерий и хотите найти
пиццерию, ближайшую к вашему дому. Если интерфейс сделан с
заботой об опыте пользователя (user friendly interface), то мы
быстро найдем вверху (header) и/или внизу (footer) страницы
хорошо заметный линк "restaurant locator" либо "store locator"
(месторасположение ресторана).
Вопрос: почему такой линк должен быть вверху или внизу стра-
ницы и называться именно так?
Классификация видов тестирования 155
Ответ: да потому, что это своего рода конвенция, и пользователь,
ищущий ближайшую к дому пиццерию, ожидает увидеть линк в
этих местах и с таким названием.
При юзабилити-тестировании также проверяется интуитивность
интерфейса. Я видел некоторые "гениальные" интерфейсы, кото-
рые словно были созданы с целью не допустить достижения
страницы, на которой можно оплатить товар.
Еще одним примером ужасного юзабилити является ставшее
популярным размещение, скажем, на новостных сайтах больших
мигающих баннеров справа от текста, после минуты чтения
новостей на таком сайте создается впечатление, что побывал
на угарной дискотеке.
Юзабилити-тестирование часто проводится путем привлечения
группы потенциальных пользователей с целью собрать впечатле-
ния от работы с системой.
В добрые доткомовские времена, на рубеже тысячелетий пред-
ставители интернет-компаний запросто ловили на улицах Сан-
Франциско праздношатающихся разгшъдяев и платили им 50 долл.
за час работы со свежеиспеченным веб-сайтом. Those were the
Ways, my friend... Those were the days... (непереводимо).
Зачастую опыт пользователя тестируется самими продюсерами
во время написания спека и создания макетов. Есть также про-
фессиональные юзабилити-инженеры.
ТЕСТИРОВАНИЕ СОВМЕСТИМОСТИ
(compatibility testing)
Это проверка того, как наш веб-сайт взаимодействует с
• "железом" (например, модемами) и
• ПО (браузерами/операционными системами) наших поль-
зователей.
Пример
МНОГО лет назад, когда Netscape Navigator все еще использовался, а
Виндоуз была еще в 98 версии, мы нашли такой баг:
"Краткое описание:
"Проблема совместимости: Win'98 перезагружается при входе в
систему с Netscape Navigator версии Х.Х"
156 Тестирование Дот Ком. Часть 2
Описание и шаги для воспроизведения проблемы:
1. Открой www.main.testshop.rs с помощью Netscape Navigator вер-
сии Х.Х, установленной на Win'98 (можно использовать машину
из тест-лаборатории).
2. Введи "rsavin-testuser11@testshop.rs" в поле "Имя пользователя"
и "121212" в поле "Пароль".
3. Нажми на кнопку "Вход".
Баг: Win'98 начинает перезагружаться.
Ожидаемый результат: вход в систему.
Комментарий:
баг воспроизводится только при таком сочетании браузера и ОС".
Из примера почерпнем по крайней мере три вещи:
• при тестировании было найдено такое сочетание браузе-
ра/операционной системы, при котором существовал фа-
тальный баг, из-за которого пользователь не только не
смог бы войти в www.main.testshop.rs, но и терял бы всю
свою несохраненную работу;
• проблемы, связанные с совместимостью между веб-сайтом
и браузером/ОС, реальны и могут вести к серьезным багам;
• можно (и нужно) создать тест-лабораторию с наиболее по-
пулярными сочетаниями браузер/ОС, установленными на
компьютерах наших пользователей.
Как найти эти популярные сочетания? Очень просто — покопайтесь
в Интернете и поищите статистику о пользовании браузеров и ОС.
Что дальше? Дальше включаем компы с популярными ОС, запус-
каем на них популярные браузеры и исполняем наши тест-кейсы.
Тестирование с разными браузерами называется кросс-браузер-
тестированием (cross-browser testing).
Тестирование с разными ОС называется кросс-платформ-тести-
рованием (cross-platform testing).
Примером тестирования совместимости вашего сайта и "железа" явля-
ется ситуация, когда полноценное пользование вашим сайтом возможно
только при наличии видеокарты определенного типа, например поддер-
живающей технологию DirectX версии Х.Х. Здесь мы можем, например,
протестировать, каков будет опыт пользователя, если у того на машине
установлена устаревшая и неподдерживаемая видеокарта (кстати, такое
тестирование будет называться негативным, но об этом позднее).
За исключением тех случаев, когда тест-кейсы специально созда-
ны для тестирования совместимости, я не рекомендую указывать
Классификация видов тестирования 157
в них детали, например, по типу и версии браузера, так как типы
и особенно версии меняются. Как мы помним, излишняя детали-
зация приводит к трате времени на поддержание тест-кейсов.
3. По субъекту тестирования
• альфа-тестировщик (alpha tester);
• бета-тестировщик (beta tester).
АЛЬФА-ТЕСТИРОВЩИК (alpha tester)
Это сотрудники компании, которые профессионально или непро-
фессионально проводят тестирование: тестировщики, програм-
мисты, продюсеры, бухгалтеры, сисадмины, секретарши. В стар-
тапах накануне релиза нередко все работники, включая Харито-
ныча, сидят по 16 часов кряду, пытаясь найти непойманные баги.
БЕТА-ТЕСТИРОВЩИК (beta tester)
Это нередко баловень судьбы, который не является сотрудником
компании и которому посчастливилось пользоваться новой сис-
темой до того, как она станет доступна всем остальным. За бета-
тестирование иногда даже платят деньги (вспомните пример с 50
долл. в час за юзабилити-тестирование).
4. По времени проведения тестирования
ДО передачи пользователю — альфа-тестирование (alpha
testing):
• тест приемки (smoke test, sanity test или confidence test);
• тестирования новых функциональностей (new feature
testing);
• регрессивное тестирование (regression testing);
• тест сдачи (acceptance или certification test),
ПОСЛЕ передачи пользователю — бета-тестирование (beta
testing)
О "До передачи пользователю — альфа-тестирование (alpha testing)"
мы еще поговорим.
О "После передачи пользователю — бета-тестирование (beta testing)"
уже говорили.
158 Тестирование Дот Ком. Часть 2
5. По критерию
"позитивности" сценариев
• позитивное тестирование (positive testing);
• негативное тестирование (negative testing).
Начнем со второго.
Пример
Допустим, что имя файла с банковскими транзакциями должно иметь
определенный формат:
bofa_< YYYYMMDD>_ach. txt,
где YYYY — это год в полном формате (2005), ММ — это месяц в полном
формате (01 — январь), DD — это день в полном формате (01 — первое
число месяца).
Этот файл служит в качестве ввода для программы process transactions,
которая ежедневно в 23:00
автоматически "забирает" его из директории /tmp/input_files/, анализирует (parse) его и вставляет данные из него в базу данных.
Предположим, что из-за ошибки кода, генерирующего файл, имя фай-
ла от 18 января 2004 г. будет не
• bofa_20040t18_ach.txt (processtransactions ожидает именно и
буквально это имя), а
• bofa_2004118_ach.txt.
Какая реакция должна быть у программы process_transactions, если
она не может найти файл?
Ответ на этот вопрос может быть найден в спеке, где, например, может
быть указано, что в ситуации, когда файл не найден, process_ transactions
посылает соответствующему дистрибутивному списку е-мейл:
• с предметом (e-mail subject) "Ошибка: файл ввода для process
transactions отсутствует" и
• содержанием (e-mail body) "Файл bofa_20040118_ach.txt
отсутствует в директории /tmp/input_files/".
Если спек не предусматривает возможности возникновения такой си-
туации, то мы как тестировщики должны ее предусмотреть и создать
тест-кейс с соответствующим сценарием.
Итак, сценарий, проверяющий ситуацию, связанную с
• потенциальной ошибкой (error) пользователя и/или
• потенциальным дефектом (failure) в системе,
называется негативным.
Классификация видов тестирования 159
Пример ошибки пользователя
ВВОД недействительных данных в поле "Имя" на странице регистрации.
Пример дефекта в системе
Вышеуказанный пример о неправильной генерации имени файла.
Создание и исполнение тест-кейсов с негативными сценариями
называется НЕГАТИВНЫМ тестированием.
Далее.
Позитивные сценарии — это сценарии, предполагающие нор-
мальное, "правильное"
• использование и/или
• работу системы.
Первый пример позитивного сценария
Ввод действительных данных в поле "Имя" на странице регистрации.
Второй пример позитивного сценария
Проверка работы системы, когда имя файла имеет правильный фор-
мат: bofa_20040l 18_ach.txt.
Создание и исполнение тест-кейсов с позитивными сценариями
называется ПОЗИТИВНЫМ тестированием.
Несколько мыслей вдогонку:
а. Как правило, негативное тестирование находит больше
багов.
б. Как правило, негативное тестирование — вещь более слож
ная, творческая и трудоемкая, так как спеки описывают,
как должно работать, когда "усе в порядке", а не как долж
но работать в ситуациях с ошибками или сбоями.
в. Если есть позитивные и негативные тесты как часть тест-
комплекта, то позитивные тесты исполняются в первую
очередь. Логика:
В большинстве случаев целью создания функционачьности
является возможность реализации именно позитивных
сценариев, т.е. работоспособность позитивных сценариев
более приоритетна, чем работоспособность негативных
сценариев.
г. Существуют спеки, полностью посвященные тому, как долж
на себя вести система при ошибках/дефектах. Следователь
но, все тестирование такого спека будет негативным.
160 Тестирование Дот Ком. Часть 2
д. Два полезных термина:
• обращение с ошибкой/дефектом (error handling /failure
handling) — это то, как система реагирует на ошиб-
ку/дефект;
• сообщение об ошибке (error message) — это информа-
ция (как правило, текстовая), которая выдается пользо-
вателю в случае ошибки/сбоя.
Маленький примерчик вдогонку
Правильность сообщений об ошибке является намного более серьез-
ной вещью, чем может показаться, при рассуждениях об этом в теории.
Например, сегодня я попытался купить по Интернету новую книгу Хару-
ки Мураками:
• добавил книгу в корзину на одном из сайтов,
• вбил номер кредитки в соответствующие поля веб-страницы и
• нажал кнопку "Купить".
Мне выдается сообщение об ошибке: так, мол, и так, проверьте, пожа-
луйста, номер своей кредитной карты, дорогой пользователь. Я про-
веряю — все в порядке: и номер карты, и срок действия. Нажимаю
"Купить" еще раз — го же сообщение об ошибке. Пробую вбить инфор-
мацию по другой карте — то же самое. Начиная с этого момента,
успешное осуществление акции покупки новой книги Харуки Мура-
ками стало для меня делом принципа. Звоню в службу поддержки, и
мне говорят
— А вы, кстати, поставили галочку в чек-бокс (check box), что
согласны
с нашим соглашением? -Нет. —А вы поставьте и попробуйте нажать на кнопку "Купить".
—Ставлю, пробую, работает.
—Ну вот и славненько. Чем-нибудь еще можем быть полезны?
—Ничем. Thank you.
В итоге я потерял 15 минут своего времени, а веб-сайт потерял меня
как пользователя, так как "ложечки нашлись, а осадок остался". Все
из-за неверного сообщения об ошибке.
6. По степени изолированности
тестируемых компонентов
• компонентное тестирование (component testing);
• интеграционное тестирование (integration testing);
• системное (или энд-ту-энд) тестирование (system or
end-to-end testing).
Сначала краткие и емкие определения, а затем иллюстрации.
Классификация видов тестирования 161
Компонентное тестирование (component testing) — это тестиро-
вание на уровне логического компонента. И это тестирование
самого логического компонента.
Интеграционное тестирование (integration testing) — это тести-
рование на уровне двух или больше компонентов. И это тестиро-
вание взаимодействия этих двух или больше компонентов.
Системное (или энд-ту-энд) тестирование (system or end-to-end
testing) — это проверка всей системы от начала до конца.
Теперь иллюстрации кратких и емких определений.
Допустим, программисту поставлена задача написать код, который
бы находил полные имена и е-мейлы пользователей, потра-
тивших больше 1000 долл. в нашем онлайн-магазине с момента
регистрации. Таким пользователям должен быть отправлен е-мейл
с подарочным сертификатом, использование которого до 17 но-
ября включительно предоставит 5%-ю скидку на любую разовую
покупку.
Кстати, для добротного тестирования данной функциональности нужно
написать гораздо больше тест-кейсов, чем я приведу, но сейчас наша
задача — это понять
суть каждого из трех рассматриваемых видов тестирования и
разницу между ними.
КОМПОНЕНТНОЕ ТЕСТИРОВАНИЕ
Для начала выделим три компонента, которые мы протестиро-
вали бы:
1. Создание файла с полными именами, е-мейлами и номера-
ми сертификатов.
2. Рассылка пользователям е-мейлов.
3. Правильное предоставление скидки вышеуказанным поль-
зователям.
Проверяем.
Компонент 1
Проверяем, что создается файл нужного формата
• с полными именами и е-мейлами пользователей, потратив-
ших > 1000 долл., и
• номером сертификата для каждого из этих пользователей.
162 Тестирование Дот Ком. Часть 2
Это позитивное тестирование.
Мы также должны проверить, не затесались ли в наш файл
пользователи, потратившие < 1000 долл.
Это негативное тестирование, связанное с потенциальным дефек-
том в коде, отвечающем за выбор правильных пользователей.
Компонент 2
Допустим, код первого компонента, который должен был создать
для нас файл, не работает. Мы не отчаиваемся, а просто вручную,
не ропща на судьбу, создаем файл установленного формата с взя-
тыми с потолка
• е-мейлами,
• полными именами пользователей и
• номерами подарочных сертификатов.
Этот файл мы "скармливаем" программе рассылки е-мейлов и
проверяем, что правильные е-мейлы доходят до пользователей из
файла(позитивное тестирование).
Компонент 3
Как мы помним, компонент 1 не работает. Что делать?
Сертификат — это как некий код, например "UYTU764587657".
который нужно ввести во время оплаты, и если сертификат дей-
ствительный, то итоговая сумма к оплате уменьшается.
В данном случае можно попросить программиста, чтобы тот по-
мог сгенерировать легитимные номера сертификатов. Когда но-
мера сертификатов имеются в наличии, можно, например, прове-
рить, работает ли подарочный сертификат только один раз (пози-
тивное тестирование) или его можно использовать для двух или
более транзакций (негативное тестирование, воспроизводящее
ошибку пользователя, использующего сертификат более одного
раза). Также нужно будет проверить размер скидки (5%) (пози-
тивное тестирование) и действительность сертификата:
до 17 ноября (позитивное тестирование), 17
ноября (позитивное тестирование) и
после 17 ноября (негативное тестирование, воспроизводящее
ошибку пользователя, использующего просроченный сер-
тификат).
Классификация видов тестирования 163
Кстати, в случаях когда тестирование связано со сроками (например,
сроком истечения сертификата), мы, естественно, не ждем до 17 но-
ября, а просто меняем системное время тест-машины на нужное время
или меняем значение времени в базе данных. Естественно, что такие
изменения вы должны предварительно согласовать с коллегами, кото-
рые работают на той же тест-машине или с той же базой данных.
Важный момент: хотя по спеку все три компонента и взаимосвя-
заны, из-за проблем в коде у нас получилось компонентное тес-
тирование в чистом виде. Другими словами, мы тестировали са-
ми компоненты, а не связь между ними.
Тестирование связи между компонентами называется интегра-
ционным тестированием.
ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ
У нас есть три связи между компонентами:
а) между 1-м и 2-м компонентами;
б) между 2-м и 3-м компонентами;
в) между 1-м и 3-м компонентами.
Подробности:
а. Компонент 1 генерирует файл со списком
• е-мейлов и полных имен подходящих пользователей и
• номерами сертификатов.
Этот список используется компонентом 2, который ответ-
ствен за рассылку е-мейлов.
б. Компонент 2 доставляет пользователю в качестве е-мейла
информацию о подарочном сертификате. Пользователь
может использовать сертификат (компонент 3), только ес
ли он знает правильный номер своего сертификата.
в. Компонент 1 генерирует код сертификата, который ис
пользуется компонентом 3.
Итак, в нашем случае при интеграционном тестировании у нас
есть для проверки 3 связи. Приведем примеры соответствующих
тестов на интеграцию.
а. Здесь можно проверить, совместим ли формат файла, соз-
данного компонентом 1, с программой рассылки компонента 2.
Например, последняя принимает следующий формат файла:
полное имя пользователя, е-мейл, номер сертификата.
164 Тестирование Дот Ком. Часть 2
Значения отделены друг от друга запятой (comma-delimited). Ин-
формация о каждом новом пользователе — на новой строчке.
Сам файл — простой текстовый файл, который можно открыть
программой Notepad.
Образец файла:
Ferdinando Magellano, f.magellano@trinidad.pt, QWERT98362
James Cook, james.cook@endeavour.co.uk, ASDFG54209 Иван
Крузенштерн, ikruzenstern@nadejda.ru, LKJHG61123
Допустим, программист ошибочно заложил в коде, что значения
файла разделяются не запятой (форматом, принимаемым про-
граммой рассылки), а точкой с запятой:
Ferdinando Magellano; f.magellano@trinidad.pt; QWERT98362
James Cook; james.cook@endeavour.co.uk; ASDFG54209 Иван
Крузенштерн; ikruzenstern@nadejda.ru; LKJHG61123
Когда мы проводим интеграционный тест, мы обнаруживаем, что
программа рассылки не принимает файл неподходящего формата,
и соответственно никакие е-мейлы до пользователей не дойдут,
если этот баг не будет устранен.
б. В данном случае у нас может быть ситуация, когда файл
имеет верный номер сертификата, но из-за бага в программе рас
сылки пользователь получает е-мейл с "неправильным" номером
сертификата.
Это может произойти из-за того, что программа рассылки
может быть ошибочно сконфигурирована, чтобы "брать"
только 9 первых символов из третьей колонки (колонки с номе-
рами сертификатов), т.е. QWERT98362 будет преподнесена поль-
зователю в укороченном виде (truncated): QWERT9836.
Интеграционный тест по использованию номера сертификата,
полученного по е-мейлу, может выявить этот баг.
в. Здесь может быть ситуация, когда номер сертификата, сгене
рированный компонентом 1, не принимается компонентом 3.
Пример такой ситуации
Компонент 1 сохранил номер сертификата в базе данных в зашифро-
ванном виде, т.е. в целях безопасности использовался алгоритм, кото-
рый превратил "LKJHG61123", например, в "*&"(*&86%(987$!$#". Из-за
бага в компоненте 3 последний не дешифровал номер сертификата,
Классификация видов тестирования 165
ВЗЯТЫЙ из БД, а просто попытался сравнить эту абракадабру из БД и
номер сертификата, введенный пользователем, что привело к тому,
что номера не сошлись и легитимная скидка не была предоставлена.
Должен ли был быть номер сертификата зашифрован или нет, для
нас сейчас значения не имеет. Значение имеет тот факт, что баг
был обнаружен во время интеграционного тестирования.
СИСТЕМНОЕ ТЕСТИРОВАНИЕ
Это тестирование системы (функциональности) от начала до
конца (end-to-end), т.е. каждый сценарий будет затрагивать всю
цепочку: компонент 1 —> компонент 2 —> компонент 3.
Я рекомендую ставить простой тест-кейс с системным тестом
в самое начало тест-комплекта. Так можно сразу увидеть, если
что-то явно не в порядке. Это своего рода тест приемки непосред-
ственно для вещи, тестируемой данным тест-комплектом.
Хорошая идея вдогонку
Е-мейл состоит из следующих частей:
е-мейла алиаса;
собаки; домена почтового сервера; точки; глобального домена.
В вашем рабочем е-мейле алиасом будет, как правило, ваши имя (или
инициал) и фамилия: rsavin.
Собака остается собакой, хотя по-аглицки она называется "at" (читает-
ся как "эт"):
@ Доменом почтового сервера будет домен
компании:
testshop
Точка остается точкой, хотя по-аглицки она называется "dot" (читается
как "дот"):
.
Глобальный домен — это зона домена компании, например "com" или "ги":
rs,
т.е. получаем: rsavin@testshop.rs
При тестировании интернет-проектов приходится создавать много сче-
тов пользователей. Загвоздка в том, что е-мейл пользователя, который
очень часто является его именем, может быть использован только один
раз, т.е. мой рабочий е-мейл rsavin@testshop.rs может быть использо-
ван для создания только одного счета.
166 Тестирование Дот Ком. Часть 2
ЧТО делать? Открывать бесчисленные счета на хотмейлах и яху? Ответ
неверный.
Самая хорошая идея: поговорите с администратором почтового сер-
вера вашей компании, чтобы он модифицировал настройки сервера
так, чтобы к вам приходили все е-мейлы следующего формата:
rsavin+sometext@testshop. rs,
т. е. после моего алиаса стоит знак плюс и между знаком плюс и соба-
кой находятся любые легитимные знаки.
Например, для тестирования компонента 1 я регистрируюсь с е-мейлом:
rsavin+component1_test@testshop.rs
Таким образом, вы можете создавать тысячи эккаунтов пользователей
своего сайта, не регистрируя тысяч новых е-мейл-эккаунтов.
Рекомендую. Очень удобно.
7. По степени автоматизированное™
тестирования
• ручное тестирование (manual testing);
• автоматизированное тестирование (automated testing);
• смешанное / полуавтоматизированное тестирование
(semi automated testing).
О каждом из трех "друзей" будет еще сказано очень много и в
подробностях. Пока же давайте поговорим концептуально.
РУЧНОЕ ТЕСТИРОВАНИЕ
Это исполнение тест-кейсов без помощи каких-либо программ,
автоматизирующих вашу работу. Например, для того чтобы
создать эккаунт нового пользователя, мы идем на наш
www.main.testshop.rs, открываем страницу регистрации, запол-
няем формы и т.д.
АВТОМАТИЗИРОВАННОЕ ТЕСТИРОВАНИЕ
Это отдельная дисциплина искусства тестирования. Значительная
часть эффективности работы отдела тестирования зависит от
того, какие задачи отданы для автоматизации и как эта автома-
тизация была осуществлена. Автоматизация может как принести
огромное облегчение всем тестировщикам, так и завалить работу
всего отдела и отложить релиз, премию, отпуск и другие сладкие
вещи.
Классификация видов тестирования 167
Оговорка
Термин "тул" (tool (англ.) — инструмент) используется для обозначения
компьютерной программы, как правило, вспомогательного свойства.
Автоматизировать можно сотни вещей. Вот наиболее часто
встречающиеся виды автоматизации:
а. Тулы для помощи в черноящичном и сероящичном тес-
тировании.
Например,
• тул, который автоматически создает для нас эккаунт поль-
зователя;
• тул, совершающий запросы к базе данных и генерирующий
файлы формата, утвержденного системой VISA, используя
извлеченные данные;
• тул, генерирующий транзакции покупки в нашем магазине,
и т.д. и т.п.
Вариантам нет конца и края. Такие тулы пишутся программиста-
ми компании или самими тестировщиками.
Пример тула, создающего эккаунты пользователя
Если набрать в браузере www.main.testshop.rs/tools/register.py (это
все, естественно, гипотетически, так как такого сайта в природе не су-
ществует), то мы увидим не 10 обязательных полей, которые нужно за-
полнить, а одно текстовое поле и кнопку "создать тест-эккаунт". Вы
просто вводите уникальный е-мейл нового пользователя, например
rsavin-testuser1000@testshop.rs, и нажимаете на кнопку. Тул делает за
вас все остальное. Пароль для всех эккаунтов будет, например "898989".
Хорошая идея:
используется автоматизация для создания новых эккаунтов или
нет, очень удобно, когда в компании существует конвенция для
одного пароля при создании тест-эккаунтов, например "898989".
Дело в том, что иногда нет времени/возможности создать эккаунт
с определенными транзакциями, настройками и т.д., и если такой
эккаунт уже существует, то, зная пароль, вы сможете им воспользо-
ваться.
При этом помните о деловой этике, и если этот эккаунт создан не вами,
то по возможности вежливо спросите у "хозяина" эккаунта разрешение.
б. Программы для регрессивного тестирования
Это специальное ПО, созданное для буквального воспроизведе-
ния действий тестировщика.
168 Тестирование Дот Ком. Часть 2
Пример
Согласно тест-кейсу вы должны
• войти в систему,
• выбрать товар,
• положить его в корзину,
• заплатить и
• удостовериться, что баланс на кредитной карте уменьшился на
сумму покупки.
Чтобы исполнить этот тест-кейс, вы должны запустить браузер, ввести
имя пользователя и пароль, нажать на кнопку "Вход"... и, в конце кон-
цов, сравнить фактический и ожидаемый результаты.
Теперь представьте себе, что некая программа делает те же самые
действия, что и вы, т.е. сама запускает браузер, печатает, где положе-
но, имя пользователя и пароль, нажимает на кнопку "Вход"... и, в конце
концов, сравнивает ожидаемый и фактический результат и сообщает
вам о нем (через сообщение на экране, запись в файле, е-мейл и т.д.).
Такое ПО, как правило, поддерживает режим "Запись / Воспроиз-
ведение", т.е. когда мы нажимаем на кнопку "Запись" и начинаем
кликать мышками и клацать клавишами клавиатуры, ПО записы-
вает наши действия и, когда мы закончили, генерирует код. Этот
код мы можем запустить с этим же ПО, и оно воспроизведет все
наши клики и клацы, т.е. буквально будет водить курсором мыш-
ки, набирать текст и т.д.
Такое ПО, как правило, имеет собственный язык программиро-
вания, т.е. можно не записывать свои действия, а непосредст-
венно написать код, что и делается теми, кто профессионально
работает с таким ПО.
Наиболее популярная и мощная программа для автоматизации
регрессивного тестирования веб-проектов — это Silk Test, выпус-
каемый компанией Segue.
У нас будет отдельная беседа о хороших и плохих вещах, связан-
ных с автоматизацией регрессивного тестирования.
в. Программы для тестирования скорости и надежности
О таком ПО мы уже говорили. И так как stress/load/performance
testing — это песня не нашего черно-сероящичного репертуара,
петь, т.е. говорить, о них больше не будем.
г. Прочие программы
Это, например, "Проверяльщики линков" (link checkers).
Классификация видов тестирования 169
СМЕШАННОЕ/ПОЛУАВТОМАТИЗИРОВАННОЕ
ТЕСТИРОВАНИЕ
Здесь ручной подход сочетается с автоматизированным. Напри-
мер, с помощью тула я создаю новый эккаунт и потом вручную
генерирую транзакцию покупки.
8. По степени подготовки к тестированию
• тестирование по тест-кейсам (documented testing);
• интуитивное тестирование (ad hoc testing).
Здесь все просто. Есть тестирование по тест-кейсам, а есть тести-
рование ad hoc (лат. — для этой цели, читается как "эд-хок"), т.е.
мы просто интуитивно роемся в ПО, пытаясь найти баги. Интуи-
тивное тестирование, как правило, применятся:
• тестировщиком в качестве теста приемки и/или теста сдачи
(если тест-кейсы для них не формализованы в документации);
• тестировщиком в качестве успокаивающего для сердца в
довесок к документированным тестированию новых функ-
циональностей и регрессивному тестированию;
• тестировщиком, который только что пришел в компанию,
где код уже написан и нужно срочно все протестировать;
• когда бухгалтерия и менеджмент протягивают тестиров-
щикам руку помощи перед релизом;
• в других случаях, когда нет тест-кейсов.
Нужно отметить, что эд хок-тестирование часто дает поразитель-
ные результаты: бывает, исполняешь только что пришедшие в
голову сценарии, которые и не снились при подготовке к тестиро-
ванию, и находишь дородные, розовощекие и ухмыляющиеся баги.
Краткое подведение итогов
1. Мы классифицировали основные виды тестирования в интернет-
компаниях.
2. Мы узнали о трех основных подходах к тестированию: "Черный
ящик", "Белый ящик" и "Серый ящик". Водораздел между ними
лежит в плоскостях степени знания о внутренностях системы и
ориентированности на надежды и чаяния конечного пользователя.
3. Мы узнали, что паттерн поведения пользователя составляют
сценарии и данные для них (хотя мы стали все это вместе на-
зывать сценариями).
170 Тестирование Дот Ком. Часть 2
4. Мы узнали об основных источниках знания о потенциальных
паттернах поведения пользователей.
5. Мы узнали концепцию тестировочного покрытия.
6. Мы узнали, что количественное и качественное тестирование
обеспечивается путем слияния в оргазме черноящичных и бело-
ящичных методик тестирования.
7. Мы узнали, что мало быть хорошим человеком. Надо еще по-
нимать, какой ожидаемый вывод является тем самым ожидае-
мым результатом, который приведет нас к реальному тести-
рованию.
8. Мы поняли разницу между тестированием интерфейса поль-
зователя и тестированием с помощью интерфейса пользо-
вателя.
9. Мы удивились, узнав, что код, прекрасно работающий функ-
ционально, может привести к сбою в работе веб-сайта (про-
блемы перформанса).
10. Мы прочувствовали, что несовместимость — это проблема не
только человеческих отношений, но и отношений нашего сайта с
"железом" и ПО пользователя.
11. Мы запомнили, что, как правило, позитивные тесты исполняются
в первую очередь.
12. Мы прошли шаг за шагом от компонентного до системного тес-
тирования.
13. Мы разобрались в видах автоматизации.
14. Мы отметили, что интуитивное (эд хок) тестирование иногда
приносит превосходные результаты.
Задание для самопроверки
Приведите, пожалуйста, классификацию видов тестирования с оп-
ределением каждого из них.
ЧАСТЬ 3
ПОДГОТОВКА К ТЕСТИРОВАНИЮ
• НИГИЛИСТИЧЕСКИЙ НАСТРОЙ
И ПРАКТИЧЕСКАЯ МЕТОДОЛОГИЯ
ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ
• ЖИЗНЬ ЗАМЕЧАТЕЛЬНЫХ БАГОВ
• ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ.
СТАДИЯ 1: ТЕСТИРОВАНИЕ НОВЫХ ФИЧА
(New Feature Testing)
• ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ.
СТАДИЯ 2: РЕГРЕССИВНОЕ ТЕСТИРОВАНИЕ
(Regression Testing)
ПОДГОТОВКА К ТЕСТИРОВАНИЮ
НИГИЛИСТИЧЕСКИЙ НАСТРОЙ И
ПРАКТИЧЕСКАЯ МЕТОДОЛОГИЯ
• МЕНТАЛЬНЫЙ НАСТРОЙ ТЕСТИРОВЩИКА
• МЕТОДЫ ГЕНЕРИРОВАНИЯ ТЕСТОВ
• МЕТОДЫ ОТБОРА ТЕСТОВ
П
одготовка к тестированию с точки зрения тестировщика
включает:
1. Написание новых тест-кейсов и/или
2. Изменение существующих тест-кейсов и/или
3. Удаление существующих тест-кейсов.
Иногда требуется создание/модификация тест-тулов, но об этом
мы здесь говорить не будем, так как фактически тест-тулы — это
чистой воды программирование, облегчающее исполнение тест-кейсов.
Кстати, дни начала и завершения ПОДГОТОВКИ к тестированию указаны в
расписании тестирования (test schedule), которое является публичной (в
пределах компании) информацией. Таким образом, тестиров-щик может
рассчитывать свои силы, т.е. уходить с работы в 4 дня или 4 утра в
зависимости от достигнутого им прогресса.
Постановка мозгов
Многие вещи, о которых мы будем говорить, могут показаться теоретиче-
ски простыми, но пусть эта псевдопростота не вводит вас в заблуждение.
Приведем аналогию с шахматами. Взрослому человеку нужно 5 минут, чтобы
запомнить правила (как ходят/бьют пешки и фигуры, правила рокировки и
пр.), а для того чтобы стать мастером игры, нужны сотни сыгранных партий.
То же самое и с методами тестирования: понять базовые элементы и
концепции особого труда не составит. Для того же, чтобы стать эффек-
тивным профессионалом, понадобятся месяцы и годы практического
применения этих элементов и концепций на реальном ПО.
173
174 Тестирование Дот Ком. Часть 3
Для тестировщика подготовка к тестированию — это наибо-
лее сложный, творческий и интересный процесс.
Венцом этого процесса являются тест-кейсы, которые после их
исполнения на стадии "Исполнение тестирования" смогли бы
превентировать встречу пользователей и багов.
Мы — ловцы. И тест-кейсы — это сеть, которую мы
• плетем (подготовка к тестированию) и
• используем (исполнение тестирования).
Как мы помним, тест-кейс содержательно состоит по крайней мере
из ожидаемого результата, но, как правило, это комбинация:
• идеи тест-кейса,
• сценария и
• ожидаемого результата.
И те, и другие, и третьи можно почерпнуть из множества источ-
ников:
• спеков,
• опыта,
• эксплоринга,
• общения,
• интуиции и
• других кладезей информации.
Вопрос: что отличает тестировщиков от других участников про-
цесса разработки ПО, которые тоже могут придумать тест-кейсы,
основываясь на спеках, опыте, эксплоринге и т.д.? Ответ:
отличают нас две профессиональные вещи:
• ментальный настрой;
• инструментарий, т.е. прикладные знания.
Сначала о ментальном настрое замолвим мы слово.
Ментальный настрой тестировщика
Помните наблюдение, что, попадая в лес,
• плотник видит доски,
• художник — пейзажи, а
• биолог — материал для диссертации?
Нигилистический настрой и практическая методология 175
Так вот,
• для пользователя код — это инструмент для выполнения
каких-либо неотложных задач (например, покупки устрой-
ства для подзаводки автоматических часов);
• для продюсера — реализация гениальных идей менедж-
мента, увековеченных в спеке;
• для программиста — кусок хлеба с черной икрой;
• для тестировщика код — это убежище багов.
Постулат "Software has bugs" ("ПО содержит баги") — это не
выдумка лицемеров и лжесвидетелей, а вселенский закон, кор-
мящий тестировщиков, а следовательно, и их жен, детей, говоря-
щих попугаев и лысых кошек. Не будем же лишать наших домо-
чадцев лакомого куска и раскроем свое сердце истинной сути ве-
щей, заключающейся в том, что ПО своей природе — это баго-
содержащее и неблагонадежное существо.
Еще раз:
код — это убежище багов.
Итак, навесив ярлыки, идем дальше...
Как известно, ищущий да обрящет (из этого не следует, что не
ищущий не сможет обрести. Однако логичнее предположить, что
именно тот, кто ищет, найдет больше. По крайней мере, как
правило...).
Тестирование — это ПОИСК багов.
"ПОИСК" — это ключевое слово, точно раскрывающее смысл
нашей профессии, которая принципиально требует от нас, как и
от сыщиков, и прикладных знаний, и интуиции, и ментальных
установок.
Постановка мозгов
Концепция "поиска багов" как пути, по которому идет тестировщик для
превентирования свидания пользователя и багов, начисто отметает
идею о том, что тестировщик, подобно ОТК (отдел технического кон-
троля в СССР), сертифицирует продукт на качество и ставит штамп
"Проверено, багов нет". Ничего мы не сертифицируем, да и штампов
у нас нет, кроме тех самых... в паспорте...
Еще раз: основа работы тестировщика — это поиск багов.
Тестировщик не занимается поиском доказательств того, что ПО
работает.
176 Тестирование Дот Ком. Часть 3
Мы должны настроить себя на поиск багов в коде, который
является убежищем этих самых багов. Nice and simple.
Основой такого настроя — ментального настроя тестировщи-
ка — является деструктивное мышление, полное подозритель-
ности, недоверия и априорного отрицания даже потенциаль-
ного наличия добродетелей — все в отношении ПО. Мы долж-
ны твердо верить в то, что "был бы код, а баги найдутся".
Пытливый ум внимательного слушателя сразу же сгенерирует
вопрос, на который я тут же отвечу.
Вопрос: «О каком деструктивном мышлении мы можем гово-
рить, если у нас есть такое понятие, как "позитивное тестирова-
ние", и позитивные тест-кейсы настолько важны, что мы испол-
няем их в первую очередь?»
Ответ: "Позитивное тестирование и принцип первичного испол-
нения позитивных тест-кейсов — это технический аспект. Де-
структивность в мышлении — это аспект ментальный. Даже если
мы создаем тест-кейс с позитивным сценарием, мы должны ис-
кать способ, чтобы обнаружить баги".
Дорогие друзья! Взращивайте и лелейте в себе неисправимый пес-
симизм в отношении идеи о коде, свободном от багов.
Смотрите на код как на виртуальную вещь, которая в процессе
тестирования послужит еще одним доказательством постулата о
несовершенстве мира. Если вы настроите себя на деструктив-
ное мышление в отношении кода, то ваша интуиция вклю-
чится на всю катушку и прекрасные идеи для тест-кейсов
будут стаями роиться в ваших головах, как только вы прочи-
таете спек.
Парочка сладких десертов
— Скажите, а исполнится ли загаданное желание, если я загадаю его,
сидя между двумя программистами?
— Конечно, исполнится, но... будет глючить!
Хирург, инженер и программист сидят в баре и обсуждают, чья про-
фессия является древнейшей:
Хирург: Моя профессия является древнейшей, потому что Богу нужны были знания по хирургии, чтобы извлечь из Адама ребро.
Инженер: Но еще до этого был хаос, и, чтобы сделать мир из хаоса, Богу нужны были инженерные знания.
Программист: Ха! Кто же, как вы думаете, создал весь этот хаос?
Нигилистический настрой и практическая методология 177
Теперь, настроенные и решительные, переходим к профессио-
нальным прикладным знаниям, а именно к методологии соз-
дания тест-кейсов (testcase design methodology) (далее — мето-
дология).
В одной из прошлых бесед мы говорили
о первой части методологии — формальной стороне построе-
ния тест-кейса.
Сегодня же речь пойдет
о второй ее части — содержательной стороне тест-кейса.
Искусство создания содержательной части тест-кейсов заключа-
ется в нахождении тех "золотых"
• идей тест-кейсов,
• сценариев и
• ожидаемых результатов,
которые при исполнении тестирования помогли бы обнару-
жить больные, багосодержащие места тестируемого ПО.
Какие два этапа составляют процесс, называемый "выбор"?
1. Сначала нам нужно увидеть, что имеется в наличии.
2. Затем, используя некий критерий (-ии), мы выбираем или
не выбираем.
Например, выбирая щенка,
1) мы должны увидеть одного или больше щенков (что имеется в на-
личии) и затем
2) посмотреть, как весело он (они) бегает, как блестят его глазенки
и пр. И посмотрев, решить — брать или не брать.
Подход к выбору сценариев концептуально схож:
1. Что имеется в наличии, мы видим после использования
методов генерирования тестов (methods of test generation);
2. Орудиями отбора являются методы отбора тестов (test selection
criterion).
Развертываем:
Методы генерирования тестов:
1. Черновик-чистовик (dirty list-white list);
2. Матричная раскладка (matrices);
3. Блок-схемы (flowchart).
178 Тестирование Дот Ком. Часть 3
Методы отбора тестов:
1. Оценка риска (risk estimate);
2. Эквивалентные классы (equivalent classes);
3. Пограничные значения (boundary values).
Методы генерирования тестов
1. Черновик-чистовик (dirty list-white list).
2. Матричная раскладка (matrices).
3. Блок-схемы (flowchart).
1. "ЧЕРНОВИК-ЧИСТОВИК"
Это самый простой и практичный метод. Суть проста. Два этапа:
а. Черновик (dirty list)
В процессе (и/или после) прочтения спека, эксплоринга ПО и/или
получения информации о ПО другим способом, не анализируя и
отдавшись вдохновению и фантазии, мы просто набрасываем на
лист бумаги (или в файл Ворда), являющийся черновиком (dirty
list), ВСЕ идеи, связанные с тестированием, которые только могут
прийти в голову, — идеи в самом широком смысле этого слова,
включая идеи для тест-кейсов, сценарии, отдельные элементы
сценариев (шаги и/или данные), ожидаемые результаты, вопросы
для выяснения у продюсера и пр.
Еще раз: ВСЕ идеи — даже самые на первый взгляд далекие от
здравого смысла. Локальный мозговой штурм.
б. Чистовик (white list)
Затем мы начинаем анализировать написанное (и, если нужно,
получать ответы на вопросы) и переносим на чистовик вещи,
имеющие право на жизнь. Право на жизнь определяется на осно-
вании информации из спека, общения, интуиции, критериев от-
бора тестов, разговора с программистом и пр. При переносе на
чистовик мы также уточняем наши идеи и группируем их (на-
пример, по позитивности и негативности; по функциональным
направлениям и т.п.). Таким образом, как правило, первый чисто-
вик превращается во второй черновик, и мы берем следующий
лист бумаги и, надеясь, что он будет чистовиком, начинаем пере-
Нигилистический настрой и практическая методология 179
носить на него наши идеи и т.д. В итоге в один из светлых май-
ских дней мы все-таки получаем чистовик. На основании мате-
риала из чистовика мы пишем тест-кейсы.
Сейчас рекомендую вам немедленно взять ручку, лист бумаги и
потратить 15 минут на генерацию черновика по тестированию
автомата для продажи банок с колой (любимый тест рекрутеров
из "Майкрософта"). Начинаем:
• Проверить, что покупателю выдается именно та банка, ко-
торую он хочет.
• А что, если покупатель нажмет на кнопку два раза?
• А что, если покупатель попробует наклонить аппарат, что-
бы банки посыпались как из рога изобилия?
• Проверить, что правильно выдается сдача.
• Какая реакция на монетку иностранного государства?
• И т.д. и т.п.
После того как черновик готов, потратьте 15 минут на составле-
ние чистовика и затем 30 минут на составление тест-кейсов по
полной форме:
• идея,
• сценарий (шаги и данные) и
• ожидаемый результат.
Ручаюсь, что этот час окупится сторицей, чем бы вы ни занима-
лись в жизни, и вы ни разу не пожалеете, что потратили 60 минут
времени на подобный тренинг.
2. МАТРИЧНАЯ РАСКЛАДКА
Давайте без прелюдий и патетики перейдем к примеру.
Украдем макет первой страницы регистрации из цикла разра-
ботки ПО:
Сделаем матричную раскладку.
180 Тестирование Дот Ком. Часть 3
Этап 1. Набросок элементов (табл. 1)
Таблица 1
Набросок элементов
Индекс
Индекс_эл_001
Индекс_эл_002
Индекс_эл_003
Индекс_эл_004
Индекс_эл_005
Индекс_эл_00б
Индекс_эл_007
Индекс_эл_008
Индекс_эл_009
Индекс_эл_010
Индекс введен?
да X
нет X
Индекс действующий?
Да X
нет X
Значения индекса
6 цифр X
5 цифр X
7 цифр X
Включает буквы X
Включает специальные
символы (например, &)
X
Включает пробелы X
Таким образом, у нас получилось 3 подгруппы:
1. "Индекс введен?"
2. "Индекс действующий?" (существует ли адрес с таким ин-
дексом в Российской Федерации?)
3. "Значения индекса".
Каждый из элементов имеет свой уникальный ID, например, эле-
мент, когда пользователь вводит в поле индекса 6 цифр, мы обозна-
чили как Индекс_эл_005 (элемент номер 005 страницы с индексом).
Буквенная часть ID (Индекс_эл) — это вещь произвольная. Про-
сто мне кажется, что для разбираемого примера это название
интуитивно и логично.
Прошу заметить, что мы набросали элементы как позитивных,
так и негативных сценариев.
Нигилистический настрой и практическая методология 181
Этап 2. Комбинация элементов (табл. 2)
Теперь мы начинаем комбинировать элементы между собой.
Таблица 2
Комбинация элементов
Индекс
Индекс_эл_001
Индекс_эл_002
Индекс_эл_003
Индекс_эл_004
Индекс_эл_005
Индекс_эл_00б
Индекс_эл_007
Индекс_эл_008
Позитивные тесты
индекс действителен, 6 цифр действую-
щего российского индекса: 119602
X
Негативные тесты
индекс недействителен, 6 цифр: 000000 X
индекс недействителен, 5 цифр: 11960 X
индекс недействителен, 7 цифр: 1196021 X
индекс недействителен, буквы: 1196о2
(буква "о" вместо нуля)
X
индекс недействителен, специальные
символы: 11(602
(символ "(" вместо девятки)
X
индекс недействителен, пробел
между цифрами: 1196 02
X
пустое место X
Как видно, мы скомбинировали элементы табл. 1 в сценарии.
У каждого из сценариев есть свой уникальный ID, например сце-
нарий, когда в поле индекса не вводится никакого значения, про-
ходит под штампом Индекс_ком_008 (комбинация номер 008 стра-
ницы с индексом).
Кстати, обратите внимание:
• в данном конкретном примере мы играем с частью сценария под
названием "данные"(варианты индекса),
• сначала расписываем позитивные, а затем негативные сценарии,
• сценарий Индекском 008 не был комбинацией элементов табл. 1,
а напрямую следовал из элемента Индекс_эл 002.
182 Тестирование Дот Ком. Часть 3
Вопрос: зачем мы присваивали уникальный ID каждому из эле-
ментов в табл. 1, если мы их не используем? Ответ: иногда в
табл. 2 вписывается не содержание элементов (как мы это
сделали), a ID. Кроме того, если у элемента есть ID, то это просто
удобно для ссылки.
Например
• при обсуждении, когда у вас и вашего коллеги есть по экземпляру
табл. 1 или
• когда я рассказываю вам о матричном методе.
Итак, у нас есть 8 сценариев для страницы, когда пользователь
должен ввести некое значение (либо пустое место) для индекса
места жительства. Мы можем сразу же, используя эти сценарии,
написать тест-кейсы. Ожидаемым результатом для всех, кроме
Индекс_ком_001, будет перезагрузка страницы с индексом с со-
общением об ошибке:
"Введите действительный российский индекс". При этом текст
"Индекс места жительства*" будет красного цвета.
Для ИндекскомОО 1 ожидаемым результатом будет следующая
страница:
Теперь вспомним об этапах покупки книг:
а. Регистрация (если нет счета пользователя).
б. Заполнение книгами виртуальной корзины.
в. Редактирование корзины: какие-то книги может убрать,
каких-то купить больше, чем одну.
Нигилистический настрой и практическая методология 183
г. Указание деталей доставки.
д. Оплата.
Так вот мы придумали сценарии только для первой части нашей
версии регистрации (вторая часть — это страница с именем, фа-
милией, е-мейлом, паролем и подтверждением пароля). У второй
части тоже будут свои табл. 1 и табл. 2.
Более того, у каждого из остальных этапов тоже могут быть
свои одна или более связок табл. 1 — табл. 2.
Черноящичное тестирование веб-проекта — это манипуляции
с одной или больше веб-страниц, зависимых друг от друга,
определенная комбинация которых ведет нас к определенному
ожидаемому результату.
Таким образом, иногда появляется потребность
• в табл. 3, когда сценарии из табл. 2 становятся элементами
более сложных сценариев,
• в табл. 4, когда сценарии из табл. 3 становятся элементами
еще более сложных сценариев,
• и т.д.
Кстати,
иногда в табл. 1 мы сразу отражаем возможные значения для несколь-
ких связанных между собой веб-страниц.
Я знаю, что матричный метод в начале работы по нему кажется
сложным и запутанным. Единственный способ освоить его — это
использовать на практике, что мы с вами сейчас и сделаем.
Однажды в классе по "юниксу" на занятии по теме "Регулярные
выражения" (наука поиска паттернов в тексте) один товарищ
удивительно метко выразил физическое состояние всех студен-
тов: "Это как операция на головном мозге". Я не удивлюсь, если
в начале использования матричного метода у вас будет схожее
состояние.
Итак, предлагаю вам сейчас самостоятельно создать табл. 1 и
табл. 2 для второй части регистрации. Также прошу вас написать
тест-кейсы по полной форме на каждый из сценариев первой и
второй частей регистрации.
Далее.
184 Тестирование Дот Ком. Часть 3
Одна из прелестей матричного подхода заключается в наглядно-
сти — мы видим перед собой таблицу со структурированными
вариантами сценариев, и нам удобно комбинировать их в более
сложные сценарии или непосредственно переносить их в тест-
кейсы.
Кстати, во многих случаях нет смысла идти дальше табл. 1, например
когда сценарии для тест-кейсов непосредственно вытекают из эле-
ментов табл. 1 или когда сценарии для тест-кейсов можно просто до-
мыслить, скомбинировав в уме элементы табл. 1.
3. БЛОК-СХЕМЫ
В беседе о продюсерах и вещах, которые им нужно улучшить в
своей работе, мы уже говорили о блок-схемах. Блок-схема — это
графическая презентация некого процесса.
Блок-схемы допускают разные уровни абстракции, например
процесс регистрации можно представить и в таком виде:
Процесс регистрации
Эта блок-схема и ее сестра из беседы о цикле разработки ПО
• похожи тем, что демонстрируют нам логику работы реги-
страции и
• различаются тем, что имеют различную детализацию этой
логики.
Нигилистический настрой и практическая методология 185
В своей работе тестировщики используют ту степень детали-
зации, которая нужна для конкретной ситуации: если мы тес-
тируем саму регистрацию, то нам необходима большая степень
детализации (процесса регистрации) по сравнению с ситуацией,
когда нам нужно увидеть место регистрации как часть процесса
покупки.
Идея о разных степенях абстрагированности раскладки в зави-
симости от того, ЧТО и КАК мы тестируем, напрямую отно-
сится и к черновику-чистовику, и к матричному методу.
Вот элементарные, непробиваемые и вечные формы (блоки) для
составления блок-схем, которых вам будет достаточно в боль-
шинстве ситуаций:
Точка начала/конца блок-схемы может
содержать название этой точки (например,
название веб-страницы) или просто и со
вкусом величаться "Начало"/"Конец".
Это любой этап процесса, кроме этапов
начало/конец, решение или перенос.
Решение — некая точка, после которой
возможны, как правило, два варианта раз-
вития процесса.
Перенос ставится в том случае, если данное
ответвление процесса представлено (будет
представлено) другой блок-схемой.
Вот несколько рекомендаций по составлению блок-схем.
1. Перед составлением блок-схемы назовите основной про-
цесс, описываемый ею, например "Процесс регистрации".
2. Сначала набросайте путь основного течения процесса, на-
пример, в случае с регистрацией это три блока, показанные
на последней блок-схеме (страница 1, страница 2 и под-
тверждение).
3. Называйте каждый блок кратко и информативно.
4. Приводите ссылки на полезную информацию, например,
см. Спек #9017 — это ссылка на соответствующий спек.
186 Тестирование Дот Ком. Часть 3
5. Для наглядности презентации старайтесь скомпоновать
блок-схему таким образом, чтобы процесс шел сверху вниз
и слева направо.
6. Для превентирования ошибки в толковании избегайте пе-
ресечения стрелок.
7. Протестируйте (проверьте) законченную блок-схему на пред-
мет соответствия спеку или другому источнику.
Для тренировки нарисуйте блок-схему следующей ситуации.
Идея: вскипятить чайник.
Вот вам в помощь блоки решений, которые предстоит разложить
в блок-схеме:
1. Вода в чайнике есть/нет.
2. Плита включена да/нет.
3. Чайник кипит да/нет.
Для совершенствования в составлении блок-схем очень рекомен-
дую найти ресурсы в Интернете или купить книгу.
Блок-схемы — это визуальные источники идей для тестиро-
вания. Кроме того,
как и в случае со всеми методами генерации тестов, процесс
создания блок-схем вызывает рождение множества превосход-
ных идей для тестирования, открывает тестировщику новые
грани ПО и вызывает ряд вопросов, которые не возникли бы
при простом прочтении спека.
Политический момент
как известно,
теория (простое прочтение спека перед его утверждением) и
практика (работа со спеком при создании тест-кейсов) — это две
разные вещи.
На "практике", если спек более или менее сложный, неизбежно воз-
никнет необходимость в уточнениях.
Нигилистический настрой и практическая методология 187
Знайте, что отвечать на вопросы по спеку — это святая обязан-
ность продюсера.
Вы имеете право, нет, ОБЯЗАНЫ задать ему ВСЕ вопросы по спеку, ко-
торые у вас возникнут, ибо шкуру будут спускать с вас, а нес него, если
вы из-за неотвеченных вопросов пропустите баги.
Кстати, обязательно сохраняйте всю переписку в отдельном фолдере
(папке) е-мейл клиента (дайте фолдеру наименование (Ю) спека):
вдруг продюсер дал вам уточнение, оно было неверным, вы написали
тест-кейс с ошибкой/не написали тест-кейс вовсе и пропустили серь-
езный баг?
Нет е-мейла — нет доказательств, есть е-мейл — есть доказательства.
Если уточнение по спеку было сделано устно, пошлите е-мейл продю-
серу, где опишите то, как вы поняли уточнение, и спросите "Я правиль-
но понял?".
Если продюсер не отвечает, пошлите ему тот же е-мейл из фолдера е-
мейл клиента "Отправленная почта", чтобы он видел, что уже один
раз проигнорировал ваш запрос.
Если ответа снова нет и продюсер не болен, не уехал на ПМЖ в Австра-
лию, а даже очень здоров, строит дачку в Малаховке, и вы видите его в
столовой каждый день, то просто перешлите последний из е-мейлов
продюсера своему менеджеру и сообщите ему, что не можете рабо-
тать по спеку.
Менеджер не будет сам говорить с ним, а переправит ваш е-мейл ме-
неджеру продюсеров, чтобы тот спросил у продюсера: "В чем, собст-
венно, дело?" Даю гарантию, через час продюсер сам прилетит к вам,
как ни в чем не бывало хлопнет по плечу, как лучшего друга, и проведет
с вами столько времени, сколько нужно, травя байки и находя удачные
аналогии для того, чтобы вы лучше поняли материал. "Бизнес есть
бизнес", вы ищете баги и, чтобы быть эффективным, должны по-
лучить всю информацию по спеку.
Теперь суперважная вещь в отношении методов генерирования и
отбора тестов.
Превосходные результаты дает комбинирование методов.
Например, можно набросать черновик и в качестве чистовика создать
табл. 1, сгруппировав в ней идеи из черновика.
С другой стороны, имея табл. 1, табл. 2 и т.д., можно использовать метод
черновик-чистовик, чтобы выделить сценарии из элементов табл. 1,
табл. 2 и т.д.
С третьей стороны, можно создать блок-схему, чтобы нагляднее ви-
деть процессы, описанные в таблицах, и найти новые интересные
идеи.
В общем бесчисленное множество комбинаций и огромное поле для
творчества! Как мы уже говорили, в тестировании НЕТ ДОГМ
188 Тестирование Дот Ком. Часть 3
и даже сами основы отрасли знания "Тестирование" постоянно
находятся под обстрелом, так что дерзайте и находите именно те
приемы и методы, которые будут работать для вас в тех ситуа-
циях, в которых вы будете работать.
Методы отбора тестов
1. Оценка риска (risk estimate).
2. Эквивалентные классы (equivalent classes).
3. Пограничные значения (boundary values).
Общая вещь: методы отбора тестов применяются во время
или после генерирования тестов.
1. ОЦЕНКА РИСКА (risk estimate)
Представьте, что вы только что прикупили отель где-нибудь в
горах Сьерра-Невада в Северной Калифорнии. У вас нет опыта
работы менеджером отеля, но вы чувствуете себя абсолютно уве-
ренным в своей новой роли, так как у вас есть высшее образова-
ние в области физики твердого тела и такую фигню, как управле-
ние отелем, вы, конечно, осилите на раз.
К вашему отелю ведут три дороги:
• первая соединяет отель и ответвление скоростной магист-
рали,
• вторая соединяет отель и дорогу, ведущую к горнолыж-
ным курортам,
• третья соединяет отель и небольшую проселочную дорогу.
по которой ездят в основном местные жители.
Все три дороги имеют одинаковую протяженность.
10 человек уже приехали и 30 человек должны приехать сегодня.
Всю ночь шел снег, и все три дороги замело так, что ни один
джип не проедет ни по одной из них.
У вас есть только одна снегоуборочная машина, и на уборку лю-
бой из дорог уйдет полдня. Так что нужно выбирать, с какой из
них начать.
Можно подойти к решению этой задачи чисто субъективно.
Нигилистический настрой и практическая методология 189
Абсолютно очевидно, что по дороге номер 3 могут приехать
только ваши местные кореша
• для игры в покер (но сегодня не день покера — пятница)
или
• на барбекю (но сегодня не суббота).
Значит, дорога 3 остается в снегу.
Абсолютно очевидно, что дорога номер 2 также не является
приоритетной в расчистке, так как абсолютно очевидно, что 10
меньше 30.
Таким образом, наш план:
• посадить отельского "жнеца, швеца и на дуде игреца" за
руль снегоуборочной машины расчищать роад намбер уан:
дорогу к скоростной магистрали;
• вывесить в лобби отеля большой плакат "Дорог на гор за-
крыт. Не ходи, а то хана" для уже вселившихся;
• накормить уже вселившихся бесплатным завтраком (в каче-
стве извинения).
Запомним, с какой уверенностью мы говорили себе: "Абсолютно
очевидно".
Давайте перед тем как реализовывать наш гениальный план, ос-
нованный на очевидных вещах, остановимся на минутку у стойки
регистрации и поговорим с менеджером отеля, который прорабо-
тал в нем 20 лет.
Первый вариант разговора
Вопрос: "Что делать, Джеймс?"
Ответ: "Босс, все очень просто. Все, кто уже вселился в отель,
приехали играть в снежки, кататься на беговых лыжах или просто
дышать свежим воздухом. Я это знаю потому, что переговорил с
каждым из них и знаю большинство из них, так как они приезжают
каждый год. Поэтому нет никакого смысла в расчистке дороги
номер 2, все остаются в отеле или развлекаются в его окрестностях.
Я также знаю, что 16 человек из 30 — это компания, которая вы-
едет к нам рано утром из Рино (я вчера говорил по телефону с
одним из них) по этой дороге (показывает на карте), которая пе-
ресекается с дорогой номер 3. Соответственно они прибудут к
нам по дороге номер 3.
190 Тестирование Дот Ком. Часть 3
Далее, посмотрите на монитор. Где живут 12 из 14 оставшихся
клиентов? Они все живут в Сан-Франциско и окрестностях.
Только что передали по радио, что на единственной скоростной
дороге, ведущей из Сан-Франциско, из-за снегопада уже образо-
вались страшные пробки. Кроме того, скорее всего большинство
членов сан-францисской команды поедут после работы, т.е. в 4
часа, а значит, будут здесь не раньше 8.
Следовательно, нам нужно сначала расчистить дорогу 3 и по-
сле этого заняться дорогой 1.
Кстати, остаются еще двое, едущие из Техаса. Вот их мобильный
телефон. Я собираюсь им позвонить, рассказать о ситуации со
снегом, наших планах по расчистке и скоординироваться с ними,
как им лучше до нас добраться".
Второй вариант разговора
Вопрос: "Что делать, Джеймс?"
Ответ: "Босс, надо сначала расчищать дорогу 2, ведущую к
горнолыжным курортам. Все наши постояльцы — это горнолыж-
ники. Кроме того, оставшиеся 30 человек скорее всего сначала
заедут на курорт, покатаются там до вечера и вечером поедут к
нам — не будут же они терять сегодняшний день, я сам заказывал
им пропуска со скидкой на подъемники, а пропуска начинают
действовать сегодня".
Третий вариант разговора
Вопрос: "Что делать, Джеймс?"
Ответ: "Босс, нет проблем. Нам нужно расчистить и дорогу 1, и
дорогу 2. Я не знаю, что важнее. Но знаю номер телефона моего
приятеля — владельца снегоочистительной компании, он даст
нам хорошую цену, и двумя машинами мы сможем к полудню
расчистить обе дороги. Ну, потратим немного денег, зато сохра-
ним репутацию отеля, ставящего заботу о клиенте выше всего".
Мораль:
субъективные суждения, основанные на тупосамонадеянном
"Абсолютно очевидно", могут элементарно завести нас в си-
туацию, когда ресурсы потрачены впустую, так как не учи-
тывают реальности. В то же время выводы, сделанные исходя
из достоверной информации, ведут к эффективным решениям
даже при нехватке ресурсов.
Нигилистический настрой и практическая методология 191
То, что сделал для нас мистер Джеймс, было оценкой риска. Он
смог сделать оценку риска, так как
• владел информацией и
• знал, как этой информацией распорядиться.
Обратно к тестированию ПО.
Наша задача — это
• получить информацию,
• если возможно, узнать мнение человека, владеющего во-
просом, и
• оценить риск по каждой из функциональностей, которые
предстоит протестировать.
Людьми, которые владеют вопросом, могут быть продюсер, глав-
ный бухгалтер, финансовый директор, бизнес-аналитик. Информа-
цию можно получить также из статистики или других источников.
Поверьте, что такой подход даст удивительные результаты.
Допустим, у нас есть небольшой проектик, где нужно протести-
ровать новый (переписанный и оптимизированный) код для уже
давно существующих функциональностей:
а) сделки купли-продажи между пользователями внутри Аме
рики;
б) сделки купли-продажи между пользователями в Японии;
в) сделки купли-продажи между пользователями в Японии
и США.
Разложим эти функциональности:
Таблица 1
Индекс_эл_001
Индекс_эл_002
Индекс_эл_003
Индекс_эл_004
Продавец
Американец X
Японец X
Покупатель
Американец X
Японец X
192 Тестирование Дот Ком. Часть 3
Таблица 2
Индекс_эл_001
Индекс_эл_002
Индекс_эл_003
Индекс_эл_004
Продавец американец —> Покупатель американец 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
ЕСЛИ сумма > 200,00 И сумма < 499,99,
ТО скидка = сумма/100 х 2
Ошибка в знаке равенства и/или сумме нижнего
предела.
Пример (знакравенства перед 200,00 пропущен):
ЕСЛИ сумма > 200,00 И сумма < 499,99,
ТО скидка = сумма/100 х 2
2% от 200
200 Тестирование Дот Ком. Часть 3
б. Затем тестируется
верхний предел
данного класса (если
верхний предел
имеется):
499,99
ЕСЛИ сумма > 200,00 И сумма < 499,99,
ТО скидка = сумма/100 х 2
Ошибка в знаке равенства и/или сумме верхнего
предела.
Пример (499,00 вместо 499,99): ЕСЛИ сумма >
200,00 И CVMMQ < 499,00, ТО скидка = сумма/100
х 2
2% от 499,99
в. Затем тестируется
любое значение
внутри данного
класса:
315,11
ЕСЛИ сумма > 200,00 И сумма < 499,99,
ТО скидка = сумма/100 х 2
Ошибка в знаках больше (>) и меньше (<). Пример
(больше вместо меньше и меньше вместо больше):
ЕСЛИ сумма < 200,00 И сумма > 499,00: ТО скидка
= сумма/100 х 2
2% от 315,11
г. Затем тестируется верхний предел класса,
непосредственно предшествующего
данному классу
(если предшествующий
класс имеется):
199,99
ЕСЛИ сумма > 200,00 И сумма < 499,99,
ТО скидка = сумма/100 х 2
Тонкий момент. Здесь мы проверяем две вещи:
1. Наличие скачка от верхнего предела предьщущего
класса к нижнему пределу нашего класса.
Это делается для следующей ситуации. Допустим,
программист напечатал 100,00 вместо 200,00: ЕСЛИ
сумма > 100,00 И сумма < 499,99,
ТО скидка = сумма/100 х 2. Если сделана такая
ошибка, то она не будет обнаружена ни тестом а, ни
тестом б, ни тестом е.
2. Логическое "И", так как если бы у нас было "ИЛИ":
ЕСЛИ сумма > 200,00 ИЛИ сумма < 499,99,
ТО скидка = сумма/100 х 2, то к данному классу
принадлежало бы любое в принципе возможное
значение
Скидка не равна 2% от 199,99
д. Затем тестируется нижний предел класса,
непосредственно следующего
за данным классом
(если следующий
класс имеется):
500,00
ЕСЛИ сумма > 200,00 И сумма < 499,99,
ТО скидка = сумма/100 х 2
1. Наличие скачка от верхнего предела нашего класса
к нижнему пределу следующего за ним класса. Это
делается для следующей ситуации. Допустим,
программист напечатал 599,99 вместо 499,99: ЕСЛИ
сумма > 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 могут использоваться для воспроизведения
проблемы и программистами, и тестировщиками, и продюсе-
рами. В тест-кейсах можно допустить употребление принятых в
отделе качества сокращений и акронимов, а также ссылок к
внешним документам: коллеги-тестировщики поймут и простят,
но многие очевидные для тестировщика вещи совершенно не-
очевидны, например, для продюсера. Поэтому, пожалуйста, пи-
шите четкие и подробные шаги, чтобы ваши коллеги из других
отделов без проблем воспроизводили баги и нахваливали ваши
описания.
Вот небольшой список наиболее часто встречающихся элемен-
тов веб-страницы, который позволит вам более четко описывать
и шаги для воспроизведения багов, и шаги тест-кейсов.
Я текст. Вещь незаменимая
Текст (text)
Не знаю, какое описание дать здесь. Текст есть текст.
Кстати:
1. Текст может быть неверного содержания* (противоречащий
спеку): например, неверное сообщение об ошибке.
2. Нужного текста может не быть вовсе*.
3. Может быть неправильным шрифт (font), цвет (color), размер
(size) текста.
Естественно, что проблемы неверного содержания элемента или полного его
отсутствия могут быть не только у текста, но и у всех остальных элементов.
Я линк. Просто линк
Линк (link)
Также известен как ссылка или гиперссылка. Если нажать на линк
(или, по-простому, "кликнуть линк") (click link), то мы попадем
• либо на другую веб-страницу,
• либо на определенное место страницы, на которой находится
линк (например, если на одной странице есть список названий
глав книги (Содержание) и сами главы, то название каждой главы
в Содержании может быть слинковано с началом текста главы).
Жизнь замечательных багов 213
Кстати:
1. Линк может быть сломан (broken link), т.е. нажимаем на линк
и никуда не идем либо получаем сообщение, что страница не
найдена.
2. Линк может вести не туда , куда нужно (misleading link), напри-
мер, вы кликаете на линк " Контактная информация", а попадаете
на страницу 'Корзина".
Для проверки сломанных линков есть прекрасный бесплатный тул,
называемый Хепи 's Link Sleuth (можете скачать его из Интернета).
Картинка (image)
Ну, куда же мы без них. Картинки — это графические файлы (как
правило, GIF либо JPG), на которые ссылается HTML-код, веб-стра-
ницы и которые через Интернет летят на жесткий диск наших ком-
пьютеров. Если вы в окне браузера видите картинку, то знайте, что
она сохранена на жестком диске...
Кстати:
Сломанная картинка (broken image): ситуация, когда, как правило,
путь к графическому файлу в HTML-коде указан неверно или путь ука-
зан верно, но сам файл поврежден (corrupted/damaged) и на веб-стра-
нице мы видим лишь рамку, в которой должна была быть картинка:
Слинкованная картинка (linked image)
По сути это линк, который представлен не текстом, а картинкой.
Соответственно у слинкованной картинки могут быть болезни как
линков, так и картинок.
214 Тестирование Дот Ком. Часть 3
Я имя текстового поля: А я текст внутри текстового поля
Однострочное текстовое поле (textbox)
Однострочное текстовое поле (или просто "текст-бокс") — это один
из элементов веб-формы (web form), которая может быть на веб-стра-
нице. Для примера: веб-форма всегда является частью веб-страницы
с регистрацией, когда вы вводите имя, пароль, е-мейл (и т.д.) и
нажимаете кнопку "Зарегистрироваться". Все остальные элементы,
перечисленные далее:
• многострочное текстовое поле;
• поле для пароля;
• радиокнопка;
• чекбокс;
• кнопка,
также являются элементами веб-формы.
Кстати,
текстовое поле используется для введения множества видов текстовой
информации: от имени пользователя до ввода текста, увиденного на
кепча (от англ. captcha, читается как кэпча).
Веб-индустрия использует кепча (которое является динамически
сгенерированной картинкой) для того, чтобы превентировать
автоматические программы от использования веб-сайта. Идея в
том, что человек может распознать символы, изображенные на
кепча, а компьютер — нет. Вот пример кепча — страница регист-
рации на Yahoo!. На ней изображено (буквы латинские): рЗт4ак:
Verify Your Registration
*Enter the code shown: This helps Yahoo! prevent automated registration.
В отношении проблем:
Размер текст-бокса (MAXLENGTH), т.е. максимальное количество
символов, которое можно ввести в текстовое поле, может быть
больше или меньше, чем указано в спецификации.
Проверка количества символов, которое может принять в себя тек-
стовое поле, проводится в рамках тестирования интерфейса пользо-
вателя (UlTesting).
More info
Жизнь замечательных багов 215
Я имя многострочного текстового поля:
А я текст внутри многострочного текстового поля.
Такие вот дела.
Многострочное текстовое поле (text entry area)
используется для ввода информации, которая не умещается в одно-
строчном текстовом поле. Например, для создания постинга на
интернет-форумах под предмет сообщения (subject) отдается текст-
бокс, а под само сообщение — многострочное текстовое поле.
Кстати,
прекрасным, истинно сероящичным тестом является проверка того,
умещается ли наш ввод в соответствующую колонку базы данных.
Под вводом в данном случае подразумеваются данные, введенные
посредством текст-бокса или многострочного текстового поля.
Пример
При регистрации наш новый пользователь заполняет соответст-
вующую веб-форму и нажимает на кнопку "Зарегистрироваться".
Некий файл (например, написанный на языке Python и живущий на
сервере с приложением) трансформирует эту форму в язык, понятный
базе данных (язык называется SQL — Structured Query Language,
произносится как "эс-кью-эл"), и создает новую строку (record) в
таблице, называемой, например, USER ADDRESS (адрес
пользователя).
Допустим, что при создании таблицы USERADDRESS программист
ошибочно указал максимальный размер колонки ADDRESS1 в 7
символов (VARCHAR (7)) вместо 37, положенных по спеку. Это при-
ведет к тому, что при создании новой строки в USERADDRESS дан-
ные, включаемые в колонку ADDRESS1, будут ограничены 7 симво-
лами, а 8-й и прочие символы будут отсечены (truncated) (кстати,
пробел — это тоже символ):
USER_ADDRESS
RECORD
ID
ADDRESS 1 ADDRESS2 CITY STAT
E Country ZIP CODE
1 12 49th Apt. 2 San Francisco CA USA 94118
2 121 Ano Moscow Russia 117602
3 221b Ba London UK NW1
4 82 Boul Paris France 75018
Что делаем? Правильно, заносим баг, и, после того как баг зафик-
сирован и проверен нами, адреса, хвосты которых были отсечены, уже
выглядят так:
216 Тестирование Дот Ком. Часть 3
USER_ADDRESS
RECORDJ
D
ADDRESS 1 ADDRESS2 CITY STAT
E Country ZIP CODE
1 12 49th Avenue Apt. 2 San Francisco CA USA 94118
2 121 Anokhin Avenue Moscow Russia 117602
3 221b Baker Street London UK NW1
4 82 Boulevard
de Clichy
Paris France 75018
Кстати, хорошей идеей для ввода при тестировании является описа-
тельный ввод, например, в текст-бокс Адрес 1 (данные которого идут
в ADDRESS1) нужно было бы ввести не милую сердцу 82 Boulevard de
Clichy, а строку
"а запятая является 38-м символом, 11111111111"
и затем проверить базу данных.
Если ADDRESS 1 содержит строку
"а запятая является 38-м символом", —
ни символом больше, ни символом меньше, то ADDRESS 1 вмещает
ровно 37 символов и код ведет себя согласно спеку. В любом ином
случае (36 или меньше символов либо 38 или больше символов) у нас
есть баг.
Я имя поля для пароля: *******
Поле пароля (passwordfield)
Это однострочное поле для ввода текста с тем нюансом, что каждый
символ, введенный в это поле, тут же автоматически преобразуется в
* (звездочку, или, по-англ. — asterisk) либо в жирную метку (bullet).
Преобразование в звездочки (или буллеты) сделано для того, чтобы
какой-либо добрый, сердечный человек не подсмотрел ваш пароль и
не очистил ваш, например, банковский эккаунт.
Кстати,
важной вещью в отношении пароля я&чяется профессиональная этика,
согласно которой нужно демонстративно отворачивать голову на
90 градусов в другую сторону от клавиатуры, если кто-то вводит
пароль. Смотреть на клавиатуру, когда кто-либо вводит пароль, так
же неприлично, как сказать о блефе, после того как вы выиграли
партию в покер и карты уже перемешаны.
Жизнь замечательных багов 217
Еще одна мысль
во множестве западных компаний каждый ваш удар по клавишам
клавиатуры (keystroke) невидимо для вас запечатлевается в
текстовом файле (log), который является собственностью компа-
нии и который, если будет нужно (естественно, не во благо вам),
будет поднят вашим менеджером и проанализирован.
Впрочем, так же могут быть подняты и проанализированы скрин-
шоты (снимок изображения на экране вашего монитора), которые
делаются с определенным интервалом (например, 60 секунд) и
также являются собственностью вашего работодателя.
Кстати,
если уж заговорили об осторожности: в США недавно был создан
судебный прецедент, согласно которому все содержимое папок е-
мейла работника является собственностью работодателя, на это
содержимое не распространяются законы о защите частной жизни
(privacy), и соответственно работодатель может спокойно про-
сматривать всю вашу корреспонденцию, посланную с рабочего е-
мейла или полученную на него.
Так что не теряйте бдительности, товарищи, блоги и личная
переписка могут подождать до вечера.
В отношении проблем:
размер поля пароля (MAXLENGTH), т.е. максимальное коли-
чество символов, которые можно ввести в него, может быть
больше или меньше, чем указано в спецификации.
Я имя ниспадающего меню: Я первое значение списка V
Я первое значение списка
Я второе значение списка
Я третье значение списка
Ниспадающее меню (pull down menu)
Ниспадающее меню дает возможность выбрать одно, и только одно,
значение из списка значений меню. Наитипичнейший пример —
ниспадающее меню со списком стран на веб-форме регистрации.
218 Тестирование Дот Ком. Часть 3
Я имя радиокнопки:
И я тоже имя радиокнопки:
либо
Я имя радиокнопки:
И я тоже имя радиокнопки:
Радиокнопка (radio button)
Радиокнопка, также известная под неудобоваримым именем "зави-
симая кнопка", — это элемент веб-формы, который позволяет
выбрать одно, и только одно, значение из списка своих собратьев.
Список называется группой радиокнопок, которая объединена
одним названием и/или логичной принадлежностью к группе. Зна-
чения радиокнопок взаимоисключаемы, и, таким образом, кнопки
взаимосвязаны.
Кстати,
согласно www.multitran.ru английское название выбрано по ана-
логии с кнопками выбора диапазона волн радиоприемника, когда в
каждый текущий момент может быть выбрана только одна волна.
Пример
возьмем группу под названием "Пол". Может быть либо так:
Пол:
Муж.
Жен.
либо этак:
Пол:
Муж.
Жен.
В отношении терминологии.
Можно выбрать (select) радиокнопку:
в первом случае — «выбрали радиокнопку "Муж."», во
втором случае — «выбрали радиокнопку "Жен."».
Радиокнопка может существовать только как элемент группы (2 и
больше) взаимоисключаемых собратьев, в случаях же когда элемент
один или элементы взаимонезависимы, используется чекбокс.
Жизнь замечательных багов 219
Я имя чекбокса (кстати, мой чекбокс не отмечен)
И я имя чекбокса (мой чекбокс отмечен):
Я тоже имя чекбокса (мой чек-бокс отмечен):
Чекбокс (checkbox)
Чекбокс, также известный под неудобоваримым именем "независи-
мая кнопка", — это элемент веб-формы, который позволяет:
установить галочку (check) либо
убрать галочку (uncheck).
Иными словами, можно соответственно:
отметить чекбокс,
очистить чекбокс.
Чекбоксы, как и радиокнопки, могут быть сгруппированы под
одним именем (в примере ниже именем является "Причины за-
крытия эккаунта"), но чекбоксы, как правило, независимы друг от
друга.
"Как правило ", так как иногда веб-мастера предусматривают (с
помощью JavaScript) взаимосвязь между чекбоксами.
Вот веб-форма опросника при закрытии счета:
Причины закрытия эккаунта:
Сайт работает слишком медленно
Неудовлетворительная служба поддержки Сбои в
работе веб-сайта Ограниченный выбор книг
Проблемы с доставкой Другое:
220 Тестирование Дот Ком. Часть 3
Я имя кнопки!!!
Кнопка (button)
Нажатие на кнопку является заключительным аккордом при запол-
нении веб-форм. Нажимая на кнопку, мы отправляем веб-форму для
обработки на сервер с приложением (application server).
Кстати,
в большинстве случаев наличие ошибок при заполнении формы (напри-
мер, обязательное для заполнения текстовое поле "Имя " пустое)
проверяется не на сервере с приложением, а на компьютере пользо-
вателя.
Это делается путем кода JavaScript, являющегося частью HTML-стра-
ницы с веб-формой, и в случае ошибки в заполнении формы
выдается сообщение об ошибке,
веб-форма не посылается на сервер с приложением.
Если неизвестно название кнопки, то при написании тест-кейсов
просто напишите "отправьте форму" ("submit the form " или просто
"submit").
ATTACHMENT (ПРИЛОЖЕНИЕ)
Нет лучшей вещи при обмене информацией, чем хорошо подоб-
ранная иллюстрация, особенно наглядная иллюстрация. Наш мозг
гораздо быстрее воспринимает зрительную информацию, чем
текстовую, и мы, зная этот научный факт, можем организовать
эффективную презентацию проблемы. Презентация может де-
латься, например, путем приложения снимка экрана (скриншота),
на котором видна проблема. Вот самый технически элементар-
ный и повсеместно распространенный способ для собственно-
ручного изготовления скриншота:
а. На клавиатуре нажимаем кнопку PrtScrn.
б. Открываем стандартную программу Виндоуз, Paint.
в. Нажимаем Ctrl+v.
г. Сохраняем графический файл (с расширением Jpeg или .gift.
д. Прилагаем его к багу.
Кстати, как Paint, так и другие графические редакторы позволяют об-
вести, например, красным цветом место на скриншоте, где видна про-
блема (например, группу радиокнопок, которые можно выбрать одно-
временно). В общем большое поле для творчества.
Жизнь замечательных багов 221
Естественно, что приложением может быть не только наглядная
иллюстрация в виде графического файла, но и любые другие
файлы, которые помогут программисту быстрее и точнее понять
суть проблемы.
Иногда бывают ситуации, что трудно описать проблему на род-
ном языке, не говоря уже об иностранном. Что делаем? Прила-
гаем файл с иллюстрацией проблемы в поле "Описание и шаги
для воспроизведения проблемы" и скромно пишем "Смотри при-
ложение" (See attachment).
Кстати, фраза "Смотри приложение" должна быть в поле "Опи-
сание и шаги..." в любом случае — чтобы каждый, кто просмат-
ривает занесенный вами баг, наверняка открыл и приложение.
SUBMITTED BY (АВТОР БАГА)
СТБ автоматически присваивает значение этому атрибуту. Как
нетрудно догадаться, значение "Submitted by " — это нередакти-
руемый текст с именем товарища, занесшего баг в СТБ (товарищ
далее именуется автором бага). Как правило, автором бага явля-
ется тестировщик.
DATE SUBMITTED (ДАТА И ВРЕМЯ ПОЯВЛЕНИЯ БАГА)
Как и в случае с Submitted by, СТБ автоматически присваивает
значение этому атрибуту. Как нетрудно догадаться, значение
"Date submitted" — это нередактируемый текст с датой и време-
нем, когда баг был занесен в СТБ своим отцом — автором.
ASSIGNED TO (ДЕРЖАТЕЛЬ БАГА)
Каждый открытый баг в каждый конкретный момент имеет
своего конкретного держателя (Owner). Держатель бага — это
участник процесса разработки ПО, на котором лежит ответствен-
ность сделать следующий шаг на пути к закрытию бага. Вариан-
ты следующего шага определяются процессом.
Когда баг заносится в СТБ, то автор бага обязательно должен вы-
брать имя из списка ниспадающего меню "Assigned to " (СТБ вы-
даст ошибку, если имя не выбрано). Список "Assigned to " состоит
из имен всех пользователей, кто имеет эккаунты в СТБ. Напри-
мер, мое имя пользователя в СТБ может выглядеть как г savin.
222 Тестирование Дот Ком. Часть 3
Кстати, счета в СТБ открывает администратор СТБ, который, как пра-
вило, является вашим коллегой-тестировщиком, корпящим в соседнем
отсеке по другую сторону серой стенки, украшенной постером с сило-
вой подачей Марии Шараповой.
Если автор бага
• не знает, кто из программистов должен ремонтировать этот
баг, или
• вообще не знает, что ему делать с этим багом,
то он просто выбирает из "Assigned to " самое родное и близкое,
что он может там найти, — свое имя.
В каждой интернет-компании на интранете должна быть стра-
ничка "Кто за что ответствен" (Who does What). На этой стра-
ничке должны быть перечислены:
• компоненты веб-сайта (те же, что и в атрибуте "Компонент",
о нем чуть позже);
• программисты, которые отвечают за эти компоненты;
• продюсеры, которые отвечают за эти компоненты.
Пример
Компонент Программист Продюсер
Регистрация Н. Гусев С. Попов
Поиск Р. Буйнов А. Ключникофф, А. Зубков
Корзина Ю. Тимофеев, И. Николаев В. Жабров
Оплата О. Столяров В. Новоселов
Нужно, чтобы эта страничка постоянно поддерживалась, напри-
мер, менеджерами программистов и продюсеров, чтобы отражать
текущее состояние компонентов и ответственных лиц:
если в компании 3 человека, сидящие в одном закутке 4x3 метра,
то каждый примерно знает, что делают двое других. Если же
компания растет и развивается, работники приходят, перево-
дятся с участка на участок, уходят, функциональности появля-
ются, модифицируются, исчезают... в общем перемены бьют
ключом, то наличие централизованного источника информации
о программистах и продюсерах — собственниках функцио-
нальностей является наиудобнейшей и наиполезнейшей вещью
(хотя бы для того, чтобы быстро и правильно выбрать имя из
"Assigned to ").
Жизнь замечательных багов 223
Кстати, автором бага может быть не только тестировщик. Любой поль-
зователь СТБ, имеющий право (privilege) на занесение багов в СТБ,
может быть автором бага. Технически права даруются (как, впрочем,
и отнимаются) администратором СТБ.
Кстати, выражение "занести баг" по-аглицки звучит как "file a bug" или
"reporta bug".
Кстати, программисты часто заносят баги против своего же кода. Это
не мазохизм, а холодный расчет, так как
• с одной стороны, сохранять баги в СТБ просто удобно, а
• с другой — программист должен тратить время на ремонт бага, и
баг, занесенный в СТБ, оправдывает такую трату в глазах началь-
ства, коллег и семьи.
Кстати, программисты любят играть багом в пинг-понг, меняя значе-
ние Assigned to на имена друг друга, говоря таким образом: "Это, доро-
гой, не мой, а твой баг", "Нет, я думаю, что это как раз твой баг", "Я не
уверен, что ты прав. Этот баг все-таки твой" и т.д. Результатом таких
игр является задержка в фиксировании бага.
Небольшой нюанс. Люди приходят в интернет-компанию и уходят
из нее. Когда они приходят, администратор СТБ создает им счета,
а когда они уходят, то эти счета НИКОГДА не удаляются: админист-
ратор СТБ просто маркирует счет бывшего коллеги как недействи-
тельный, т.е. им нельзя больше пользоваться. При этом имя пользо-
вателя СТБ в списке пользователей СТБ остается. Принцип неудале-
ния нужен для сохранения данных, связанных с занесенными багами.
ASSIGNED BY (ИМЯ ПЕРЕДАВШЕГО БАГ)
Значение этого атрибута (как и Submitted by) является нередактируе-
мым текстом. СТБ автоматически присваивает атрибуту Assigned by
имя пользователя СТБ, который выбрал значение Assigned to. Таким
образом, счастливчик, который стал Assigned to, всегда знает, кто
был тем доброжелателем, который сделал его держателем бага.
VERIFIER (ИМЯ ТОГО, КТО ДОЛЖЕН ПРОВЕРИТЬ РЕМОНТ)
Это ниспадающее меню с тем же списком имен сотрудников, что
и в Assigned to.
Как мы помним, баг может быть занесен в СТБ любым сотрудни-
ком интернет-компании, который имеет счет в СТБ и соответст-
вующую привилегию.
При занесении бага значение Verifier автоматически становится
равным имени автора бага. После того как баг был зафиксирован
224 Тестирование Дот Ком. Часть 3
и отремонтированный код был доставлен на тест-машину, держа-
телем бага должно стать лицо, указанное в Verifier.
Как правило, если баг заносится не тестировщиком, то "нетести-
ровщик" сразу (при занесении) выбирает значение Verifier, чтобы
умыть руки и позабыть об этом баге навсегда.
Кстати, каждый эккаунт в СТБ принадлежит к определенной группе.
Как минимум таких групп 3:
• "Тестировщики" — сотрудники департамента качества;
• "Программисты" — сотрудники департамента программирования;
• "Прочие" — все остальные.
В зависимости от принадлежности эккаунта к определенной группе
определяются его привилегии. Например, закрыть баг может только
тот, кто принадлежит к группе "Тестировщики".
Кстати, можно настроить СТБ так, чтобы, когда "Прочие" заносят баг,
значение Verifier не становилось автоматически равным Submitted By, a
было пустым и "Прочие" обязаны (под страхом незанесения бага) вы-
брать значение Verifier.
Не будем больше о привилегиях, это отдельная песня, зависящая
от компании и возможностей СТБ.
COMPONENT (КОМПОНЕНТ)
Это ниспадающее меню со списком, как правило, функциональ-
ных частей веб-сайта. Например, этот список вполне может быть
таким вот коротким и скромным:
"Регистрация
Поиск
Корзина
Оплата
Другое"
При занесении бага в СТБ автор бага должен выбрать компонент,
тестируя который он нашел заносимый баг. Что я могу еще сказать?..
FOUND ON (ГДЕ БЫЛ НАЙДЕН БАГ)
Это ниспадающее меню, которое включает
• имена тест-сайтов, обитающих на нашей тест-машине;
• скромное слово "ZJFЈ"' (машина для пользователей);
• Spec ("Спек");
• Other ("Другое").
Жизнь замечательных багов 225
Например, в нашем любезном сердцу проекте (www.testshop.rs)
список Found on состоит из следующих друзей:
"www.old.testshop.rs,
www.main.testshop.rs,
LIVE,
Spec,
Other".
Понятно, что если значение Found on равно "LIVE", то это означа-
ет, что был пропущен баг, который через релиз добрался до ма-
шины для пользователей или, как говорят некоторые любители
повыпендриваться, "Баг вышел на продакшн". Found on является
обязательным для заполнения.
Немедленная польза от использования атрибута Found on заклю-
чается в том, что каждый, кто хочет воспроизвести занесенный
баг, знает, где конкретно это можно сделать.
VERSION FOUND
(ВЕРСИЯ, В КОТОРОЙ БЫЛ НАЙДЕН БАГ)
Это ниспадающее меню с версиями веб-сайта, автор бага обязан
выбрать значение, соответствующее номеру версии продукта, в
которой был найден баг.
BUILD FOUND (БИЛД, В КОТОРОМ БЫЛ НАЙДЕН БАГ)
Это небольшое (примерно 10 символов) текстовое поле, куда ав-
тор бага обязан вбить номер билда, в котором был найден баг.
VERSION FIXED (ВЕРСИЯ С ПОЧИНЕННЫМ КОДОМ)
Это ниспадающее меню с версиями веб-сайта. После того как
программист починил баг, он должен передать этот баг далее (ре-
лиз-инженеру), для того чтобы в итоге Verifier произвел регрес-
сивное тестирование (у нас будет подробное объяснения процес-
са через 5 минут). Программист обязан выбрать номер версии,
соответствующий бранчу в CVS, куда он направил отремонтиро-
ванный код.
Version Fixed может иметь, как одно из значений, "N/A " (Not applicable
— "к данной ситуации неприменимо"), которое продюсер
обязан выбрать, зафиксировав баг, найденный в спеке.
226 Тестирование Дот Ком. Часть 3
BUILD FIXED
(БИДД С ПОЧИНЕННЫМ КОДОМ)
Это небольшое (например, 10 символов) текстовое поле, которое
заполняется в то же время, что и Version Fixed, т.е. после починки
бага и помещения починенного кода в CVS. В Build Fixed про-
граммист обязан указать номер следующего билда, который под-
хватит исправленный код из CVS. Так, если
• номер последнего билда на www.main.testshop.rs равен 114,
• билд-скрипт для нового билда стартует в 16:00 и
• программист направил код в CVS в 15:30,
то билд 115 должен содержать исправленный код из CVS и,
следовательно, программист должен вбить в Build Fixed значение
"115".
Очень очевидный и очень важный момент, о которым мы уже
говорили: перед началом регрессивного тестирования Verifier
должен удостовериться, что версия и билд на тест-машине
соответствуют значениям атрибутов Version Fixed и Build Fixed
для данного бага.
COMMENTS (КОММЕНТАРИИ)
Это многострочное текстовое поле, куда любой имеющий счет в
СТБ и соответствующую привилегию может занести свои ком-
ментарии, пояснения, уточнения и т.д.
• о баге и/или
• своих действиях в отношении бага.
В некоторых случаях комментарий должен быть обязательным
для заполнения, например когда программист возвращает баг
тестировщику, так как считает, что это вовсе не баг.
SEVERITY (СЕРЬЕЗНОСТЬ БАГА)
Форма: ниспадающее меню со значениями от О до С4 (51—4)
включительно.
Содержание: серьезность бага — это степень воздействия бага
(magnitude of impact) на ПО, исходя из принадлежности бага к
определенной технической категории.
Жизнь замечательных багов 227
Вот пример категоризации:
Серьезность бага Определение
С1 — Критический (Critical) • критический системный сбой (crash);
• потеря данных (data loss);
• проблема с безопасностью (security issue)
С2 — Значительный (Major) • сайт "зависает" (site hangs);
• баг блокирует кодирование, тестирование
или использование веб-сайта (blocker)
СЗ — Умеренный (Minor) • функциональные проблемы (functional bugs)
С 4 — Косметический (Cosmetic) • косметическая проблема (cosmetic problem)
Примеры
С1— КРИТИЧЕСКИЙ
Критический системный сбой — ситуация, когда какая-то часть ПО на
машине для пользователей "рушится" — например, нажимаете на кнопку
"Поиск" и получаете ошибку "HTTP Error 500 Internal server error".
Потеря данных (data loss) — чаще всего это происходит, когда данные:
а) не достигают базы данных либо
б) незапланированно удаляются из нее.
Например:
а) при регистрации е-мейл пользователя не вставляется в опреде
ленную колонку определенной таблицы базы данных;
б) при обновлении пользователем адреса на фронтенде старый
адрес удаляется из базы данных.
Проблема с безопасностью — например, когда после логина пароль виден
как часть URL, так что кто-то может подсмотреть пароль и ис-
пользовать его в своих корыстных целях. При современном состоянии дел
в Интернете, когда 4% монетарных транзакций осуществляется
мошенниками, безопасность — вещь первостепенная.
С2 — ЗНАЧИТЕЛЬНЫЙ
Веб-сайт "зависает" — одна из основных бед интернет-проектов, на-
пример, нажимаешь на кнопку "Купить", и следующая страница грузится, и
грузится, и грузится... Как правило, после таких "загрузов" очень хочется
попробовать веб-сайт конкурента.
Баг блокирует кодирование, тестирование или использование вебсайта
— ситуация, когда
работа тестировщика (и/или программиста) и/или
использование веб-сайта
не могут быть продолжены, так как на одном из этапов появляется про-
блема, превентирующая дальнейшее продвижение.
228 Тестирование Дот Ком. Часть 3
Например, пользователь не может добавить кредитную карту к своему
эккаунтуи, следовательно, не может ничего купить на нашем веб-сайте.
Термин "блокирование" также связан с понятием "обходной путь" (workaround),
а вернее, с отсутствием этого пути. Например, согласно тест-
кейсу нужно создать эккаунт путем использования тест-тула, но тест-тул
не работает (баг в тест-туле является абсолютно легитимным багом!).
Если есть возможность найти обходной путь, который разблокировал бы
в данной ситуации тестирование, то баг не является блокирующим и не
подходит под С2. Примером обходного пути в данном случае является
создание эккаунта вручную.
СЗ — УМЕРЕННЫЙ
Функциональные проблемы (functional bugs) — под эту категорию
подходят все функциональные баги, не подходящие под С1 и С2. Как
правило, это простое расхождение между фактическим и ожидаемым
результатами, когда все шаги тест-кейса (все этапы флоу) исполнены.
СА — КОСМЕТИЧЕСКИЙ
Косметическая проблема — баги, связанные с содержанием вебсайта
(content), правописанием (spelling) и интерфейсом пользователя (User
Interface).
Значение серьезности бага обязательно должно быть выбрано из
списка, иначе баг нельзя занести в СТБ.
PRIORITY (ПРИОРИТЕТ БАГА)
Форма: ниспадающее меню со значениями от Ш до П4 (Ш—4)
включительно.
Содержание: приоритет бага — это показатель важности бага
для бизнеса компании.
Кстати, многие товарищи путают приоритет и серьезность. Ко-
ренное различие между ними кроется в том, что серьезность
отражает технический аспект бага, а приоритет — коммер-
ческий.
Серьезность — это категория абсолютная. Приоритет — это
категория относительная.
Так, если сайт рушится (crash), то это С1, и мы не можем, на-
пример, по политическим соображениям изменить серьезность
такого бага, например, на С2, так как ситуация (с системным
сбоем) четко соответствует дефиниции С1. Если же тести-
ровщик назначил приоритет как П1, то программист вполне
Жизнь замечательных багов 229
может оспорить такое решение и в итоге приоритет будет П2.
Таким образом, назначение серьезности — это механическое дей-
ствие, а приоритета — творческое, связанное с оценкой угрозы
бага для бизнеса компании.
Часто в документации процесса и настройках СТБ определена
четкая связь между верхними значениями серьезности и приори-
тета.
Например, если установлено, что "при серьезности С1 значение при-
оритета должно быть П1", и тестировшик выбирает С1 и П2, то СТБ не
позволит занести баг и выдаст ошибку.
В большинстве же случаев, т.е. при СЗ (функциональных) багах,
нет четкой зависимости между серьезностью и приоритетом, и в
"Описании и шагах..." иногда стоит объяснить, почему вы
выбрали именно этот приоритет, а не более высокий или более
низкий.
Кстати, П1 — баг, из-за которого может сорваться запланированный
релиз, называется showstopper ("пробка"). Примером такого бага мо-
жет служить ситуация, когда тестирование функциональности "Оплата"
полностью заблокировано из-за бага во вспомогательном ПО, симули-
рующем платежную систему.
Еще пара слов о связи серьезности и приоритета бага: например,
мы имеем дело с судопроизводством, а не интернет-проектом.
Фраза "казнить нельзя помиловать" содержит баг, так как от-
сутствует запятая. Отсутствие запятой — это С4, но ситуация,
когда может быть наказан невиновный или оправдан преступник, —
это П1. Ну, например, из-за величины негативных последствий
для имиджа правосудия (шутка).
Кроме привязки к серьезности бага на приоритет могут воздейст-
вовать следующие потенциальные либо реальные вещи:
• процент затронутых пользователей,
• денежные потери для компании,
• негативные юридические последствия для компании,
• негативные последствия для имиджа компании.
В каждой компании должны быть дефиниции приоритета багов
(bug priority definitions), в которых обязательным элементом яв-
ляется указание сроков для починки багов (дополнительным эле-
ментом могут быть факторы, указанные выше, например процент
затронутых пользователей).
230 Тестирование Дот Ком. Часть 3
Вот простейший пример дефиниций.
Приоритет бага Дефиниция
П1 Брось все дела и зафиксируй баг
П2 Зафиксируй баг в течение 72 часов
ПЗ Зафиксируй баг до завершения тестирования данного
основного релиза
П4 Зафиксируй, если возможно
Примеры
П1 —П2 — все понятно.
ПЗ — каждая стадия цикла разработки ПО имеет свои запланирован-
ные временные рамки. Таким образом, если релиз должен состояться
16 марта, то до 16 марта все ПЗ должны быть зафиксированы и закрыты.
П4 — такие баги фиксируются, если у программиста есть время. На-
пример, в какой-нибудь старой версии браузера интернет/эксплорер
(Internet Explorer — IE) не работает какое-нибудь суперзамысловатое
флоу, которое вряд ли может прийти кому-либо в голову.
У каждой компании есть свои заморочки, но, как правило, все баги П1,
П2 и ПЗ должны быть зафиксированы и закрыты до релиза.
В случае с ПЗ, если не хватает времени, может приниматься решение о
релизе, содержащем баг, с условием, что в течение такого-то периода
времени (дни) этот баг будет зафиксирован, протестирован и патч-
релиз выпущен на машину для пользователей.
Почему принимается такое решение, которое, казалось бы, противо-
речит здравому смыслу?
Очень просто. Политика, господа: акционеры компании ждут доходов
от своих инвестиций, и каждый основной либо дополнительный релиз —
это потенциальный катализатор новых прибылей, и такие вещи, как пароч-
ка незафиксированных ПЗ, в мире чистогана в расчет не принимаются.
Кроме того, менеджменту придется держать ответ перед теми же акцио-
нерами, почему релиз не был выпущен вовремя.
Иногда опять же по политическим соображениям принимается реше-
ние о понижении приоритета бага со всеми вытекающими отсюда по-
следствиями, например, когда П2 понижается до ПЗ и этот ПЗ выпус-
кается на продакшн.
Приоритет обязательно должен быть выбран из списка, иначе баг
нельзя занести в СТБ.
В случае сомнений в том, какой приоритет поставить, например
ПЗ или П2, я обычно иду по пути повышения приоритета, т.е.
выбираю П2. Как говорится, не корысти ради, а во благо наших
дорогих и любимых пользователей.
Жизнь замечательных багов 231
Иногда возникают конфликтные ситуации, когда программист
считает, что приоритет завышен, а тестировщик утверждает, что
"сам ты такой" и приоритет назначен правильно. В таком случае
вы можете попросить своего менеджера принять решение о сни-
жении приоритета, если вы считаете, что поставленный вами
приоритет верен и не хотите снижать его сами. Помните, что
дружба дружбой, а если вы были заблокированы и из-за люб-
ви к своему программисту поставили ПЗ вместо Ш, то про-
блемы с невыполнением плана будут у вас, а не у него, так
как это вы, а не он можете не закончить в срок исполнение
тестирования.
Приоритет — это мощнейший инструмент, используя который вы
влияете на расписание работы программиста, поэтому не зло-
употребляйте им (приоритетом) и используйте его мудро.
NOTIFY LIST (СПИСОК ДЛЯ ОПОВЕЩЕНИЯ)
Это ниспадающее меню со списком алиасов всех пользователей,
зарегистрированных в СТБ. Во многих случаях тестировщику не-
обходимо, чтобы
• о факте занесения бага и
• о любом изменении в самой записи о баге
знал определенный круг людей.
Оповещение происходит с помощью е-мейла, в который вклю-
чаются:
• номер бага;
• статус;
• краткое описание;
• приоритет;
• серьезность бага;
• название, старое и новое значение измененного атрибута
(например, кто-то занес свое мнение в комментарий);
• имя того, кто покусился изменить баг (либо занести новый
баг в СТБ).
Кстати,
каждый пользователь СТБ может отрегулировать настройки оповеще-
ния как ему удобно, например, можно сделать так, чтобы е-мейл посы-
лался каждый раз, когда заносится баг, упоминающий в кратком опи-
сании некий спек, например, за номером 7611.
232 Тестирование Дот Ком. Часть 3
Как правило, по умолчанию
• после занесения бага е-мейл посылается
автору бага и
держателю бага,
• а при изменении записи о баге —
автору бага,
держателю бага и лицу,
изменившему баг.
Настройками оповещения, общими для всех участников процес-
са, ведает, как вы уже догадались, администратор СТБ.
Таким образом, атрибут "Список для оповещения" используется
автором бага либо другим заинтересованным лицом для того,
чтобы е-мейлы посылались тем, кто не является реципиентом
по умолчанию.
Я всегда включаю в "Список для оповещения" имя продю-
сера, чтобы тот знал о состоянии дел, связанных с тестирова-
нием его спека.
Выбор значений для данного атрибута не является обязательным.
CHANGE HISTORY (ИСТОРИЯ ИЗМЕНЕНИЙ)
Это наиважнейший, автоматически заполняемый атрибут. Суть
его в том, что любое изменение бага отражается в нередактируе-
мом многострочном текстовом поле в следующем формате:
• дата и время изменения (date and time of change);
• имя лица, изменившего баг (who changed);
• название измененного атрибута (what was changed);
• предыдущее значение атрибута (previous value);
• новое значение атрибута (new value).
Запомните, что любые действия любого лица, имеющего счет в
СТБ, автоматически записываются, запись доступна для всех
пользователей СТБ и не подлежит редактированию. Таким обра-
зом, можно до секунды увидеть, что конкретно, как конкретно и
кем конкретно было изменено. Анонимность, столь любимая по-
сетителями интернет-форумов, полностью исключена.
Жизнь замечательных багов 233
TYPE (ТИП БАГА)
Это ниспадающее меню со значениями:
• bug (баг),
• feature request (запрос о фича).
По умолчанию значение типа бага (типа записи) — это "баг", т.е.
расхождение между фактическим и ожидаемым результатом, и
95% багов (записей) в СТБ имеет значение "баг".
Компьютерный термин "Feature " не имеет эквивалентного тер-
мина в русском языке, и мы можем
• либо изобрести новое слово,
• либо позаимствовать существующее слово из английского
языка и соответственно писать его русскими буквами (что
мы и сделаем).
Я всегда стараюсь найти подходящий перевод английской тер-
минологии, но иногда это просто не удается, и хотя заимство-
ванные слова, написанные кириллицей, могут поначачу коробить
слух и глаз, это вещь вполне легитимная. Например, книга Васи-
лия Аксенова "В поисках грустного бэби" изобилует такими сло-
вами, так как многие из них просто невозможно правильно пере-
вести (например, "плаза "). Кроме того, есть термины, устояв-
шиеся в профессиональной среде (например, наша "фича ").
Итак, фича — это в зависимости от контекста
• функциональность либо
• характеристика (или свойство) компонента кода, интер-
фейса, базы данных и пр.
Например
Значение "функциональность" работает, если мы говорим о кепча.
Значение "характеристика" работает, если мы говорим об оптимиза-
ции кода с целью улучшения перформанса (скорости работы сайта).
Обратно к Feature request.
Баг с типом Feature request заносится в СТБ с именем продюсера
или программиста в Assigned to, когда у вас родилась идея об
улучшении некой существующей фича или о новой фича.
Значение типа Feature request также используется в баге, служа-
щем основанием для патч-релиза, в случае, когда появилась не-
234 Тестирование Дот Ком. Часть 3
обходимость в срочном изменении кода на машине для пользо-
вателей и это изменение не связано с багом (как отклонением
фактического от ожидаемого).
Логичным будет вопрос: почему мы употребили выражение
"срочное изменение"?
Вот ответ: если нужна новая функциональность, то продюсер
пишет спек, программист его кодирует и т.д. в соответствии с про-
цессом разработки ПО. Каждая стадия процесса имеет свои вре-
менные рамки, которые привязаны к расписанию релизов (release
schedule). А что, если у нас появилась незапланированная потреб-
ность в новой фича и ее нужно срочно выпустить?
Пример
Допустим, мы выпускаем один основной релиз в месяц. Сегодня 10
ноября, и последний основной релиз (7.0) состоялся 31 октября.
Если сегодня (Ю ноября) появилась новая идея (например, о добавле-
нии кепча на страницу регистрации), то если мы включим ее в наш
процесс разработки как любую очередную идею, то наша многостра-
дальная кепча появится на машине для пользователей не 1 декабря в
релизе 8.0 (так как все спеки релиза 8.0 уже заморожены), а 1 января
в релизе 9.0. Таким образом, придется ждать больше полутора меся-
цев. Что делать, если у нас нет полутора месяцев, а есть полтора часа ?
Нужно занести баг "Feature request" с приоритетом П1. Если же фича
может подождать до 8.0, то опять же заносим баг с типом "Feature request",
но уже с приоритетом ПЗ.
Вот такие дела...
STATUS (СТАТУС)
Это ниспадающее меню со значениями:
• Open (Открыт),
• Closed (Закрыт),
• Re-Open (Повторно открыт).
Значение Open присваивается багу автоматически при занесении бага.
Закрыть баг можно только при соответствующей резолюции (об этом
через минуту).
Значение Re-Open выбирается тестировщиком, когда он возрож-
дает к жизни закрытый баг.
Почему возникают ситуации, когда баги приходится открывать
заново?
Жизнь замечательных багов 235
Например
• программист сделал изменение в коде и поломал отремонтиро-
ванный ранее код, так что проблема появилась заново. В этом слу-
чае говорят о том, что баг был reintroduced ("заново внесен на рас-
смотрение" — так себе перевод, но ничего лучше я не нашел);
• баг был найден на машине для пользователей. Программист сде-
лал checkin отремонтированного кода в бранч-версии машины для
пользователей и позабыл сделать checkin в ствол. Следовательно,
в следующем релизе баг появляется снова.
В связи со статусом запомним две вещи:
• ВСЕ найденные баги должны заноситься в СТБ. Исклю-
чений быть не может. Ваша работа как тестировщика —
искать баги. Единственный и неповторимый результат вашей
работы — баг, занесенный в СТБ. Умные программисты ни-
когда на вас не обидятся, так как качество их работы измеря-
ется не количеством багов, ими допущенных, а скоростью,
с которой они эти баги чинят (почти по Глебу Жеглову);
• занесенные в СТБ баги НИКОГДА не удаляются из СТБ.
Чтобы ни случилось, пока живет компания, ее СТБ вклю-
чает ВСЕ баги, найденные в продукте. Администратор СТБ
должен настроить последнюю так, чтобы исключить воз-
можность удаления багов пользователями СТБ.
Таким образом, каждый баг, когда-либо найденный в продукте,
будет иметь одно из трех упомянутых значений статуса.
RESOLUTION (РЕЗОЛЮЦИЯ)
Это ниспадающее меню со значениями:
Not Assigned (не приписан)
Assigned (приписан)
Fix in Progress (баг ремонтируется)
Fixed (баг отремонтирован)
Build in Progress (билд на тест-машину в процессе)
Verify (проведи регрессивное тестирование)
Fix is Verified (ремонт был успешен)
Verification Failed (ремонт был неуспешен)
Can't Reproduce (не могу воспроизвести)
Duplicate (дубликат)
Not a bug (не баг)
3rd party bug (не наш баг)
No longer applicable (поезд ушел)
236 Тестирование Дот Ком. Часть 3
Резолюция — очень важный атрибут, напрямую связанный со
статусом.
Если статус — это своего рода "жив", "умер", "реинкарнировался",
то резолюция — это "поступил в институт", "женился", "купил
машину", т.е. резолюция — это детализация статуса.
Not Assigned (не приписан)
Такая резолюция может быть после того, как баг занесен, но лицо,
занесшее баг в СТБ, не знает, кто может этот баг зафиксировать.
Assigned (приписан)
К новому багу приписан держатель (owner), т.е. лицо, ответст-
венное за совершение следующего действия в отношении бага в
соответствии с процессом.
Как мы помним, у каждого открытого бага всегда есть дер-
жатель.
В случае резолюции Not Assigned держателем бага является автор
бага, не передавший его дальше.
Итак, меняем статус на Assigned, когда передаем баг для ремонта,
и выбираем имя из ниспадающего меню Assigned to.
Fix in Progress (баг ремонтируется)
Это значение резолюции выбирается программистом, когда он
начинает ремонт бага. Держатель бага — программист.
Fixed (баг отремонтирован)
Это значение резолюции выбирается программистом после того,
как он
• отремонтировал баг и
• сохранил код в CVS.
Держатель бага — релиз-инженер.
Build in Progress (билд на тест-машину в процессе)
Это значение резолюции выбирается релиз-инженером (а иногда
и билд-скриптом) после запуска на тест-машину билда с отре-
монтированным кодом, т.е. Build in Progress приходит на смену
Fixed.
Жизнь замечательных багов 237
Здесь нужно заметить, что если даже баг найден на машине для
пользователей, патч-релиз происходит только после того, как ре-
монт протестирован на тест-машине.
Держатель бага — релиз-инженер.
Verify (проведи регрессивное тестирование)
Это значение резолюции выбирается релиз-инженером (а иногда
и билд-скриптом) после того, как билд на тест-машину завершен.
Держатель бага — лицо, чье имя указано в Verifier. Если у вери-
фаера нет возможности проверить ремонт, то он может просто
выбрать другое значение Verifier так, чтобы его коллега принял
груз ответственности.
Fix is Verified (ремонт был успешен)
Регрессивное тестирования бага состоит из двух частей, следую-
щих одна за другой в таком порядке:
Часть 1:
проверка того, что баг был действительно починен, т.е.
четко следуем инструкциям из "Описания и шагов..." для вос-
произведения бага. Если функциональность работает как сле-
дует, то баг действительно был починен.
Часть 2:
проверка того, что ремонт бага не наплодил других багов.
Код — это тонкая материя, состоящая из множества взаимо-
зависимых компонентов, и чем сложнее ПО, тем труднее пред-
угадать, как изменение кода в одном месте отразится на рабо-
те всех закоулков системы. Если программист не указывает в
комментариях, какая часть ПО может быть попутно затронута
ремонтом, я в зависимости от ситуации
• прохожу по приоритетному флоу функциональности,
код которой был отремонтирован, и/или
• делаю энд-ту-энд-тест.
Пример с энд-ту-энд-тестом
в функциональности корзины была проблема с тем, что пользователь
не мог изменить количество книг. Энд-ту-энд-тест, который бы я сделал:
а) добавить в корзину книгу,
б) изменить количество книг и в) произвести оплату.
238 Тестирование Дот Ком. Часть 3
Таким тестом мы проверяем, что флоу, в которое включен отремонти-
рованный компонент, все еще работает.
Изменить резолюцию на Fix is Verified можно непосредственно
после успешного завершения части 1.
При значении Fix is Verified можно закрыть баг. После закрытия
бага у него нет держателя, так как его некуда больше передавать.
После того как резолюция стала Fix is Verified и до закрытия бага
держателем бага является товарищ, который выбрал эту резолюцию.
Verification Failed (ремонт был неуспешен)
Если первая часть регрессивного тестирования показала неус-
пешность ремонта, т.е. баг все еще существует в коде, то мы не
делаем второй части, а просто выбираем это значение резолюции,
после чего держателем бага становится программист, который
починил код.
Can Ч Reproduce (не могу воспроизвести)
Эта неприятная для тестировщика резолюция выбирается про-
граммистом после того, как перед починкой кода он пытается
воспроизвести проблему и не может сделать этого. Как правило,
Can 7 Reproduce имеет место в следующих случаях:
• "Описание и шаги..." содержат неполную, неверную или
нечеткую информацию о том, как воспроизвести баг, и/или
• бага нет, т.е. тестировщик принял за баг правильно рабо-
тающий код.
Одной из основных вещей в отношении багов в ПО является идея
об их воспроизводимости, т.е. если баг существует, его можно
воспроизвести. Бывает так, что тестировщик, найдя баг в ПО,
сразу же открывает СТБ, заносит новый баг и, довольный собой,
продолжает работу. Программист же соответственно бросает ра-
боту, начинает воспроизводить этот баг и после нескольких не-
удачных попыток посылает его обратно тестировщику с резолю-
цией Can't Reproduce. Особенно неприятна ситуация, когда опи-
сание бага содержит сложную и долгую процедуру, необходимую
для воспроизведения.
Лучшим средством превентирования подобных вещей является
правило: "Перед тем как занести новый баг, воспроизведи его
еще раз", т.е., после того как найден баг, необходимо воспроиз-
Жизнь замечательных багов 239
вести его повторно. Это, казалось бы, простое правило поможет и
тестировщику, и программисту быть немного счастливее, а наше
счастье — это счастье пользователей.
Бывают такие случаи, когда очень сложно выявить условия, ко-
торые привели к появлению бага.
Кстати, проведем границу между условиями возникновения бага и
причинами возникновения бага.
Условие появления бага — это непосредственная ситуация, воспроиз-
ведя которую мы воспроизводим баг. Например, пользователь может
добавить кредитную карту с датой истечения действия в прошлом.
Причина появления бага — это конкретная ошибка программиста или
продюсера, результатом которой является баг (например, сделана
ошибка в логике кода).
Идем дальше.
Например, мы увидели баг и не можем воспроизвести его, совер-
шая, казалось бы, те же самые действия, которые привели нас к
багу в самом начале. После того как баг не был воспроизведен,
мы оставляем наши попытки, так как, если баг существует, его
можно воспроизвести, продолжаем работу, а затем снова видим
тот же баг и снова не можем его воспроизвести.
Что я могу сказать? Именно такие ситуации бросают вызов на-
шему профессионализму. Если баг появился один раз и мы никак
не смогли воспроизвести его, то после его второго появления мы
ОБЯЗАНЫ найти условия, в результате которых он появляется.
Такие условия есть всегда, как порой ни сложно найти их.
бог вам история, рассказанная моим приятелем
В одной фармацевтической лаборатории работали четыре сотрудника.
Один из них, сотрудник N., изобрел уникальное вещество, которое
должно было послужить основой нового лекарства. N. составил под-
робный рецепт, но никто из его коллег не смог изготовить то же веще-
ство, хотя они в точности выполняли все шаги. Дошло даже до того, что
троица, стоя по бокам от Л/., повторяла все его действия, и все-таки
вещество получалось только у него одного. В итоге четыре человека с
университетским образованием собрались на совещание и решили,
что они поверят в мистическое происхождение вещества, но после од-
ного последнего теста: АБСОЛЮТНО все действия N. в процессе изго-
товления вещества должны были быть засняты на видеокамеру и тща-
тельно проанализированы.
После съемки, тщательного анализа и последующих тестов разгадка
была найдена: в процессе изготовления вещества сотрудник N. пере-
ходил из одной лаборатории в другую по морозной улице.
240 Тестирование Дот Ком. Часть 3
Так как он был заядлым курильщиком, то перед выходом на улицу, что-
бы освободить руки для зажигалки и сигареты, он клал пробирку
с веществом "ближе к сердцу" — во внутренний карман пиджака, и, таким образом, жидкость в пробирке не охлаждалась, как это было
с коллегами N., которые не курили и переносили пробирки в руках.
Мораль сей истории такова: порой мельчайший нюанс может иметь
радикальное влияние на конечный результат.
Кстати,
условием (а вернее, одним из необходимых условий) для воспроизве-
дения вещества было недопущение охлаждения жидкости в пробирке.
Причиной же появления того или иного итогового вещества были хи-
мические процессы.
Итак, стремитесь к тому, чтобы программисты никогда не воз-
вращали вам баги с резолюцией Can't reproduce.
Держатель — тот, кто занес баг в СТБ.
Duplicate (дубликат)
Эта резолюция выбирается после того, как повторный баг был
занесен СТБ для той же проблемы.
Даже в стартапах в СТБ заносятся сотни и тысячи новых багов, и
порой физически нет возможности просмотреть каждый из них,
так чтобы постоянно быть в курсе дел и не занести баг — дубли-
кат уже существующего. На помощь может прийти модификация
ваших персональных настроек СТБ, где можно предусмотреть,
что вы будете извещаться е-мейлом о всех багах, имеющих опре-
деленные значения определенных атрибутов (например, слово
"корзина" в кратком описании).
Такая резолюция позволяет закрыть баг.
Держатель — тот, кто занес баг в СТБ.
Not a bug (не баг)
Это значение резолюции присваивается, как правило, программи-
стом, когда возникает ситуация "it's not a bug, it's a feature " ("это
не баг, а фича"), т.е. тестировщик принял за баг то, что, по мне-
нию программиста, работает правильно.
Когда возникают подобные ситуации? Например, когда тести-
ровщик создал тест-кейсы, руководствуясь спеком, а програм-
мист создал код, руководствуясь чем-то иным.
Жизнь замечательных багов 241
Почему возникает "руководствуясь чем-то иным"? Из-за плохих
спеков, когда программист фактически делает работу продюсера,
придумывая то, как должны работать функциональности, либо же
из-за того, что программист решает просто "забить", скажем, на
часть спека и сделать по-своему.
Бывает также, что либо тестировщик, либо программист, либо оба
из них неправильно поняли спек.
Бывает также, что программист просто "пропустил" часть спека
и не написал для этой части код.
Причин множество.
Как правило, после того как программист возвращает мне баг с
Not a bug, я читаю его комментарии и принимаю решение о за-
крытии бага или возврате его программисту (меняю резолюцию
на Assigned и меняю мое имя в Assigned to на имя программиста)
с моими комментариями.
Кстати, в зависимости от СТБ и ее настроек значения атрибутов могут быть
а) взаимозависимыми или
б) нет.
Примеры
а) значение атрибута Assigned to меняется автоматически в зависи
мости от резолюции: если программист выбрал Not a bug, значение Assigned to само ме-
няется на имя лица, занесшего баг в СТБ; б) значение атрибута Assigned to статично: после того как программист выбрал резолюцию Not a Bug, он дол-
жен самостоятельно изменить значение Assigned to на имя лица,
занесшего баг в СТБ.
Обратно к Not a bug.
Если нужно, я уточняю у самого программиста дополнительные
детали, и если мы не приходим к консенсусу о том, закрывать баг
либо начать ремонт, то я меняю Not a bug на Assigned, выбираю в
Assigned to имя продюсера и пишу в комментариях, чтобы тот
принял решение, что с этим багом делать.
Важный момент: если проблема была в спеке, то продюсер ста-
новится держателем бага (после того как я изменю Not a bug на
Assigned и выберу имя продюсера в Assigned to), и он должен из-
менить резолюцию на Verify после того, как спек будет изменен.
Я поменяю резолюцию на Fix is Verified, если своими глазами
242 Тестирование Дот Ком. Часть 3
увижу, что спек на самом деле был изменен, изменение было
правильным и спек находится в том месте интранета компании,
где он должен находиться.
Кстати, в некоторых компаниях качество работы тестировщика оцени-
вается (конечно, наряду с прочими факторами) по тому, сколько багов
было закрыто с резолюцией Not a bug от общего количества найден-
ных им багов в том смысле, что, чем больше нот-э-багов, тем хуже по-
работал тестировщик.
В случае если баг, возвращенный с Not a bug, на самом деле не баг,
то держателем становится автор бага и баг может быть закрыт.
3rd party bug (не наш баг)
Во всех интернет-компаниях уже используют ПО, написанное дру-
гими софтверным компаниями, например интерпретатор для лю-
бимого мною языка Python. Допустим, что я нахожу баг и заношу
его в СТБ. Программист начинает поиск причины бага и видит,
что его код работает чики-пики и корень зла находится в "не на-
шем" ПО, которое каким-либо образом связано с нашим кодом.
Что делает программист? Правильно — возвращает мне баг с ре-
золюцией 3rd party bug.
Что может быть дальше?
Вариант 1: мы не можем повлиять на производителей "не нашего'"
ПО так, чтобы они зафиксировали свою проблему (которая стала
нашим багом).
Например, если проблема была в интерпретаторе Python, то един-
ственное, что мы можем сделать, — это найти обходной путь
(workaround). Для того чтобы программист начал искать такой
путь, мы должны оправдать его усилия тем, что закроем баг с ре-
золюцией 3rd party bug и занесем новый баг, над которым он и
станет работать.
Важный момент: этот новый баг будет с типом "Feature Request".
Вариант 2: мы можем повлиять на производителей "не нашего'"
ПО так, чтобы они зафиксировали свою проблему (которая стала
нашим багом).
Одним из видов особей, обитающих в софтверных компаниях,
являются менеджеры проекта (Project Manager or PjM). Менед-
жер проекта — это администратор, который отвечает за проект.
Жизнь замечательных багов 243
Основа его работы — координация между такими частями про-
екта, как идея, дизайн, кодирование и тестирование, и всеми связан-
ными с ними нюансами типа сроков, людей и прочих ресурсов.
Можно также провести аналогию с должностью директора кар-
тины в советском кинематографе, который мог ничего не пони-
мать в работе оператора, но который знач все ходы и выходы,
чтобы достать и пленку, и аппаратуру, и самого оператора.
Менеджер проекта — это первый и главный контакт, кото-
рый должен быть в курсе событий, знать состояние дел и
знать, кто за что отвечает, чтобы быстро и точно переадресо-
вать проблему тому, кто ее может решить.
Кстати, термин "проект" употребляется здесь (в разговоре о менед-
жерах проекта) в двух значениях:
• некая часть ПО, например, "Оплата". У Оплаты может быть свой
менеджер проекта, который на постоянной основе ведает всеми
делами, связанными с ней;
• новая инициатива, например, под названием "Обновление архи-
тектуры базы данных".
Хороший менеджер проекта — это благословение проекта, пло-
хой — его проклятие. Любимое развлечение плохих менеджеров
проекта — организация бесконечного числа бесконечных сове-
щаний с переливанием из пустого в порожнее.
Кстати, я однажды подсчитал, сколько денег компания тратила на ка-
ждое из совещаний по одному из проектов, — цифра была более чем
внушительная. Вот формула для консервативного подсчета стоимости
одного совещания, может быть, пригодится как-нибудь:
total cost of meeting =
=number of participants x median hourly rate x number of hours,
где total cost of meeting — сколько стоит компании одно совещание;
number of participants — число присутствующих на совещании; median
hourly rate — средняя заработная плата в час. Заработная плата каждого
— это вещь индивидуальная, но все равно можно прийти к некой условной
величине, исходя хотя бы из вашей собственной заработной платы; number of
hours — количество часов, которое длится совещание.
Я встречал PJ'MOB очень разных квалификаций и навыков в обще-
нии. Бывали даже случаи, когда я шел к своему менеджеру и про-
сил его дать мне другой проект, так как не хотел работать с неким
конкретным менеджером проекта.
В подавляющем большинстве случаев в стартапах обязанно-
сти менеджера проекта исполняют продюсеры.
244 Тестирование Дот Ком. Часть 3
Итак, обратно к "не нашему" ПО.
Во многих случаях наш веб-сайт так или иначе связан с ПО, ко-
торое принадлежит нашим бизнес-партнерам и ими же поддер-
живается в рабочем состоянии, например это ПО для процессинга
кредитных карт.
Так вот если найденный баг является багом в таком ПО, то тот,
кто исполняет обязанности менеджера проекта, набирает номер
ответственного лица на стороне наших бизнес-партнеров и коор-
динирует действия между нашей и не нашей стороной (например,
нашим и не нашим программистами) по разрешению проблемы.
Может, это и не баг вовсе, а недопонимание нами, как работает
не наше ПО.
Если же это баг, то наш партнер заносит запись о нем в собствен-
ную СТБ.
Далее.
Если это баг, то могут быть следующие варианты:
• баг имеет место быть на не нашей тест-машине, т.е. наша
тест-машина "разговаривает" с их тест-машиной и/или
• баг имеет место быть на не нашей машине для пользовате-
лей (мы выступаем в роли пользователей), т.е. наша машина
для пользователей "разговаривает" с их машиной для поль-
зователей.
В зависимости от того, где был найден баг в не нашем ПО и от
его важности для нас, а соответственно для нашего контрагента,
назначается приоритет, от которого зависит и скорость починки.
Всю координацию от "А" до "Я" с нашей стороны осуществляет
тот, кто исполняет обязанности менеджера проекта.
Итак, если мы можем повлиять на производителей не нашего ПО
и программист вернул вам баг с резолюцией 3rd party bug, вы в
Assigned to выбираете имя того, кто исполняет обязанности ме-
неджера проекта, и, сопровождая баг своими комментариями,
делаете его держателем бага. Он со своей стороны после выясне-
ния: "Кто виноват? Что делать? и Едят ли курицу руками?" —
может вернуть вам баг с резолюцией Not a Bug (если это был не
баг, а недопонимание того, как работает не наше ПО) либо же
вернуть вам баг (путем Assigned to) с той же резолюцией — 3rd
party bug, и вы в обоих случаях спокойно его закроете.
Жизнь замечательных багов 245
Важно: в обоих случаях (когда мы не можем/можем повлиять на
производителя не нашего ПО) наш программист может ошибочно
допустить, что проблема в не нашем ПО, хотя на самом деле это
наш баг. В этом случае тестировщик делает:
Resolution — Assigned
Assigned to — имя программиста.
No longer applicable (поезд ушел)
Такое значение резолюции присваивается багу, который раньше
действительно был багом, но теперь по какой-то причине тако-
вым не является.
Например
мы исполняем тест-кейс по проверке одного из флоу функционально-
сти "Оплата" и видим, что отсутствует поле для ввода номера CW2. Мы
заносим баг и получаем его обратно с резолюцией No Longer Applicable
и комментарием программиста, что согласно багу #7723 с типом "Feature
Request" мы больше не должны спрашивать CW2 у пользователя.
Таким образом, до занесения продюсером бага #7723 ситуация с от-
сутствующим CW2 была бы багом, а теперь это не баг.
Баги, возвращенные с резолюцией No longer applicable, как пра-
вило, возникают из-за отсутствия информации.
В моей практике, если фактический результат после исполнения
тест-кейса расходится с ожидаемым результатом по этому тест-кей-
су, я пытаюсь воспроизвести баг заново, и если он воспроизводится,
то я сразу же заношу его в СТБ. Если же я вижу проблему, которая
не связана с моим ожидаемым результатом и/или функциональ-
ностью, о которой я имею полную информацию, то обычно контак-
тирую с коллегами-тестировщиками, которые владеют вопросом
о функциональности, в которой, как мне кажется, есть баг.
Резолюция No longer applicable позволяет закрыть баг, если он на
самом деле больше не баг.
Процесс трэкинга багов
Теперь, после того как мы поговорили об атрибутах СТБ, посмот-
рим на блок-схему. На ней мы воочию видим основу процесса
трэкинга багов. Эта основа сама по себе является стандартной
версией процесса, и интернет-компании используют ее в таком
либо измененном виде.
246 Тестирование Дот Ком. Часть 3
Процесс трэкинга багов
Жизнь замечательных багов 247
Кстати, для упрощения допустим, что баг заносится тестиров-
щиком (хотя мы знаем, что баг может заноситься кем угодно)
и против кода программиста (хотя мы знаем, что существуют
и баги спека, которые заносятся против продюсера).
Давайте сделаем так:
• сначала рассмотрим процесс концептуально, затем
• привяжем к каждой его стадии наши атрибуты (детальное
рассмотрение процесса), затем
• приведем конкретный пример.
Концептуальное рассмотрение процесса трэкинга багов
Задача 1: После того как мы нашли проблему в ПО, заносим новый
баг.
Задача 2: Программист получает баг, старается понять, в чем про-
блема, и если это действительно баг, то
Задача 3: Программист начинает ремонт.
Задача 4: После того как ремонт закончен, программист
должен сделать checkin кода в CVS.
Задача 5: Релиз-инженер запускает новый билд, чтобы от-
ремонтированный код пришел из CVS на тест-ма-
шину.
Задача 6: Тестировщик проводит регрессивное тестирова-
ние, и если починка НЕ удалась, то
Задача 7: Баг возвращается программисту на но-
вый ремонт.
Если же починка удалась, то
Задача 8: Баг закрывается. Goodbye my love, Goodbye.
Идем обратно к развилке после задачи 2. Допустим, программист
не считает, что зарапортованная ситуация является багом. Тогда он:
Задача 9: Возвращает баг.
Задача 10: Тестировщик старается понять свою ошибку, и
если ошибка имела место и баг соответственно
места не имел, то
Задача 8: Баг закрывается.
Если же тестировщик считает, что это все-таки баг, то
баг отправляется обратно программисту.
Задача 2: Программист снова пытается понять, баг ли это. И т.д.
248 Тестирование Дот Ком. Часть 3
Детальное рассмотрение процесса
Давайте вольем в рассмотренную форму содержимое, состоящее
из атрибутов и их значений, как мы хотим это нашей компании
www.testshop.rs.
Задача 1:
Атрибут Комментарий по заполнению либо
конкретное(ые) значение(я) атрибута
Summary Краткое описание
Description and Steps
to Reproduce
Описание и шаги...
Attachment Используем это поле, если нужна дополнительная
иллюстрация
Assigned to Имя программиста
Component Название компонента
Found on Где был найден баг
Version Found Номер версии
Build Found Номер билда
Severity Значение серьезности
Priority Значение приоритета
Notify list По минимуму — имя продюсера
Type "Bug"
Resolution "Assigned"
Задача 2:
Программист признает, что это баг:
Задача 3:
Resolution "Fix in Progress"
Задача 4:
Resolution "Fixed"
Version Fixed Номер версии
Build Fixed Номер билда
Assigned to Имя релиз-инженера
Задача 5:
Resolution "Build in Progress"
Жизнь замечательных багов 249
и после того, как новый билд появился на тест-машине:
Resolution "Verify"
Assigned to Имя лица из Verifier
Задача 6:
Баг НЕ починен:
Задача 7:
Resolution "Verification Failed"
Assigned to Имя программиста
Баг починен:
Задача 8:
Resolution "Fix is Verified"
Status "Closed"
Обратно к задаче 2:
Программист НЕ признает, что это баг:
Задача 9:
Resolution "Can't Reproduce", либо
"Duplicate", либо "Not a
bug", либо "3rd party
bug", либо "No longer
applicable"
Assigned to Имя тестировщика
Задача 10:
Баг:
Resolution "Assigned"
Assigned to Имя программиста
HE баг:
Status "Closed"
Конкретный пример
Тестировщик Антон Никонов при исполнении тест-кейса #NBST0001
обнаружил новый баг. Он открывает СТБ и заносит в нее нового
жителя:
250 Тестирование Дот Ком. Часть 3
Атрибут: Summary.
Значение:
"Спек. 1211: неверное значение колонки result таблицы
cc_transaction для VISA ".
Атрибут: Description and steps to reproduce.
Значение:
"Description:
При оплате картой VISA в колонке result таблицы
cc_transaction в базе данных записывается неверное значение.
Используйте следующую информацию для воспроизведения
проблемы:
Эккаунт: testuser1/pa$$wOrd
Наименование товара: book117
Данные карты:
Номер: 9999-5148-2222-1277
Окончание действия: 12/07
CVV2: 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. Введи CVV2.
14. Нажми кнопку "Завершить заказ".
15. Запиши номер заказа.
16. Запроси базу данных с SQL1.
Bug: 20.
Expected: 10".
Жизнь замечательных багов 251
Атрибут: Assigned to.
Мистер Никонофф идет на страничку в интранете "Кто ответст-
вен за что" и видит, что программистом Оплаты в настоящее
время является О. Столяров. Так и запишем. Значение:
"О. Столяров".
Атрибут: Component
Значение: "Оплата ".
Атрибут: Found on.
Баг был найден при тестировании на www.main.testshop.rs.
Значение:
"www.main.testshop.rs".
Атрибут: Version Found.
Антон знает, что номер версии и номер билда видны в коммента-
риях HTML-кода на всех страницах нашего веб-сайта. Поэтому он
открывает в окне браузера www.main.testshop.rs, делает клик пра-
вой кнопкой мышки и выбирает View Page Source (посмотреть
код страницы). Запускается текстовый редактор, например Notepad
(Блокнот), в котором виден HTML-код страницы, и в коммен-
тариях Антон находит номер версии и номер билда, например
7.0-58. Значение: "7.0".
Атрибут: Build Found.
Значение:
"55".
Атрибут: Severity.
Это обычный функциональный баг, четко подходящий под СЗ.
Значение:
"С5 ".
Атрибут: Priority.
Мы должны понять, какие будут последствия в случае если зна-
чение колонки result таблицы cc_transaction не равно 10 при оп-
лате карточкой VISA. Мы задаем вопрос программисту, и выясня-
ется, что в этом случае на машине для пользователей транзакция
будет считаться недействительной, даже если деньги с карточ-
ку будут сняты и соответственно пользователь не получит своего
252 Тестирование Дот Ком. Часть 3
заказа. Довольно серьезный баг, если учесть, что VISA — это наи-
более широко используемая платежная система. Исходя из
вышесказанного, мы должны дать багу приоритет П1. Значение:
"Я7 ".
Атрибут: Notify list.
Согласно странице интранета "Кто ответствен за что", оплата ку-
рируется продюсером В. Новоселовым. Значение:
"5. Новоселов".
Атрибут: Туре.
Значение: "Bug".
Атрибут: Resolution.
Мы знаем имя программиста, который должен заняться багом, и
поэтому ставим резолюцию как "Assigned". Значение: "Assigned".
СТБ присвоила багу номер 3221.
После того как баг был занесен, е-мейлы летят к
• А. Никонову (Submitted by — автор бага),
• О. Столярову (Assigned to — держатель бага) и
• В.Новоселову (лицо из Notify list).
Поскольку держателем бага стал Олег Столяров, то за ним и сле-
дующее действие, а именно рассмотрение проблемы.
Проблема рассмотрена, и баг найден в коде Python файла
create_payment.py:
ifcredit card== "VISA":
update _db(" update cc transaction set result = 20 where external
id = " + transaction id).
Этот код, переведенный на язык Пушкина и Булгакова, означает:
Если используется кредитная карта VISA,
сделай значение колонки result таблицы cc_transaction рав-
ным 20 в строке, где значение колонки externalid равно
значению переменной transactionid.
Жизнь замечательных багов 253
Как видим, это простой в починке баг, который исправляется из-
менением цифры 2 на цифру 1:
if credit card == "VISA ":
update_db("update cc transaction set result — 10 where external
id - " + trans action id).
Олежек входит в СТБ:
Атрибут: Resolution.
Значение:
"Fix in Progress ".
Олежек исправляет баг на своем плэйграунде, делает скоренький
юнит-тест и сохраняет баг в бранче CVS для релиза 7.0 и в стволе.
Затем он снова входит в СТБ и передает баг дальше:
Атрибут: Resolution.
Значение:
"Fixed".
Атрибут: Version Fixed.
Значение:
"7.0".
Атрибут: Build Fixed.
Значение:
"59".
Сегодня вторник, а значит, согласно страничке в интранете "Рас-
писание релиз-инженеров", новый билд может запустить для нас
релиз-инженер С. Щетинин, который сегодня находится на де-
журстве по всем вопросам, связанным с багами.
Атрибут: Assigned to.
Значение:
"С. Щетинин".
С. Щетинин, только что вернувшийся с обильного обеда, про-
шедшего в ресторане "Mayflower" в окружении институтских
дружков, таких же, как он, тунеядцев и игроков в покер, получает
от СТБ е-мейл о том, что он стал новым держателем бага #3221.
С. Щетинин является держателем и множества других багов,
ждущих своего регрессивного тестирования. Согласно распи-
санию билдов в компании www.testshop.rs, у нас есть 3 билда
254 Тестирование Дот Ком. Часть 3
в день: в 12:00, 15:00, 18:00 по московскому времени. Сейчас 14:45,
и через 15 минут Станислав должен запустить новый очередной
билд (59) для версии 7.0.
Запустив билд-скрипт для версии 7.0, он входит в СТБ и среди
прочих меняет и #3221:
Атрибут: Resolution.
Значение:
"Build in Progress ".
После того как билд-тест сайта www.main.testshop.rs завершен и не
было никаких ошибок (например, проблем с интеграцией кода одного
программиста с кодом другого), сеньор Щетинин снова идет в СТБ:
Атрибут: Resolution.
Значение:
"Verify".
Атрибут: Assigned to.
Значение:
"А. Никонов".
Если ошибки поломали билд, то начинается выяснение и устра-
нение. Ошибка может быть допущена как релиз-инженером, так
и программистом. В последнем случае срочно посылают е-мейлы
программистам с целью выяснить, чем код поломал билд, чтобы
те немедленно разобрались, в чем дело. Если проблема сломан-
ного билда (broken build) не решается в течение, скажем, 60 ми-
нут, то, согласно правилам нашей компании, С. Щетинин воз-
вращает на www.main.testshop.rs предыдущий билд, т.е. 58.
Тестировщик Антон Никонов получает радостное известие, что
баг #3221 был зафиксирован и отремонтированный код ждет его
на www.main.testshop.rs. Удостоверившись, что www.main.testshop.rs
имеет версию и билд 7.0-59, он исполняет шаги, указанные в
"Описании и шагах..." бага, и, удостоверившись, что значение
result стало равным 10, закрывает баг:
Атрибут: Resolution.
Значение:
"Fix is Verified".
Атрибут: Status.
Значение: "Closed".
Жизнь замечательных багов 255
А затем в качестве второй части регрессивного тестирования ис-
полняет, например, тест-кейс с картой MasterCard. Флоу с
MasterCard — это приоритетное флоу функциональности Оплата,
и неплохая идея проверить, что ремонт ситуации с VISA не сломал
флоу с MasterCard.
Краткое подведение итогов
1. СТБ —это
• с одной стороны, хранилище багов, а
• с другой — средство коммуникации.
2. Баг — это в зависимости от контекста
• расхождение между фактическим и ожидаемым результатами
и/или
• запись (виртуальная карточка) в СТБ.
3. Настройки СТБ определяются процессом, а не наоборот.
4. Настройками СТБ и созданием эккаунтов ведает администратор
СТБ.
5. Занести баг может любой, у кого есть счет в СТБ и соответст-
вующая привилегия.
6. У бага в СТБ есть атрибуты, значения которых позволяют судить
о состоянии и истории бага.
7. Значения некоторых атрибутов присваиваются автоматически
(номер бага).
8. Мы никогда не заносим баг с кратким описанием "Ничего не
работает".
9. Приложение (attachment) — это суперполезная вещь, так как
служит графической (как правило) иллюстрацией бага.
10. У каждого открытого бага всегда есть держатель.
11. На интранете обязательно должна быть страничка "Кто ответ-
ственен за что".
12. Серьезность бага —это техническая категория.
13. Приоритет бага — категория, связанная с бизнесом.
14. Нет ни одного изменения бага, которое бы не стало достоянием
гласности.
15. Функциональность — это только одно из значений емкого тер-
мина фича.
16. Значения резолюции — это этапы жизни бага.
Вопросы и задания для самопроверки
1. Могут ли простые бумажные карточки или текстовый файл слу-
жить в качестве СТБ?
2. Приведите пример формата значения атрибута "Шаги и ожи-
даемый результат".
256 Тестирование Дот Ком. Часть 3
3. Чем били по голове тех, кто заносил баг с кратким описанием
"Ничего не работает"?
4. Перечислите элементы веб-страницы и проблемы, с ними свя-
занные.
5. Как сделать графический файл с тем, что мы видим на экране
монитора?
6. Основная обязанность держателя бага.
7. Что должен проверить Verifier перед началом регрессивного
тестирования?
8. Приведите две части регрессивного тестирования. Нужно ли
проводить вторую часть, если первая не работает? Можно ли
закрыть баг уже после первой части, если ремонт был успешен?
9. В чем концептуальное различие серьезности и приоритета? 10. Кого мы обычно включаем в Notify list?
11. Дайте определение фича.
12. Почему возникают ситуации, когда баги приходится открывать
заново?
13. Что нужно делать для того, чтобы программисты не возвращали
вам баги как "Not Reproducible'"?
14. Почему возникают ситуации, когда баг возвращается с резо-
люцией "Not a bug"?
15. Нарисуйте блок-схему процесса трэкинга багов.
ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ.
СТАДИЯ 1:
ТЕСТИРОВАНИЕ НОВЫХ ФИЧА
• TEST ESTIMATION (ТЕСТ-СМЕТА)
• ENTRY/EXIT CRITERIA (КРИТЕРИЙ НАЧАЛА/ЗАВЕРШЕНИЯ)
• TEST PLAN (ТЕСТ-ПЛАН)
отя при разговоре о процессе разработки ПО мы перевели
"New Feature Testing" как "Тестирование новых компонен-
тов", я предлагаю немедленно заменить "компонентов" на "фича",
так как это более точный перевод и мы уже знаем, что такое фича.
Исполнение тестирования состоит из двух стадий, идущих в сле-
дующей очередности:
1. Тестирование новых фича (new feature testing);
2. Регрессивное тестирование (regression testing).
Сначала о стадии 1.
После того как код проинтегрирован, тест приемки пройден и код
заморожен, мы начинаем тестирование новых фича.
Кстати, тест приемки — это, как правило, эд хок-тестирование, при ко-
тором мы проверяем, работают ли самые базовые вещи, как, например,
создание нового эккаунта. Я рекомендую составить список с такими
базовыми вещами, например:
Создай новый эккаунт
Войди в систему
Добавь книгу в корзину... и во время теста приемки мы просто идем
от строчки к строчке и делаем проверку. Тест приемки считается
пройденным, когда каждый из наших мини-тестов имеет положительный
исход.
257
Комментариев нет:
Отправить комментарий