Приветствую вас в первой части своего блога, посвященную введению в тестирование. Я решил начать его, помня о тех проблемах, с которыми столкнулся в начале, и постараюсь сделать максимально доступным для восприятия. Материал собирался и обрабатывался из разных источников, для более глубокого изучения могу порекомендовать краткую и содержательную книгу, которая была для меня наиболее полезной - Тестирование программного обеспечения. Базовый курс. Автор - Святослав Куликов.
Обратная связь приветствуется.
Скорее всего, сейчас вы изучаете тестирование программного обеспечения с нуля, так что давайте разберемся, с чем будем иметь дело.
Тестирование ПО — процесс анализа программного продукта и его документации с целью выявить дефекты и тем самым повысить качество. Другими словами, мы сравниваем ожидаемое поведение тестируемого объекта с фактическим. Делается это на определенном наборе тестов (test suite). Тестирование - это лишь одна из техник контроля качества, куда также входят планирование работ, проектирование тестов, их выполнение, и анализ полученных результатов.
Качество ПО определяется как совокупность характеристик, относящихся к его способности удовлетворять установленные и предполагаемые потребности.
В тестировании есть две фундаментальные идеи. Его можно рассматривать как процесс доказательства работоспособности программы в определенных условиях - позитивное тестирование, и наоборот доказательство его неработоспособности - негативное тестирование.
Стоит отметить, что успешным прохождением негативного теста является не критическая ошибка в приложении, а корректную обработку этой ошибки и продолжение работы.
Тестирование не ведется хаотично, оно должно быть структурировано. Перед его началом составляется план тестирования - этот документ описывает весь объем работ по тестированию. Туда должны входить описание объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения. Обо всем этом мы поговорим в дальнейшем.
Чтобы лучше понять это, зададим несколько вопросов.
Что надо тестировать? - Опишем объект тестирования: систему, приложение, оборудование, документацию. Составляем список функций системы и её компонентов по отдельности.
Как будем тестировать? - Определяем подходящие виды тестирования (об этом в дальнейшем) и их применение по отношению к объекту тестирования.
Как понять, что можно начинать тестирование? Готовность тестовой платформы, законченность разработки требуемого функционала, наличие всей необходимой документации.
Какова последовательность действий в тестировании? - Подготовка к тестированию, тестирование, анализ результатов тестирования.
Тестирование окончено, если результаты тестирования удовлетворяют критериям качества продукта.
В тестовый план должно входить также описание окружения тестируемой системы - тестового стенда и его конфигурации.
Для повышения качества тест плана рекомендуется проводить его периодическое рецензирование со стороны участников проектной группы. Это можно сделать, просто договорившись между собой или же реализовать в виде "процедуры утверждения". Как пример, приведем список участников проектной группы, утверждение которых мы считаем необходимым: Ведущий тестировщик, Тест менеджер (менеджер по качеству), Руководитель разработки, Менеджер Проекта.
Воспользовавшись советами, вы можете составить качественный тест план.
В тест план должен входить непосредственно и сам
Тестовый сценарий (test case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. Из них состоит набор тестов (test suite) - это последовательность действий, по которой можно проверить, соответствует ли тестируемая функция установленным требованиям.
В тестовый сценарий должны входить следующие пункты:
Предусловия (Preconditions) - список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Описание теста (Test Case Description) список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
Постусловия (PostConditions) - список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state).
В случае, когда ожидаемое и фактическое состояние тестируемого объекта отличаются, оформляется отчет о дефекте (bug report) - это документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Структура отчета:
Короткое описание (Summary) - Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Проект (Project) - Название тестируемого проекта.
Компонент приложения (Component) - Название части или функции тестируемого продукта.
Номер версии (Version) - Версия на которой была найдена ошибка.
Серьезность (Severity) - Наиболее распространена пятиуровневая система градации серьезности дефекта: • S1 Блокирующий (Blocker) • S2 Критический (Critical) • S3 Значительный (Major) • S4 Незначительный (Minor) • S5 Тривиальный (Trivial).
Приоритет (Priority) - Приоритет дефекта: • P1 Высокий (High) • P2 Средний (Medium) • P3 Низкий (Low).
Статус (Status) - Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle).
Автор (Author) - Создатель баг репорта.
Назначен на (Assigned To) - Имя сотрудника, назначенного на решение проблемы
Окружение (Environment) - ОС / Сервис Пак и т.д. / Браузера + версия /… Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования — имя и версия браузера и т.д.
Шаги воспроизведения (Steps to Reproduce) - Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Фактический Результат (Result) - Результат, полученный после прохождения шагов к воспроизведению.
Ожидаемый результат (Expected Result) - Ожидаемый правильный результат.
Дополненительно - Прикрепленный файл (Attachment) - Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы.
Думаю, для начала вам хватит (=
Дополнительные ресурсы для изучения:
https://habr.com/ru/post/279535/