Определение набора тестовых данных
Отталкиваясь от требований к полям, используя техники тест дизайна начинаем определение набора тестовых данных:
· в зависимости от того обязательное поле или нет, определим какие поля необходимо проверить на пустое значение, так как оно может вызывать ошибку (В результирующей таблице оранжевый цвет)
· т.к. исчерпывающее тестирование не представляется возможным из-за огромного числа всевозможных комбинаций значений, в первую очередь необходимо определить минимальный набор данных. Это можно сделать используя такие техники, как EP и BVA. (В результирующей таблице голубой цвет)
· На форме присутствует поле, имеющее составной тип (цифры используются совместно с символами), обладает специальным форматом данных и поэтому выделение тестовых данных для него - это достаточно трудоемкая задача.
В пределах данной статьи ограничимся только простой проверкой форматов и основных требований описанных в форме приема заявок.
· По завершению генерации данных с применением стандартных техник, можно добавить некоторое количество значений на основании личного опыта (техника EG)
Это может быть использование спец. символов, очень длинных строк, разных форматов данных, регистров в строках (Upper, Lowwer, Mixed cases), отрицательные и нулевые значения, кейворды Null - NaN - Infinity и т.д.
Сюда можно включить все, что вы полагаете может вывести приложение из строя (В результирующей таблице фиолетовый цвет
· Что такое баг репорт?
Это документы, описывающие ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата. Состоит он из двух частей: короткое описание содержание бага и его детальное описание.
Предлагаю Вам комментарий одного разработчика:
Прочитав короткое описание бага (Bug Summary), я должен понять в чем состоит проблема, прочитав детальное описание бага (Bug Description) я должен знать строку кода, которую править.
Смысл этого высказывания в том, что вы должны делать все так, чтобы к вам меньше было вопросов по существу описанной в баг репорте проблемы. Так как каждый возвращенный вам баг репорт со статусом "Отклонен", "Не воспроизводится", "Требуется информация" (Rejected, Can't Reproduce, More info) - это потеря времени, как вашего так и разработчика
· Основные поля баг / дефект репорта
Разные системы менеджмента дефектами, предлагают нам разные поля для заполнения и разные структуры описания дефектов.
Нижеприведенная таблица - это попытка показать то, что на основании полученного нами опыта, мы рекомендуем вам использовать в виде шаблона баг репорта.
| Шапка | |
| Короткое описание (Summary) | Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации. |
| Проект (Project) | Название тестируемого проекта |
| Компонент приложения (Component) | Название части или функции тестируемого продукта |
| Номер версии (Version) | Версия на которой была найдена ошибка |
| Серьезность (Severity) | Наиболее распространена пятиуровневая система градации серьезности дефекта:
|
| Приоритет (Priority) | Приоритет дефекта:
|
| Статус (Status) | Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle) |
| Автор (Author) | Создатель баг репорта |
| Назначен на (Assigned To) | Имя сотрудника, назначенного на решение проблемы |
| Окружение | |
| ОС / Сервис Пак и т.д. / Браузера + версия / ... | Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования - имя и версия браузера и т.д. |
| ... | |
| Описание | |
| Шаги воспроизведения (Steps to Reproduce) | Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке. |
| Фактический Результат (Result) | Результат, полученный после прохождения шагов к воспроизведению |
| Ожидаемый результат (Expected Result) | Ожидаемый правильный результат |
| Дополнения | |
| Прикрепленный файл (Attachment) | Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы |
· Важность и приоритет дефекта
Разные системы баг трекинга предлагают нам разные пути описания серьезности и приоритета баг репорта. Неизменным остается лишь смысл, вкладываемый в эти характеристики.
Например, в таком баг-трекер, как Atlassian JIRA, начиная с какой-то версии вместо использования полей серьезности (Severity) и приоритета (Priority), оставили только Priority, которое собрало в себе свойства обоих полей отчета
Таким образом, те кто привык работать с JIRA не всегда понимают разницу между этими понятиями, так как не имели опыта их совместного использования.
Серьезность (Severity) - это атрибут, характеризующий влияние дефекта на работоспособность приложения.
Приоритет (Priority) - это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.
· Опишите градации атрибута Серьезности дефекта (Severity)
Градация Серьезности дефекта (Severity)
S1 Блокирующий дефект (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.
S2 Критический дефект (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.
S3 Значительный дефект (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
S4 Незначительный дефект (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
S5 Тривиальный дефект (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная по средствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
· Опишите градации атрибута Приоритета дефекта (Priority)
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.
Порядок исправления ошибок по их приоритетам: High -> Medium -> Low
· Требования к количеству открытых багов
Можно предложить следующий подход к определению требований к количеству открытых багов:
- Наличие открытых дефектов P1, P2 и S1, S2, считается неприемлемым для проекта. Все подобные ситуации требуют срочного решения и идут под контроль к менеджерам проекта.
- Наличие строго ограниченного количества открытых ошибок P3 и S3, S4, S5 не является критичным для проекта и допускается в выдаваемом приложении.
Количество же открытых ошибок зависит от размера проекта и установленных критериев качества.
Все требования к открытым ошибкам оговариваются и документируются на этапе принятия решения о качестве разрабатываемого продукта. Как пример документирования подобных требований - это пункт Критерии окончания тестирования в плане тестирования.
· Основные фазы процесса тестирования
Тестирование начинается не с того момента, когда вам дали рабочее приложение, а намного раньше - как только пошли слухи, что команда будет работать над проектом, можно считать, что вы уже приступили.
После получения первых спецификаций, вы начинаете писать тест план, разрабатываете тест кейсы, оцениваете необходимость использования автоматизации, причем как автоматизации функционального тестирования, так и нагрузочного.
Как только разработчики подготовили билд, вы должны провести дымовое тестирование, по результатам которого делается вывод о возможности и целесообразности дальнейшего тестирования:
В случае если "smoke test failed!!!", вы отправляете приложение на доработку.
Если же "smoke test passed!!!", то вы переходите к следующему виду тестирования - регрессионное тестирование (Regression testing) и санитарное тестирование (Sanity testing).
Открыв багтрекер, вы должны перепроверить дефекты, которые разработчики перевели в статус Fixed (Исправлено), Rejected, Can't Reproduce и т.д.
Заметим, что статусы Rejected и Can't Reproduce для вас самые неприятные - это явное свидетельство того, что либо вы недостаточно хорошо локализовали дефект, не очень понятно описали шаги для воспроизведения, либо разработчик поленился воспроизвести ситуацию.
Покончив с закрытием и пере-открытием дефектов, вы переходите к основной работе - централизованному тестированию по тест кейсам и/или (если вы адепт исследовательского тестирования) вы начинаете "исследовать" приложение.
Когда все, что было запланировано, пройдено, вы имеете результаты прогона тест кейсов, баг репорты, вопросы к аналитикам и заметки на полях своих тетрадей.
Основываясь на всем этом, вы составляете отчет по проведенному тестированию и отправляете его на проектную группу.
Подобный процесс проходит от версии к версии, и через какое-то время результаты тестирования сойдутся, с прописанными в плане тестирования критериями окончания тестирования.
На этом основная работа, связанная с непосредственно с тестированием, окончена, и вы можете приступить к передаче приложения заказчику.
Надеюсь что вы запомнили, последовательность выполненных видов тестирования: