[Из песочницы] Automation QA — это отдельная команда?09.04.2017 22:18

«Конечно отдельная!», — ответит большая часть читающих. Такой ответ укладывается в их картину мира, потому что «так работали всегда». 


Так работали всегда


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


Компания понимает, что обойтись без страховочной сети нельзя, поэтому создается QA-отдел, который обычно не обеспечивает качество продукта, а лишь контролирует его. С QA-отделом разработчик может спокойно заниматься любимым делом — писать код, ведь ответственность за качество теперь несет выделенный отдел! Происходит классическое «перебрасывание кода через стену» в отдел тестирования:


e5c5c590eb31430dbe16a2c58f3086fc.png

QA-отдел пишет сотни black-box тест-кейсов на уже готовую функциональность, которые необходимо проходить во время регрессии. А также, если продукт продолжает развиваться, сотни тест-кейсов на новую функциональность, которые позже добавляются в регрессию. 

Прохождение каждого тест-кейса ручное, поэтому процесс тестирования занимает много времени. Количество тест-кейсов в регрессии по естественным причинам постоянно растет, и принимается решение о создании внутри QA-отдела команды автоматизации.


Так как новоиспеченная команда набиралась из-за необходимости ускорить цикл регрессии, который состоит из black-box тестов, то и автоматизация происходит на уровне black-box: через GUI или API. Автоматизация через GUI наиболее болезненная и дорогостоящая из-за хрупкости и низкой скорости тестов, но зачастую начинают именно с нее. 


Тем временем, факт создания новой команды никак не влияет на команду разработки: она все также продолжает отдавать в тестирование некачественный продукт, игнорируя написание модульных и интеграционных тестов. Учитывая огромное количество black-box сценариев, находящихся в очереди на автоматизацию, получаем анти-паттерн тестирования Ice-Cream Cone, в котором количество самых медленных и самых дорогостоящих GUI-автотестов намного больше количества дешевых и быстрых модульных и интеграционных тестов.


10555101968a4be89bb8b2272440d946.png

Нестабильных и медленных по своей природе GUI-автотестов с каждым релизом становится все больше, а значит больше ресурсов уходит на их поддержку, что ведет к расширению команды автоматизации. Департамент обеспечения качества растет, но не обеспечивает должный рост качества выпускаемого продукта. Вы действительно хотите так работать всегда?  


В чем проблема?


Одна из главных причин возникновения ситуации, описанной выше, — это отсутствие культуры разработки, в которой каждый разработчик несет ответственность за написанный им код. А даже минимальная ответственность понимает под собой необходимость удостовериться в работоспособности кода прежде чем радостно восклицать: «Моя работа готова!».


Eye Driven Development является самым простым способом удостовериться в работоспособности кода, но не самым оптимальным. Прост этот способ тем, что не предполагает практически никакой интеллектуальной работы: мы тестируем руками приложение, сервис, класс и т.д. с точки зрения конечного пользователя, не рассматривая граничные значения, классы эквивалентности, негативные сценарии, сценарии с разными уровнями permissions и прочее. Такой способ не дает быстрой обратной связи при разработке, не позволяет проверить сущность на разнообразной выборке данных, занимает много времени и не улучшает качество продукта.


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


Работаем не так как всегда


Предлагаю мысленно смоделировать возможное развитие событий в команде, члены которой несут ответственность за написанный код. 


У нас имеется продукт, уже работающий на продакшене или только готовящийся зарелизиться, который покрыт модульными и интеграционными тестами. Код постоянно совершенствуется, а новая функциональность добавляется без страха сломать уже имеющуюся. Чтобы убедиться в работоспособности разрабатываемой функциональности больше не нужно «перебрасывать код через стену» в отдел тестирования и терять время, ожидая вердикта, после чего повторять итерацию снова и снова.


QA-отдел уже создан и активно участвует в процессе разработки, занимаясь действительно обеспечением качества выпускаемого продукта. При разговоре об обеспечении качества, как мне кажется, удобно руководствоваться Testing Quadrants:


8becaaaf9c3d411d8682360d5705eef8.jpg

Используя Testing Quadrants, тестирование можно разбить на 4 категории.


Первая категория — это тестирование реализации продукта, создающее страховочную сеть для команды разработки. Эта категория отвечает за низкоуровневое тестирование с помощью модульных и интеграционных тестов и позволяет понять разработчикам, что с технической точки зрения они делают вещи правильно (Do Things Right). Очевидно, что низкоуровневые тесты являются полностью автоматизированными и пишутся командой разработки, так как лежат в ее сфере интересов.


Вторая категория — это тестирование бизнес-функций продукта, создающее страховочную сеть для команды разработки. Здесь речь идет о таких видах тестирования как Examples, Story Tests и прочих, направленных в первую очередь на создание правильной коммуникации между бизнесом и командой разработки, и позволяющих команде понять, что она делает правильные вещи (Do Right Things), которые действительно нужны бизнесу. 


Автоматизирование Examples или Story Tests представляет из себя End-to-End тесты, которые тестируют не сложные сценарии использования интерфейса, а лишь бизнес-логику, но через интерфейс, который доступен конечному пользователю. Так как данная категория тестирования все еще лежит в сфере интересов разработки, то автоматизация ложится на плечи команды разработки.


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


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


I always argue that high-level tests are there as a second line of test defense. If you get a failure in a high level test, not just do you have a bug in your functional code, you also have a missing or incorrect unit test. Thus I advise that before fixing a bug exposed by a high level test, you should replicate the bug with a unit test. Then the unit test ensures the bug stays dead.

Я утверждаю, что высокоуровневые тесты — всего лишь вторая линия обороны. Упавший высокоуровневый тест означает не только баг в коде продукта, но и отсутствие соответствующего модульного теста или ошибку в уже имеющемся. Мой вам совет: прежде чем фиксить баг, найденный высокоуровневым тестом, воспроизведите его с помощью модульного теста, и вы попрощаетесь с багом навсегда.

Четвертая категория — это тестирование реализации продукта, которая критична для восприятия качества продукта конечным пользователем. Обычно в эту категорию попадают нагрузочное тестирование, тестирование производительности, тестирование безопасности и надежности системы. Такое тестирование проводится с использованием специальных инструментов, зачастую написанных под нужды конкретного проекта. По-хорошему, инфраструктурой для проведения подобных тестов занимается DevOps-отдел, а разработкой соответствующих инструментов —
отдельная команда. Причем инструменты должны позволять проводить тесты по-требованию (Testing as a Service). 


Так как созданный QA-отдел теперь отвечает не только за контроль качества продукта, но и за обеспечение качества, то в его обязанности входит:


  1. Помощь разработчикам при написании тестов из первой категории
  2. Участие в формировании Examples и Story Tests во время общении команды разработки с представителями бизнеса
  3. Проведение исследовательского тестирования и тестирования сложных сценариев
  4. Проведение тестирования юзабилити и работа с фидбеком от пользователей 

Бесконечного роста регрессионных ручных black-box тест-кейсов не происходит, потому что большая их часть покрыта в первой и второй категориях командой разработки. В таком случае у нас формируется правильное отношение тестов или, как это принято называть, «пирамида тестирования»:


f3970b8bb6d843e7a3a9e4ae519ab125.PNG

Рост количества регрессионных ручных тестов минимален, автоматизация на уровне модульных, интеграционных и GUI тестов осуществляется командой разработки. Причем количество GUI-тестов небольшое, они описывают не сложные сценарии использования GUI, а работу бизнес-логики через пользовательский интерфейс, а значит являются менее хрупкими и более дешевыми в поддержке. Отдел QA действительно занимается обеспечением качества, получая и работая с фидбеком от пользователей, проводя исследовательское тестирование, тестирование новой функциональности с помощью сложных сценариев, а также помогая разработчикам общаться с бизнесом. Тестирование в проекте автоматизировано эффективнее чем в первом случае, но команда автоматизации внутри QA-отдела так и не появилась.


И я повторю вопрос: «Automation QA — это отдельная команда?»

Комментарии (2)

  • 9 апреля 2017 в 20:32

    +1

    ↑

    ↓

    > Автоматизация через GUI наиболее болезненная и дорогостоящая из-за хрупкости и низкой скорости тестов, но зачастую начинают именно с нее.

    Дорогостоящая? Автоматизаторов GUI-тестирования нужно на порядок меньше, чем остальных программистов.
    И правильно делают, что начинают с нее — первые 10 строк GUI-тестов заменят первые десять тысяч строк юнит-тестов. «Взять и покрыть юнитами все, что наделали на сегодняшний день» можно только если ничего не наделали, поэтому надо начинать с высокоуровневых тестов, которые укажут, в какие направления нужно спускаться, уровень за уровнем, а не бросаться с юнитами на все подряд.

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

    Ничего подобного, если есть CI. К следующему спринту (или какую у вас там религию планирования менеджеры придумают) чувак, не сумев позеленить свой мержреквест будет вынужден начать включать голову, когда код пишет. Если у него это получаться будет хуже, чем у коллег, то вообще отлично — нашли, кто баги наплодил.

    > Нестабильных и медленных по своей природе GUI-автотестов с каждым релизом становится все больше, а значит больше ресурсов уходит на их поддержку, что ведет к расширению команды автоматизации.

    Автотест не бывает «нестабильный» просто так — либо витую пару грызут мыши, либо кто-то сильно гордый отказывается логировать/дебажить. А то, что нестабильность выявляется — это потому, что автотест более внимателен к деталям, чем наивный пользователь, который просто ленится багрепортить нестабильность, а вместо этого ругает свою винду, браузер или старый комп.

    > Департамент обеспечения качества растет, но не обеспечивает должный рост качества выпускаемого продукта.

    см. пункт 2

    P.S.: две недели отвечать не смогу. Только в личку.

    • 9 апреля 2017 в 21:21

      0

      ↑

      ↓

      И правильно делают, что начинают с нее — первые 10 строк GUI-тестов заменят первые десять тысяч строк юнит-тестов.

      Если стоит задача создать хоть какое-нибудь покрытие автотестами проекта, на котором отсутствуют автотесты, правильнее начинать с небольшого количества End-to-End тестов, и продолжить спускаться на более низкие уровни. Но когда в создании автотестов заинтересована только Automation QA команда, этого спуска не происходит, и все заканчивается на End-to-End.
      Ничего подобного, если есть CI.

      Это действительно возможный вариант. влияния отдела Automation QA на разработку, если разработка и менеджмент доверяют и понимают результаты прогонов с CI.
      Автотест не бывает «нестабильный» просто так

      Просто так не бывает, но в End-to-End тестах бывает чаще, чем в других. Как минимум из-за взаимодействия с системой через пользовательский интерфейс, который иногда бывает довольно изменчив. Если с разработчиками фронтенда удается выстроить работу так, чтобы изменения во фронте не сильно влияли на результаты тестов, это, конечно, замечательно.

© Habrahabr.ru