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