Сценарий = тест, шаг сценария = тест.

Заметки при прохождении курса “Сценарное тестирование в 1С: настройка и практика использования”

🔗Ссылка на курс

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

Окружение, инструменты

• Платформа: 8.3.26.1498
• Конфигурация: Демонстрационное приложение 1.0.40.5
• Vanessa Automation: 1.2.036.21
• allure: 2.32.0

Техники тест-дизайна

• Граничные значения
• Классы эквивалентности
• Таблица решений
• Предугадывание ошибок
• Причина/следствие

Тестовые данные

Виды

• Реальные (данные из эксплуотируемой системы) и синтетические (сгенерированные данные, на сновании опыта и требований к задаче)
• Зависимые и независимые друг от друга
• Для позитивного (ожидаемые входящие данные) или негативного (не ожидаемые входящие данные, например - отрицательная продажа) тестирования

Способы подготовки

• Создание с помощью тестов
• Загрузка ранее подготовленных
  • только тех, без которых нельзя обойтись и накапливать по мере необходимости, а не сразу все
  • не дублировать тестовые данные, чтобы не исправлять в нескольких местах
  • по возможности переиспользовать

Теги

Теги можно добавлять свои и их использовать для выполнени только нужных сценариев (чаще всего локально).

• @tree - для вложенности, но можно и не указывать.
• @ExportScenarios - для экспорта сценариев фичи как шаги сценария в другой фиче. Так же позволяет добавлять сценарии в библиотеку известных шагов, для этого перед сценарием нужно добавить следующие теги:
  • @ТипШага:
  • @Описание:
  • @ПримерИспользования:
• @IgnoreOnCIMainBuild - для отключения выполнения сценариев фичи на CI.
• @Screenshot - добавляется за заш или несколько шагов до шага, на который происходит падение, чтобы получить скриншот.
• @Recordvideo - добавляется за заш или несколько шагов до шага, на который происходит падение, чтобы получить скринкаст.

Обязанности QA-инженера

• разработка сценариев тестирования
• сам процесс тестирования
• анализ результатов тестирования
• внесение обнаруженных багов в трекинговую систему
• повторное тестирование проблемных моментов после исправления багов
• доработка сценариев тестирования
• проверка требований к программе

Стадии внедрения процесса автоматического тестирования

Нулевая стадия

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

Первая стадия

1. Организация процесса взаимодействия между QA-инженерами и программистами.
   • Налаженные процесс работы в команде;
   • понимание того кто какие пишет тесты, когда пишет тесты, зачем они нужны и когда их использовать.
2. Подготовка первичных тестов.
   • Наличие тестовых данных для написания первичных тестов на покрытие бизнес-критических кейсов.
3. Подготовка дымовых тестов на проверку открытия форм.
   • Проверка того что после обновления все формы откроются без ошибок.
4. Определение критически важных бизнес-кейсов и автоматизация их проверки.
   • Проверка бизнес-критических кейсов при ошибке в которых остановиться забота пользователя (например, проведение отгрузки, создание заказов, проведение продажи).
5. Формирование отчетов о прохождении тестов.
   • Вывод результатов тестов в виде отчета (например, allure), благодаря которому можно быстро понять где произошла ошибка либо убедиться, чтобы тесты прошли успешно.

Вторая стадия

1. Покрытие тестами изменений и разветвленных кейсов.
   • Созданные тесты на изменения в том числе и на исправление старых багов;
   • Тесты на разветсленные кейсы.
2. Налаженныя структура тестовых данных.
   • Общие тестовые данные;
   • Тестовые данные под конкретные тесты;
   • Есть понимание того какие тестовые данные использовать.
3. Налаженныя структура тестов (группировка по функциональности).
   • Тесты сгруппированы между собой (например, по каталогам, тегам и т.п.).
   • Когда добавляется новый тест, есть понимание того в какую группу его добавлять.
4. Налаженные процессы тестирования предрелизной версии.
   • В релиз не попадают ошибки по бизнес-критическим кейсам, новый функционал работает.
5. Общие практики и методология тестирования во всех командах.
   • Тесты написаны в едином формате;
   • Тесты может обновлять не только тот сотрудник, который их написал.

Третья стадия - польностью интегрированный процесс тестирования

• Автоматизация выполнения тестов (CI контур)
• Возможность регресс-тестирования каждого изменения
• Возможность запуска тестов в разных потоках по тегам (для сокращения времени их прохождения)
• автоматизация подготовки тестовой базы для разработки
• анализ покрытия кода тестами и постепенное увеличение процента покрытия
• тестирование сложных механизмов

Технологии

• Git
• CI/CD
  • Забирает изменения из репозитория с кодом и тестами
  • Запускает сборку конфигурации/внешнего модуля из исходников
  • Запускает проверку качества кода
  • Запускает обработчики перехода на новую версию (если есть)
  • Запускает тестирование
  • Снимает покрытие кода тестами
  • Отправляет все результаты в SonarQube
  • Формирует тестовую базу
  • Выполняет предрелизные операции (локализация, вставка драйверов и т.п.)
  • Формирует поставку для обновления
• DevOps

Анализ качества тестов

• Как долго по времени проходят тесты?
• Сколько времени требуется для поддержки и обновления тестов?
• Насколько понятны результаты выполнения тестов?
• Насколько надежны тесты?

Факторы влияющие на оценку сроков тестирования

• Квалификация тестировщика
• Наличие документации
• Тестовое окружение
• Тестируемая задача
• Время на регресс тестирование
• Квалификация разработчиков
• Налаженность процесса тестирования в команде и на проекте

Способы и методы оценки сроков тестирования

Интуитивная оценка

“пальцем в небо”, “пол, палец, потолок” и т.д.

Метод расчета процентного отношения к разработке

Средний процент времени, которое было затрачено на тестирование предыдущих проектов * Планируемое время на разработку = Плановое время на тестрование.

Экспертная оценка

Выполняется по аналогии с другими проектами, привлекается несколько экспертов.

Специальный метод

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

Структура декомпозиции работы

1. Декомпозировать требования и определить количество тестов чтобы их покрыть;
2. Определить среднее время на написание и выполнение 1 теста;
3. Определить количество возможных ошибок и время на работу с 1 дефектом;
4. Учесть возможные дополнительные затраты времени и риски;
5. Получить суммарную оценку, с учетом предыдущих шагов.

Риски в тестирование

• У тестировщика мало опыта;
• Нестабильные тесты;
• Разработчики делают много багов и долго их чинят;
• Частое переключение между задачами;
• Постоянные изменения в требованиях;
• Нестабильное тестовое окружение.

Баг репорт

Структура

• Заголовок
• Критичность
  • Критический - есть бизнес-потери (не запускается программа)
  • Значительный - нарушение в логике работы бизнес фич
  • Незначительный - исправление может подождать некоторое время
• Приоритет
  • Высокий
  • Средний
  • Низкий
• Статус
  • Новый
  • Открыт
  • Закрыт
  • Переоткрыт
• Окружение
  • Версия платформы
  • Наименование и версия конфигурации
  • Операционная система
  • и т.д.
• Детальное описание
• Шаги для воспроизведения
• Фактический результат
• Ожидаемый результат
• Артефакты (скрины, тестовые базы с данными для воспроизведения)

Алгоритм создания

• Воспроизвести баг несколько раз, убедиться что он повторяется
• Проверить наличие найденного дефекта в баг трекинговой системе
• Написать заголовок (отвечает на восросы: Что? Где? Когда?, например: При проведении документа реализации не срабатывает проверка на превышение общей суммы кредитного лимита)
• Заполнить поля баг репорта
• Прочитеть отчет, убрать лишнее, добавить нужное
• Ещё раз перечитать баг репорт и сохранить его
• Переназначить баз репорт ответственному сотруднику (тимлиду или разработчику)

Частые ошибки

• Неконкретизированный заголовок
• Недостаточное описание самой проблемных
• Невнятные шаги для воспроизведения
• В одном баг репорте несколько несвязанных проблем
• Скриншот без описания

Настройка CI

https://github.com/Pr-Mex/vanessa-automation/blob/develop/docs/CommandSetting/CommandSetting.md

Глоссарий

• flaky-тесты - это тест, который то зеленый то красный.