Проблемно-зависимые архитектуры
Рассмотренные ранее архитектурные модели являются обобщенными. Они широко применяются для многих классов приложений. Наряду с основными моделями, используются архитектурные модели, характерные для конкретной предметной области приложения. Эти модели называются проблемно-зависимыми архитектурами.
Можно выделить два типа проблемно-зависимых архитектурных моделей.
1. Модели классов систем. Отображают классы реальных систем, вобрав в себя основные характеристики этих классов. Как правило, архитектурные модели классов встречаются в системах реального времени, например в системах сбора данных, мониторинга и т.д.
2. Базовые модели. Более абстрактны и предоставляют разработчикам информацию по общей структуре какого-либо типа систем. Например, в работе [298] предложена базовая модель разработки ПО.
Конечно, четких различий между этими видами моделей нет. В некоторых случаях могли классов служат в качестве базовых. Здесь я провожу различие между ними, поскольку 1зовые модели можно напрямую повторно использовать в проекте. Базовые модели зычно используются в системах коммуникаций и при сравнении возможных системных архитектур. Различны также процессы разработки этих моделей. Модели классов разрабатываются как обобщение существующих систем "снизу вверх", в то время как разработка адовых моделей идет "сверху вниз".
Модели классов систем
Модель компилятора, вероятно, наиболее известный пример архитектурной модели класса систем. В настоящее время разработаны тысячи компиляторов. Считается, что компилятор должен включать перечисленные ниже модули.
1. Лексический анализатор, транслирующий входной язык в некоторый внутренний код.
2. Таблица идентификаторов, выдаваемая лексическим анализатором, в которой содержится информация об используемых в программе именах и типах.
3. Синтаксический анализатор, который проверяет синтаксис компилируемого кода. Он использует заданную грамматику языка и создает синтаксическое дерево.
4. Синтаксическое дерево, которое представляет внутреннюю структуру компилируемой программы.
5. Семантический анализатор, который проверяет семантическую корректность программ на основании информации, полученной из синтаксического дерева и таблицы идентификаторов.
6. Генератор кода, который проходит по синтаксическому дереву и генерирует машинный код.
Базовые архитектуры
Архитектурные модели классов систем отражают архитектуры уже существующих систем. В противоположность им базовые модели обычно появляются как результат исследований в определенной предметной области приложения. Они представляют собой идеализированную архитектуру, в которой отражены особенности, присущие системам, работающим в данной предметной области.
Примером базовой архитектуры может служить модель OSI, являющаяся стан-1ртом взаимодействия открытых систем. Если некоторая система совместима с этой моделью, она может взаимодействовать с любыми другими системами, поддерживающими этот стандарт. Таким образом, система управления ассортиментом товаров в супермаркете, разработанная на основе модели OSI, может непосредственно осуществлять обмен данными с системой заказов поставщиков, также разработанной на основе этой модели.
С другой стороны, базовые модели обычно не рассматриваются в качестве методов -реализации. Их основное назначение — служить эталоном для сравнения различных систем в какой-либо предметной области, т.е. базовая модель является стандартом при оценки различных систем.
Литература:
Ларман, Крэг. Применение UML и шаблонов проектирования.: Пер. с англ..: Уч. Пос. – М.: Издательский дом «Вильямс», 2001. – 496 с.: ил. – Парал. Тит. Англ..
Соммервилл, Иан. Инженерия програмного обеспечения, 6-е издание.: Пер. с англ.. – М.: Издательский дом «Вильямс» 2002. – 624 с.: ил. – Парал. Тит. Анг.
Ф.Брукс. Мифический человеко-месяц или как создаются программные системы. – пер. с англ. – СПб.: Символ-Плюс, 2001.-304 с.: ил.
Лекция 1: Основы Software Quality Control в терминах и определениях. Интеграция Software Quality Control в Software Development Process
Введение в SQC-курс
Введение в тестинг
Кто такой тестировщик?
Качества которыми должен обладать тестировщик
Что необходимо уметь и знать тестировщику
Что такое ошибка (bug)?
Классификация ошибок
Тип ошибки (Type)
Серьезность ошибки (Severity)
Приоритет ошибки (Priority)
Статус ошибки (Status)
Что такое тест?
Классификация тестов
Что такое Test Case?
Заметки по терминологии
Краткий обзор Software Development Process
Модель жизненного цикла продукта
Что такое Software Development Process?
Место тестирования в Software Development Process
Стадии тестирования
Введение
Обработка входной документации
Разработка рабочей документации
Test cycle (непосредственное тестирование)
Test outcome (результаты)
Тестирование (тестинг) – деятельность, требующая терпения, внимания к деталям и весьма непрямолинейного мышления. Иногда менеджеры делают ошибку, рассматривая тестирование как работу второго сорта, которую могут выполнять менее квалифицированные или более младшие сотрудники. Такое искаженное восприятие служит плохую службу как проекту, так и сообществу тестировщиков.
Тестирование – это процесс, направленный на выявление характеристик системы и демонстрации различий между ее требуемым и фактическим состоянием.
Цель тестирования – распознать дефекты в объекте тестирования и увеличить вероятность того, что он при любых обстоятельствах будет работать в соответствии с установленными требованиями.
Это специалист, который способен рассматривать проблему с точки зрения пользователя, а обсуждать ее с разработчиком на языке программиста.
Тестер должен быть знаком с основными понятиями, исходя из поставленной задачи, т.е. хорошо владеть терминологией.
Тестер должен знать операционную систему, в которой производится тестирование, хотя бы на уровне «продвинутого» пользователя.
Тестер должен хорошо изучить тестируемую программу (здесь многое зависит от документооборота между ним и разработчиком).
Желательно, чтобы тестер имел хотя бы базовые знания в том языке программирования, на котором разработана тестируемая программа.
Тестер должен уметь пользоваться специальным ПО для тестирования, в том числе автоматизированного.
Тестер должен уметь писать, читать, а иногда и рисовать.
Баг (bug) – это отклонение фактического результата (actual result) от ожидаемого результата (expected result)
Ошибки бывают разные, и классификаций ошибок тоже существует много – в каждом проекте свой набор. Здесь мы просто перечислим некоторые виды и типы ошибок, чтобы стало понятно, как вообще они могут различаться.
Тип ошибки (Type)
Functional – ошибка, затрагивающая функциональность, то есть, нарушение работы той или иной функции.
GUI – ошибка, затрагивающая графический интерфейс пользователя, его дизайн.
Error Handling – ошибка в обработке некорректных действий пользователя или коллизий в процессе выполнения программы.
Setup – баги при инсталляции и настройке программы.
Documentation – ошибки в документации.
Серьезность ошибки (Severity)
Cosmetic – ошибка дизайна графического интерфейса (например, не тот цвет линии или шрифт), такая ошибка не мешает программе работать, но портит ее «товарный вид».
Minor – теоретически малозначимая ошибка, почти не влияющая на работу программы.
Major – ошибка, которую не стоит игнорировать, так как она заметно влияет на работу программы.
Critical – серьезная ошибка, способная «повесить» программу или лишить ее важной функциональности.
Causes crash – очень серьезная ошибка, которая может привести к краху системы.
Приоритет ошибки (Priority)
Приоритет ошибки отличается от серьезности тем, что привязан не к работоспособности программы, а к плану работ над программой. Бывает, что несерьезная ошибка получает более высокий приоритет, так как ее можно успеть исправить до конкретной даты, а серьезная получает низкий приоритет, и ее исправление переносится на следующую фазу развития проекта.
Low – приоритет низкий, не требует срочного исправления, возможно «откладывание» исправления на определенный срок.
Medium / Normal – приоритет данной ошибки является нормальным (срочность исправления оценивается самим разработчиком). Исправляется в порядке основной очереди.
High – требует срочного, иногда немедленного исправления.
Стиль названий приоритетов может быть и таким:
ASAP (as soon as possible) – исправление требуется так скоро, как это возможно. Обычно это равнозначно Medium или Normal.
Before next build – ошибку нужно исправить до следующей сборки программы.
Before release 2 – ошибку нужно исправить до выпуска версии 2.
Статус ошибки (Status)
В практике чаще всего используются следующие статусы ошибки:
New / Submitted / added (новая, добавлена) – ошибка только открыта и еще не была обработана. Когда тестер открывает ошибку, то первым информацию о ней получает некто по умолчанию (для разных тестируемых систем это может быть менеджер, старший разработчик и т.д.), читает ее, и переправляет (назначает) разработчику, который непосредственно будет ее исправлять.
Ошибка переходит в состояние Assigned (назначена) когда исправление поручено конкретному лицу (разработчику). По мере работы, этот разработчик может переадресовать ошибку другому разработчику, который, например, знает данную часть системы лучше. К сожалению, иногда это порождает ситуации, когда ошибка «плутает» от одного разработчика к другому.
Когда разработчик ошибку исправляет, ее статус превращается разработчиком в Resolved / Fixed (исправлена). В этом случае тестировщик обязан перепроверить факт исправления.
В случае, если ошибка изначально не повторяется на стороне разработчика (по его мнению, ошибки нет), он превращает ее статус в Rejected (отклонена) и «переправляет» тестировщику обратно (с комментариями своего решения).
Если тестировщик получает «свою» ошибку со статусом rejected, он обязан перепроверить ее, после чего или закрывает ошибку, или присваивает ей статус Re-Open (открыта заново), когда ошибка все же существует (но ему следует улучшить описание ошибки, чтобы разработчик ее, наконец, обнаружил). Также этот статус получает ошибка, которая была объявлена как fixed, но при перепроверке оказалась не исправленной вследствие тех или иных причин.
Если ошибка о той же проблеме уже есть (внесена другим тестировщиком или разработчиком), то ее статус помечается как Duplicated (аналогичная уже имеющейся).
In Process / Open (в процессе) – ошибка зарегистрирована и принята, сообщение разработчиком прочитано, понято (или обсуждено), работа над ошибкой ведется.
Cannot Verify (невозможно перепроверить) – статус тех ошибок, которые были исправлены разработчиком, но не могут быть проверены тестировщиком по ряду причин (например, ошибка была описана разработчиком, но не воспроизводилась на машине тестировщика из-за различий в аппаратных конфигурациях компьютеров, следовательно после ее исправления она не может быть проверена, так как не воспроизводилась ранее).
Cannot Reproduce (невозможно воспроизвести) – часто аналогично rejected, статус ошибки, которая воспроизводится у тестировщика, но не воспроизводится у разработчика (или наоборот) по ряду причин.
Deferred / Postponed (отложена) – исправление ошибки отложено до выхода новой версии, обновления версии или на определенный/неопределенный срок.
Verified, Closed (проверена и закрыта) – статус тех ошибок, которые были исправлены разработчиком, и этот факт подтвержден тестировщиком.
Searching Conditions (поиск условий) – статус ошибки, появление которой было зафиксировано тестировщиком, но условия ее воспроизведения не ясны. Требуется дальнейшая работа по локализации условий воспроизведения ошибки. Может быть «понята» разработчиком при наличии дополнительных инструментов тестирования (дополнительных логов, специальных утилит) или фрагментов кода программы, написанного другим разработчиком.
Will not be fixed (не будет исправлена) – ошибка, которая по различным причинам не может быть исправлена ответственным за нее разработчиком. Такой статус требует аргументированного комментария разработчика.
Not a bug (не баг) – ошибка на самом деле ею не является. Как правило, это касается тех особенностей программы, которые не были описаны в документации и были восприняты тестировщиком как ошибки.
Verified (исправление подтверждено) – ошибка исправлена и перепроверена тестировщиком, однако пока не закрыта (например, историю ошибки должен изучить еще кто-то перед тем, как она будет закрыта).
Closed (закрыта) – ошибка исправлена, перепроверена, исправленный код помещен на живую систему, или выпущен новый билд (сборка). Запись об ошибке отправляется в архив.
Тест – это исполнение части программы с целью верифицировать (проверить) отдельный ее компонент на предмет содержания ошибок. Большие составные тесты могут дробиться на простые, которые проверяют буквально один так называемый тестовый случай (test case), такой как поведение надписи при наведении указателя мышки или внешний вид кнопки в нажатом состоянии, или, скажем, звук сворачивающегося окна. По мере готовности объекта тестирования большие тесты могут включать в себя уже более сложные действия, которые в будущем будет выполнять конечный пользователь, – так называемые случаи применения (use cases). Это могут быть логически отделяемые задачи: набрать номер на клавиатуре телефона, открыть файл для редактирования, сделать заказ на сайте и т.д.
Обычно тесты проектируются и описываются в документации самими тестировщиками.
Тесты можно классифицировать следующим образом:
GUI-тесты (тестирование графического интерфейса пользователя). Т.е. тестирование интерфейса – экранов, кнопок и т.д. Большая часть функциональности ПО реализуется, как правило, через пользовательский интерфейс.
Функциональное тестирование. Подразумевает воспроизведение действий пользователя для решения поставленной задачи с проверкой реакции ПО на эти действия.
Тестирование производительности. Т.е. тестирование ПО в имитационной и реальной средах.
Нагрузочное тестирование (стресс-тесты). Т.е. тестирование в экстремальных условиях (нехватка памяти, дискового пространства, одновременное использование большим числом пользователей, функционирование в непрерывном режиме и т.д.). В эту группу относят тесты на заведомо дефектном («условно рабочем») оборудовании.
Регрессионное тестирование – повторное тестирование всей системы после внесения изменений для проверки корректности ее работы (все протестированное ранее тестируется повторно). Обычно используется на последних этапах ЖЦРПО (жизненный цикл разработки программного обеспечения).
Производственные тесты (профилактические). Цель – убедиться, что за время эксплуатации не произошло никаких ухудшений в работе системы с точки зрения производительности или функциональности («предполетные испытания»).
Тестирование запаса прочности. Выполняется после введения системы в эксплуатацию для выяснения нераскрытых ее возможностей. Последние две группы проводятся заказчиком в ходе эксплуатации системы.
Тест-кейс – это минимальный элемент тестирования. Хороший тест-кейс состоит из трех частей:
1) привести тестируемый продукт в нужное состояние;
2) верифицировать то, что подлежит проверке;
3) привести продукт в исходное состояние.
Существенно то, что акт верификации только один. Именно поэтому тест-кейс нельзя раздробить, разбить на несколько тест-кейсов. Именно поэтому он является минимальным элементом проверки. Если верификаций больше, чем одна, то это не очень правильный тест-кейс.
Однако есть такое нежелательное, но иногда вынужденное явление как составной тест-кейс. И часто бывает, что одно действие просто невозможно проверить без выполнения еще пяти перед ним (которые тоже надо протестировать). Например, чтобы проверить, что после заполнения формы и ее отправки появляется страница с благодарностью, мы вынуждены проконтролировать, что поля формы перед отправкой заполнены правильно, так как если неправильно, то должна появиться страница с описанием ошибки заполнения формы.
Первый и третий компоненты тест-кейса тоже очень важны. Они делают тест-кейс независимым от других тест-кейсов. Их можно выполнять в любой последовательности. Это исключительно важно при автоматизации тестирования. Но и для ручного тестирования это тоже важно.
Зачастую путают тестирование и обеспечение качества, причем как у нас, так и за рубежом.
QUALITY CONTROL (QC, контроль качества) измеряет качество продукта, а QUALITY ASSURANCE (QA, гарантия качества) измеряет качество процессов, используемых для создания качественных продуктов. Тестирование (QC) имеет дело только с качеством продукта, а вся система качества включает в себя также и обеспечение качества процессов (QA), применяемых в производстве. Однако на практике тестирование часто вместо QC обозначается тоже QA, это, похоже, стало уже традицией.
Стандарт качества ISO 9000/2000 определяет, что процесс проверки продукта на соответствие входным данным (требованиям, спецификациям) называется верификацией, а валидация – это проверка продукции на соответствие потребностям пользователя. Другими словами, верификация отвечает на вопрос «правильно ли мы делаем работу?», а валидация – «правильную ли работу мы делаем?».
Верификация происходит при помощи статических методов, валидация – динамических. При статических методах программный код не исполняется, тестирование производится при помощи группы методов STR (Software Technical Reviews), то есть, тестируется документация. При динамических программа запускается на выполнение, тестирование происходит по методу, так называемых, «черного ящика» (код программы закрыт и не нужен для тестировщиков) или «белого ящика» (тестировщику необходимо вникать в технологии и код).
Software Development Process – структура наложенная на разработку ПО. (Wikipedia)
Процессы разработки ПО состоят из множества этапов. Ниже приведены самые основные активности, которые расположены в последовательности «водопадного» процесса (Waterfall process). Последовательность этапов в других процессах может быть изменена.
Анализ требований (Requirements Analysis)
Составление требований, которым должен соответствовать разрабатываемый продукт, является первым шагом к созданию требуемого ПО. Пока заказчик, возможно, считает, что он знает, что должно делать требуемое ПО, может потребоваться знания и опыт в разработке ПО, чтобы распознать недостаточность, двусмысленность и противоречия в требованиях.
Спецификации (Specification)
Эта активность предполагает точное описание ПО, которое требуется разработать в строгой математической форме. В реальности самые удачные спецификации пишутся на понятные и точно урегулированные приложения, которые были успешно разработаны в прошлом. Спецификации наиболее важны для заказчиков которые хотят убедиться в стабильности будущего продукта.
Программная архитектура (Software Architecture)
Архитектура ПО является абстрактным представлением разрабатываемого приложения. Основная цель данного этапа – убедиться что система будет соответствовать требованиям, а также будущие требования смогут быть реализованы. Еще одной важной целью на данном этапе является рассмотрение всех интерфейсов между разрабатываемым продуктом и другим ПО, а также определение необходимых аппаратных средств и ОС для успешной разработки.
Программирование (Coding)
На данном этапе создают дизайны (design в данном случае – это фаза в разработке ПО, на которой функциональные спецификации транслируются в текст программы) и реализуют их с помощью определенных технологий и языка программирования. Упрощение программирования с помощью дизайнов является очевидной частью разработки ПО, однако составление дизайнов не должно быть большой частью данного этапа.
Тестирование (Testing)
Тестирование частей системы, особенно в тех местах где код двух или более разработчиков должен работать вместе.
Документирование (Documentation)
Важная часть (которой зачастую не придают значения) - документирование внутренних дизайнов ПО для дальнейшей поддержки и расширения. Документация – самый важный этап для заказчика.
Поддержка (Maintenance)
Поддержка и расширение ПО совместно с найденными проблемами или новыми требованиями могут требовать намного больше времени, чем разработка самого ПО. Не только добавление кода, который не был написан в соответствии с дизайном, а и определение, как ПО работает с разных сторон после окончания разработки, может потребовать значительных усилий со стороны инженеров. Около 2/3 работы всех инженеров – поддержка, однако такая статистика может ввести в заблуждение. Лишь малая часть поддержки это исправление ошибок. Большая часть – это добавление новых возможностей системы.
Анализ требований
Процесс статического тестирования начинается с определения и анализа требований к системе. Изучаются и уясняются:
существующие материалы и методические вопросы (техническое задание на разработку, рабочий и технический проект и др.);
основные используемые понятия;
термины и определения;
ожидаемые функциональные требования к системе, такие как требования к интерфейсу (описывают входы, получаемые из внешних систем, и выходы, направляемые во внешние системы, накладываются ли на эти интерфейсы какие-то ограничения), данным (описывают входные и выходные данные системы, формат данных, их хранение), производительности (описывают проблемы масштабирования и синхронизации, например, сколько пользователей одновременно должна обслуживать система);
требования к пользователям и человеческому фактору (кто будет работать с программным обеспечением, учет необходимого уровня удобства и простоты использования);
требования к физическим средствам тестирования (операционная система под управлением которой выполняется программный продукт, и вычислительная платформа, на которой эксплуатируется система);
требования к безопасности (доступ к программному продукту и управление данными), документации (определяется в каком виде она должна быть и должна ли быть вообще);
требования к устранению неисправностей (реакция системы на неисправности);
требования к сопровождению (определяется, как производится устранение проблем, обнаруженных в системе).
На данной стадии документация по тестированию не разрабатывается.
Планирование процесса тестирования
Для того чтобы тестирование было эффективным, необходимо потратить значительные средства и усилия на планирование. Действия, выполняемые на стадии планирования испытаний, представляют собой подготовительные работы для этапов системных и приемочных тестов. На этапе планирования определяется стратегия тестирования, производится оценка времени для проведения тестовых работ, определяется состав и структура испытательной системы (выявление аппаратных и программных средств тестирования), подготовка и утверждение плана проведения испытаний. План проведения испытаний дает описание подхода, который предусматривается задействовать при проведении тестирования, а также объем трудозатрат на тестирование.
На данном этапе разрабатывается Master Test Plan.
Проектирование тестов
На этапе проектирования и разработки тестов определяются цели теста, спецификация для ввода каждого теста, тестовая конфигурация. Производится автоматизация часто используемых тестов, требующих больших затрат времени. Разрабатывается методика тестирования, обладающая требуемым уровнем детализации. В результате выполнения этих действий будет получен набор тестовых случаев, который может использоваться для проведения системных испытаний.
На данном этапе разрабатываются System Test Plan для каждого модуля тестируемой системы (или один для всех модулей). System Test Plan может быть разбит на две части: High Level Test Description (содержит общие тестовые случаи) и Low Level Test Description / Test Specification (содержит детальные тестовые случаи).
Реализация и отладка тестов
После этапа проектирования тест необходимо проверить на наличие дефектов с целью их немедленного устранения и затем испытать на некоторой сборке программного продукта. После прогона тестов необходимо провести анализ неудачных результатов прогона тестов, выяснить причину неудачи теста – программный код или сам тест.
На данном этапе усовершенствуется документация, разработанная на предыдущем этапе.
Системное тестирование (System Testing)
Входными данными для системного тестирования являются набор завершенных отлаженных тестов. Системное тестирование проводится для удостоверения того, что программное обеспечение делает именно то, что от него ожидает пользователь. Используются два основных типа испытаний: функциональная проверка и тестирование для определения рабочих характеристик.
Функциональное тестирование
Функциональная проверка использует набор тестов, которые определяют, выполняет ли система все то, что она должна делать с точки зрения пользователя. Производится тестирование функций программного продукта (т.е. поиск различий между разработанной программой и ее внешней спецификацией). Проверяются наличие всех функциональных требований технического задания; корректность и полнота выполняемых функций. Проводятся многократное тестирование каждой функции системы, всех функций системы, множества их сочетаний, имитация и проверка на наличие сбоев применительно к каждому функциональному требованию.
Тестирование для определения рабочих характеристик системы
После того, как тестирование подтвердило адекватность базовой функциональности системы, задачей тестирования становятся испытания для определения рабочих характеристик. В рамках данной задачи выполняется тестирование в предельных режимах, нагрузочные испытания (так например, если программа рассчитана на подключение к ней большого числа пользователей (БД, терминальный режим доступа или же режим клиент-сервер), то ее необходимо тестировать при максимально возможной нагрузке. Для программ, выполняющих операции «запись-чтение», проводится тестирование операций обработки больших массивов данных с оценкой изменения времени отклика для выявления коэффициента пропорциональности падения быстродействия с увеличением количества обрабатываемых данных), контроль синхронизации. Испытания на надежность и эксплуатационную готовность. Также проводится ряд дополнительных испытаний, таких как: проверка безопасности, тест инсталляции и настройки (installation, fine tuning), проверка на совместимость, проверка удобства и простоты использования (GUI), проверка возможности наращивания.
На этапе системного тестирования разрабатывают и заполняют Test Report, а также Matrix of Traceability (сводная таблица, содержит картину покрытия требований тестами). Также возможно заполнение специфических отчетов по желанию заказчика.
Приемочные испытания (Acceptance Testing)
По завершении системного тестирования продукт может быть передан пользователю для проведения приемочных испытаний. Производится бета тестирование, также возможен случай, когда заказчик выполняет заранее определенный набор тестовых случаев, имитирующих типовые условия, в которых система будет работать после ввода в эксплуатацию. Заключительным типом приемочных испытаний является установочная проверка, по условиям которой завершенная версия программного продукта устанавливается на площадках заказчика с целью получить от него подтверждение, что программный продукт соответствует всем требованиям.
На данной стадии заполняют документы об окончании тестирования Close-Out Report и приеме программного продукта заказчиком.
Литература:
Microsoft Corporation - Тестирование производительности Web-приложений Microsoft .NET / Пер. с англ. – М.: Издательско-торговый дом «Русская Редакция», 2003. – 352 с.: ил.
Диан Стотлемайер. – Тестирование Web-приложений. Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2003. – 240 с.
Рекс Блэк. – Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование. – М.: Издательство «Лори», 2006.
Тамре Л. – Введение в тестирование программного обеспечения.: Пер. с англ. – М.: Издательский дом «Вильямс», 2003. – 368 с.: ил. – Парал. тит. англ.
Лекция 7: Циклы тестирования
Введение
Что такое Test cycle?
Из чего состоит Test cycle
Введение
Проверка на пригодность к тестированию (Sanity testing)
Проверка исправлений (fixes verification)
Функциональное тестирование (Functional testing) / тестирование соответствия (Conformance testing, Correctness testing)
Тестирование пользовательского интерфейса (GUI testing)
Регрессионное тестирование (Regression testing)
Результаты (Test outcome)
Важные типы тестирования в Test cycle
Тестирование инсталляции (Installation testing)
Тестирование производительности (Performance testing)
Нагрузочное тестирование (Stress testing)
Сравнительное тестирование (Back-to-back testing)
Восстановительные тесты (Recovery testing)
Конфигурационное тестирование (Configuration testing)
Тестирование удобства и простоты использования (Usability testing)
Итак, что же такое Test cycle? По сути это процесс выполнения последовательности различных типов тестов для определения работоспособности конкретной версии продукта. По содержанию это набор тестовых сьютов и их выполнение в процессе тестирования конкретной версии продукта. По назначению это структурированный подход к проверке текущей версии продукта на соответствие реализованным требованиям.
Test cycle – явление итерационное и выполняется он для каждой новой версии от начала и по возможности до конца.
В процессе Test cycle выполнение различных типов тестов может быть последовательным, параллельным или комбинированным. Это зависит от множества компонентов: специфики самого проекта, разработки проекта, процесса тестирования, требований заказчика и т.д.
Test Cycle с последовательным выполнением:
В данном разделе рассматриваются основные типы тестирования которые попадают практически в каждый Test cycle, а так же результаты выполнения Test cycle.
Test cycle – это набор тестов из различных разделов тест-плана (различных типов тестирования), отобранных для проверки определенной версии на определенной фазе проекта; это также процесс проверки конкретной версии на соответствие тем требованиям к продукту, которым соответствует воплощенная в версии функциональность. В связи с этим, сам Test cycle может менять свое содержание, временные характеристики и требуемые ресурсы. Как правило, Test cycle разрастается от версии к версии. Однако в процессе разрастания может потребоваться проведение отдельного Test cycle для специфической части продукта. Более того, может понадобиться проводить несколько Test cycles для одного продукта параллельно разными командами.
В данном разделе типы тестирования объясняются в том порядке, в котором их принято выполнять. Однако четкой последовательности для выполнения типов тестов нет
Проверка на пригодность к тестированию (Sanity testing)
Данный тип тестов является одним из ключевых типов в тестировании и организации Test cycles. Назначение этих тестов заключается в предварительной проверке пригодности новой версии для последующего полного тестирования. Проверяется базовая функциональность и общая стабильность продукта. В случае успешного прохождения данных тестов новая версия принимается для тестирования. В противном случае, отсылается на доработку с указанием того, что не работает.
Проверка исправлений (fixes verification)
Эти тесты предназначены для проверки исправлений дефектов, найденных во время предыдущих Test Cycles. На самом деле, данный вид тестов не обязательно выполнять сразу после приема новой версии для тестирования. Однако весьма полезно дать быструю информацию разработчикам о состоянии исправленных дефектов до того как начнется новый цикл.
Функциональное тестирование (Functional testing) / тестирование соответствия (Conformance testing, Correctness testing)
Эти тесты могут называться по разному, однако, их суть проста – проверка соответствия системы предъявляемым к ней требованиям.
Тестирование пользовательского интерфейса (GUI testing)
Основной целью данных тестов является проверка графического пользовательского интерфейса на соответствие GUI-спецификациям продукта (соблюдение всех размеров, взаиморасположение, цветовая гамма, и т.д.).
Регрессионное тестирование (Regression testing)
Определение успешности регрессионных тестов (IEEE 610–90 “Standard Glossary of Software Engineering Terminology”) гласит: «повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам». На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходить и после внесения таковых. Основная проблема регрессионного тестирования заключается в поиске компромисса между имеющимися ресурсами и необходимостью проведения таких тестов по мере внесения каждого изменения. В определенной степени, задача состоит в том, чтобы определить критерии «масштабов» изменений, с достижением которых необходимо проводить регрессионные тесты.
Результаты (Test outcome)
Результаты являются целью выполнения Test cycle. В конечном итоге всех интересует, в каком состоянии находится продукт, а особенно это интересует менеджеров. Отчетам об ошибках/дефектах посвящен целый курс, поэтому мы не будем подробно останавливаться на этом вопросе. Стоит лишь отметить, что полнота описания проблемы, доступность в объяснении, а так же коллекционирование вспомогательной информации (скриншоты, логи, конфигурационные файлы и т.д.) существенно облегчают жизнь и ускоряют процесс исправления дефектов, а с ним и разработки.
В большей степени многим интересен отчет по результатам всего тестирования. Данный результат дает некий срез состояния продукта на текущий момент. Это то, ради чего и выполнялся сам Test cycle.
Основная информация, которую необходимо собрать в одном документе:
набор характеристик продукта, которые были протестированы в данном Test cycle;
время, затраченное на тестирование, с указанием количества человеческих ресурсов, задействованных в выполнении Test cycle;
покрытие тестами реализованного функционала по каждой характеристике;
общая статистика найденных дефектов в разрезе серьезности проблемы;
детальная статистика найденных дефектов для каждой характеристики;
краткое описание состояния каждой характеристики;
дальнейшие действия после окончания Test cycle.
Следует обратить внимание на еще один очень важный документ, который предназначен для просмотра состояния продукта – это Матрица Соответствия (Matrix of Traceability). Этот документ, как правило, заполняется руководителями команд на стадии планирования, а потом контролируется менеджером проекта.
Документ содержит список требований, для каждого требования указывается дата разработки, набор тестов, которые покрывают реализацию данного требования (только идентификаторы тестов), результаты тестирования на текущий момент. Этот документ можно расширять очень сильно, но его назначение от этого не изменится. Суть документа – посмотреть, что уже реализовано в продукте (либо на какой стадии находится реализация) и какие проблемы были найдены.
Не все типы тестирования необходимо, а порой и возможно проводить с самого начала. По этой причине некоторые типы тестирования включаются в Test Cycle на поздних стадиях, а некоторые со временем переходят в разряд регрессионных.
Установочное тестирование (Installation testing) Из названия следует, что данные тесты проводятся с целью проверки процедуры инсталляции системы в целевом окружении.
Тестирование производительности (Performance testing) Специализированные тесты проверки удовлетворения специфических требований, предъявляемых к параметрам производительности. Существует особый подвид таких тестов, когда делается попытка достижения количественных пределов, обусловленных характеристиками самой системы и ее операционного окружения.
Нагрузочное тестирование (Stress testing) Необходимо понимать отличия между рассмотренным выше тестированием производительности с целью достижения ее реальных (достижимых) возможностей производительности и выполнением программной системы c повышением нагрузки, вплоть до достижения запланированных характеристик и далее, с отслеживанием поведения на всем протяжении повышения загрузки системы.
Сравнительное тестирование (Back-to-back testing) Единичный набор тестов, позволяющих сравнить две версии системы.
Восстановительные тесты (Recovery testing) Цель – проверка возможностей рестарта системы в случае непредусмотренной катастрофы, влияющей на функционирование операционной среды, в которой выполняется система.
Конфигурационное тестирование (Configuration testing) В случаях, если программное обеспечение создается для использования различными пользователями (в терминах «ролей»), данный вид тестирования направлен на проверку поведения и работоспособности системы в различных конфигурациях.
Тестирование удобства и простоты использования (Usability testing) Цель – проверить, насколько легко конечный пользователь системы может ее освоить, включая не только функциональную составляющую – саму систему, но и ее документацию; насколько эффективно пользователь может выполнять задачи, автоматизация которых осуществляется с использованием данной системы; наконец, насколько хорошо система застрахована (с точки зрения потенциальных сбоев) от ошибок пользователя.
Литература:
Microsoft Corporation - Тестирование производительности Web-приложений Microsoft .NET / Пер. с англ. – М.: Издательско-торговый дом «Русская Редакция», 2003. – 352 с.: ил.
Диан Стотлемайер. – Тестирование Web-приложений. Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2003. – 240 с.
Рекс Блэк. – Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование. – М.: Издательство «Лори», 2006.
Тамре Л. – Введение в тестирование программного обеспечения.: Пер. с англ. – М.: Издательский дом «Вильямс», 2003. – 368 с.: ил. – Парал. тит. англ.
Лекция 8: Тест-план и работа с ним. Тест-кейс и его структура в тест-плане
Тест-план — основной документ тестировщика
место тест-плана в тестовой документации
когда начинать и заканчивать писать тест-план
какой формат документа выбрать
чек-лист как вариант тест-плана в экстремальных условиях
Принципы написания тест-плана и тестов
документ должен быть понятен не только автору
тесты пишутся пошаговые, с прицелом на автоматизацию
еще правила, которых нужно придерживаться
Структура тест-плана
общие разделы
описание тестов, разделение их на группы (тест-сьюты)
Тестировщик обычно имеет дело с несколькими документами по проекту, но в непосредственном тестировании основным для него является System Test Plan (или Software Test Plan, STP, Check-list, Test Specification, Test Cases Document), в обиходе «тест-план». Он, в основном, содержит собственно сами тесты, которые команда тестировщиков не только запускает, но и предварительно их описывает в этом документе.
Существует еще один документ, который называют тоже «тест-план» — Master Test Plan, но у него другие цели и аудитория, в нем содержится описание методики тестирования, стратегия, ресурсы и т.д., но не содержатся сами тесты. Этим тест-планом занимаются тест-менеджеры, и здесь мы о нем больше упоминать не будем.
Место тест-плана в тестовой документации
System Requirements Definition (или Product Requirements Definition, SRD, PRD, требования к продукту) — это источник для тест-плана. Ведь главный смысл тестирования — проверить, что продукт соответствует замыслу заказчика, выраженному в требованиях к продукту. Поэтому, прежде чем выдумывать хитроумные тесты, нужно написать очевидные, четко соответствующие каждому требованию. Можно сказать, что тест-план — это дочерний документ Требований. Разумеется, в идеале Требования должны быть уже полностью готовы и утверждены перед написанием тест-плана, но в жизни это случается нечасто.
Test Report (тест-отчет) — это для тестировщика практический результат его работы, а также вердикт для тестируемой версии продукта, список оценок прохождения каждого теста в двоичной системе: прошел (pass) или не прошел (fail). Третьего не дано. Бывает еще N/A (not available, нет и не будет возможности выполнить тест в этой стадии тестирования), pending (возникли вопросы, тест не выполняется, временно отложен до выяснения обстоятельств), но эти метки говорят не о качестве продукта, а о качестве тест-плана, в идеальном плане все нюансы предусмотрены. Таким образом, тест-план — это родительский документ Тест-отчетов.
Когда начинать и заканчивать писать тест-план
Может показаться, что тест-план следует начинать собственно на стадии тестирования, после того как вышла хотя бы первая версия продукта. Ведь до этого тест-план и работа самих тестировщиков продукту особо не нужны. Такой подход имеет место только в компаниях, практикующих неразумный расход человеческих и финансовых ресурсов.
Более верный и профессиональный путь — начинать создавать план тестирования в одно время с началом практических работ над самим продуктом, то есть, сразу после принятия Требований, Дизайна и другой документации, предназначенной прежде всего для… непосредственных разработчиков. Почему, разве тест-план можно писать, не имея перед глазами сам объект тестирования?
Если вспомнить, какой документ на самом деле является входным для тест-плана, а также подумать, чего будут ждать программисты после выпуска первой версии, станет ясно, что лучшее время для написания тест-плана — это период создания первых строчек кода объекта тестирования.
Чтобы последнее утверждение не звучало категорично, можно упомянуть про существующую практику использовать готовый тест-план как один из документов для… программистов, согласовывающих по нему ожидаемое поведение своего участка функционала
Какой формат документа выбрать
Есть несколько вариантов для оформления тест-плана, таких как многостраничный текст, электронная таблица, база данных. Причем нет связи между масштабом компании, проекта и способом вести документацию, бывает, что маленький проект хранит описания тестов в базе данных, а грандиозный использует формат RTF.
Конечно, при выборе формата нужно исходить из текущих потребностей, однако стремиться надо к форме коллективно используемой базы данных или хотя бы выбрать формат, имеющий максимум из этого набора свойств:
возможность в нужный момент внести необходимые изменения в тест-план, которые сразу же доступны всем заинтересованным участникам процесса;
возможность немедленно получить дополнительную информацию, такую как изначальное требование к продукту, которое «покрывается» тем или иным тестом, или результат выполнения конкретного теста из тест-отчетов;
возможность в любой момент быстро и точно составить отчет о состоянии тестирования: получить статистику о покрытии требований тестами, количестве тестов вообще (для планирования сроков), количестве успешно пройденных тестов, найденных ошибках и т.д., причем все это желательно по отдельным компонентам продукта и по различным периодам и фазам тестирования;
возможность разделить доступ к тест-плану, ведь кому-то можно его изменять, а кому-то только читать или не иметь доступа вовсе.
Использование других форматов, не имеющих всех перечисленных свойств, может вызвать вынужденное дублирование информации, путаницу в версиях тестов, недоступность последних изменений и прочие неудобства. Конечно, такая взаимоинтеграция документов возможна, только если вся документация выполнена в таком же формате
Чек-лист как вариант тест-плана в экстремальных условиях
В ситуациях, когда не готовы ни требования, ни дизайн, ни другая документация, которая может служить источником для тест-плана, а также нет времени на документацию, но какие-то тесты нужно составить и пройти прямо сейчас, выходом может стать чек-лист (check-list).
Чек-лист — это список необходимых для проверки нюансов, элементов, функций, составленный в свободной форме, чаще всего разработчиком. Тестирование по такому списку происходит тоже в свободной форме, на усмотрение тестировщика, а не по шагам с конкретными описаниями ожидаемых результатов, как по тест-плану.
Разумеется, качество такого тестирования оставляет желать лучшего, и такой документ не может заменить тест-план, но в экстремальных ситуациях именно он может быть полезным для быстрого оценивания программы и нахождения очевидных ошибок.
Документ должен быть понятен не только автору
Тот, кто пишет тест-план, должен не забывать, что этот документ предназначен для коллективной работы, поэтому нужно использовать принятый шаблон, соблюдать единый с другими документами стиль изложения и форматирования (хотя не возбраняется предлагать улучшения), писать грамотно (по возможности применять проверку орфографии) и перечитывать написанное несколько раз, оценивая документ с точки зрения других его читателей.
При внесении изменений в уже опубликованный документ (то есть, при создании новой версии документа) обязательно включайте отслеживание изменений (tracking changes), если это возможно (например в MS Word), чтобы отличия от старой версии можно было выделить, не сравнивая документ построчно.
Тесты пишутся пошаговые, с прицелом на автоматизацию
При сочинении тестов сами тестовые случаи нужно разбивать на логические шаги (test steps), после которых имеет смысл снимать ключевые промежуточные результаты (которые уже могут судить о наличии ошибок и остановить тест как провальный до его полного окончания). Описывать тесты желательно так, чтобы их затем можно было без особого труда перевести, к примеру, на скриптовый язык в программе автоматизации, то есть, уже создавая по сути сам скрипт — последовательность команд или действий, сценарий. Даже если тесты не придется автоматизировать (это в худшем случае), их все равно будет легче и понятнее выполнять при ручном тестировании, особенно неопытному тестировщику.
Еще правила, которых нужно придерживаться
необходимо в каждом тесте уделять внимание процедуре приведения объекта тестирования в некую исходную позицию до прохождения теста и, если это рационально, его возврата в эту же позицию после прохождения теста — это дает возможность запускать тесты независимо, в любом нужном порядке, не заботясь о том, в каком состоянии объект остался после предыдущего теста;
при этом следует определить оптимальные стартовые позиции/состояния объекта тестирования для всех тестов, чем их получится меньше, тем лучше (меньше усилий и времени для подготовки объекта к новому тесту и больше удобства при группирования тестов);
количество шагов нужно оптимизировать, иногда в одном шаге можно объединить несколько, если нам важен промежуточный результат только последнего из них, однако, если уверенности нет, лучше описать лишнее, чем пропустить ключевой шаг;
упорядочивать тесты в тест-плане желательно последовательно по отношению к функциональности объекта тестирования, двигаясь от тестов первых действий или экранов объекта (например, запуска самой программы) до последних (например, ее закрытия);
тестер не должен придумывать спецификации и термины, которые нигде пока не описаны и не применяются в требованиях, не должен использовать условности из своей жизни (например, «phone receives the call» не обязательно соответствует фразе «телефон звонит», а «open the door» не всегда означает, что дверь открывается именно поворотом ручки), такое придумывание может привести к написанию неверных тестов;
раздел тест-плана «Open Issues» (открытые вопросы, нюансы) используется для того, чтобы собрать в одном месте отсутствующие в требованиях данные, запросы на уточнения, без которых нельзя написать некоторые тест-кейсы;
главное в конструировании тестов — руководствоваться здравым смыслом и интуицией, если есть ощущение, что в каком-то случае имеет смысл нарушить правила, нужно их нарушить.
Общие разделы
Тест-план как и другая документация должен содержать помимо полезной информации (описания тестов) некую второстепенную, придающую ему официальный и формальный статус. Как правило, такой информацией общего характера является набор следующих разделов:
описание документа (document description), зачем и для кого он нужен, к чему имеет отношение — в нашем случае там описывается следующее: вкратце об объекте тестирования (object of testing); список родственных документов (related documents), в нем как минимум ссылка на Требования и Тест-отчеты; глоссарий (glossary) — расшифровка терминов и обозначений; указание границ, глубины документа (scope) — что документ описывает хорошо, что лишь упоминает, а что не описывает вообще (например, он может не описывать подробно все параметры функций и не содержать историю версий продукта, в этом случае будет уместна ссылка на документ, который описывает упущенное лучше); открытые вопросы (open issues), которые нужно обсудить и определить до такого-то этапа тестирования;
условия тестирования (test conditions) — обычно это программная (software) и аппаратная (hardware) конфигурация, при которой данный тест-план считается верным и годным к применению, и ограничения (restrictions), сужающие область ответственности для данной версии тест-плана (например, следующие версии продукта не могут быть протестированы некоторой частью тестов);
другие особенности тестирования (other issues), здесь уместно упоминание об используемой системе регистрации и ведении истории найденных в процессе тестирования ошибок (bug tracking system) и еще каких-то относительно важных моментов;
список функциональности, которая не будет протестирована вообще (not to be tested) и почему (чаще всего это идентификаторы Требований, которые не поддаются покрытию тестами или поддаются слишком трудно, что делает нерациональным их покрытие);
возможны другие разделы, например, отказ от ответственности (disclaimer), копирайт (авторские права) и прочее.
Описание тестов, разделение их на группы (тест-сьюты)
Это самая важная часть документа, а точнее, он сам и есть. Здесь после возможного вступления, разъяснения принятого стиля описания тестов и находится весь набор тестов, разделенный на тест-кейсы (test cases) и тест-сьюты (test suites).
Последнее понятие применяется в случае, если набор всех тест-кейсов планируется разделить на отдельные группы (сьюты), а не проходить каждый раз все тесты подряд. Например, имеет смысл создать тест-сьют для быстрого тестирования самой важной функциональности (sanity testing suite) с целью быстро оценить стабильность новой сборки, для стрессового тестирования (abusive или stress testing suite) и другие сьюты, подходящие для конкретной ситуации с конкретным объектом тестирования.
В некоторых случаях тест-сьюты могут содержать так называемые случаи применения (use cases) — это как правило комплексные тест-кейсы высокого уровня, то есть, реальные случаи применения продукта пользователем, описание целой процедуры работы с отдельной функцией продукта тестирования, а не проверка отдельного элемента этой функции. Например, если объект тестирования — телефонный терминал, то совершить звонок (дозвониться, побыть в состоянии соединения, закончить звонок) — это случай применения (use case), а убедиться, что при «поднятии» трубки слышен гудок или включается подсветка клавиатуры, — это тестовый случай (test case), то есть, тестирование системы на низком уровне, а не на пользовательском.
Необязательно тест-сьюты должны содержать уникальный набор тестов, иногда какие-то тест-кейсы, если они в чем-то универсальны, могут входить в состав нескольких тест-сьютов. А бывает даже, что тест-сьюты вмещают в себя другие тест-сьюты.
Главное, чтобы организация тестов подчинялась здравому смыслу, была понятна и максимально удобна для тестировщика, который будет с ней работать. Поэтому нужно оценить ее с точки зрения выполнения тестирования.
Тест-кейс и его структура в тест-плане
Тест-кейс как элемент тестирования
Заголовки
Тестовые шаги и результаты
Примеры и шаблоны
Тест-кейс как элемент тестирования
Тест-кейс — это минимальный (атомарный) компонент теста, как правило, он нацелен только на один элемент объекта тестирования. Чем меньше у тест-кейса покрытие функциональности, тем четче область поиска причины в случае найденной ошибки. Если же в тест-кейсе расписан целый сценарий из десятков действий, то усложняется, во-первых, его прохождение, во-вторых, определение причины сбоя, если результат негативный; также есть большая вероятность получить ложный негативный результат из-за ошибки в другом, второстепенном для данного тест-кейса узле, вовлеченном в этот сценарий и проверяемом отдельными тестами. Однако в некоторых случаях тест-кейсы намеренно делаются объемными и составными, если того требует специфика объекта тестирования.
В тест-плане каждый тест-кейс обычно состоит из двух частей: заголовков с сопутствующей информацией и списка тестовых шагов, ожидаемых результатов.
Заголовки
В этой части тест-кейса собраны необходимые его реквизиты, набор которых в каждом проекте различный. Как минимум, должны присутствовать: идентификатор тест-кейса, заголовок или краткое описание тестируемой функциональности и идентификатор покрываемого требования, в дополнение могут присутствовать: текст требования, конфигурация теста, описание предварительных действий, пометки об автоматизации, идентификатор группы тестировщиков, ответственной за тест и другое. В зависимости от принятой формы хранения тест-кейса заголовки могут быть собраны и описаны полностью в каждом тест-кейсе, а могут быть вынесены в отдельное место. Какие-то заголовки могут быть общими для нескольких тест-кейсов.
Тестовые шаги и результаты
Эта часть уникальная для каждого тест-кейса, потому как и является его «телом». Как было сказано выше, тестовые шаги пишутся в виде списка, перечня шагов, которые проходит тестировщик. Каждому шагу, как правило, соответствует описание ожидаемого результата. Поэтому удобно эту часть тест-кейса оформлять в виде таблицы с тремя колонками: номер шага, действие и ожидаемый результат.
Часто тест-кейс пишется и хранится в линейном виде как табличка в MS Word или MS Excel. Хранимые в базе данных тест-кейсы тоже удобнее всего выводить в виде таблицы, где все части тест-кейса логически разделены по ячейкам. Пример такой таблички:
Литература:
Microsoft Corporation - Тестирование производительности Web-приложений Microsoft .NET / Пер. с англ. – М.: Издательско-торговый дом «Русская Редакция», 2003. – 352 с.: ил.
Диан Стотлемайер. – Тестирование Web-приложений. Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2003. – 240 с.
Рекс Блэк. – Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование. – М.: Издательство «Лори», 2006.
Тамре Л. – Введение в тестирование программного обеспечения.: Пер. с англ. – М.: Издательский дом «Вильямс», 2003. – 368 с.: ил. – Парал. тит. англ.
Лекция 9:
Ошибки, жизненный цикл и описание. Отчет о контроле ошибок
Синонимы ошибки
Системы хранения и отслеживания истории ошибок
Когда писать отчет об ошибке
Как зарегистрировать ошибку
Как правильно описать проблему
Дополнения к отчету об ошибке
Примеры информативных скриншотов
Примеры
Ошибка в программе обычно называется «баг» от английского bug — жук, клоп и др. Историй возникновения этого термина несколько, все они доступны для любознательных в интернете.
В процессе работы с ошибкой, особенно в англоязычной среде, можно встретить различные вариации этого термина, такие как:
bug
error
defect
system problem
misfeature
fault
В профессиональном тестинге продукта обязательно использование специализированной утилиты, системы хранения и отслеживания истории багов (bug tracking system) или на сленге «багобазы». Ее применение не только значительно облегчает учет ошибок, а и делает работу над ошибками последовательной, прозрачной, эффективной.
Существуют десятки таких систем на разный вкус, но самые правильные имеют следующий минимальный набор функций:
немедленное оповещение (по e-mail) заинтересованных лиц об изменении статуса бага (добавлении нового, исправлении, закрытии и т.п.);
выдача статистики, отчета о текущем состоянии всех или отфильтрованных по критериям багов;
добавление и хранение не только текста с описанием проблемы, но и вложенных снимков экрана (скриншотов), логов и прочих материалов;
добавление и хранение ответных комментариев других лиц по каждому багу, истории манипуляций с багом;
настройка окружения (пользователи, количество и названия всех реквизитов ошибки: тип, серьезность, приоритет, продукт, модуль, версия, конфигурация и т.д.) под проект.
Во время выполнения тестов или по собственному наблюдению тестировщик может обнаружить какую-то проблему, претендующую на роль бага. Но в некоторых ситуациях найденный нюанс может оказаться как раз не багом, а «фичей» (от англ. feature), то есть, предусмотренной функцией, в этом случае тестировщик, зарегистрировавший проблему в багобазе, получит от разработчика злорадный ответ «not a bug» (который, правда, можно оспорить, если это имеет смысл).
Основной критерий, помогающий определить баг — это точное описание ситуации в документации. Если в авторитетной документации по проекту (тест-план, требования, спецификация, RFC) описано определенное поведение объекта тестирования в данной ситуации, а в реальности этот объект ведет себя иначе, это баг. Бывает, правда, что ошибка не в продукте, а в документации, но это уже отдельный разговор.
Но даже если найденный баг не подкрепляется достойными аргументами, а тестировщик считает, что проблема все-таки есть (например, его опыт подсказывает, что определенное поведение продукта не соответствует ожиданиям пользователя), он может внести свое замечание под грифом, который в различных багобазах называется как «feature request», «enhancement», «suggestion» или «probably a bug».
Следует, однако, проявлять сдержанность в творческом процессе поиска багов и не наполнять багобазу никому не нужными замечаниями. Также, если известно (или это можно быстро определить), что такой баг уже опубликован, добавлять дубликат не надо. Перед принятием решения о регистрации бага желательно запустить тест с негативным результатом еще раз или два и быть уверенным, что ошибка повторяется.
Но и бояться опубликовать лишнее тоже не следует, гораздо больший грех — оставить найденную серьезную проблему без внимания разработчика.
Что нужно делать, когда решение о публикации ошибки принято?
Прежде всего, нужно открыть используемую в проекте багобазу и авторизоваться там под своим аккаунтом. Затем, если это возможно сделать быстро, убедиться, что такого бага еще никто не регистрировал (если в проекте выделен человек — диспетчер добавленных ошибок, то об этом можно не заботиться).
Теперь можно добавить новый отчет о найденной проблеме. Обычно для этого нужно использовать ссылку или кнопку с названием типа «добавить новый», в этом случае откроется форма, в которой уже должны быть заполнены некоторые общие поля:
продукт;
дата;
имя тестировщика, его e-mail;
статус нового бага («новый», «добавленный»);
остается только указать из списка или вписать индивидуальные данные об ошибке:
модуль, в котором найдена проблема;
заголовок, суть проблемы (summary);
серьезность ошибки и приоритет ее исправления;
описание ошибки, шагов ее воспроизведения (см. далее);
дополнительные материалы (см. далее).
В случае если нужно использовать большинство информации из уже опубликованного бага, можно воспользоваться функцией копирования имеющегося бага в новый.
После заполнения формы остается подтвердить ее (отправить на сервер, добавить в базу), и новому багу будет присвоен уникальный идентификатор, который следует использовать в отчетах тестирования. Затем хорошие багобазы шлют уведомления о добавленной записи заинтересованным лицам.
В форме добавления нового бага поле «описание» самое важное, поэтому максимум внимания нужно уделить ему. Обычно в этом поле пишутся такие возможные подробности (напомним, что суть проблемы у нас уже есть в заголовке отчета): что именно произошло, при каких обстоятельствах получена ошибка, полная цитата сообщения об ошибке или кусочек лога, что от объекта тестирования ожидалось вместо ошибки, ссылка на тест-кейс или требование, каковы возможные причины ошибки и как она может быть исправлена (это писать следует, только если наверняка известно), конфигурация окружения (если она неочевидна), а также шаги воспроизведения ошибки (steps to reproduce), если она может быть повторена.
Если к описанию прикладываются дополнительные материалы, желательно указать это в тексте описания, чтобы их не забыли посмотреть, например: «see also screenshot ”bug-144-screenshot-001.gif” attached» или «see log “bug-144-log.txt” attached for details».
Можно ли объединять в одном отчете несколько ошибок или все ошибки следует разъединять и описывать в одном отчете только одну ошибку? Считается, что разъединять надо всегда. Но все же объединить кое-что можно — то, что исправляется одним действием одним человеком. Например: 1 человек должен 1 раз открыть страницу и исправить на ней 5 опечаток. В этом случае все 5 опечаток можно заявить в одном отчете. Но если есть подозрение, что все объединенные ошибки не будут исправлены «за один заход», скопом, то надо разъединять.
Поставьте себя на место разработчика и напишите описание проблемы так, чтобы у него возникло минимум вопросов к вам по вашему отчету.
Лишнюю информацию, которая не поможет делу, можно пропустить.
Обычно одного описания проблемы разработчику мало для того, чтобы ее понять и исправить, а иногда для того, чтобы признать ошибку. Поэтому к описанию желательно по возможности добавлять следующие материалы:
Фрагмент лога работы продукта, в котором отмечена проблема. Если работа продукта логируется, разработчик в 90% случаях потребует лог ошибки, так как для него это самый понятный язык описания проблемы. Но километровый лог, собранный за весь день тестирования, будет ему бесполезен. Нужно выкусить только ту часть лога, которая имеет отношение к регистрируемой проблеме, обычно это от начала запуска теста до его завершения или до проблемной точки.
Скриншот (снимок экрана) или несколько с обозначением проблемы. Если ошибка представлена наглядно на экране, разработчик будет благодарен за возможность увидеть ее своими глазами без повторения теста на своей стороне. Желательно иметь базовые навыки работы с каким-нибудь графическим редактором, чтобы уметь вырезать только относящуюся к делу часть экрана и акцентировать проблему стрелками, окружностью, возможно текстом, а иногда и нарисовать то, что должно было быть, и тогда разработчику будет еще легче понять претензии тестировщика.
Однако не стоит перегружать отчет об ошибке лишней информацией, если дополнительные материалы никак не помогут разработчику, прикреплять их не нужно.
Хорошо составленный отчет о найденной проблеме может содержать следующее:
Заголовок: Не открывается новое окно при нажатии кнопки «Go» в окне «Start game».
Описание: Открой экран начала игры в IE6sp2. Прокрути экран вниз, поставь чекбокс «Start new game» и нажми кнопку «Go». Игра начинается в том же окне, см. прикрепленный скриншот «screen-game1-01.gif».
Согласно требованию «Req-System1-0010» при нажатии кнопки «Go» должно открываться новое окно «Game 1».
Посмотрел код, у кнопки пропущен параметр «'_blank'».
Необязательно заполнять все поля формы, предложенные багобазой. Бесполезные в конкретном случае данные, как уже говорилось, не помогут.
Итак, полезность отчета о найденной ошибке — в его точности, то есть, нужная информация должна присутствовать в полном объеме, а ненужная нет.
Еще примеры отчетов:
Литература:
Microsoft Corporation - Тестирование производительности Web-приложений Microsoft .NET / Пер. с англ. – М.: Издательско-торговый дом «Русская Редакция», 2003. – 352 с.: ил.
Диан Стотлемайер. – Тестирование Web-приложений. Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2003. – 240 с.
Рекс Блэк. – Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование. – М.: Издательство «Лори», 2006.
Тамре Л. – Введение в тестирование программного обеспечения.: Пер. с англ. – М.: Издательский дом «Вильямс», 2003. – 368 с.: ил. – Парал. тит. англ.