Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Как при фейле авто-теста вы заводите баг?

management
Теги: #<Tag:0x00007f7b6d1d7e60>

(Romanchuk Katerina) #1

Как вы обычно заводите баг на функциональность?

1) Пишите в дискрипшен бага ссылку на сам авто-тест без особых деталей. :bath:
2) Либо же заводите баг с четким steps to reproduce ? :memo: :memo: :memo:
Пошагово описывая все-все, что нужно сделать, чтоб воспроизвести проблему и чтоб воспроизвести смог любой, даже тот кто совсем не знает где посмотреть на автотесты и что они там проверяют. :broken_heart:


(rmerkushin) #2

Завожу баг как при ручном тестировании с полным описанием всех шагов и аттачем доп. артефактов (sql скрипты, логи и т.д.) :slight_smile:


(Александр Таранков) #3

Для UI так же как и при ручном - с чётким описанием шагов, версий, environment и т.п. Потому что воспроизвести его можно и вручную.

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

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


(asolntsev) #4

При поломке автотеста никаких багов заводить не надо!
Автотест, если он действительно “авто”, запускается автоматически на сервере непрерывной интеграции (Jenkins то бишь). Разработчики получает от Jenkins злобное письмо и бросаются исправлять сломанный тест.

Что значит “любой, даже тот кто совсем не знает где посмотреть на автотесты”? Разработчики обязаны знать, где посмотреть и как запустить автотесты! Более того, в идеале они их сами же должны и писать!


(Romanchuk Katerina) #5

У вас все автотесты прогоняются после каждого сабмита?

Я не про сломанный тест спросила, а про тест который сфейлился по причине бага в функционале.

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

Это баг.
Баг в коде на фичу сделанную много времени назад.
Его нужно завести в багтрекинговой системе.
Как его завести?

Написать пошагово описывая все, что делает тест либо написать в саммери бага:
“Упал автотест: такойто…” и в дискрипшене - ссылку на тест?


(asolntsev) #6

Да, у нас все автотесты прогоняются после каждого сабмита. Но это даже неважно.
Неважно, сломанный тест или сломанная функциональность - ответ тот же. Если билд в дженкинсе красный - разработчик должен сам это сразу увидеть (в мейле, на большом экране - неважно) и отреагировать.

Другими словами, разработчики должны следить за цветом дженкинса. Красный билд - тревога, все бросаются исправлять. Если есть такая дисциплина, зачем заводить баг? А если дисциплины нет, то и баг заводить бесполезно. Вы просто перегоняете информацию о проблеме из одного источника в другой (из дженкинса в джиру). Зачем тратить на это время? Пусть разработчики сразу смотрят в правильный источник.


(vmaximv) #7

Вы говорите про юнит тесты либо про синтетические. Насколько я понимаю, эта тема не про данные виды тестирования.


(Romanchuk Katerina) #8

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


(Romanchuk Katerina) #9

Это конечно. Я спрашивала про функциональные тесты (Билд зеленый)


(asolntsev) #10

Я имею в виду любые виды тестирования.
Обычно юнит-тесты запускаются вместе с компиляцией проекта, а остальные тесты запускаются в отдельном JOB’е. Каждый из этих JOB’ов может быть красным или зелёным.

Если функциональный тест падает, значит, соответствующий JOB в Jenkins должен быть красным. Функциональность сломана - тревога - все бросаются исправлять.


(vmaximv) #11

А теперь постройте цепочку взаимодействия между этими “всеми кто кинулся исправлять” - без баг трекера это возможно?
А так же подумайте про метрики, которые могут хоть как-то показать эффективность автоматизации на проекте.


(asolntsev) #12

А чем по сути баг трекер отличается от дженкинса? Баг трекер - это веб-приложение, откуда разработчик может узнать, что ему дальше делать. Дженкинс - точное такое же веб-приложение, откуда разработчик точно так же может узнать, что ему дальше делать.

Я не очень понимаю, что означает “строить цепочку” и какие такие метрики настолько полезны, что ради них нужно вручную копировать информацию из одного веб-приложения в другое. И как эта ручная работа может повысить эффективность автоматизации на проекте, я уж точно не понимаю.


(Romanchuk Katerina) #13

А вы не трекаете рабочее время?
У нас, например, принято трекать рабочие часы.

И еще…, а если фикс заафектил какой-то другой функционал? Автомейшен тесты пройдут, но кто проверит какие-то вещи, которые тоже могли поломаться и на которых еще нет авто-тестов.
Если будет баг, то разработчик может в affected component написать, что могло заафектиться и тестеровщики посмотрят, перепроверят.


(Romanchuk Katerina) #14

Это модель подходит для малюсенькой команды, в которой несколько разработчиков и нет ни менеджера, ни возможно даже QA. Для больших команд, в которых нужно работать очень слажено - это абсурд.


(asolntsev) #15

Конечно мы трекаем рабочее время. Только его бессмысленно трекать “на багфиксинг”.
Ведь функциональность была сломана не просто так, а в процессе работы над новым таском X, так? Вот и записываем время на этот таск X. Раз сделали багу и пришлось её чинить, значит, так и есть, потратили на этот таск больше времени.

Ох уж эти affected component… Ведь разработчика на слово нельзя верить! Какая разница, что они там написали в “affected component”? Этому нельзя доверять! Как правило, ломается то, о чём они и не подумали, ведь так? Тестер должен доверять своему чутью и опыту, а не словам разработчиков, нет?

P.S. У нас такого не бывает, ибо авто-тестами покрыто вся функциональность.

Что именно абсурд? Что и баг трекер, и дженкинс являются веб-приложениями? Что разработчики обязаны туда изредка посматривать? Что разработчики обязаны немедленно реагировать на красные билды? Размер команды тут не при чём!


(Kolesnik Nickolay) #16

Необязательно. Бывает такое, что какие-то проблемы обнаруживаются уже впоследствие, как результат расширения того или иного теста. И эти проблемы могут затрагивать несколько команд, соответственно нужен способ коммуникаций, по которому можно следить статус выполнения, переназначать на кого-то и так далее. Форма, в которой это делается - это дело десятое. Таск или баг - в любом случае это какая-то запись ,которая как-то отслеживается

Даже если у вас и так:

то это не значит, что вы покрыли все возможные пути использования той или иной части системы (покрытие - достаточно широкое понятие и их видов достаточно большое множество) -> периодически тесты надо дополнять, уточнять -> могут появиться новые проблемы. И они никак не связаны с текущими задачами.

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

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


(vmaximv) #17

Вашу точку зрения я знаю, но… Давайте порелаксируем…
Представим проект, который билдится 5-6 часов с документацией на инсталляцию на 4-5 страниц. В котором работают менеджеры, девы, тестеры, автоматизаторы, бизнес-аналитики, техникал-райтеры, перфоманс тестеры, build engineers и т.д. Для пущей сложности разобьем команду на разные локации - часть работает на стороне заказчика (США например), часть в оффшоре (Индия и Россия).
Итак четверг и выходит новый билд. После 12 часов автотестов регресии видно, что один (из 1500+ тестов упал), который состоит более чем из 50 степов и затрагивает несколько областей приложения. А за эти 12 часов мануальщики честно трудились, а девы вполне могли “подложить” несколько патчей.

Разбор упавшего теста состоит из следующих этапов:

  1. Определить не фейл ли это скриптов
  2. Локализовать проблему (тут подэтапов вагон и тележка: проверка корректности установки билда, проверка инвайромента, пройти ручками, разбор логов и т.д.)
  3. Минимизировать кол-во степов
  4. Пролапатить баг-трекер в котором 10К+ багов на предмет регресии, либо на то, что баг на этот фейл уже выписан
  5. Проверить соответствует ли зафейленный тест текущим требованиям, корректен ли тест в отношении текущего функционала
  6. Если требования противоречивы, уточнить их у заказчика, обновить спецификации, обновить авто-тест в соответствии с новыми требованиями.
    и т.д.

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

Говоря, что баг-трекер для автоматизации не нужен, вы автоматически подразумеваете одно из следующего:

  1. На проекте отсутствует ручное тестирование
  2. Проект с очень коротким лайфтаймом и маленькой командой.
  3. Вы говорите про BAT (Build Acceptance Test) - серия коротких и быстрых интеграционных UI тестов, с таймраном не более часа, которые проверяют самый критичный функционал приложения. Такой уровень тестирования довольно часто применяется. На фейлы в BAT баги не выписываются, просто билд не релизается до их устранения.

Про метрики:
Весьма велика вероятность, что у заказчика когда-нибудь возникнут сомнения по поводу эффективности автоматизации, и появится желание сэкономить некоторую сумму на “этих ребятах”. Вот тут могут возникнуть вопросы: сколько багов нашлось авто-тестами?
“- Хм. Нисколько? А мануальщики вон по сотне за неделю находят. Зачем я тогда плачу за автоматизацию?”


(asolntsev) #18

А, ну тогда ответ на поставленный вопрос “Как вы заводите багу?” очень просто: вы не заводите багу. Пусть разработчики сами решат, мелочёвка ли это (и они пофиксят её сразу) или что-то более серьёзное, и тогда они заведут багу.


(Kolesnik Nickolay) #19

Ну так если у вас производительность команды тестирования меряется в количестве найденных багов, то может быть действительно стоит гнать в шею “этих ребят”, так как стоят они дороже, а выхлоп минимальный? Или может у вас тестирование устроено так, что автоматизация используется только на старом проверенном функционале и естественно, на этом направлении мало что можно найти. Тогда да, нафик такую автоматизацию, это напрасная трата времени и денег. Да и если мануальщики при этом постят по сотне багов, то скорее всего 90% из этого либо дубликаты либо ложные ошибки, либо вот такая мелочевка, которая могла бы быть выловлена намного раньше.

А вот если внезапно окажется, что цикл тестирования уменьшается раза в 2-3, при том, что команда остается той же самой и % покрытия не уменьшается, хотя постоянно все обрастает новыми фичами, то это уже совсем другой разговор.


(Kolesnik Nickolay) #20

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

  1. Описание проблемы - если эту проблему выловил не разработчик в ходе своих тестов, то это наверняка подразумевает, что был использован более сложный flow, требующий достаточно сложной комбинации входных параметров и направленный на какую-то конкретную проверку. Соответственно, описание проблемы, предоставление входных данных и сопутствующих ресурсов - это скорее задача того, кто эту проблему обнаружил, так как у этого человека есть весь набор входных данных
  2. Верификация исправления ошибки - разработчики могут исправить проблему, но не до конца или в том виде, в котором они видят нужным. Но это совсем не значит, что это будет именно то исправление, которое ожидается. Соответственно, нужна дополнительная проверка

Из-за этого скорее всего баг надо будет заводить тестировщику. А так как это отдельная задача, которую надо отдельно трекать и переназначать, то ее надо где-то хранить в таск трекере.

Ну, и наконец, не надо переоценивать возможности разработчиков. Да, они могут писать автотесты (и делают это лучше, чем большинство автоматизаторов), они во многом могут быть лучше в тех местах, когда надо определить КАК надо сделать. А вот когда надо определить ЧТО надо сделать - вот тут возникают проблемы. И не потому, что разработчики этого не могут сделать (все что нужно, так это голова на плечах и здравый смысл), наоборот, могут, но это требует углубленных знаний и навыков на тех направлениях, на которых разработчики не работают или это отнимает достаточно сил. Именно из-за этого тестировщик выделился в отдельную роль.