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



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

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

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

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


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

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


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


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


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


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

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


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

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


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

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

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


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

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


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

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


    Идея выделенной команды тестирования хорошо вписалась в основные принципы нашей работы. Команда работает на проектах уже 3 года и показала свою эффективность.
    Нам найденный вариант кажется оптимальным. Но, может, и вы расскажете, как организовали тестирование в своих Scrum-проектах, есть у вас выделенный отдел или группа тестирования, если нет, то почему отказались?
    НПО «Компьютер»
    Company
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 13

      +5
      Откровенно сказать, тестировщики из разработчиков не очень. Проверять свой же код — сплошное мучение: «Он и так работает, я же его только что написал»

      Откровенно сказать, когда тестируешь свой код, то подсознательно понимаешь слабые места и стараешься на них сильно не давить. Этакий щадящий режим.
        0
        Еще бывает наоборот — «Что там тестировать то, там три строчки кода». Тестировщикам проще — их не сбивает с толку простота реализации.
        +3
        На оптимальную структуру тестирования очень сильно влияет орзанизация разработки в целом, а также как продукт доставляется к пользователям, как пользователи выбирают и покупают продукт, какова структура релизов.
        Когда наиболее эффективным в SCRUM оказывается выделенный отдел тестирования, весьма вероятно что в остальных аспектах проект по каким-то причинам тоже не очень agile.
          0
          У нас и нет выделенного отдела, у нас есть команда тестирования. Команда нужна чтобы в целом развивались технологии тестирования, чтобы знания передавались, аккумулировались. Получилась некая сервисная команда, которую ни scrum, ни agile в принципе не отвергают. Например, те же Devops может вполне работать в scrum оказывая услуги по разворачиванию.
            +2
            Если работает, то хорошо. Я просто не понял, я прочитал команда — team — scrum team (kanban or anything). Значит люди занимаются разработкой но ни в одну группу SCRUM не входят.

            Я старый идеалист скептик — devops оказывающий услуги по разворачиванию я называю внутренним сервис деском :)

            Для себя мы нашли правильным поместить тестировщиков в SCRUM группы, у нас разработчики очень хорошо и критически тестируют, пока плохова-то автоматизируют — над этим мы работаем. Тестировщиков очень хочется наконец превратить из людей только предоставляющих сервис в людей в перую очередь организующих и обучающих. Да, ещё у нас есть группы по дисциплинам: UI/UX, тестирование, архитектура, безопасность, настольные игры и другие (которые возникают и работают пока у них есть что обсуждать между членами несколькими SCRUM команд)

            Кстати, тестировщики начинающие программировать — это хорошо, если они продалжают понимать что, как и почему правильно тестировать. К сожалению, зачастую, люди перемещаются из тестировщихов в программисты отнють не потому что они хорошие тестировщики.
              +1
              Разработчики у Вас тестируют код, который написали сами или тестируют код коллег (напр. во время CodeReview)?
              Как правило, последнее более результативно в силу незамыленности глаза.
                0
                Код ревью он проходит отдельно от тестирования.
                Разработчики тестируют и своё и чужое, специфика нашего продукта — он очень большой и старый, поэтому основные проверки на отсутствие регрессии это ручное тестирование. Подобное тестирование не вызывает сложностей у разработчиков, наоборот зачастую они знают больше о деталях поведения системы если они недавно что-то меняли в этой части, тогда они легче могут заметить проблемы возникающие за границами основных сценариев на который они сейчас смотрят.

                Сложности такого подхода которые я вижу:
                — чтобы человек чувствовал себя комфортно тестируя, когда его основная специализация программирование, процесс должен быть организован так, чтобы это было очевидно что в текущий момент именно этими действиями он приносит максимальное количество пользы (при том что все вокруг также равномерно и эффективно загружены).
                — если человек проводит чересчур много времени занимаясь делами не связанными с его основной специализацией он очень сильно устаёт и перестаёт чувствовать себя занятым профессиональной деятельностью.
          +1
          У вас в статье не раскрыты моменты с тем, как требования доходят до тестеров.
          PO вынужден 2 раза объяснять story или все ходят на все митинги?

          Если следовать Scrum, то тестер должен быть в одной команде с разработчиком, они же делают общее дело. При этом их число должно быть примерно 2 к 1, т.е. 1 тестер на 2х разработчиков.
          У Вас выходит, что тестеры хотели развиваться в разработке, а вы им не дали?

          Вообще такое чувство, что вам нужна была изначально не команда тестеров, а скорее команда, которая будет заниматься поддержкой автоматизации, т.е. настроит наконец все тулзы, авто-билды и т.п., чтобы можно было работать.
            +2
            У вас в статье не раскрыты моменты с тем, как требования доходят до тестеров.
            PO вынужден 2 раза объяснять story или все ходят на все митинги?

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

            Почему не дали, как раз наоборот. Один из тестировщиков стал в итоге полноценным разработчиком, вполне успешно работает сейчас в команде.
            Все же ситуации, когда тестировщик развивается в разработке (пишет автоматические тесты, какие то скрипты и т.д.), и когда он становится полноценным разработчиком, несколько разные. У нас тестировщики в итоге хотели стать полноценными разработчиками и уйти из тестирования в принципе.
            Ну и, чтобы тестировщик хорошо вписался в команду, он должен быть матерым спецом. Нужно это, чтобы его просто не задавили в команде авторитетом и знаниями. На момент организации команд и организации тестирования ребята у нас были в большинстве своем не такими опытными. Если следовать scrum, то люди должны быть с очень неплохими скилами, поэтому тут мы несколько отошли от концепции.
            Вообще такое чувство, что вам нужна была изначально не команда тестеров, а скорее команда, которая будет заниматься поддержкой автоматизации, т.е. настроит наконец все тулзы, авто-билды и т.п., чтобы можно было работать.

            Вообще автоматические тесты у нас пишут и разработчики, и тестировщики. Причем они независимы. Сделано так, чтобы не было «Этот функционал все равно у тестировщиков покрывается, тест писать не будем». Прогон автотестов от разработчиков был и до организации команды тестирования, технологии для этого уже были отработаны. Так что нет, нам нужна была именно команда тестирования, которая будет тестировать конкретные пользовательские кейсы.
              +1
              Какие тесты пишут разработчики, тоже функциональные? В статье вы говорили, что у вас есть тестировщики, которые занимаются именно автоматизацией, зачем тогда разработчикам тратить время на написание тестов?
                0
                Разработчики пишут функционаольные невизуальные тесты на внутренние механизмы и иногда модульные тесты. Эти тесты гоняются при каждом чекине и предназначены для быстрой проверки что в системе ничего не сломали. Результат приходит очень быстро и разработчики сразу могут поправить функционал.

                Тестировщики пишут функциональные-UI тесты для имитаций реальных действий пользователей и нефункциональные тесты (время выполнения действий, трафик, количество запросов и т.д.). Ограниченное число этих тестов гоняется на стенде все время, результат от такого прогона приходит за 2-3 часа. Все тесты команды тестирования гоняются ночью и результаты известны на следующий день.
                  0
                  Да, я понимаю разницу между Unit-тестами и UI-тестами. Просто из-за комментария подумала, что разработчики тоже UI-тесты пишут ;]
            0
            Об организации тестирования в команде, сделавшей отличный продукт.
            Инженеры по тестированию — часть команды разработки, где также есть системный аналитик, системный инженер и два инженера технической поддержки. Сначала соотношение было 0 к 1-му, потом 2 к 7-ми, сейчас 3 человека занимаются тестированим и 11 разработкой. Большой кабинет, общий митинг. Требования уточняются у системного аналитика и группы аналитики.

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

            Группа разработки — сработавшиеся люди, знающие друг друга, доверяющие друг другу, обладающие различными знаниями, навыками. Обмен знаниями повсечастный.

            Only users with full accounts can post comments. Log in, please.