Регламент представлен в виде локомотива с вагонами, который движется к станции релизного продукта

Своевременно донесены плановые даты всех релизов проекта

Все задачи релиза заведены и указана версионность

При отправке сборки Заказчику добавлена почта qa@baccasoft.ru со списком замечаний

ПМ - несут ответственность за планирование тестировщиков на проекте, координацию взаимодействия работ по тестированию и исправлению выявленных дефектов и организацию разрешения спорных вопросов по проблемам.

Ответственность:

Изменения боевого сервера происходят с участием тестировщика

Каждая задача связана с задачей Jira

Предоставлены сборки в срок

Сборка для релиза собрана из релизной ветки

ГР - несет ответственность за формирования способов и исправление выявленных ошибок, за целостность тестовых сред.

Ответственность:

Ответственность:

• Завершено полное тестирование всех задач.
• Получено согласование от дизайнера.
• Своевременно эскалированны проблемы.
• Выполнены тестирования по плану.
• Выполнено предрелизное тестирование релизной сборки на тестовом стенде.
• Выполнен smoke-тест релизной сборки на продуктиве.
• Выполнено автоматизированное тестирование (если есть).
• Выполнено smoke-тестирование подписанной сборки

Формирование группы тестировщиков.
Подготовка вводной документации в Confluence

Руководитель отдела назначает тестировщика или группу тестировщиков на проект, распределяет между сотрудниками задачи, поступающие в отдел тестирования, контроль процесса тестирования на проектах.

Ответственность тестировщиков:

• Ведущий тестировщик несёт ответственность за организацию процесса тестирования, планирование, контроль процесса тестирования на проекте, согласование тест-кейсов.
• Тест-дизайнер несёт ответственность за составление тестовых случаев и тестовых сценариев.
• Тестировщик несёт ответственность за фактическое исполнение тестов, проведение различных видов тестирования и документирование выявленных дефектов.
• Тест-разработчик несёт ответственность за разработку автоматизированных тестов, предусмотренных в плане тестирования.

До старта тестирования ведущий тестировщик должен создать тест-план с указанием перечня задач и трудозатрат

Ежедневно тестировщик обновляет тест-план:

• даты начала и завершения задач
• стату задачи и фактические тредозатраты

Ведущий тестировщик информирует менеджеров о статусе тестирования, превышения плановых затрат по задаче

Тест план хранится в общем доступе в Zephyr Scale или Confluence

Плановые временные затраты и даты старта работ утверждает менеджер проекта (ПМ)

Еженедельно руководитель отдела составляет отчет о тестировании на проектах

Ведущий тестировщик составляет список задач на тестирование, предоставляет трудозатраты, исходя из дат релиза. Утверждает план тестирования с менеджером проекта.

Дерево требований

ТЗ

В случае нахождения противоречия в требованиях, необходимо сообщить менеджеру проекта о найденных проблемах.
После решения противоречий менеджер доводит до проектной команды изменения в исходных данных по проекту.

Тест-кейсы будут написаны, если требования обладают следующими свойствами:

• Атомарность
• Завершенность
• Непротиворечивость, последовательность
• Недвусмысленность
• Выполнимость
• Актуальность

Тестовые сценарии и тест-кейсы должны быть логичными и непротиворечивыми.
Тест-кейсы утверждаются менеджерами / аналитиками.

После решения противоречий менеджер доводит до проектной команды изменения в исходных данных по проекту.

Анализ требований и составление тест-кейсов

ВИДЫ ДОКУМЕНТИРОВАНИЯ

Тестирование завершенных задач на разработку, полученных от отдела разработки

Проведение:

• полного функционального тестирования,
• регрессионного тестирования,
• нефункционального тестирования,
• предрелизного тестирования,
• smoke-тестирования,
• автоматического тестирования

Связь задач в Jira на разработку с тестовыми сценариями и тест-кейсами

Обнаружение и фиксация багов в работе программного продукта

В данный этап тестирования входят задачи:

Тестирование реализованной задачи
Проверка конкретного функционала, реализованного в рамках одной задач. Направлено на проверку реализованного функционала, а также проверку корректности работы функционала, связанного с новыми функциями, включает также нефункциональные проверки.

Функциональное тестирование
Применяется для проверки функционала программного продукта. Тестирование может осуществляться как полностью для всего функционала, так и для отдельных модулей.

Нефункциональное тестирование
Предназначен для тестирования особенностей программного продукта, не относящихся к функционалу: инсталляционное, тестирование обновления, удобства использования, тестирование на отказ и восстановление, конфигурационное тестирование.

Регрессионное тестирование
Направлен на проверку изменений, сделанных в приложение или окружающей среде, для того чтобы убедиться в корректности работы ранее разработанного функционала. Регрессионными могут быть как функциональные, так и нефункциональные проверки.

Нагрузочное тестирование
Автоматизированное тестирование, имитирующее одновременную работу определенного количества пользователей в разработанной системе. Используется для проверки корректности поведения программного продукта при различных нагрузках.

Smoke-тестирование
Короткий цикл ключевых проверок, предназначенный для подтверждения того, что конкретная сборка программного продукта выполняет свои функции.

Предрелизное тестирование
Комплекс тестов, успешное выполнение которых свидетельствует о том, что проверяемая сборка готова к релизу. Предрелизное тестирование обязательно для каждой сборки, предназначенной для публикации и распространения пользователям.

Автоматизированное тестирование
Тестирование, которое проводится с использованием программных средств для выполнения тестов и проверки результатов выполнения.

Виды тестирования

Стабилизация - выделенный этап, после окончания разработки задач в релиз.

Стабилизация подразумевает запрет на внесение любых изменений, кроме исправления ошибок для достижения желаемого уровня качества.

Продолжительность - 30% от разработки.

Найденные ошибки создаются в Jira как Bug.

Продолжительность стабилизации не сокращается, при форс-мажорах ПМ необходимо согласовать с ККК сроки.

Согласуй с ККК.
В данный этап тестирования входят задачи:

Релиз включает в себя:

• Передачу сборки Заказчику и инструкций по установке.
• Передачу исходников Заказчику и инструкций по сборке и установке.
• Публикацию сборки и распространение пользователям (Google Play, AppStore).
• Публикацию сборки в тестовой среде Заказчика.

Релиз (жарг. от англ. release — выпуск) — выпуск окончательной версии программы — готового для использования продукта.