Как мы делаем тестирование прозрачным. Всё об инфраструктуре QA
Привет! Я Ольга Лобанова, руководитель отдела качества в AGIMA. Моя главная задача на любом проекте — сделать процесс тестирования прозрачным и измеримым. Поэтому мы в компании уделяем много внимания построению инфраструктуры тестирования. В этой статье объясню, почему это важно, а заодно поделюсь нашими подходами — думаю, коллеги оценят. Интересно будет тестировщикам, руководителям проектов, техническим директорам и нашим заказчикам. Welcome.
Зачем нужна инфраструктура — на примере бега
Инфраструктура тестирования — это артефакты, необходимые для проведения тестирования, включающие тестовое окружение, инструменты тестирования, офисное окружение и процедуры. Объясню на спортивном примере.
Я увлекаюсь бегом. Кажется, что нет ничего проще, чем выйти на пробежку — встаешь и выходишь. Но на самом деле бег, как и любое большое дело, предполагает серьезную подготовку. Выбрать правильную обувь, построить маршрут, научиться правильно ставить ногу, правильно одеться. При это бежать нужно не слишком быстро, но и не слишком медленно. Темп нужен средний, подходящий именно вам. Бег принесет удовольствие, только если к нему подготовиться.
Инфраструктура тестирования — это вся та подготовительная работа, с помощью которой вы сможете быстро и эффективно тестировать новые фичи. Наша задача — выстроить прозрачный и измеримый процесс тестирования. Регламенты и правильно подобранные инструменты помогают в этом.
Если вернуться к нашему примеру, то мы, чтобы начать бегать, ставим цель, покупаем обувь, выбираем день и и находим себе компанию. Только в этом случае мы получим удовольствие от тренировки и сможем не бросить после первой пробежки.
Когда процессы не описаны, команде и заказчику непонятно, как мы работаем и что вообще происходит. Когда же инфраструктура, наоборот, продумана, любой участник процесса может зайти в базу знаний проекта и освежить все нюансы в памяти, посмотреть отчетность, метрики, регламенты работы с задачами и инструменты, которые мы используем. Это делает процесс прозрачным. А прозрачный процесс помогает экономить время и деньги.
Вывод: инфраструктура тестирования нужна, чтобы экономить ресурсы.
Шаг №1: анализ проекта
Начинаем новый проект с исследования.
У нас в компании помешаны на исследованиях, и это круто. Исследования помогают быстро найти уязвимые стороны проекта и придумать, как эти уязвимости закрыть. Поэтому первым делом мы анализируем текущие процессы и уровень их зрелости. Всего существует 5 уровней зрелости:
Чем ниже уровень, тем более хаотичный процесс на проекте.
Когда уровень известен, мы разрабатываем план улучшения процессов. Всегда стремимся к следующему уровню зрелости процесса. Часто на проектах с низким уровнем зрелости процессов команды пренебрегают системами управления тестированием. Например, Test IT, Allure, Zephyr, Qase и др. А вместо них используют чаты в Telegram, Google Docs или Trello.
Это неудобно — тест-кейсы теряются, забываются, не фиксируются. Поэтому мы обычно предлагаем все-таки выбрать какую-то из систем, тем более цены за их использование начинаются от 400 рублей. Но если заказчик не хочет, мы не давим. Тут хозяин — барин.
Еще на этом этапе мы анализируем объем работы: есть ли какая-то тестовая модель, каков объем тестирования, в каком виде документация. Это тоже важно, потому что помогает нам составить картину проекта и понять, как мы в него встроимся.
Шаг №2: готовим документацию
Когда анализ завершен, мы разрабатываем 2 основных документа:
План тестирования — это всеобъемлющий документ, который описывает всё необходимое для успешного тестирования. Отвечает на вопрос «что тестировать?».
Стратегия тестирования — это описание того, как выполнять тестирование для достижения целей тестирования в заданных условиях. Она помогает определить охват и область тестирования. Благодаря этому мы получаем четкое представление о проекте, а вероятность пропустить какое-либо тестовое действие снижается. Отвечает на вопрос «как будем тестировать?».
Эти документы — наша святая святых. В этих документах подробно описан процесс тестирования. Любой человек, который откроет их, поймет, что мы тестируем и как. Это путь к той самой прозрачности, о которой я писала выше. Оба документа храним в базе знаний — например, в Wiki.
Вот что мы в них прописываем:
Как мы тестируем продукт, какие инструменты используем, где хранятся задачи. Если это Jira, описываем процесс работы с Jira. Если YouTrack — с YouTrack. В документе абсолютно всё: из какого статуса мы берем задачи, как правильно заводим баги и когда берем их на повторное тестирование.
Как мы работаем с дефектами: правила их заведения, воркфлоу, градации серьезности. Мы не боимся прописывать даже самые элементарные вещи — понимать процесс должен даже тот, кто никогда не работал в QA.
Правила работы с Test Management System, в которой будем вести тестовую документацию. На наших проектах мы используем такие системы, как Test IT, Allure TestOps, DoQA и другие. Системы могут быть абсолютно любые. Главное — чтобы система отвечала потребностям проекта.
Регламент разработки тест-кейсов и правила прохождения тест-ранов. Тест-ран — это выполнение заданного набора тестов. По сути, это наш отчет о результатах прохождения тестирования: сколько тестов пройдено, сколько провалено по причине багов.
Когда процессы прописаны, инфраструктура готова, остается применить все на практике.
Шаг №1,5: если процессы не настроены
Вернемся на полшага назад.
До этого я описала подключение к действующему процессу. Мы подключились к проекту, он работает давно, какие-то процессы на нем существуют, мы их изучили, предложили улучшения. Если наши идеи нравятся — круто. Если нет — мы просто встроимся в существующий процесс.
Но что, если проект стартует с нуля, и пока никаких регламентов и правил не существует?
В таком случае мы просто выстраиваем процесс с нуля, опираясь на свой опыт и знания. Также на этот случай у нас есть готовое решение — Agimaban. Подробно описывать, что это за подход, в этой статье я не буду. Но и совсем ничего не сказать о нем тоже не могу. Agimaban — это уже разработанные и используемые нами процессы и инструменты.
Мы предлагаем клиенту работать в уже готовой инфраструктуре, использовать наши регламенты и работать по нашему воркфлоу. Во-первых, это позволяет быстро начать работу, поскольку ничего выдумывать не надо. Во-вторых, бережет ресурсы всем участникам: все процессы отлажены, не нужно тратить дополнительные силы.
Ниже отдельно расскажу, как и с какими инструментами мы любим работать.
Шаг №3: метрики
Метрики тестирования заслуживают отдельной статьи, и однажды я ее напишу. Но когда мы говорим про инфраструктуру, игнорировать их нельзя. Напомню, наша задача — сделать процесс прозрачным и измеримым. Про прозрачность я рассказала. Теперь про измеримость.
С помощью метрик можно контролировать показатели эффективности. К примеру, плотность дефектов на задачу. У нас уже есть набор базовых метрик и расширенный набор, которым мы пользуемся, если базового списка недостаточно.
А главная новость: затраты на внедрение метрик минимальны.
Если это ручной сбор метрик, то потребуется совсем немного времени тестировщика, при этом пользу они принесут огромную. Даже на старте проекта мы можем внедрить метрики и контролировать количественные показатели.
Вот пример некоторых из наших базовых метрик:
количество дефектов, заведенных командой за отчетный период;
плотность дефектов на задачу;
процент отмененных дефектов
процент исправленных дефектов;
процент переоткрытых дефектов.
Когда какие-то показатели проседают, заказчик теряет деньги. Поэтому регулярный сбор метрик и анализ показателей помогает вовремя внести изменения в процесс и сэкономить ресурсы. Плюс таким образом мы можем выявлять узкие места и зоны роста.
На тестирование приходит мало задач — можно увеличить команду разработки или количество задач в спринте. Тестирование находит слишком много багов — возможно, в команде разработки какая-то проблема. Например, пришел новый разработчик или задачи на разработку приходят с «сырыми» требованиями. Метрики как раз помогают нам выявить подобные ситуации, провести анализ проблемы и внедрить эффективное решение.
Также мы умеем автоматизировать сбор метрик с использованием инструмента Metabase. Для этого нам нужен доступ к базе данных Jira на чтение.
Какие инструменты мы любим
Этот и следующий раздел про то, какие ресурсы позволяют нам сделать тестирование максимально эффективным.
На этапе создания инфраструктуры мы решаем с бизнес-заказчиком, какие инструменты будем использовать в работе. Мы готовы и умеем работать с любыми, но есть те, которые нам кажутся более удобными.
Про системы управления проектом я уже упоминала. Мы предпочитаем Jira, хорошо относимся к Redmine и YouTrack. Хотя в нашей практике были разные проекты и разные варианты работы. Когда мы заходим на проект, рассказываем заказчику о преимуществах и недостатках каждой из этих систем. Но если процессы уже выстроены по-другому — мы подстроимся.
Тест-кейсы мы разрабатываем в системе управления тестированием. Мы чаще работаем в Test IT, Allure TestOps и DoQA. У каждого свои плюсы и минусы. В Test IT более удобный интерфейс, а через TestOps удобнее автоматизировать процесс. Использование этих систем — дополнительные затраты для заказчика, но зато мы лучше контролируем процесс тестирования. Даже если бюджет на проекте ограничен, мы готовы подыскать очень недорогой вариант.
Внедрять такие системы важно — это организует процесс. Хранить тест-кейсы, например, в гугл-документах неудобно и в конечном счете опасно. Их можно потерять. А любая специализированная система делает процесс не только прозрачнее, но и эффективнее.
Всё это мы обсуждаем с заказчиком заранее. Наша общая цель — сделать качественный проект, и мы объясняем, что нам в этом поможет.
Мы всегда ориентируемся на проект и потребности заказчика. Мои коллеги уже делились нашим опытом работы на сложных и интересных проектах.
Вот пример с одного из наших проектов:
Там мы работали по двухнедельным спринтам, спринт начинался в среду. Шесть дней на тестирование новых функций. В среду вечером наступал фича-фриз, к нам могли попасть только фичи, которые были разработаны до этого. В четверг стартовал регресс, он длился три дня. Во вторник проходил смоук на препроде. И во вторник ночью релиз выкатывался на прод.
Параллельно мы разрабатывали автотесты. Целью было сокращение времени на проведение регресса. Мы постепенно автоматизировали регрессионную модель и применяли различные способы, чтобы ее сократить без потери качества.
Итоги и выводы (снова про бег)
Вернусь к своему спортивному примеру.
Чтобы начать бегать, нужно заранее подготовиться. Раздобыть обувь, узнать хотя бы что-то про технику, определить маршрут и размяться. Вспомните все уроки физкультуры в школе, когда нас заставляли делать специальные беговые упражнения.
Создание инфраструктуры тестирования — это примерно о том же. Самый логичный и правильный процесс, чтобы начать тестировать продукт, описать процессы, подобрать и разложить по местам инструменты, получить доступы и настроить аккаунты.
После этого мы можем сосредоточиться на самом тестировании — прозрачном и измеримом. А значит, на эффективном и точном.
_____________________________________________________________________
Если есть вопросы и мнения — буду рада ответить в комментариях. Следить за нашими статьями про разработку и тестирование можно в нашем телеграм-канале.
