Предварительный этап
Формирование группы тестирования по проекту. Подготовка вводной информации для начала процесса тестирования.

Изучение, анализ и работа с требованиями
Анализ требований, составление тест-кейсов. Документ подготавливается в общедоступном формате и размещается в корпоративной системе alfresco в папке проекта, составление критериев качества продукта.

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

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

Введение

• Ссылки на исходные документы.
• Общее описание проекта.

Способ ведения задач и багов

• Основные этапы тестирования (изучение ТЗ, создание дерева требований и т.п.).
• Способ ведения задач в Jira на разработку в проекте.
• Способ хранения требований и тест-кейсов.
• Способ ведения багов.

Требования к среде тестирования

• Список адресов и паролей к тестовым стендам хранится в TeamPass.
• Ссылки на исходные сборки.
• Список окружений (ОС, браузеры, устройства, разрешения).
• Доп. программы (эмуляторы, доступ к БД, среда для разработки автотестов).

Источники требований
ТЗ, разработанный дизайн, карта переходов, бизнес-требования и т.п.

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

• фактическая дата начала выполнения задачи;
• дата завершения задачи;
• фактические затраты (ч.);
• обновление статуса задач;
• состав задач и плановые затраты могут быть изменены.

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

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

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

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

Тест-кейсы утверждаются ПМ / ТМ / аналитиком.

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

• Связь задач в Jira на разработку c тестовыми сценариями и тест-кейсами.
• Тестирование завершенных задач на разработку, полученных от отдела разработки.
• Обнаружение и фиксация багов в работе программного продукта.
• Проведение полного функционального тестирования, регрессионного тестирования, нефункционального тестирования, предрелизного тестирования, smoke-тестирования, автоматического тестирования.

Что нужно определить?
Web-приложения:

• Список ОС (Windows, Mac ...).
• Список браузеров с указанием версии.
• Разрешения экрана.

Мобильные приложения:

• Список ОС (Android, ios, windows ...), Диапазон версий ОС (от … до ….).
• Состав устройств (список разрешений).

Документирование
Список окружений фиксируется в системе Sitechсo.

После ввода в систему Jira задач на разработку тест-дизайнер в системе Sitechсo/Excel создает набор тестов, который полностью проверяет новый реализуемый в рамках данной задачи функционал, а также проверяет старый функционал приложения, который взаимосвязан с текущими доработками.

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

1 вариант:

Задачи (только task) на разработку ведутся в системе Jira.
Задачи на тестирование ведутся в Моноцеросе/Jira.

1) Зоной ответственности тестировщиков являются колонки «Ready for test» и «Test».
2) При поступлении задачи в Ready for test тестировщик переводит задачу в колонку Test и переводит задачу на себя.
2.1) При обнаружении багов в реализованной задаче все баги фиксируются в комментариях к задаче. Сама задача переводится в статус Reopen и переводится на разработчика, который ответственен за выполнение данной задачи.
2.2) Если тестирование задачи успешно завершено, то задача переводится в статус UAT.

2 вариант:

Задачи (sub-task) на разработку ведутся в системе Jira.
Задачи на тестирование ведутся в Моноцеросе /Jira.

1) Зоной ответственности тестировщиков являются колонки «Ready for test» и «Test».
2) При поступлении общей задачи в Ready for test тестировщик переводит задачу в колонку Test. В случае работы с саб-таском, он остается в колонке Ready for test.
2.1) При обнаружении багов в реализации задачи все баги фиксируются в комментариях к задаче, а сама задача переводится в колонку Ready for dev.
2.2) Если тестирование задачи успешно завершено, то статус задачи саб-таска меняется на Resolved. А общая задача переводится в колонку UAT только когда все её саб-таски имеют статус Resolved.

После того, как задача готова к тестированию, разработчик оставляет комментарий в задаче в котором присутствуют следующие поля:

Если в задаче нет комментария, задача не проверяется, возвращается разработчику.

*Прямая ссылка на скачивание сборки, либо ссылка с QR-кодом

* - в зависимости от платформы (Android, iOS)
будет разный сценарий установки

Android - будет скачана в папку загрузок смартфона. Сборку необходимо установить вручную
iOS - после нажатия на Install сборка автоматически установится на смартфон

Сборка - https://install.appcenter.ms/users/bacca/apps/test_app/distribution_groups/dev/releases/2
Окружение - iPhone Xs, iOS 13.7
Стенд - PreProd
****************************
Предусловия (условия для выполнения шагов):
У пользователя есть удаленные файлы в папке «Корзина».

Заголовок (краткое и емкое описание ошибки):
Удаленные файлы появляются в корзине после ее очистки.

Шаги (последовательность действий для воспроизведения ошибки):

• Залогинить пользователя в МП.
• Перейти в папку «Корзина».
• Нажать «Очистить корзину». Отобразился попап «Корзина очищена»,

файлы исчезли

• Перейти в папку «Входящие», затем обратно в «Корзину».

Фактический результат:
В папке «Корзина» присутствуют файлы, которые были там до очистки.

Ожидаемый результат:
Папка «Корзина» пуста.

Дополнительная информация (видео, скриншот, логи, вероятность воспроизведения):
Дефект начал проявляться после внедрения новых методов сортировки.

Скриншот или видео для наглядности (если требуется)

Заголовок
Содержит предельно краткую, но в то же время достаточную для понимания сути проблемы информацию о баге.
Рекомендуется указать слово «Backend», «Server», «Сервер» и т.д в начале заголовка в зависимости от терминологии, используемой на проекте.

Тело бага
Содержит подробное описание проблемы и информацию:

• пользователь,
• адрес сервера;
• метод с параметром в случае GET-запроса;

Заголовок
Содержит предельно краткую, но в то же время достаточную для понимания сути проблемы информацию о баге.

Тело бага
Содержит подробное описание проблемы и информацию:

• пользователь,
• адрес сервера;
• метод;
• заголовки метода;
• тело и/или параметры запроса, особенно если это не GET-запрос;
• скриншоты логов; *
• данные из внешних сервисов; *

* - в зависимости от проекта, задачи

Проведено нефункциональное тестирование:

• Инсталляционное.
• Тестирование обновления.
• Удобства использования.
• Тестирование на отказ и восстановление.
• Конфигурационное тестирование.

Стабилизация – выделенный этап, после окончания разработки задач в релиз (все task, sub-task переведены в UAT).
Стабилизация подразумевает запрет на внесение любых изменений, кроме исправления ошибок для достижения желаемого уровня качества.

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

Продолжительность - 30% от разработки. Например, если релиз раз в месяц – неделя, если в 2 недели – 2-3 дня.

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