Pull to refresh

Группа тестирования в Scrum-проекте

Reading time 5 min
Views 17K


У нас в отделе четыре Scrum-команды. Спринты, таймбоксинг, митинги, демо, Product Owner, заказчик и т.д. С годами сформулировался список основных ценностей:
  • командный дух и атмосфера в командах — удобство процессов важнее сложившихся годами правил и привычек;
  • автоматизация рутины важнее задавливания массой;
  • быстрое принятие решений важнее консилиумов, коллегий, долгих совещаний;
  • доверие к людям, возможность учиться (и ошибаться!) важнее централизации управления;
  • открытость для всех (от высшего руководства до конкретного участника проекта) и вовлеченность важнее сиюминутной экономии времени и видимости согласия;
  • демократия в обсуждении вопросов, но диктатура в претворении решений в жизнь;
  • необходимый минимум правил, но требовательность при их исполнении;
  • когда все думают одинаково — никто не думает;
  • «мужик сказал — мужик сделал», все несут ответственность за свои решения.

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

Сначала мы пробовали тестировать силами самих разработчиков. Чтобы разработчики не просто писали модульные тесты, а полноценно работали как тестировщики — проверяли сложные кейсы, тестировали руками. Откровенно сказать, тестировщики из разработчиков не очень. Проверять свой же код — сплошное мучение: «Он и так работает, я же его только что написал».
Пробовали включать тестировщиков в команды разработки. Это сближает разработчиков и тестировщиков, заставляет понимать проблемы друг друга. Порой сближает настолько, что тестировщик становится еще одним разработчиком в команде, а разработчик, как я говорил выше, — уже плохой тестировщик. Но тут есть и положительный момент — разработчики начинают задумываться о том, как тестировать продукт.
Пробовали привлекать внешние по отношению к проекту команды тестирования (есть отдельный отдел тестирования, который не участвует в проекте). Долго объясняли членам внешней команды, что и как, разворачивали инфраструктуру, долго объясняли, что нам от них нужно. Потратили кучу времени, а профита особого не получили.
В итоге и появилась идея того, что нам, собственно, нужно для организации тестирования.

Постоянная команда тестирования


Нам нужна была именно команда — сработавшиеся люди, знающие друг друга, доверяющие друг другу, обладающие схожими знаниями, навыками. Команда, которая помимо самого тестирования могла бы развивать технологии и развиваться сама. Сейчас у нас есть такая выделенная команда из 7 человек.
Изначально хотели получить команду универсалов, которые умеют делать все. Но универсал, как правило, знает обширные области, но поверхностно. А хотелось, чтобы погружение в область было большим. В итоге от этой идеи отказались и выделили два направления: функциональное и автоматизированное тестирование.
Функциональное тестирование — базовое для всех тестировщиков. Сюда входят и выделение требований, и проектирование тестов, и непосредственно их выполнение. Функциональное тестирование, в свою очередь, делится на тестирование базового функционала и тестирование прикладной логики.
Автоматизированное тестирование подразумевает автоматизацию ручных тестов, организацию специализированных видов тестирования.
Тестировщики, которые закреплены за какой-то одной областью, могут туда глубоко погружаться, это повышает качество тестирования.

Максимальная ориентация на автоматизацию


Автоматическое развертывание, автоматический прогон тестов, имитация реальных действий пользователей, автоматическая фиксация результатов, причин заваленных тестов, окружения.
Сейчас у нас порядка 800 GUI-тестов, которые покрывают львиную долю функционала системы. Запускаются они без какого-либо участия тестировщика. Автоматически поднимается окружение, автоматически создают необходимые для тестирования данные, автоматически прогоняются тесты.


Таблица автоматического прогона тестов
(упс, похоже, кто-то завалил последний прогон)


Тесты работают через API и UI. API используется для подготовки каких-то тестовых данных, а тестирование через UI позволяет проверять реальные сценарии работы пользователей.
Кроме самих тестов мы автоматически снимаем нефункциональные показатели работы системы: время выполнения операций, количество запросов между сервером и клиентом, трафик. Измеренные характеристики доступны всем на проекте в виде графиков в динамике.


Графики трафика и времени выполнения операций

Доверие к тестированию


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

Проведение специализированного тестирования


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

Утилита для имитации действий пользователей

Тестирование полноты, удобства функционала


Тестировщики не могут проверить, что сама задумка, идея продукта верная, что делать надо было именно так, а не иначе. Эту проблему мы закрываем коридорным тестированием, но это отдельная тема отдельной статьи…
Однако тестировщики вполне могут проверить, что функционалом удобно пользоваться. Зачастую бывает так, что формально требования к функционалу были удовлетворены, но пользователь просто замучается использовать продукт.
Удобство в данном случае — это не только пользовательский интерфейс. Это и внешнее API, и возможность с помощью системы быстро и качественно реализовать предусмотренные задачи.

Максимально близко к разработчикам


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

Графики продолжительности разработки и тестирования;
второй вариант сокращает срок на 1/4


Идея выделенной команды тестирования хорошо вписалась в основные принципы нашей работы. Команда работает на проектах уже 3 года и показала свою эффективность.
Нам найденный вариант кажется оптимальным. Но, может, и вы расскажете, как организовали тестирование в своих Scrum-проектах, есть у вас выделенный отдел или группа тестирования, если нет, то почему отказались?
Tags:
Hubs:
+5
Comments 13
Comments Comments 13

Articles

Information

Website
www.npo-comp.ru
Registered
Founded
Employees
201–500 employees
Location
Россия