Что такое превентирование багов
Словарь тестировщика
Баг (bug, дефект) — отклонение фактического результата (actual result) от ожидаемого результата (expected result).
Если проще, то это ошибка.
◓ Пример из жизни.
Смотрим мы прогноз погоды и слышим, что сейчас на улице тепло и солнечно. Мы ожидаем, что при выходе на улицу будет тепло и солнечно (ожидаемый результат). Выходим на улицу, а там холодно и все небо затянуто тучами (фактический результат). То есть мы ждали одного (ожидаемый результат), а получили совсем другое (фактический результат).
Если бы мы вышли на улицу и там было тепло и солнечно, то фактический результат совпал бы с ожидаем и, значит, багов нет и все работает как надо.
◆ Пример из работы.
Возьмем форму авторизации на сайте. Мы ожидаем, что введя в поле “Имя” и в поле “Пароль” те данные, под которыми мы регистрировались, произойдет вход в систему. Если этого не случается, то мы имеем дело с багом.
Тестирование — это процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов.
Если проще, то это процесс проверки работоспособности продукта и его пригодности к использованию. То есть это не просто поиск багов.
◓ Пример из жизни.
Нам дали на проверку кружку. Что мы будем делать? Сначала продумаем, как именно ее можно проверить и набросаем себе план. И только затем присудим к делу. Осмотрим ее снаружи, проверим на трещины, оценим качество рисунка. Уроним ее на пол, чтобы проверить на прочность. Нальем в нее холодную воду, теплую, кипяток, чтобы посмотреть не лопнет ли она. Возьмем ее в руки, оценим, удобно ли держать. После расскажем о результатах нашей работы создателю кружки.
То есть мы не просто ищем дефекты, а проверяем ее со всех сторон и оцениваем, точно ли ей будем удобно пользоваться и выполняет ли она все заявленные функции.
◆ Пример из работы.
Есть задача проверить корзину покупок. Опять же начинаем с планирования. Мы пробуем положить в нее товар, удалить, изменить количество, оцениваем удобство и так далее. После заносим все найденные баги в специальные документы (баг-репорты) и отправляем разработчику (программисту).
Обычно тестирование осуществляется на основании документации, но не всегда.
Техническое задание (ТЗ) – документ, в котором зафиксированы требования к решениям, которые должны быть реализованы в ходе создания сайта или программного обеспечения.
Если проще, то это то, что пишет заказчик, когда хочет получить продукт.
◓ Пример из жизни.
Тесть решил построить дом для тещи и нанял для этого зятя (мужа дочери), который как раз работает инженером. У тестя есть свое видение этого дома. Он рисует и описывает его своими словами и передает мужу.
◆ Пример из работы.
Данный документ описывает, каким именно должен получиться продукт. Исходя из него мы понимаем, что это будет игра в виде фермы, тематика космос и т.д.
Спецификация (specialization, спек) — детальное описание того, как должно работать ПО.
Если проще, то это описание технических свойств своего продукта (размеры, различные параметры, материалы, функции, etc).
◓ Пример из жизни.
Зять читает желания тестя и на их основании уже рисует чертежи, выбирает материал, просчитывает его количество, продумывает как именно технически будет проведены коммуникации (вода, электричество, канализация) и так далее. И уже по этим готовым схемам строители начинают строить дом.
◆ Пример из работы.
На основании ТЗ прописывается, как это все реализовать с технической точки зрения. То есть по спецификации мы будем видеть, как именно должен работать наш продукт. В ней мы пропишем какие семена у нас будут, что из них вырастет, сколько времени займет рост, с помощью чего уже можно ускорить, сколько будут стоить сами семена и т.д.
(!) Все что не соответствует ТЗ и спецификации как раз и будет багом.
Отчет о дефекте (bug report) — документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.
Его еще называют отчет об ошибке, баг-репорт.
Если проще, то это документ, в котором мы фиксируем найденный баг.
◓ Пример из жизни.
Вернемся к нашему забагованному прогнозу погоды. Что делать? Кому и как сообщить, что погода-то совсем не такая, как говорят? Надо просто написать отчет. Причем написать так, чтобы они поняли про какой именно район речь и что именно с этой погодой не так.
◆ Пример из работы.
На каждую найденную ошибку (баг) составляется отчет об ошибке. Данный отчет имеет определенный шаблон. У каждой компании может быть свой шаблон, но основные поля остаются неизменными. Именно этот шаблон позволяет разработчикам быстро ориентироваться и находить ошибку в коде.
Система отслеживания ошибок (bug tracking system) — программа учета и/или контроля багов.
Ее обычно называют баг-трекер или баг-трекинг.
◓Пример из жизни.
Где вы храните информацию о всех ошибках, которые допустила ваша вторая половинка, чтобы при удобной возможности ей это припомнить? Если вы ее где-то записываете и храните в определенном месте, то считайте, что у вас есть система отслеживания ошибок.
◆ Пример из работы.
Каждая фирма использует свою систему учета. Это могут быть как специально разработанные программы, так и обычные гугл-таблицы. Суть в том, что в одном месте собраны все наши отчеты об ошибках и в любое время можно получить доступ к любому отчету и посмотреть пофикшен он или нет.
Пофиксить — внести изменения, а именно исправления, в код программы.
Если проще, то это правка.
◓ Пример из жизни.
Жена сломала дверцу шкафа. Пошла к мужу, привела к дверце за руку, все показала (считайте, что предоставила баг-репорт с прикрепленным видео). Муж сел, там покрутил, тут постучал и дверца опять начала работать как положено. То есть муж исправил (пофиксил) шкаф.
◆ Пример из работы.
Мы создали баг-репорт и отправили в наш баг-трекер. Разработчик взял баг-репорт в работу, изучил его и внес изменения в код. То есть он исправил (пофиксил) код так, чтобы в продукте больше не было бага.
Билд — версионированная сборка программного обеспечения.
Если проще, то это продукт или кусок продукта, который можно тестировать.
◓ Пример из жизни.
Зять строит дом для тещи. Уже готов каркас и пару комнат. Эти комнаты уже можно показать жене на проверку. Именно эти пару комнат, которые ей уже можно смотреть и оценивать — это и есть билд, который будет тестировать жена.
◆ Пример из работы.
Разработчик создает продукт. Часть кода уже написана и готова к проверки. Именно эту часть он и отдает тестировщикам на проверку.
Релиз или RTM (англ. Release to manufacturing — промышленное издание) — издание продукта, готового к тиражированию.
Если проще, то это продукт, который видит конечный пользователь.
Можно сказать, что релиз — это билд, который команда разработчиков предоставляет наружу.
◓ Пример из жизни.
Зять закончил строить дом для тещи. Жена все протестировала. Теперь можно привозить тещу и поздравлять ее с новосельем. То есть готовый дом — это и есть релиз.
Также этот пример наглядно показывает насколько вообще важно тестирование и чем может закончиться ситуация, когда продукт вышел в релиз без этапа тестирования)
◆ Пример из работы.
Разработчик создал продукт. Тестировщик его проверил. Если все хорошо, то принимается решение отдать продукт конечному потребителю.
Выдержки из книги Романа Савина Тестирование DOT COM
Хочу поделиться основными выдержками и тем, что я отметил для себя основного из книги Савина Тестирование DOT COM.
Вот книга кому интересно
Определение бага Итак, баг (bug) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result). Мы имеем баг при наличии любого фактического результата, отличного от ожидаемого. Любое тестирование — это поиск багов. Испытываем ли мы новую соковыжималку, наблюдаем ли за поведением подруги или занимаемся самокопанием — мы ищем баги. Баги находятся следующим образом:
1. Мы узнаем (или уже знаем) ожидаемый результат;
2. Мы узнаем (или уже знаем) фактический результат;
3. Мы сравниваем пункт 1 и пункт 2
Основными источниками ожидаемого результата являются:1. Спецификация.
Спецификация (или spec — читается “спек”. Далее употребляется в мужском роде) — это детальное описание того, как должно работать ПО. Вот так, ни много ни мало.
В большинстве случаев баг — это отклонение от специфика-ции (я говорю о компаниях, в которых спеки в принципе сущест-вуют и ими пользуются).
Цель тестирования — это нахождение багов до того, как их найдут пользователи. Другими словами, вклад тестировщика в счастье пользователя — это приоритет в нахождении багов.
QA — это забота о качестве в виде превентирования появления багов, тестирование — это забота о качестве в виде обнаружения багов до того, как их найдут пользователи.
Общее в QA и тестировании заключается в том, что они призваны улучшить ПО, различие между ними — в том, что
• QA призвано улучшить ПО через улучшение процесса разработки ПО;
• тестирование — через обнаружение багов.
Тест кейс шаги — это инструкция по вводу,
исполнение шагов — это ввод;
ожидаемый результат — это ожидаемый вывод;
фактический результат — это фактический вывод.
Исполнение тест-кейса завершается сравнением вывода факти-ческого и вывода ожидаемого.
Исход исполнения тест-кейса (test case result) Каждый тест-кейс, исполнение которого завершено, дает нам одно из двух:
1. Положительный исход (PASS), если ФР равен ОР, либо
2. Отрицательный исход (FAIL), если ФР не равен ОР: найден баг!
Иногда возникает ситуация, когда мы заблокированы (test case execution is blocked), так как не можем пройти ВСЕ шаги тесткейса. Например, мы не можем продвинуться дальше, если кнопки “Завершить заказ” из шага не существует на соответствующей веб-странице. В таком случае мы рапортуем баг (в данном случае баг об отсутствии кнопки “Завершить заказ”).
Атрибуты тест-кейса
1 УНИКАЛЬНЫЙ ID (Unique ID)ID должен быть уникальным в пределах не только документа, содержащеготест-кейс (об этом документе позже), но и всего департамента
2 ПРИОРИТЕТ ТЕСТ-КЕЙСА (Test Case Priority)Это важность тест-кейса. Важность отражается по шкале от 1 до п,где 1 — это высший приоритет, а п — это низший приоритет.Думаю, что рационально делать п = 4.
3 ИДЕЯ (IDEA)Это описание конкретной вещи, проверяемой тест-кейсом (в даль-нейшем эту конкретную вещь мы также будем называть “идеятест-кейса”).
4 ПОДГОТОВИТЕЛЬНАЯ ЧАСТЬ (SETUP and ADDITIONAL INFO)В подготовительную часть тест-кейса могут включаться:• данные о существующем эккаунте пользователя (legacy useraccount) или инструкции по созданию нового эккаунта (newuser account);• другие данные, используемые в тест-кейсе, например атри-буты используемой кредитной карты;
• запросы к базе данных (SQL queries), используемые в тест-кейсе;
• комментарии в помощь тестировщику, например о нюансах, которые могут встретиться при исполнении тест-кейса;
• другие вещи, облегчающие исполнение и поддержку тест-кейса (о поддержке мы еще поговорим).
5 ИСТОРИЯ РЕДАКТИРОВАНИЯ (Revision History)
| «> Что не должно быть |
| «> 1. Зависимость тест-кейсов друг от друга. |
| «> 2. Нечеткая формулировка шагов. |
| «> 3. Нечеткая формулировка идеи и/или ожидаемого результата. |
Тест-комплекты
Совокупность тест-кейсов (находящихся, как правило, в одном
документе), которые проверяют
• какую-то определенную часть нашего интернет-проекта
и/или
• определенный спек
Атрибуты
Author:
Spec ID:
Priority:
Producer:
Developer:
OVERVIEW:
GLOBAL SETUP and ADDITIONAL INFO:
Author — автор тест-кейсов.
Spec ID — номер (или иной уникальный ID) спека. Сам ID дол-
жен быть линком к спеку в локальной сети (об этом мы еще
поговорим).
Priority — приоритет тест-комплекта (например, от 1 до 4), обыч-
но соответствующий приоритету спека.
Producer — продюсер, написавший спек.
Developer — программист, пишущий код в соответствии со спеком. Искусство создания тест-кейсов
Цикл разработки ПО (cycle) — это путь от идеи до поддержки готового продукта.
Чем более отлажены каждая из стадий цикла и координация меж-
ду ними, тем эффективнее работает интернет-компания, тем вы-
ше качество и тем счастливее пользователи.
Хороший спек, как и хороший закон, отличают следующие вещи:
1. Акцент на деталях и их четкое определение.
2. Забота о недопущении неверного толкования.
3. Непротиворечивость внутри спека и с другими спеками.
4. Логическая взаимосвязь компонентов.
5. Полнота охвата предмета.
6. Соответствие нормативным актам.
7. Соответствие деловой практике.
Спеки имеют следующую очередность статусов:
1. Во время написания они имеют статус Черновик (Draft).
Продюсер пишет спек.
2. После написания и до утверждения — Ожидание утвер-
ждения (Approval Pending).
Спек написан, и назначается совещание (meeting) с про-
граммистами и тестировщиками по его обсуждению или
же просто им посылается е-мейл с приложением.
3. После утверждения — Утверждено (Approved или Final).
Если на митинге все закричали “Ура!” или получены по-
ложительные отзывы от всех реципиентов, утвержденный
спек немедленно выкладывается на один из серверов в ло-
кальной сети, чтобы быть доступным любому лицу внутри
компании, которому положено его видеть. Если же спек не
принят, то все начинается с пункта 1
Юнит-тестирование (unit testing) — это тестирование, произ-
водимое самим программистом. Здесь нужно подчеркнуть, что
неправильный подход к введению юнит-тестирования вызо-
вет справедливое раздражение программистов, так как за тес-
тирование платят тестировщикам, а отсутствие требований к
юнит-тестированию вообще увеличит стоимость багов.
Давайте рассмотрим большую картину цикла разработки ПО в
динамике.
Сначала обобщим знания об игроках, их ролях и стадиях цикла с
их участием.
Игрок
Роль
Стадия
Маркетолог Генерирует идеи и составляет MRD Идея
Продюсер Разрабатывает и документирует
дизайн продукта Дизайн
и документация
Программист Переводит дизайн продукта на язык
программирования Кодирование
Ремонтирует баги Тест и ремонт
Готовится к исполнению
тестирования Кодирование
Исполняет тестирование Тест и ремонт
Цикл тестирования ПО состоит из трех этапов:
1. Изучение и анализ предмета тестирования.
2. Планирование тестирования.
3. Исполнение тестирования.
На любом из этапов может быть найден баг (как в ПО, так и в
документации), баг должен быть отремонтирован ответственным
товарищем (например, программистом или продюсером), и
качество ремонта должно быть сертифицировано тестиров-
щиком.
Свяжем цикл тестирования с циклом разработки:
1. Изучение и анализ предмета тестирования
начинаются перед утверждением спека (в завершение стадии
Разработка дизайна продукта и создание документации) и про-
должаются на стадии “Кодирование”.
2. Планирование тестирования
происходит на стадии “Кодирование”.
3. Исполнение тестирования
происходит на стадии “Исполнение тестирования и ремонт багов”.
Классификация видов тестирования по признаку
состоит из следующих элементов.
Перечисляем:
1. По знанию внутренностей системы:
• черный ящик (black box testing);
• серый ящик (grey box testing);
• белый ящик (white box testing).
2. По объекту тестирования:
• функциональное тестирование (functional testing);
• тестирование интерфейса пользователя (UI testing);
• тестирование локализации (localization testing);
• тестирование скорости и надежности (load/stress/perfor-
mance testing);
• тестирование безопасности (security testing);
• тестирование опыта пользователя (usability testing);
• тестирование совместимости (compatibility testing).
3. По субъекту тестирования:
• альфа-тестировщик (alpha tester);
• бета-тестировщик (beta tester).
4. По времени проведения тестирования:
• до передачи пользователю — альфа-тестирование (alpha-
testing);
– тест приемки (smoke test, sanity test или confidence test);
– тестирование новых функциональностей (new feature
testing);
– регрессивное тестирование (regression testing);
– тест сдачи (acceptance or certification test);
• после передачи пользователю — бета-тестирование (beta
testing).
5. По критерию “позитивности” сценариев:
• позитивное тестирование (positive testing);
• негативное тестирование (negative testing).
6. По степени изолированности тестируемых компонентов:
• компонентное тестирование (component testing);
• интеграционное тестирование (integration testing);
• системное (или энд-ту-энд) тестирование (system or end-
to-end testing).
7. По степени автоматизированности тестирования:
• ручное тестирование (manual testing);
• автоматизированное тестирование (automated testing);
• смешанное/полуавтоматизированное тестирование (semi
automated testing).
8. По степени подготовки к тестированию:
• тестирование по документации (formal/documented testing);
• эд хок-тестирование (ad hoc testing).
По знанию внутренностей системы
При подходе “Черный ящик” тестировщик не основывает
идеи для тестирования на знании об устройстве и логике тес-
тируемой части бэк-энда. Идеи формируются путем предпо-
ложений о сценариях, которые будут реализовываться и при-
меняться пользователями. Такие сценарии называются пат-
тернами поведения пользователей.
БЕЛЫЙ ЯЩИК (white box)
также известен под именами Стеклянный ящик (glass/clear box),
Открытый ящик (open box) и даже Никакой ящик (по box).
В отличие от “Черного ящика” при подходе “Белый ящик” тес-
тировщик основывает идеи для тестирования на знании об
устройстве и логике тестируемой части бэк-энда.
Таким образом, при белоящичном тестировании сценарии созда-
ются с мыслью о том, чтобы протестировать определенную часть
бэк-энда, а не определенный паттерн поведения пользователя.
Тестировочное покрытие (test coverage) состоит из двух вещей:
а. Покрытие возможных сценариев.
б. Покрытие исполнения тест-кейсов.
СЕРЫЙ ЯЩИК (gray/grey box)
Это подход, сочетающий элементы двух предыдущих подходов, это
• с одной стороны, тестирование, ориентированное на поль-
зователя, а значит, мы используем паттерны поведения поль-
зователя, т.е. применяем методику “Черного ящика”;
• с другой — информированное тестирование, т.е. мы знаем,
как устроена хотя бы часть тестируемого бэк-энда, и активно
используем это знание.
По объекту тестирования
Функциональное тестирование (functional testing);
Тестирование интерфейса пользователя (UI testing);
Тестирование локализации (localization testing);
Тестирование скорости и надежности (load/stress/ per-
formance testing);
• Тестирование безопасности (security testing);
• Тестирование опыта пользователя (usability testing);
• Тестирование совместимости (compatibility testing).
ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ (functional testing)
ТЕСТИРОВАНИЕ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ
(UI (читается как “ю-ай”) testing)
Это тестирование, при котором проверяются элементы интерфей-
са пользователя. Мы рассмотрим все основные элементы
ТЕСТИРОВАНИЕ СКОРОСТИ И НАДЕЖНОСТИ
(load/stress/performance testing)
Это проверка поведения веб-сайта (или его отдельных частей)
при одновременном наплыве множества пользователей.
ТЕСТИРОВАНИЕ БЕЗОПАСНОСТИ (security testing)
Тестирование безопасности — это множество вещей, суть кото-
рых заключается в том, чтобы усложнить условия для кражи —
кражи данных, денег и информации.
ТЕСТИРОВАНИЕ ОПЫТА ПОЛЬЗОВАТЕЛЯ
(usability testing)
Юзабилити-тестирование часто проводится путем привлечения
группы потенциальных пользователей с целью собрать впечатле-
ния от работы с системой.
Зачастую опыт пользователя тестируется самими продюсерами
во время написания спека и создания макетов. Есть также про-
фессиональные юзабилити-инженеры.
ТЕСТИРОВАНИЕ СОВМЕСТИМОСТИ
(compatibility testing)
Это проверка того, как наш веб-сайт взаимодействует с
• “железом” (например, модемами) и
• ПО (браузерами/операционными системами) наших поль-
зователей.
По субъекту тестирования
• альфа-тестировщик (alpha tester);
• бета-тестировщик (beta tester).
АЛЬФА-ТЕСТИРОВЩИК (alpha tester)
Это сотрудники компании, которые профессионально или непро-
фессионально проводят тестирование: тестировщики, програм-
мисты, продюсеры, бухгалтеры, сисадмины, секретарши. В стар-
тапах накануне релиза нередко все работники, включая Харито-
ныча, сидят по 16 часов кряду, пытаясь найти непойманные баги.
БЕТА-ТЕСТИРОВЩИК (beta tester)
Это нередко баловень судьбы, который не является сотрудником
компании и которому посчастливилось пользоваться новой сис-
темой до того, как она станет доступна всем остальным. За бета-
тестирование иногда даже платят деньги (вспомните пример с 50
долл. в час за юзабилити-тестирование).
По времени проведения тестирования
ДО передачи пользователю — альфа-тестирование (alpha
testing):
• тест приемки (smoke test, sanity test или confidence test);
• тестирования новых функциональностей (new feature
testing);
• регрессивное тестирование (regression testing);
• тест сдачи (acceptance или certification test),
ПОСЛЕ передачи пользователю — бета-тестирование (beta
testing)
По критерию
позитивности сценариев
• позитивное тестирование (positive testing);
• негативное тестирование (negative testing).
По степени изолированности
тестируемых компонентов
компонентное тестирование (component testing);
• интеграционное тестирование (integration testing);
• системное (или энд-ту-энд) тестирование (system or
end-to-end testing).
Компонентное тестирование (component testing) — это тестиро-
вание на уровне логического компонента. И это тестирование
самого логического компонента.
Интеграционное тестирование (integration testing) — это тести-
рование на уровне двух или больше компонентов. И это тестиро-
вание взаимодействия этих двух или больше компонентов.
Системное (или энд-ту-энд) тестирование (system or end-to-end
testing) — это проверка всей системы от начала до конца.
По степени автоматизированности
тестирования
• ручное тестирование (manual testing);
• автоматизированное тестирование (automated testing);
• смешанное / полуавтоматизированное тестирование
(semi automated testing).
8. По степени подготовки к тестированию
• тестирование по тест-кейсам (documented testing);
• интуитивное тестирование (ad hoc testing).
Подготовка к тестированию с точки зрения тестировщика
включает:
1. Написание новых тест-кейсов и/или
2. Изменение существующих тест-кейсов и/или
3. Удаление существующих тест-кейсов.
Иногда требуется создание/модификация тест-тулов, но об этом
мы здесь говорить не будем, так как фактически тест-тулы — это
чистой воды программирование, облегчающее исполнение тест-кейсов.
Постулат “Software has bugs” (“ПО содержит баги”)
Искусство создания содержательной части тест-кейсов заключается в нахождении тех “золотых”
• идей тест-кейсов,
• сценариев и
• ожидаемых результатов,
которые при исполнении тестирования помогли бы обнаружить
Методы генерирования тестов:
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 МАТРИЧНАЯ РАСКЛАДКА
Одна из прелестей матричного подхода заключается в наглядно-
сти — мы видим перед собой таблицу со структурированными
вариантами сценариев, и нам удобно комбинировать их в более
сложные сценарии или непосредственно переносить их в тест-
кейсы.
3. БЛОК-СХЕМЫ
Блок-схема — это
графическая презентация некого процесса.
В своей работе тестировщики используют ту степень детали-
зации, которая нужна для конкретной ситуации: если мы тес-
тируем саму регистрацию, то нам необходима большая степень
детализации (процесса регистрации) по сравнению с ситуацией,
когда нам нужно увидеть место регистрации как часть процесса
покупки.
Методы отбора тестов
1. Оценка риска (risk estimate).
2. Эквивалентные классы (equivalent classes).
3. Пограничные значения (boundary values).
1 Оценка рентабельности использования ресурсов и перенапровление ресурсов в нужное русло
2. Эквивалентные классы (equivalent classes).
эквивалентный класс — это одно или больше значений ввода,
к которым ПО применяет одинаковую логику.
3. Пограничные значения (boundary values).
Пограничные значения — это конкретные предельные значения, образующие водораздел между эквивалентными классами. Для каждого эквивалентного класса может быть лишь один из трех вариантов: а. Есть только нижний предел (класс 5). б. Есть нижний и верхний пределы (класс 2, класс 3, класс 4). в. Есть только верхний предел (не рассматриваемый в данном примере класс, который ограничен только сверху гипотети ческим отрицательным значением, непосредственно пред шествующим классу 1). Пограничным тестированием (boundary testing) называется применение метода тестирования пограничных значений.
Итак, концептуально СТБ (система трекинга багов) — это инфраструктура, позволяющая
• модифицировать информацию о багах.
Существует множество профессиональных СТБ — от бесплатной Багзиллы (Bugzilla) до многотысячедолларового тест-директора (Test Director by Segue), и естественно, что интернет-компании используют для трэкинга багов не тетрадки или текстовые файлы, а именно специальное ПО, непосредственно созданное для трэкинга багов. О таком ПО и процессе трэкинга багов мы и поговорим сегодня.
Пример Процесса После того как баг заносится в СТБ, его статус автоматически становится “Open”; после того как баг зафиксирован и регрессивное тестирование подтвердило успех починки, мы меняем статус на “Closed”; если же тот же баг, после того как мы его закрыли, был найден снова, то мы меняем “Closed” на “Re-Open”.
Атрибуты бага
BUG NUMBER (НОМЕР БАГА) Каждому новому багу СТБ автоматически присваивает уникальный, следующий по порядку номер. Например, подходите вы к программисту и спрашиваете: “Слушай, браза, как там 1232 поживает?”
SUMMARY (КРАТКОЕ ОПИСАНИЕ) Краткое описание — это максимально информативное и сжатое описание проблемы. Как правило, текстовое поле для краткого описания не превышает 100 символов и в эти 100 символов (включая пробелы) нужно уместить информацию, достаточную для понимания сути проблемы. Кстати, то, как тестировщик формулирует краткое описание, наглядно говорит о его профессионализме.
Пример самого плохого Summary “Ничего не работает”. За такое Summary раньше били по голове канделябром, и хотя сейчас времена другие, но все равно, пожалуйста, никогда, никогда не пишите в кратком описании ничего подобного. Почему поле для краткого описания такое короткое? Потому что баги, занесенные в СТБ, выглядят примерно так, списком, на значения которого можно кликнуть мышкой и получить полную информацию по конкретным багам:
Итак, в кратком описании сжато и информативно излагаем суть проблемы.
DESCRIPTION AND STEPS TO REPRODUCE (ОПИСАНИЕ И ШАГИ ДЛЯ ВОСПРОИЗВЕДЕНИЯ ПРОБЛЕМЫ) Это многострочное текстовое поле. Я пользуюсь следующим форматом для заполнения этого атрибута: Description: Полезная информация о баге: описание, комментарии, нюансы и т.д.
Steps to reproduce: Конкретные шаги для воспроизведения проблемы.
Bug: Фактический результат.
Expected: Ожидаемый результат.
ATTACHMENT(ПРИЛОЖЕНИЕ) Нет лучшей вещи при обмене информацией, чем хорошо подобранная иллюстрация, особенно наглядная иллюстрация. Наш мозг гораздо быстрее воспринимает зрительную информацию, чем текстовую, и мы, зная этот научный факт, можем организовать эффективную презентацию проблемы.
Презентация может делаться, например, путем приложения снимка экрана (скриншота), на котором видна проблема. Вот самый технически элементарный и повсеместно распространенный способ для собственноручного изготовления скриншота: а. На клавиатуре нажимаем кноп
SUBMITTED BY (АВТОР БАГА) СТБ автоматически присваивает значение этому атрибуту. Как нетрудно догадаться, значение “Submitted by ” — это нередактируемый текст с именем товарища, занесшего баг в СТБ (товарищ далее именуется автором бага). Как правило, автором бага является тестировщик.
DATE SUBMITTED (ДАТА И ВРЕМЯ ПОЯВЛЕНИЯ БАГА) Как и в случае с Submitted by, СТБ автоматически присваивает значение этому атрибуту. Как нетрудно догадаться, значение “Date submitted” — это нередактируемый текст с датой и временем, когда баг был занесен в СТБ своим отцом — автором.
ASSIGNED TO (ДЕРЖАТЕЛЬ БАГА) Каждый открытый баг в каждый конкретный момент имеет своего конкретного держателя (Owner). Держатель бага — это участник процесса разработки ПО, на котором лежит ответственность сделать следующий шаг на пути к закрытию бага. Варианты следующего шага определяются процессом.
Когда баг заносится в СТБ, то автор бага обязательно должен выбрать имя из списка ниспадающего меню “Assigned to ” (СТБ выдаст ошибку, если имя не выбрано). Список “Assigned to ” состоит из имен всех пользователей, кто имеет эккаунты в СТБ. Например, мое имя пользователя в СТБ может выглядеть как г savin.
VERSION FOUND (ВЕРСИЯ, В КОТОРОЙ БЫЛ НАЙДЕН БАГ) Это ниспадающее меню с версиями веб-сайта, автор бага обязан выбрать значение, соответствующее номеру версии продукта, в которой был найден баг.
BUILD FOUND (БИЛД, В КОТОРОМ БЫЛ НАЙДЕН БАГ) Это небольшое (примерно 10 символов) текстовое поле, куда автор бага обязан вбить номер билда, в котором был найден баг.
VERSION FIXED (ВЕРСИЯ С ПОЧИНЕННЫМ КОДОМ) Это ниспадающее меню с версиями веб-сайта. После того как программист починил баг, он должен передать этот баг далее (релиз-инженеру), для того чтобы в итоге Verifier произвел регрессивное тестирование (у нас будет подробное объяснения процесса через 5 минут). Программист обязан выбрать номер версии, соответствующий бранчу в CVS, куда он направил отремонтированный код. Version Fixed может иметь, как одно из значений, “N/A ” (Not applicable — “к данной ситуации неприменимо”), которое продюсер обязан выбрать, зафиксировав баг, найденный в спеке.
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) на ПО, исходя из принадлежности бага к определенной технической категории.
С1— КРИТИЧЕСКИЙ Критический системный сбой — ситуация, когда какая-то часть ПО на машине для пользователей “рушится” — например, нажимаете на кнопку “Поиск” и получаете ошибку “HTTP Error 500 Internal server error”. Потеря данных (data loss) — чаще всего это происходит, когда данные: а) не достигают базы данных либо б) незапланированно удаляются из нее.
Например: а) при регистрации е-мейл пользователя не вставляется в опреде ленную колонку определенной таблицы базы данных; б) при обновлении пользователем адреса на фронтенде старый адрес удаляется из базы данных. Проблема с безопасностью — например, когда после логина пароль виден как часть URL, так что кто-то может подсмотреть пароль и использовать его в своих корыстных целях. При современном состоянии дел в Интернете, когда 4% монетарных транзакций осуществляется мошенниками, безопасность — вещь первостепенная.
С2 — ЗНАЧИТЕЛЬНЫЙ Веб-сайт “зависает” — одна из основных бед интернет-проектов, например, нажимаешь на кнопку “Купить”, и следующая страница грузится, и грузится, и грузится… Как правило, после таких “загрузов” очень хочется попробовать веб-сайт конкурента. Баг блокирует кодирование, тестирование или использование вебсайта — ситуация, когда работа тестировщика (и/или программиста) и/или использование веб-сайта не могут быть продолжены, так как на одном из этапов появляется проблема, превентирующая дальнейшее продвижение.
Например, пользователь не может добавить кредитную карту к своему эккаунтуи, следовательно, не может ничего купить на нашем веб-сайте. Термин “блокирование” также связан с понятием “обходной путь” (workaround), а вернее, с отсутствием этого пути. Например, согласно тесткейсу нужно создать эккаунт путем использования тест-тула, но тест-тул не работает (баг в тест-туле является абсолютно легитимным багом!). Если есть возможность найти обходной путь, который разблокировал бы в данной ситуации тестирование, то баг не является блокирующим и не подходит под С2. Примером обходного пути в данном случае является создание эккаунта вручную.
СЗ — УМЕРЕННЫЙ Функциональные проблемы (functional bugs) — под эту категорию подходят все функциональные баги, не подходящие под С1 и С2. Как правило, это простое расхождение между фактическим и ожидаемым результатами, когда все шаги тест-кейса (все этапы флоу) исполнены. СА — КОСМЕТИЧЕСКИЙ Косметическая проблема — баги, связанные с содержанием вебсайта (content), правописанием (spelling) и интерфейсом пользователя (User Interface).
PRIORITY (ПРИОРИТЕТ БАГА) Форма: ниспадающее меню со значениями от Ш до П4 (Ш—4) включительно. Содержание: приоритет бага — это показатель важности бага для бизнеса компании. Кстати, многие товарищи путают приоритет и серьезность. Коренное различие между ними кроется в том, что серьезность отражает технический аспект бага, а приоритет — коммерческий. Серьезность — это категория абсолютная. Приоритет — это категория относительная. Так, если сайт рушится (crash), то это С1, и мы не можем,
Примеры П1 —П2 —всепонятно. ПЗ — каждая стадия цикла разработки ПО имеет свои запланированные временные рамки. Таким образом, если релиз должен состояться 16 марта, тодо 16 марта все ПЗ должны быть зафиксированы из акрыты. П4 — такие баги фиксируются, если у программиста есть время.
Например, в какой-нибудь старой версии браузера интернет/эксплорер (Internet Explorer — IE) не работает какое-нибудь суперзамысловатое флоу, которое вряд ли может прийти кому-либо в голову. У каждой компании есть свои заморочки, но, как правило, все баги П1, П2 и ПЗ должны быть зафиксированы и закрыты до релиза. В случае с ПЗ, если не хватает времени, может приниматься решение о релизе, содержащем баг, с условием, что в течение такого-то периода времени (дни) этот баг будет зафиксирован, протестирован и патчрелиз выпущен на машину для пользователей.
Почему принимается такое решение, которое, казалось бы, противоречит здравому смыслу? Очень просто. Политика, господа: акционеры компании ждут доходов от своих инвестиций, и каждый основной либо дополнительный релиз — это потенциальный катализатор новых прибылей, и такие вещи, как парочка незафиксированных ПЗ, в мире чистогана в расчет не принимаются. Кроме того, менеджменту придется держать ответ перед темиже акционерами, почему релиз не был выпущен вовремя. Иногда опять же по политическим соображениям принимается решение о понижении приоритета бага со всеми вытекающими отсюда последствиями, например,
CHANGE HISTORY (ИСТОРИЯ ИЗМЕНЕНИЙ) Это наиважнейший, автоматически заполняемый атрибут. Суть его в том, что любое изменение бага отражается в нередактируемом многострочном текстовом поле в следующем формате: • дата и время изменения (date and time of change); • имя лица, изменившего баг (who changed); • название измененного атрибута (what was changed); • предыдущее значение атрибута (previous value); • новое значение атрибута (new value).
STATUS (СТАТУС) Это ниспадающее меню со значениями: • Open (Открыт), • Closed (Закрыт), • Re-Open (Повторно открыт). Значение Open присваивается багу автоматически при занесении бага. Закрыть баг можно только при соответствующей резолюции (об этом через минуту). Значение Re-Open выбирается тестировщиком, когда он возрождает к жизни закрытый баг. Почему возникают ситуаци
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 (поезд ушел)
Test Estimation (тест-смета)
Тестировщик готовит тест-смету (Test Estimation), которая включает: • предварительную оценку времени, необходимого на подготовку к тестированию; • предварительную оценку времени, необходимого на тестирование новых фича
Сложность заключается в том, что тест-смета создается после того, как прочитан спек, а между чтением спека и работой по нему такая же дистанция, как между теоретиком и практиком кунфу. Во время работы над спеком, т.е. создания по нему тесткейсов, открываются такие грани и нюансы, о существовании которых было трудно (если не невозможно) предположить во время простого прочтения. Кроме того, всегда есть непредвиденные обстоятельства, среди которых может быть, например, неприлично большое количество блокирующих багов.
Процесс трэкинга багов Теперь, после того как мы поговорили об атрибутах СТБ, посмотрим на блок-схему. На ней мы воочию видим основу процесса трэкинга багов. Эта основа сама по себе является стандартной версией процесса, и интернет-компании используют ее в таком либо измененном виде.
Исполнение тестирования состоит из двух стадий, идущих в следующей очередности:
1. Тестирование новых фича (new feature testing);
2. Регрессивное тестирование (regression testing).
• Test Estimation (тест-смета).
• Entry/Exit Criteria (критерий начала/завершения).
• Test Plan (тест-план).
Вот факторы, которые я рекомендую принять во внимание при составлении сметы: • предполагаемая сложность новых фича. Чем они сложнее, тем больше нюансов всплывет при подготовке и исполнении и тем больше времени понадобится на тестирование; • есть ли у вас опыт тестирования похожих фича.
Например, если вы эксперт в тестировании оплаты, то для вас будет проще и быстрее протестировать добавление еще одного вида кредитной карточки по сравнению с тестировщиком, который никогда кредитных карточек не касался; • опыт работы на прошлых проектах с теми же продюсе ром и программистом. Например, одни программисты пишут удивительно чистый код, всегда проводят юнит-тестирование и с охотой кооперируются с тестировщиками.
Другие же бросают куски кода в проект, как грязь на стену, считают юнит тестирование вещью, не подобающей для компьютерного гения, и не склонны кооперироваться ни с кем, кроме виртуальных солдат игры Halo. Следовательно, во втором случае мы должны заложить больше времени на наше тестирование; • будет ли интеграция нашего ПО с ПО наших бизнес-парт неров — вендоров (vendor), например интеграция с ПО платежной системы. Тест-конфигурация выглядит так: наша тест-машина “разговаривает” с их тест-машиной. Соответственно если что-то не в порядке с их тест-машиной, то проблема решается сложнее, чем при локальном тестировании, когда вы заносите баг и наш программист его ремонтирует. В случае с их тест-машиной
TestPlan (тест-план)
1. Название тест-плана, имя автора и номер версии. Например «Тест-план проекта “Новые алгоритмы для поиска”». Автор Т. Черемушкин. Версия 2. 2. Оглавление с разделами тест-плана: Например Введение стр.
2 Документация с требованиями к ПО стр. 3 и т. д.
3. Введение, в котором мы приводим информацию о сути и истории тестируемого проекта.
4. Документация с требованиями к ПО — здесь мы перечисляем имена, номера и приоритеты спеков и/или другой документации, определяющей тестируемые фича.
5. Фича, которые будут тестироваться, перечисляем и, если нужно, комментируем. Каждой фича назначается приоритет.
6. Фича, которые НЕ будут тестироваться, перечисляем и объясняем, почему НЕ будут тестироваться. Например, частью спека #9172 “Улучшение безопасности платежных транзакций” являются требования к скорости работы веб-сайта (performance). Допустим, у нас нет ни специалиста, ни ПО для тестирования скорости работы, и если мы не собираемся их нанять и приобрести, то указываем, чтоперформанс тестироваться не будет, так как нет ресурсов.
7. Объем тестирования — виды тестирования, которые мы будем проводить, и разъяснения к ним. Например “Системное тестирование будет исполняться для проверки всего флоу оплаты, начиная от добавления книги в корзину и заканчивая проверкой значений базы данных и подтверждением от тест-машины вендора”.
8. Тест-документация — перечисление тест-документации, которая должна быть создана для данного проекта Например “Тест-комплектпо тестированию опека #1288. Тест-комплект по тестированию спека #3411”.
9. Тест-тулы — функциональности тест-тулов, которые должны быть созданы для тестирования проекта.
10. Критерий начала/завершения — те самые критерии, о кото рых мы говорили минуту назад: • критерий начала подготовки к тестированию; • критерий завершения подготовки к тестированию; • критерий начала исполнения тестирования; • критерий завершения исполнения тестирования.
11. Допущения — список допущений, которые мы сделали при составлении данного тест-плана и которые сделаем при тестиро вании. Например, мы допускаем (предполагаем), что код будет заморожен в срок, без задержки.
12. Зависимости — список вещей (с пояснениями), от которых зависит та или иная часть тестирования. Например, покупка новых тест-машин, лицензия на осуществление платежных операций на территории Великобритании.
13. “Железо” и ПО — список и конфигурации “железа” и ПО, которые будут использоваться при тестировании.
14. Условия приостановки/возобновления тестирования — это условия, при которых тестирование должно быть остановлено/ продолжено. Например, к условию приостановки можно отнести количество П1 багов, при котором (и/или после которого), по мнению автора (-ров) тест-плана, дальнейшее продолжение тестирования не имеет смысла (например, 7 П1). Соответственно условием возобновления должно быть количество оставшихся П1 багов (после ремонта и регрессивного тестирования), которое позволяет возобновить тестирование (например, 2 П1).
15. Ответственные лица — подробный список товарищей (продюсеров, программистов, тестировщиков и пр.), контактная информация и обязанности каждого из них. Такой список может включать лиц со стороны вендора.
16. Тренинг — тренинг, необходимый для данного проекта. Например, при соответствующей ситуации нужно указать, что для создания тесткейсов тестировщику необходимо прослушать семинар “Банковская система США”.
17. Расписание — сроки, имеющие отношение к тестированию данного проекта:
• дата замораживания спеков;
• дата начала подготовки к тестированию;
• дата завершения подготовки к тестированию;
• дата интеграции и замораживания кода;
• дата начала тестирования новых фича;
• дата завершения тестирования новых фича;
• дата начала регрессивного тестирования;
• дата завершения регрессивного тестирования.
18. Оценка риска — предположение о том, как и что может пой ти по неправильному пути и что мы в этом случае предпримем. Например, если мы не успеваем закончить тестирование (не выполняем требование “Условия завершения”, например, “все тест-кейсы исполнены”) в срок, то придется задерживаться на работе и приходить в офис в выходные и праздники. Кстати, если народ приходит в выходные и праздники, то компания должна, по крайней мере, кормить его обедом.
19. Прочие положения — вещи, не вошедшие в тест-план, о которых неплохо было бы упомянуть.
20. Утверждения — это подписи лиц, которые утвердили тестплан. Чем больше будет таких подписей, тем лучше. По крайней мере, нужны подписи менеджера тестировщика, составившего план, самого тестировщика, продюсера и программиста.
21. Приложения — например, расшифровка терминов и аббревиатур, используемых в тест-плане. Это все о тест-планах и о первой стадии исполнения тестирова
Регрессивное тестирование как второй этап исполнения тестирования — это проверка того, что изменения, сделанные в ПО (для того, чтобы мир увидел новые фича), не поломали старые фича.
1. Выбор тест-комплектов для регрессивного тестирования.
2. Решение проблемы противоречия между ограниченными ресурсами (например, время на регрессивное тестирование) и перманентно у
Первый вопрос: “Как узнать, какие части ПО могут быть поломаны?” С одной стороны, как мы уже не раз говорили, в сложной системе, которой является более или менее серьезный веб-сайт, во многих случаях сверхсложно определить, где и как откликнется изменение кода, с другой — мы все-таки можем предполагать: • к какой части ПО принадлежат новые фича
(например, фича из спека #5419 “Новые функциональности для Корзины” принадлежат к “Корзине”) и • какие старые фича напрямую зависят от части ПО с новыми фича (например, компонент “Оплата” использует данные (по ценам книг), которые передаются ей компонентом “Корзины”). Решение следующее: Первой группой кандидатов для регрессивного тестирования у нас будут тест-комплекты, проверяющие часть ПО, к которой принадлежат новые фича. Например, при новых фича для “Корзины” в первую группу идут все тест-комплекты, непосредственно тестирующие “Корзину”.
Второй группой кандидатов для регрессивного тестирования у нас будут тест-комплекты, проверяющие старые фича, которые зависят от части ПО с новыми фича. Например, при новых фича для “Корзины” во вторую группу мы можем отнести тест-комплекты, проверяющие “Оплату”. Рациональное объяснение: если даже программист НЕ сломал ничего, есть большая вероятность того, что код фича, напрямую зависящей от измененной части ПО, также нуждается в модификации (о необходимости которой и продюсер, и программист могли просто… забыть).
Выводы
1 Тест-смета необходима для приведения к одному знаменателю потребностей компании и возможностей тестировщиков.
2. Каждый этап тестирования начинается/заканчивается при наступлении условия начала/завершения.
3. Тест-план — это документ, обобщающий и координирующий тестирование.
4. Приоритезация тест-комплектов и тест-кейсов имеет наиважнейшее значение, так как в условиях постоянного дефицита ресурсов у нас, как правило, есть время только на проверку главного.
5. Из всех способов решения проблемы асинхронизации ресурсов и объема регрессивного тестирования наем новых людей самый простой и недалекий.
6. Лучше хороший черноящичный тестировщик, чем один или больше плохих инженеров по автоматизации регрессивного тестирования.