"Конечно отдельная!", — ответит большая часть читающих. Такой ответ укладывается в их картину мира, потому что “так работали всегда”.
Так работали всегда
Эта фраза обычно означает наличие продукта, уже работающего на продакшене или только готовящегося зарелизиться, но написанного без модульных и интеграционных тестов. Без страховочной сети из тестов, изменения вносятся долго, дорого и с большим количеством новых багов. Такой проект в мире разработки принято называть “легаси”.
Компания понимает, что обойтись без страховочной сети нельзя, поэтому создается 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-отдел теперь отвечает не только за контроль качества продукта, но и за обеспечение качества, то в его обязанности входит:
- Помощь разработчикам при написании тестов из первой категории
- Участие в формировании Examples и Story Tests во время общении команды разработки с представителями бизнеса
- Проведение исследовательского тестирования и тестирования сложных сценариев
- Проведение тестирования юзабилити и работа с фидбеком от пользователей
Бесконечного роста регрессионных ручных black-box тест-кейсов не происходит, потому что большая их часть покрыта в первой и второй категориях командой разработки. В таком случае у нас формируется правильное отношение тестов или, как это принято называть, “пирамида тестирования”:
Рост количества регрессионных ручных тестов минимален, автоматизация на уровне модульных, интеграционных и GUI тестов осуществляется командой разработки. Причем количество GUI-тестов небольшое, они описывают не сложные сценарии использования GUI, а работу бизнес-логики через пользовательский интерфейс, а значит являются менее хрупкими и более дешевыми в поддержке. Отдел QA действительно занимается обеспечением качества, получая и работая с фидбеком от пользователей, проводя исследовательское тестирование, тестирование новой функциональности с помощью сложных сценариев, а также помогая разработчикам общаться с бизнесом. Тестирование в проекте автоматизировано эффективнее чем в первом случае, но команда автоматизации внутри QA-отдела так и не появилась.
И я повторю вопрос: “Automation QA — это отдельная команда?”
Комментарии (31)
kna986
10.04.2017 00:39«End-to-End тесты, которые тестируют не сложные сценарии использования интерфейса, а лишь бизнес-логику, но через интерфейс, который доступен конечному пользователю. Так как данная категория тестирования все еще лежит в сфере интересов разработки, то автоматизация ложится на плечи команды разработки»
А с чего бы это вдруг? Команда разработки будет делать эти тесты как? Коллегиально, каждый по 100 строк? Фронтендеры или бекэндеры, кто лучше справится? Чтобы разрабатывать End-to-End тесты, разработчики внезапно должны залезть уж очень глубоко в бизнес-домен и заодно на «поле» своих коллег, иначе ничего не выйдет. А им ещё фичи писать. Переключение контекста, которое требует времени и нервных клеток, а так же само время на создание и поддержку этих тестов, кто оплатит? Бизнес. А ему это выгодно? Представляю ситуацию — а чего у нас к релизу половина фич не сделана? Да тут Селениум 3-ий вышел и Огнелис перестал работать с 50-ой версии со старым драйвером, так что звиняйте, мы тут тесты правим.
Или всё таки логичнее выделить одного-двух несчастных для этого? Ой, вот вам и появился выделенный отдел автоматизации.
Ну и доставило «не сложные сценарии использования интерфейса, а лишь бизнес-логику». То есть, в кровавом интерпрайзе бизнес логика так, тьфу, не сложная?) По моему опыту как раз таки наоборот. И end-to-end там будет не «добавить товар в корзину», а нечто фееричное. Так что, не убедили.
Telichkin
10.04.2017 10:41+3А с чего бы это вдруг? Команда разработки будет делать эти тесты как? Коллегиально, каждый по 100 строк? Фронтендеры или бекэндеры, кто лучше справится?
Один из вариантов: GUI End-to-End покрывают фронтенд-разработчики, API End-to-End — бэкенд-разработчики. Фичи же получается как-то коллегиально делать, с автотестами тоже не возникнет проблем.
Чтобы разрабатывать End-to-End тесты, разработчики внезапно должны залезть уж очень глубоко в бизнес-домен
По-моему писать бизнес-логику, не понимая как должен будет выглядеть конечный результат, довольно странно. А для понимания конечного результата придется залезать в бизнес-домен в любом случае.kna986
10.04.2017 12:52+1А вы так делали, чтобы утверждать, что не возникнет проблем? А насчёт переключение контекста, времени, ничего не хотите сказать? А с точки зрения управления — по факту, вместо того, чтобы управлять небольшой командой автоматизаторов, нужно будет управлять всей командой разработки, которым придётся разрабатывать параллельно ещё один продукт, проблем не возникнет?
Уровни понимания конечного результата дюже разные бывают. Некий результат в вакууме понять то не сложно. Но тонкости изучать и при этом ещё постоянно быть в курсе всех изменений? Вы, верно, шутите.
samizdam
10.04.2017 01:23+1Хорошая статья, качественно написанная и оформленная. И тезисы верные.
С почином, пишите ещё!Sinatr
10.04.2017 12:07Мне картинка очень понравилась… жизненно!
Rozmysel
10.04.2017 21:13Не понятно только для чего на ней 2, 4 и 6я. Они же совершенно не несут никакой информации а 2 и 4 вообще одна и та же.
Sinatr
11.04.2017 10:38С удовольствием полюбовался еще раз, сообщаю: на 2 картинке верхний жук обходит релиз чтобы катить его к тестерам (на 3й он поворачивается к собеседнику) на 4й он обдумывает свой ответ и план действий, на 6й оказывается что нижний жук тоже катит свой релиз к тестерам… Очень жизненно: пообщались, посетовали и продолжили работу дальше (а что делать? дома семья, дети голодные, против системы идти себе в ущерб).
lxsmkv
10.04.2017 03:18+3У нас приложение поделено на функциональные разделы. У каждого раздела свой подрядчик. Мы делаем три раздела из двенадцати. В каких-то командах четверо пишут ui-автотесты на один раздел, у нас один пишет на три.
Я — отдельная команда. Нашего тимлида по-поводу автотестов дергает техлид заказчика. Мое дело держать автотесты «в зеленом секторе». Не дергают моего тимлида он не дергает меня. И никому нет особенно дела как у меня там дела, пока все нормально. Правда я еще багрепорты пишу. Если бы не это наверное бы не знали как и звать :) И можно было бы передать ответственность за написание автотестов разработчикам, но это сьедает столько времени, что лучше не надо. Пусть пишут код. А «Команда-Я» как нибудь бегом широкими прыжками на хвосте.
Соглашусь, был бы рад, если бы мне дали какого нибудь студента в помощники, но проект строго бюджетирован.
В принципе считаю что лучше брать на автоматизацию специально людей. Но не из-за пирамид на графике. Просто они по другому смотрят на продукт.
Когда тестировщик приходит к программисту прояснить принцип работы куска функционала, программист часто говорит или думает «о, обьяснил и сам лучше понял» — это очень ценный диалог. Тестировщик может задавать наивные вопросы. Мне кажется это имеет положительное влияние на вырабатывание качественно другого подхода к разработке. Но на это нужно время. Время. Его всегда мало.
Jef239
10.04.2017 15:46Просто они по другому смотрят на продукт.
Золотые слова. Всеми лапами и хвостам ЗА.
aintghost
10.04.2017 10:42Подход интересный, но к снижению количества высокоуровневых тестов не приведет. QA в любом случае несет ответственность и будут проверять все возможные сценарии.
Но соглашусь, покрытие кода unit-тестами снизит количество возвратов билда девелоперам в случае наличия ошибок, что в итоге может привести к снижению времени производственного цикла.
Dmitriy_M
10.04.2017 12:44В статье упущено много опций, например, про тестируемые конфигурации в GUI тестах (как пример тестирование мобильных приложений и взаиможействие с ОС) это сильно изменит процентное соотношение, или наличие отдельной бизнес-логики на стороне клиента и т.д.
Если кратко, то да, этот подход будет действенен для какого-либо проекта, но реальность намного сложнее и не все так просто.
mike1
10.04.2017 13:38I always argue that high-level tests are there as a second line of test defense.
Только не "утверждаю", а "спорю" с тем, что это вторая линия обороны. То есть, это не вторая, а первая линия.
Jef239
10.04.2017 15:41-1Беда, коль пироги начнет тачать пирожник...
В тесте две мысли, о переносе тестирования в отдел разработки и о написании тестов программистами. Первая — частично верная, а вторая — нет.
Есть такое золотое правило тестирования "в своем коде баги не видны". Если программист при написании кода решил, что «не меньше» это «больше», он так решит и при написании тестов. В итоге написанные программистом тесты годятся лишь для рапорта «у нас все хорошо». А на самом деле — в коде ещё полно ошибок.
Я уж не говорю о том, что программеры больше синтетики, а тесты хорошо пишут аналитики (люди, у которых процессы анализа преобладают над синтезом).
Поэтому к программистам добавляется тестер. Из расчета примерно один тестер на 2-3 программиста. Он получает ТЗ вместе с программистами и пишет тесты. В идеале тестер ещё и участвует в ревью кода.
Чтобы избежать давления, тестер подчиняется при этом руководству QA. И его оплата — как-то завязывает на число найденных им багов. Или на число багов, пролетевших мимо него и найденных на поздних стадиях тестирования.
Все это не новость, давно описано у Брукса под названием «Бригада главного хирурга».
Дополнительный плюс этого метода — через пару лет такой практики тест становится достаточно зрелым разработчиком и готов к переходу в девелоперы.Telichkin
10.04.2017 22:31Если программист при написании кода решил, что «не меньше» это «больше», он так решит и при написании тестов
Именно поэтому QA-отдел и должен осуществлять «Помощь разработчикам при написании тестов из первой категории».
Из расчета примерно один тестер на 2-3 программиста.
А JIRA разрабатывают с 6 QA-инженерами на 70 девелоперов, причем QA-инженеры отвечают не за написание тест-кейсов и называются немного иначе.Jef239
11.04.2017 00:09-1«Помощь» — это не то. Хороший тестер знает психологические профили разработчиков и их типичные ошибки. И ещё до тестов понимает, в каких местах может скрываться ошибка. Помощь тут бесполезна. Разработчику можно 10 раз сказать, что он делает типичную ошибку — но он все равно будет её делать, ибо это особенность его мышления.
Но главное не в этом. Чтобы получить senior development нужно лет 10 практической работы. Senior QA становятся намного быстрее. Поэтому и надо заменять дорогих разработчиков на дешевых тестеров. А уж как называть их — дело десятое. Можно и тестерами и подаванами и секретарями…
Но общий вектор в любом случае состоит в разгрузке высококвалифицированных сотрудников за счет передачи вспомогательных функций низкоквалифицированным.
Впрочем, если у вас QA получают больше девелоперов, то ваша идея имеет смысл.NeverIn
11.04.2017 10:38Все хотят дешевых тестеров, но требования как с сеньоров-разрабов, эта тема не прокатывает. Хороший тестер не будет дешевле разраба.
Jef239
11.04.2017 10:52Разница в оплате тестеров и программистов — это разница в образовании и опыте работы. Из опытного пользователя — получается вполне приличный тестер. Из юниора-программиста — выходит отличный тестер.
Есть лишь одна особенность, нужная для тестера — умение влипать в редкие ситуации. Всему остальному тестер обучается быстро.
Это как по собственному опыту, так и по руководству группой тестеров.
ekungurov
11.04.2017 14:03Из юниора-программиста — выходит отличный тестер.
Ох не всегда из программиста выходит тестер, тем более отличный.Jef239
11.04.2017 14:12Не всегда. Тестеры — аналитики, программисты — синтетики. Но… шанс, что из юниора выйдет тестер больше, чем то, что юниор станет сеньором.
Что такое тестерская невезуха, оно же чутье.
Тыкаю мышкой в интерфейс — 100% баг, тыкает второй тестер — 50% баг, тыкает автор — нет бага. Оказывается была там полоска высотой в один пиксель… Ну в общем я не ту точку мышиного курсора на цель наводил. :-))))lxsmkv
11.04.2017 15:08+1да, и тестировщик интуитивно (по опыту) знает какие комбинации стоит проверить а какие бессмысленно. позитивный кейс тестировщик даже проверять не станет, его уже 100 раз проверил разработчик.
NeverIn
10.04.2017 21:42> Так как созданный QA-отдел теперь отвечает не только за контроль качества продукта, но и за обеспечение качества, то в его обязанности входит: Помощь разработчикам при написании тестов из первой категории…
т.е. автоматизатор == разработчик (читает код, понимает его, пишет код тестов на том же языке) + аналитик бизнес-стори, сложные сценарии) + контакты с пользователями, поддержка + юзабилити (дизайн, UX)…
А что делает разработчик — пилит нетленку по ТЗ+юнит тесты на нее же за бОльшую зп.
При таком раскладе QA сваливает на разработчика в течении полугода.Jef239
11.04.2017 10:53А разве плохо иметь свою кузницу кадров? Врубание в проект через тестирование — это вполне нормальный подход. Просто надо быть готовым к текучке у тестеров.
Nakilon
> Автоматизация через GUI наиболее болезненная и дорогостоящая из-за хрупкости и низкой скорости тестов, но зачастую начинают именно с нее.
Дорогостоящая? Автоматизаторов GUI-тестирования нужно на порядок меньше, чем остальных программистов.
И правильно делают, что начинают с нее — первые 10 строк GUI-тестов заменят первые десять тысяч строк юнит-тестов. «Взять и покрыть юнитами все, что наделали на сегодняшний день» можно только если ничего не наделали, поэтому надо начинать с высокоуровневых тестов, которые укажут, в какие направления нужно спускаться, уровень за уровнем, а не бросаться с юнитами на все подряд.
> Тем временем, факт создания новой команды никак не влияет на команду разработки: она все также продолжает отдавать в тестирование некачественный продукт, игнорируя написание модульных и интеграционных тестов.
Ничего подобного, если есть CI. К следующему спринту (или какую у вас там религию планирования менеджеры придумают) чувак, не сумев позеленить свой мержреквест будет вынужден начать включать голову, когда код пишет. Если у него это получаться будет хуже, чем у коллег, то вообще отлично — нашли, кто баги наплодил.
> Нестабильных и медленных по своей природе GUI-автотестов с каждым релизом становится все больше, а значит больше ресурсов уходит на их поддержку, что ведет к расширению команды автоматизации.
Автотест не бывает «нестабильный» просто так — либо витую пару грызут мыши, либо кто-то сильно гордый отказывается логировать/дебажить. А то, что нестабильность выявляется — это потому, что автотест более внимателен к деталям, чем наивный пользователь, который просто ленится багрепортить нестабильность, а вместо этого ругает свою винду, браузер или старый комп.
> Департамент обеспечения качества растет, но не обеспечивает должный рост качества выпускаемого продукта.
см. пункт 2
P.S.: две недели отвечать не смогу. Только в личку.
Telichkin
Если стоит задача создать хоть какое-нибудь покрытие автотестами проекта, на котором отсутствуют автотесты, правильнее начинать с небольшого количества End-to-End тестов, и продолжить спускаться на более низкие уровни. Но когда в создании автотестов заинтересована только Automation QA команда, этого спуска не происходит, и все заканчивается на End-to-End.
Это действительно возможный вариант. влияния отдела Automation QA на разработку, если разработка и менеджмент доверяют и понимают результаты прогонов с CI.
Просто так не бывает, но в End-to-End тестах бывает чаще, чем в других. Как минимум из-за взаимодействия с системой через пользовательский интерфейс, который иногда бывает довольно изменчив. Если с разработчиками фронтенда удается выстроить работу так, чтобы изменения во фронте не сильно влияли на результаты тестов,, это, конечно, замечательно.
izzholtik
> Автотест не бывает «нестабильный» просто так
Бывает. UiAutomator, например, не работал нормально на SGS4, там даже ввод текста в поле приходилось руками делать, через эмуляцию нажатий клавиш. Причём весьма долго не работал, месяцев 8.
maxim_0_o
Суть автоматизации тестирования в сокращении времени между появлением бага и его обнаружением. В случае юнит теста вы узнаете о баге еще до коммита. И вы будете с точностью до метода знать, где находится проблема. В случае GUI теста в лучшем случае сценарий будет такой:
1. Разработчик сделает пул реквест
2. Другой разработчик его посмотрит и зааппрувит
3. Сработает какой-либо триггер сборки новой версии (будь то наличие изменений в репозитории или просто ночью в определенное время)
4. Где-нибудь сразу после сборки пойдут тесты и упадут (и, вероятно, отправят письмецо «команде автоматизации»)
5. Через некоторый промежуток времени у автоматизатора появится время посмотреть в чем проблема. Он, скорее всего попробует воспроизвести проблему локально чтобы убедиться, что проблема не в тесте (а тесты довольно нестабильная штука, что бы вы не говорили о ленивости их разработчиков)
6. Убедившись, что это действительно проблема в продукте, тестировщик пойдет заводить баг
7. Баг попадает в бэклог (или еще какое-то хранилище, где он будет ждать пока его починят)
8. Разработчик через некоторое время доберется до бага.
9. Из бага не всегда можно понять где именно проблема, поэтому некоторое время разработчик потратит на отладку
10. После этого баг будет пофикшен и пул реквест снова отправится на код ревью
И далеко не факт, что после правки этого бага не появилось новых двух ;)
Поэтому да. Дорогостоящая как по трудовым ресурсам, так и по времени обнаружения и устранения
Jef239
В чем проблема прогнать GUI-тест до пул-реквеста? Для многих систем это обычное дело.
Ogra
Минимизация времени обнаружения и устранения — это важно. Поэтому приведенный вами процесс разработки в корне неверен. Какой еще аппрув пул-реквеста до тестов?
1. Разработчик коммитит в свою ветку и пушит (часто!) эту ветку в репозиторий
2. На каждый пуш, в каждую ветку, запускаются тесты.
3. Если тесты неудачны — этому разработчику сразу же отправляется письмо.
4. На каждый пул-реквест автоматически запускаются тесты. Если тесты не прошли, пул-реквест аппрувить нельзя!
justboris
А если тест ломается по причине новой функциональности? Как поступить с мерджем в такой ситуации?
Ogra
Не проводить мердж, пока тесты не починены.
justboris
Не очень понял.
Например есть кнопка отправки формы. В новой версии она сменила местоположение и GUI-тест ее не может найти. При этом в мастер-бранче, она все еще на прежнем месте и тест проходит.
Как обработать эту ситуацию?
Обычно у выделенной QA-команды еще и отдельный репозиторий, так что вариант закоммитить правку в тот же фича-бранч не подойдет.