Группа тестирования в Scrum-проекте
У нас в отделе четыре Scrum-команды. Спринты, таймбоксинг, митинги, демо, Product Owner, заказчик и т.д. С годами сформулировался список основных ценностей: командный дух и атмосфера в командах — удобство процессов важнее сложившихся годами правил и привычек;
автоматизация рутины важнее задавливания массой;
быстрое принятие решений важнее консилиумов, коллегий, долгих совещаний;
доверие к людям, возможность учиться (и ошибаться!) важнее централизации управления;
открытость для всех (от высшего руководства до конкретного участника проекта) и вовлеченность важнее сиюминутной экономии времени и видимости согласия;
демократия в обсуждении вопросов, но диктатура в претворении решений в жизнь;
необходимый минимум правил, но требовательность при их исполнении;
когда все думают одинаково — никто не думает;
«мужик сказал — мужик сделал», все несут ответственность за свои решения.
Все хорошо, но несколько лет нас не отпускали мысли о том, как организовывать тестирование. Мы немало поэкспериментировали, прежде чем пришли к нынешнему положению вещей.Сначала мы пробовали тестировать силами самих разработчиков. Чтобы разработчики не просто писали модульные тесты, а полноценно работали как тестировщики — проверяли сложные кейсы, тестировали руками. Откровенно сказать, тестировщики из разработчиков не очень. Проверять свой же код — сплошное мучение: «Он и так работает, я же его только что написал».Пробовали включать тестировщиков в команды разработки. Это сближает разработчиков и тестировщиков, заставляет понимать проблемы друг друга. Порой сближает настолько, что тестировщик становится еще одним разработчиком в команде, а разработчик, как я говорил выше, — уже плохой тестировщик. Но тут есть и положительный момент — разработчики начинают задумываться о том, как тестировать продукт.Пробовали привлекать внешние по отношению к проекту команды тестирования (есть отдельный отдел тестирования, который не участвует в проекте). Долго объясняли членам внешней команды, что и как, разворачивали инфраструктуру, долго объясняли, что нам от них нужно. Потратили кучу времени, а профита особого не получили.В итоге и появилась идея того, что нам, собственно, нужно для организации тестирования.Постоянная команда тестированияНам нужна была именно команда — сработавшиеся люди, знающие друг друга, доверяющие друг другу, обладающие схожими знаниями, навыками. Команда, которая помимо самого тестирования могла бы развивать технологии и развиваться сама. Сейчас у нас есть такая выделенная команда из 7 человек.Изначально хотели получить команду универсалов, которые умеют делать все. Но универсал, как правило, знает обширные области, но поверхностно. А хотелось, чтобы погружение в область было большим. В итоге от этой идеи отказались и выделили два направления: функциональное и автоматизированное тестирование.Функциональное тестирование — базовое для всех тестировщиков. Сюда входят и выделение требований, и проектирование тестов, и непосредственно их выполнение. Функциональное тестирование, в свою очередь, делится на тестирование базового функционала и тестирование прикладной логики.Автоматизированное тестирование подразумевает автоматизацию ручных тестов, организацию специализированных видов тестирования.Тестировщики, которые закреплены за какой-то одной областью, могут туда глубоко погружаться, это повышает качество тестирования.Максимальная ориентация на автоматизацию
Автоматическое развертывание, автоматический прогон тестов, имитация реальных действий пользователей, автоматическая фиксация результатов, причин заваленных тестов, окружения.Сейчас у нас порядка 800 GUI-тестов, которые покрывают львиную долю функционала системы. Запускаются они без какого-либо участия тестировщика. Автоматически поднимается окружение, автоматически создают необходимые для тестирования данные, автоматически прогоняются тесты.
Таблица автоматического прогона тестов (упс, похоже, кто-то завалил последний прогон)
Тесты работают через API и UI. API используется для подготовки каких-то тестовых данных, а тестирование через UI позволяет проверять реальные сценарии работы пользователей.Кроме самих тестов мы автоматически снимаем нефункциональные показатели работы системы: время выполнения операций, количество запросов между сервером и клиентом, трафик. Измеренные характеристики доступны всем на проекте в виде графиков в динамике.
Графики трафика и времени выполнения операций
Доверие к тестированию
В любой момент времени мы можем спросить у команды тестирования, в каком состоянии находится продукт. Команда тестирования на основании прогона автоматических тестов, экспресс тестирования может быстро ответить, можно ли ставить продукт в продакшн, а если нельзя, то почему.Этому мнению мы доверяем. Мы знаем, что если команда тестирования дала добро, то мы не получим критичных ошибок в продакшне. Мы знаем, что команда запрещает нам выпускать версию не просто так, а потому что на то есть основания.Проведение специализированного тестирования
В первую очередь речь идет о нагрузочном тестировании. Все остальные виды так или иначе покрываются за счет него. Инструменты для проведения такого тестирования достаточно дороги. Мы написали свой инструмент, чтобы проводить разнообразные виды спецтестирования.Основная задача утилиты — моделирование работы множества пользователей в системе. Можно писать различные сценарии работы пользователей с минимальными затратами времени и сил.
Утилита для имитации действий пользователейТестирование полноты, удобства функционала
Тестировщики не могут проверить, что сама задумка, идея продукта верная, что делать надо было именно так, а не иначе. Эту проблему мы закрываем коридорным тестированием, но это отдельная тема отдельной статьи…Однако тестировщики вполне могут проверить, что функционалом удобно пользоваться. Зачастую бывает так, что формально требования к функционалу были удовлетворены, но пользователь просто замучается использовать продукт.Удобство в данном случае — это не только пользовательский интерфейс. Это и внешнее API, и возможность с помощью системы быстро и качественно реализовать предусмотренные задачи.Максимально близко к разработчикам
Сближение тестировщиков и разработчиков позволяет раньше получать результат тестирования. Если баги доходят до разработчика через неделю, то ему снова надо погружаться в код, снова вникать, а если через день, то проще вспомнить, что ты писал еще вчера.Разработчики стараются выдавать фичи частями, которые можно тестировать прямо в ходе спринта, рассказывают, что сейчас готово, а что еще находится в работе. Это позволяет быстрее начать тестировать и находить проблемы на еще сыром функционале.
Графики продолжительности разработки и тестирования; второй вариант сокращает срок на 1/4Идея выделенной команды тестирования хорошо вписалась в основные принципы нашей работы. Команда работает на проектах уже 3 года и показала свою эффективность.Нам найденный вариант кажется оптимальным. Но, может, и вы расскажете, как организовали тестирование в своих Scrum-проектах, есть у вас выделенный отдел или группа тестирования, если нет, то почему отказались?
