Как вы обычно заводите баг на функциональность?
1) Пишите в дискрипшен бага ссылку на сам авто-тест без особых деталей. 
2) Либо же заводите баг с четким steps to reproduce ? 
Пошагово описывая все-все, что нужно сделать, чтоб воспроизвести проблему и чтоб воспроизвести смог любой, даже тот кто совсем не знает где посмотреть на автотесты и что они там проверяют. 
Завожу баг как при ручном тестировании с полным описанием всех шагов и аттачем доп. артефактов (sql скрипты, логи и т.д.) 
Для UI так же как и при ручном - с чётким описанием шагов, версий, environment и т.п. Потому что воспроизвести его можно и вручную.
Если же особенность автотестов такова, что ручное воспроизведение затруднительно (например, тестирование интеграции приложений и т.п.) и при этом есть механизм, позволяющий легко запустить тест и увидеть баг, тогда можно и ссылку на тест (на запуск теста, воспроизводящего баг) дать.
На одной из прошлых работ, где тестировался API приложения, я даже делал автоматическую генерацию т.н. “баг-репитеров”, то есть если автотест падает, то на его базе автоматически генерится автотест, который воспроизводит баг. От самого теста он отличался тем, что сценарий теста прогонялся не целиком, а только до места падения. Такие “баг-репитеры” можно было использовать для воспроизведения бага и для дальнейшей верификации его исправления.
При поломке автотеста никаких багов заводить не надо!
Автотест, если он действительно “авто”, запускается автоматически на сервере непрерывной интеграции (Jenkins то бишь). Разработчики получает от Jenkins злобное письмо и бросаются исправлять сломанный тест.
Что значит “любой, даже тот кто совсем не знает где посмотреть на автотесты”? Разработчики обязаны знать, где посмотреть и как запустить автотесты! Более того, в идеале они их сами же должны и писать!
У вас все автотесты прогоняются после каждого сабмита?
Я не про сломанный тест спросила, а про тест который сфейлился по причине бага в функционале.
Например :
Автоматизатор написал и засабмитил тест - он успешно выполняется.
Тест работает много времени и вдруг упал.
Автоматизатор начал разбираться - оказалось, что поменяли конфиги билд скриптов и при определенных конфигурация проявляется ошибка.
Это баг.
Баг в коде на фичу сделанную много времени назад.
Его нужно завести в багтрекинговой системе.
Как его завести?
Написать пошагово описывая все, что делает тест либо написать в саммери бага:
“Упал автотест: такойто…” и в дискрипшене - ссылку на тест?
Да, у нас все автотесты прогоняются после каждого сабмита. Но это даже неважно.
Неважно, сломанный тест или сломанная функциональность - ответ тот же. Если билд в дженкинсе красный - разработчик должен сам это сразу увидеть (в мейле, на большом экране - неважно) и отреагировать.
Другими словами, разработчики должны следить за цветом дженкинса. Красный билд - тревога, все бросаются исправлять. Если есть такая дисциплина, зачем заводить баг? А если дисциплины нет, то и баг заводить бесполезно. Вы просто перегоняете информацию о проблеме из одного источника в другой (из дженкинса в джиру). Зачем тратить на это время? Пусть разработчики сразу смотрят в правильный источник.
Вы говорите про юнит тесты либо про синтетические. Насколько я понимаю, эта тема не про данные виды тестирования.
Все верно, я спрашивала именно про функциональные тесты.
Юнит-тесты конечно прогоняются сразу и никто на них баги никогда не заводит.
Это конечно. Я спрашивала про функциональные тесты (Билд зеленый)
Я имею в виду любые виды тестирования.
Обычно юнит-тесты запускаются вместе с компиляцией проекта, а остальные тесты запускаются в отдельном JOB’е. Каждый из этих JOB’ов может быть красным или зелёным.
Если функциональный тест падает, значит, соответствующий JOB в Jenkins должен быть красным. Функциональность сломана - тревога - все бросаются исправлять.
А теперь постройте цепочку взаимодействия между этими “всеми кто кинулся исправлять” - без баг трекера это возможно?
А так же подумайте про метрики, которые могут хоть как-то показать эффективность автоматизации на проекте.
А чем по сути баг трекер отличается от дженкинса? Баг трекер - это веб-приложение, откуда разработчик может узнать, что ему дальше делать. Дженкинс - точное такое же веб-приложение, откуда разработчик точно так же может узнать, что ему дальше делать.
Я не очень понимаю, что означает “строить цепочку” и какие такие метрики настолько полезны, что ради них нужно вручную копировать информацию из одного веб-приложения в другое. И как эта ручная работа может повысить эффективность автоматизации на проекте, я уж точно не понимаю.
А вы не трекаете рабочее время?
У нас, например, принято трекать рабочие часы.
И еще…, а если фикс заафектил какой-то другой функционал? Автомейшен тесты пройдут, но кто проверит какие-то вещи, которые тоже могли поломаться и на которых еще нет авто-тестов.
Если будет баг, то разработчик может в affected component написать, что могло заафектиться и тестеровщики посмотрят, перепроверят.
Это модель подходит для малюсенькой команды, в которой несколько разработчиков и нет ни менеджера, ни возможно даже QA. Для больших команд, в которых нужно работать очень слажено - это абсурд.
Конечно мы трекаем рабочее время. Только его бессмысленно трекать “на багфиксинг”.
Ведь функциональность была сломана не просто так, а в процессе работы над новым таском X, так? Вот и записываем время на этот таск X. Раз сделали багу и пришлось её чинить, значит, так и есть, потратили на этот таск больше времени.
Ох уж эти affected component… Ведь разработчика на слово нельзя верить! Какая разница, что они там написали в “affected component”? Этому нельзя доверять! Как правило, ломается то, о чём они и не подумали, ведь так? Тестер должен доверять своему чутью и опыту, а не словам разработчиков, нет?
P.S. У нас такого не бывает, ибо авто-тестами покрыто вся функциональность.
Что именно абсурд? Что и баг трекер, и дженкинс являются веб-приложениями? Что разработчики обязаны туда изредка посматривать? Что разработчики обязаны немедленно реагировать на красные билды? Размер команды тут не при чём!
Необязательно. Бывает такое, что какие-то проблемы обнаруживаются уже впоследствие, как результат расширения того или иного теста. И эти проблемы могут затрагивать несколько команд, соответственно нужен способ коммуникаций, по которому можно следить статус выполнения, переназначать на кого-то и так далее. Форма, в которой это делается - это дело десятое. Таск или баг - в любом случае это какая-то запись ,которая как-то отслеживается
Даже если у вас и так:
то это не значит, что вы покрыли все возможные пути использования той или иной части системы (покрытие - достаточно широкое понятие и их видов достаточно большое множество) -> периодически тесты надо дополнять, уточнять -> могут появиться новые проблемы. И они никак не связаны с текущими задачами.
В-общем, есть проблемы, которые по своей форме и сути тянут на полноценные задачи. И их надо отслеживать точно так же.
Но если речь идет о какой-то мелочевке, которую можно выявить и исправить за пару минут, то ради такого, действительно, не стоит марать баг-трекер. Это заметно уменьшит бюрократию и позволить больше времени использовать основной инструмент - мозг. Но это не значит, что от трекинга ошибок нужно отказываться. Некоторые ошибки стоят того, чтобы их увековечили в таск-трекере.
Вашу точку зрения я знаю, но… Давайте порелаксируем…
Представим проект, который билдится 5-6 часов с документацией на инсталляцию на 4-5 страниц. В котором работают менеджеры, девы, тестеры, автоматизаторы, бизнес-аналитики, техникал-райтеры, перфоманс тестеры, build engineers и т.д. Для пущей сложности разобьем команду на разные локации - часть работает на стороне заказчика (США например), часть в оффшоре (Индия и Россия).
Итак четверг и выходит новый билд. После 12 часов автотестов регресии видно, что один (из 1500+ тестов упал), который состоит более чем из 50 степов и затрагивает несколько областей приложения. А за эти 12 часов мануальщики честно трудились, а девы вполне могли “подложить” несколько патчей.
Разбор упавшего теста состоит из следующих этапов:
Было бы очень здорово, если бы все пункты делали разработчики
Но, как видно, в работу включается вся команда, и ни один из них не в состоянии пройти все этапы самостоятельно. И именно тут коммуникативным мостом между ними является баг-трекер - в котором внятным, минималистичным и простым языком описана проблема, безо всяких стек-трейсов и прочей никому не нужной информации.
Говоря, что баг-трекер для автоматизации не нужен, вы автоматически подразумеваете одно из следующего:
Про метрики:
Весьма велика вероятность, что у заказчика когда-нибудь возникнут сомнения по поводу эффективности автоматизации, и появится желание сэкономить некоторую сумму на “этих ребятах”. Вот тут могут возникнуть вопросы: сколько багов нашлось авто-тестами?
“- Хм. Нисколько? А мануальщики вон по сотне за неделю находят. Зачем я тогда плачу за автоматизацию?”
А, ну тогда ответ на поставленный вопрос “Как вы заводите багу?” очень просто: вы не заводите багу. Пусть разработчики сами решат, мелочёвка ли это (и они пофиксят её сразу) или что-то более серьёзное, и тогда они заведут багу.
Ну так если у вас производительность команды тестирования меряется в количестве найденных багов, то может быть действительно стоит гнать в шею “этих ребят”, так как стоят они дороже, а выхлоп минимальный? Или может у вас тестирование устроено так, что автоматизация используется только на старом проверенном функционале и естественно, на этом направлении мало что можно найти. Тогда да, нафик такую автоматизацию, это напрасная трата времени и денег. Да и если мануальщики при этом постят по сотне багов, то скорее всего 90% из этого либо дубликаты либо ложные ошибки, либо вот такая мелочевка, которая могла бы быть выловлена намного раньше.
А вот если внезапно окажется, что цикл тестирования уменьшается раза в 2-3, при том, что команда остается той же самой и % покрытия не уменьшается, хотя постоянно все обрастает новыми фичами, то это уже совсем другой разговор.
Пообщаться по поводу данной проблемы с разработчиками имеет смысл, конечно, но я бы не делегировал им полностью такие вещи, как:
Из-за этого скорее всего баг надо будет заводить тестировщику. А так как это отдельная задача, которую надо отдельно трекать и переназначать, то ее надо где-то хранить в таск трекере.
Ну, и наконец, не надо переоценивать возможности разработчиков. Да, они могут писать автотесты (и делают это лучше, чем большинство автоматизаторов), они во многом могут быть лучше в тех местах, когда надо определить КАК надо сделать. А вот когда надо определить ЧТО надо сделать - вот тут возникают проблемы. И не потому, что разработчики этого не могут сделать (все что нужно, так это голова на плечах и здравый смысл), наоборот, могут, но это требует углубленных знаний и навыков на тех направлениях, на которых разработчики не работают или это отнимает достаточно сил. Именно из-за этого тестировщик выделился в отдельную роль.
testomat.io управление авто тестами