Home

Оригинальная публикация: https://habrahabr.ru/post/326020/

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

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

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

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

Нажмите на картинку, чтобы увеличить изображение

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

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

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

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

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

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

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

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

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

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

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

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

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

Нажмите на картинку, чтобы увеличить изображение 

Используя 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 тест-кейсов не происходит, потому что большая их часть покрыта в первой и второй категориях командой разработки. В таком случае у нас формируется правильное отношение тестов или, как это принято называть, “пирамида тестирования”:

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

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

Обсудить в форуме.