В ноябре 2020 года провели шикарный Online митапчик в Redmadrobot. Была рада увидеть коллег и поделиться знаниями.

Особенности организации

Для меня этот митап был достаточно необычным, по факту для зрителей он Онлайн, для меня - офлайн. все действо происходило в робохранилище. Будто побывала на съемках кино: свет , звук и другие приблуды, Но ценность в другом, в эпоху пандемии это реальное общение и микро нетворкинг... Ну а теперь к делу!)

Делюсь результатами

Весь митапчик посмотреть и прочитать про другие доклады можно здесь.

Коротко - в чем суть моего докладика

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

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

Основная цель тестирования — своевременно оповещать команду о реальном состоянии системы или продукта

Основные точки опоры для построения тестирования

Анализ требований или технического задания.
Инфраструктура — важно настроить окружение, выбрать целевые устройства, какие тестовые данные потребуются.
Процесс коммуникации — нужно договориться, в каком формате мы выстраиваем обратную связь с командой (например, делаем отчеты о тестировании в Jira).
Разбираемся, как именно организовываем тестирование: какие виды тестирования, на каких этапах применяем, как распределяем ресурсы, планирование и так далее.
Уделяем время написанию отчетности и договариваемся, какая отчетность и в каком виде нужна.
Постоянно внедряем улучшения и анализируем изменения.

О чем тестировщик должен сообщать команде

Что нужно автоматизировать. В процессе коммуникации с разработчиками и менеджерами тестировщику нужно определить и рассказать, какие тесты должны быть автоматизированы и на каком уровне.

Как оптимизировать работу. Нужно делать постоянную оптимизацию тестов, чтобы они затрачивали меньше времени. Задача тестировщика — минимизировать время выполнения тестов, оптимизировать фича тесты и регресс. Это нужно, для того чтобы быстро получать информацию о состоянии продукта.

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

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

Тестирование — это как круговая оборона. Весь продукт «охранять» очень сложно, поэтому тестировщики создают «датчики» (некие красные флажки), которые в нужный момент сообщают: alarm! И подобные «датчики» — это метрики, а также автотесты, различные приемы и т.д. Задача команды тестирования выстроить многослойную систему защиты, состоящую из нужных «датчиков». Также стоит помнить, что помимо того, что QA тестирует, команда ещё сообщает реальное состояние системы, где все окей, где начинает «рваться», а где все плохо и нужно срочно исправлять.

Как тестировщику обеспечивать обратную связь для команды

С помощью парного тестирования или программирования. Автоматизацию тестирования полезно делать при поддержке разработчиков. На этом этапе должно происходить взаимное ревью, это помогает тестировщику глубже узнать систему и уже на этом этапе обнаружить какие-то проблемы.
С помощью Code Reviews. Это не совсем работа тестировщика, но в проекте через Code Reviews можно получить обратную связь. Например, если у нас фича автоматизации типовая, и она долго ревьювится на разных проектах, то нужно выяснить причину.
Через модульные тесты (Unit tests).
С помощью автоматизированных интеграционных тестов (Automated Integration Test).
С помощью автоматизированных Acceptance Tests. Эту активность можно разделить с продакт-менеджерами.
По возможности следует автоматизировать Regression Test.
Постоянный Exploratory Testing.
Обратная связь от пользователей или бизнес-юзеров.
Постоянное UAT-тестирование + DEMO-сессии.

Через что тестировщик может организовать обратную связь с командой

С помощью работы с дефектами (багами) — нужно определить формат их заведения и оповещения о них, например, делать это в Jira или другом удобном инструменте. Разработчикам не всегда хватает информации в дефекте, чтобы приступить к фиксу, поэтому иногда требуется дополнительная коммуникация с багрепортером.
Организовать коммуникацию по сборкам и состояниям тестовых сред. Это понадобится, если вдруг с ними что-то пойдет не так или они задерживаются.
Кросс-обучение внутри тестирования. Все специалисты разные, они могут учиться друг у друга, поэтому важно иногда собираться и обсуждать результаты работы и делиться лайфхаками и знаниями продукта. Это некий knowledge transfer.
Тест-документация — собирать отчетность по фичам, сборкам и по приемке. Для составления отчетности поможет изучение ГОСТов: в них описаны градации дефектов, как с ними быть и так далее. Для проектов, связанных с государственным подрядом, поможет изучение ГОСТ 34.603-92.

Современные паттерны тестирования