Именно. По-моему это главное назначение автотестов.

Кокрастыке если автоматизирована регрессия - автотесты должны быт ьвсегда зелёные.

при регрессе - очень редко. пару раз на сотню.

Эм.. Что значит - должны быть зеленые?

Даже там где случилась регрессия кода?

Макс, если автоматизирована регрессия и если автотесты падают после сборки билда, то тесировщику даже приближаться к этому билду не надо.

Рассуждение о том кому приближаться к такому билду не относятся к моему вопросу

Поэтому зеленые автотесты обозначают, что у тестировщика есть работа, что перешли на этап тестирования. А красные - что работа программиста ещё не закончена, ибо он напесал плохой. Очень плохой код, который болье калечит, чем лечит.

Ещё как относятся.

Вот тебе и "частота полезных фейлов".

Каждый такой фейл свидетельствует о деградации кода. И чтобы она не допускалась - до тестов допускаются только прошедшие зелёный свет на автотестах.

Ещё как относятся.

Как автор вопроса, ответственно заявляю что не относится =)

Ты применяешь свои ботинки на мою ситуацию

Я предлагаю посмотреть более обще.

Тогда переформулируй вопрос :)

Куда уж ещё более-то :)

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

экономия времени же

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

есть автотест находит ошибку во время регресса, нужно все равно воспроизвести ее вручную и завести в баг трекере

если релизитесь часто - то смысл в автоматизации есть

Макс, если ты про это, то это считается как минимум элементарным ROI

Куда уж ещё более-то :)

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

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

не сказал бы что это супер выгодно на нашем примере, но удобно, ощущения, что где то там, есть что то, где все нормально и туда надо иногда заглядывать + появляется доп. время

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

экономия времени же

Экономия??? Сколько вы тратите времени на автоматизацию?

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

+

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

Да, про калькулятор я в курсе, и про roi. Мой вопрос был не КАК это посчитать, а - кто-то оценивал из вас?

Если у тебя прогон ручных тестов занимает неделю (то есть 5 рабочих дней), а написание автотестов займёт месяц (условно 20 рабочих дней), но на прогон будет уходить теперь по 2 дня. Макс, ты же сможешь посчитать когда автоматизация выйдет на самоокупаемость?

Я оценивал.

Выгоднее автоматизировать?

Когда как.

Если у тебя прогон ручных тестов занимает неделю (то есть 5 рабочих дней), а написание автотестов займёт месяц (условно 20 рабочих дней), но на прогон будет уходить теперь по 2 дня. Макс, ты же сможешь посчитать когда автоматизация выйдет на самоокупаемость?

добавь еще поддержку.

добавь еще поддержку.

Конечно.

я как автоматизатор могу ответить только "Да выгодно" =)

Ну, тут каждый со своей колокольни.

Я могу сказать только, что всё упрётся в "it depends..." и однозначного ответа тебе никто не даст.

Ну, может Антон только :)

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

хотя при этом риски только возросли как мне кажется

а слишком дорогой она становилась после того как на нее время уже потратили, но пользы не получили

Знать, не то автоматизировали.

а слишком дорогой она становилась после того как на нее время уже потратили, но пользы не получили

что подразумеваешь под "пользой" ?

что подразумеваешь под "пользой" ?

ну я могу объяснить не пользу, а то что было по факту. По факту автотесты падали не из-за ошибок на стенде, а из-за неправильных автотестов (предусловия и прочее)

ну я могу объяснить не пользу, а то что было по факту. По факту автотесты падали не из-за ошибок на стенде, а из-за неправильных автотестов (предусловия и прочее)

ох жесть то какая

Мой случай таков. Я как тест менеджер инвестировал 3 месяца опытного тестера в пуско-наладку этих вот всех дженкинсов с hp qtp. Сейчас пью чай и смотрю на результаты. Появилось 50 автотестов, прогоняемых еженочно. С момента релиза тестов они ничего не нашли, а то, что нашли - было на этапе дизайна, т.е. неотличимо от ручного тестирования. Да, эти тесты покрывают топ критичного функционала и их постоянный прогон создаёт ощущение комфорта и защищенности как подгузники хаггис. Но не отпускают сомнения что все эти было зря.. Даже программисты спрашивают - а нахера это все? Субъективно вы руками работаете намного эффективнее.

значит объем регресса наверное небольшой

А зачем он большой? Он важный должен быть, а не большой.

Или Вы из партии 100% автоматизации? =)

ну я о том что на таком объеме невидно разницы, или в вашем случае "Смысла автоматизации"

Мой случай таков. Я как тест менеджер инвестировал 3 месяца опытного тестера в пуско-наладку этих вот всех дженкинсов с hp qtp. Сейчас пью чай и смотрю на результаты. Появилось 50 автотестов, прогоняемых еженочно. С момента релиза тестов они ничего не нашли, а то, что нашли - было на этапе дизайна, т.е. неотличимо от ручного тестирования. Да, эти тесты покрывают топ критичного функционала и их постоянный прогон создаёт ощущение комфорта и защищенности как подгузники хаггис. Но не отпускают сомнения что все эти было зря.. Даже программисты спрашивают - а нахера это все? Субъективно вы руками работаете намного эффективнее.

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

Мой случай таков. Я как тест менеджер инвестировал 3 месяца опытного тестера в пуско-наладку этих вот всех дженкинсов с hp qtp. Сейчас пью чай и смотрю на результаты. Появилось 50 автотестов, прогоняемых еженочно. С момента релиза тестов они ничего не нашли, а то, что нашли - было на этапе дизайна, т.е. неотличимо от ручного тестирования. Да, эти тесты покрывают топ критичного функционала и их постоянный прогон создаёт ощущение комфорта и защищенности как подгузники хаггис. Но не отпускают сомнения что все эти было зря.. Даже программисты спрашивают - а нахера это все? Субъективно вы руками работаете намного эффективнее.

А про юнит тесты ваши программмисты не спрашивают - нахрена нам они?

Поэтому я и вопрошаю к тем кто собаку съел на автоматизации регрессионного тестирования

А про юнит тесты ваши программмисты не спрашивают - нахрена нам они?

?

Или Вы из партии 100% автоматизации? =)

можно сказать попробовал такие проекты и понял что такое никак невозможно. и вернулся к проектам в режиме 50 на 50 =)

А про юнит тесты ваши программмисты не спрашивают - нахрена нам они?

Не спрашивают. Их польза видна.

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

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

Факт в том, что прошло уже 3 месяца, а тесты зеленые

Ну и хорошо же.

Это может быть проявлением "Систематической ошибки выживших".

Ну а они действительно зеленые? Мож просто кривые?)

Факт в том, что прошло уже 3 месяца, а тесты зеленые

а ты разбираешься хотябы примерно в коде тестов? Посмотри какие там проверки стоят, exeptions итд в каких случая fail-ы, мб они и должны быть зелеными)

К слову, мы ловим регрессию при ручном тестировании.. Мне кажется автотестам не остаётся работы =)

запускайте их тогда раньше

а ты разбираешься хотябы примерно в коде тестов? Посмотри какие там проверки стоят, exeptions итд в каких случая fail-ы, мб они и должны быть зелеными)

Тесты с хорошим дизайном. Писал человек с большим опытом автоматизации.

А зачем вы дублируете автотесты руками?

запускайте их тогда раньше

Зачем? Я все равно знаю что руками более богатые приемы провожу нежели созданные автотесты. А расширять автотесты до такой же степени долго и дорого

так сключите из ручного то, что автоматизировано? Или я что-то не понял?

А зачем вы дублируете автотесты руками?

Не дублируем. Просто при приемочном тестировании я чую ливером кто что мог поломать.

так сключите из ручного то, что автоматизировано? Или я что-то не понял?

Я не верю в то, что автотест может быть таким же широким и глубоким как ручной тест. Только если ручной тест плохой =) как можно исключать из области ручной проверки вообще что-то?

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

Для ясности - я не прохожу руками в точности те же действия что и автотесты.

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

Автотесты прогоняются на каждом билде, но они не находят ничего такого что я не "вижу" руками

Ручное тестирование я провожу в любое угодное мне время

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

Пытаюсь понять нужно ли это все

Автотесты прогоняются на каждом билде, но они не находят ничего такого что я не "вижу" руками

ну у нас аналогичная ситуация, тесты просто крутятся на jenkins-e, набираются задачи в спринт оцениваются и тестятся, в процессе тестирования полгядываешь в результат автотестов, если хочешь чтобы они находили баги, просто расширьте их, будет в чем покапаться (если есть куда расширять), а так если ничего не находит и в качестве проверок ты уверен, все норм работает, значит хороший спец делал) это как в одной из известных историй где чувак все автоматизировал и сидел месяцами ничего не делал +-

Для ясности - я не прохожу руками в точности те же действия что и автотесты.

вот для этого, чтобы у тестировщика было больше времени на свободное тестирование

ну у нас аналогичная ситуация, тесты просто крутятся на jenkins-e, набираются задачи в спринт оцениваются и тестятся, в процессе тестирования полгядываешь в результат автотестов, если хочешь чтобы они находили баги, просто расширьте их, будет в чем покапаться (если есть куда расширять), а так если ничего не находит и в качестве проверок ты уверен, все норм работает, значит хороший спец делал) это как в одной из известных историй где чувак все автоматизировал и сидел месяцами ничего не делал +-

Спасибо, ценный для меня фидбек

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

если человека есть занять чем поинтересней, значит пока не нужно

Спасибо, ценный для меня фидбек

нз?

вот для этого, чтобы у тестировщика было больше времени на свободное тестирование

Если я отключу от работы тестера чтобы он расширял базу автотестов, то свободного времени у него вообще ни на что не будет =)

А если база автотестов вырастет настолько что поддержка съест всё его время, то я по сути лишусь сотрудника

Может эти написанные тесты дублируют в каком-то смысле проверки юнит-тестов и поэтому могут ничего не находить.

Не сказал бы.. Я видел и то и то

Автотесты прогоняются на каждом билде, но они не находят ничего такого что я не "вижу" руками

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

Автотесты e2e, покрывают критичые для бизнеса кейсы. Просто из этого обстоятельства вытекает и то, что эти же области в фокусе пристального внимания всех вовлечённых лиц

можно узнать возможности вашего тестового фреймворка и добавить еще каких-то тестов, затраты на создание которых в этом тестовом фремворке малы

Автотесты e2e, покрывают критичые для бизнеса кейсы. Просто из этого обстоятельства вытекает и то, что эти же области в фокусе пристального внимания всех вовлечённых лиц

тогда возможно они созданы для успокоения менеджеров и заказчика

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

Потому что я хочу чтобы то, во что я вложил 3 месяца приносило пользу по сравнению с тем, если бы я не вложил их туда

И мы слишком углубились в мой кейс. Мой исходный вопрос был в том, чтобы услышать ваши истории. Довольны ли вы выгодой от автоматизации регрессионного тестирования на своих проектах?

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

Я скорее удовлетворён, но продолжать в ближайшее время не буду.

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

Понятно что я не совсем его потеряю, он же не забухать уйдёт. Но основной деятельностью у нас является на данном проекте приемка нового функционала. Ей он не сможет заниматься.

Но на регресс все равно силы тратите. Если сейчас это несколько людей, а будет один - тоже плюс.

Но на регресс все равно силы тратите. Если сейчас это несколько людей, а будет один - тоже плюс.

Ну в идеале это так. Но по моим оценкам на максимально полное покрытие регрессионного пакета автотестам у человека уйдёт года полтора. Это много в моем случае.. Лучше он будет заниматься приёмкой, а я в чате болтать =)

У нас есть правки кода, которые вообще до тестирования не доходят, потому что тестировщиков мало и новые (весьма мелкие) фичи проверяют только самими кодерами и заказчиками. Вот на эти бы сервисы тесты точно бы не помешали.

Я скорее удовлетворён, но продолжать в ближайшее время не буду.

если покрытие удовлетворяет, то почему бы и нет.