Как оценить пользу автотестов?
#1
Отправлено 19 июня 2013 - 09:39
И не лучше ли потратить ресурсы, затраченные на их написание и поддержку, на аналогичное тестирование вручную?
В теории, я примерно представляю, что нужно посчитать, сколько времени мы потратили на написание теста, сколько тратим на его поддержку, что он проверяет и много ли багов находит.
Но на практике, все это очень грубо и примерно.
Допустим, я посчитаю, что на написание теста мы потратили неделю и тратим по 10 часов в месяц на поддержку.
И тест нам находит к пример 2 бага в неделю.
И что из того? Могу ли я знать, найдем ли мы эти два бага, если будем вместо поддержки теста проверять всё руками?
А что если тест не находит багов? Вот раньше когда-то находил, а сейчас больше не находит, т.к. разработчики им уже "натренированы". Значит ли это что тест больше не нужен и мы можем отказаться от его поддержки?
Пока у меня вопросов больше, чем ответов.
Проблема еще в том, что у нас с разработкой автотестов не всё складывается гладко. Делаем ошибки, собираем грабли и действительно порой тратим время зря. Банально не хватает опыта и практики. Но чутьё мне подсказывает, что опускать руки рано, и что в перспективе автотесты нам нужны.
Подскажите, как и что можно рассчитать, чтобы убедить руководство, что автотесты нам нужны (или всё-таки убедиться самой, что не нужны)? В какую сторону думать?
#2
Отправлено 19 июня 2013 - 10:18
по моей статистике, автотесты это выкинутые деньги.На днях меня озадачили "сверху" - попросили оценить, а выгодны ли нам автотесты, которые мы пишем?
И не лучше ли потратить ресурсы, затраченные на их написание и поддержку, на аналогичное тестирование вручную?
Угу. На одном и том же участке кода. Угу. 2 бага в неделю. Угу. И так пять лет подряд. Угу.И тест нам находит к пример 2 бага в неделю.
Такие проблемы лечатся не автотестеми, а огнеметом. Из которого расстреливают архитектора. Или программиста.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#3
Отправлено 19 июня 2013 - 10:18
Опять же Вам нужны баги или чтобы продукт работал так как надо? Сегодня он не находит баг, а завтра внесли изменение в какую то часть продукта и теперь этот тест не проходит, но Вы от него решили отказаться.А что если тест не находит багов? Вот раньше когда-то находил, а сейчас больше не находит, т.к. разработчики им уже "натренированы". Значит ли это что тест больше не нужен и мы можем отказаться от его поддержки?
Мой совет - оценить покрытие, сколько функционала Вы покрываете текущими автотестами, сколько ручными. Потом оцените сколько времени тратится на автотесты и сколько на ручные. Исходя из графика релизов и сроков оцените что выгоднее тратить Х дней и Х людей на прохождение Х ручных тестов или потратить Х часов и написать для этого дела автотесты которые будут выполнять бОльшую часть проверок.Подскажите, как и что можно рассчитать, чтобы убедить руководство, что автотесты нам нужны (или всё-таки убедиться самой, что не нужны)? В какую сторону думать?
#4
Отправлено 19 июня 2013 - 11:04
Почему Вы отталкиваетесь от кол-ва найденных багов, а не от покрытия? Вот вы написали автотест для покрытия какой-то функции системы и теперь каждый раз при любом изменении системы, Вы просто можете запустить тест и убедится что эта функция работает так как надо.
Опять же Вам нужны баги или чтобы продукт работал так как надо? Сегодня он не находит баг, а завтра внесли изменение в какую то часть продукта и теперь этот тест не проходит, но Вы от него решили отказаться.А что если тест не находит багов? Вот раньше когда-то находил, а сейчас больше не находит, т.к. разработчики им уже "натренированы". Значит ли это что тест больше не нужен и мы можем отказаться от его поддержки?
Если у вас высокоадаптивный тест-план, и тесты, которые не находят баги, отменяются, то да - автотесты не нужны. Автотесты не должны находить баги (не считая технологии MBT, но я ее в реальности не встречал). Автотесты нужны: (а) для выполнения тест-плана и избавления тестировщиков от рутины, (б) когда вручную протестировать нельзя (API, нагрузка и т.п.). Если они находят новые баги, то это получается только дороже, т.к. баг всё равно перепроверяется руками.
Мой совет - оценить покрытие, сколько функционала Вы покрываете текущими автотестами, сколько ручными. Потом оцените сколько времени тратится на автотесты и сколько на ручные. Исходя из графика релизов и сроков оцените что выгоднее тратить Х дней и Х людей на прохождение Х ручных тестов или потратить Х часов и написать для этого дела автотесты которые будут выполнять бОльшую часть проверок.Подскажите, как и что можно рассчитать, чтобы убедить руководство, что автотесты нам нужны (или всё-таки убедиться самой, что не нужны)? В какую сторону думать?
Скажу то же самое другими словами. Главные моменты здесь - скорость и повторяемость. Автотесты должны давать возможность делать всё быстрее, чем руками, и они должны позволять проводить проверки чаще. Иначе говоря, у вас должен быть набор тестов, который постоянно присутствует в тест-плане, постоянно дает примерно одинаковые результаты, но время на него всё равно тратится, т.к. в вашей системе контроля качества необходимо каждый раз подтверждать, что эти тесты проходят. И если в результате автоматизации время выполнения этих тестов сократится с нескольких человеко-дней до нескольких часов + ставка автоматизатора, а мануальщики освободятся для более творческой работы, то это и будет основанием.
#5
Отправлено 19 июня 2013 - 11:34
А зачем мне, как заказчику или ПМ-у тестовое покрытие? Мне нужно, чтобы количество багов отнормировнных по функции Тагути в продакшее было в определенных пределах. Прочитайте статьи: http://blog.shumoos.com/archives/281 и http://blog.shumoos.com/archives/271Почему Вы отталкиваетесь от кол-ва найденных багов, а не от покрытия? Вот вы написали автотест для покрытия какой-то функции системы и теперь каждый раз при любом изменении системы, Вы просто можете запустить тест и убедится что эта функция работает так как надо.
Это указывает на системную проблему. Скорее всего, в архитехтуре. Так же возсожно есть проблемы в управлении версиями. Не надо лечить симптом. Лечите болезнь.Опять же Вам нужны баги или чтобы продукт работал так как надо? Сегодня он не находит баг, а завтра внесли изменение в какую то часть продукта и теперь этот тест не проходит, но Вы от него решили отказаться.А что если тест не находит багов? Вот раньше когда-то находил, а сейчас больше не находит, т.к. разработчики им уже "натренированы". Значит ли это что тест больше не нужен и мы можем отказаться от его поддержки?
Возможно, понадобятся воспитательные меры, вроде увольнения.
Это отвратительный метод рассчета.Мой совет - оценить покрытие, сколько функционала Вы покрываете текущими автотестами, сколько ручными. Потом оцените сколько времени тратится на автотесты и сколько на ручные. Исходя из графика релизов и сроков оцените что выгоднее тратить Х дней и Х людей на прохождение Х ручных тестов или потратить Х часов и написать для этого дела автотесты которые будут выполнять бОльшую часть проверок.Подскажите, как и что можно рассчитать, чтобы убедить руководство, что автотесты нам нужны (или всё-таки убедиться самой, что не нужны)? В какую сторону думать?
Попробуйте прочитать "Цель" Голдратта.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#6
Отправлено 19 июня 2013 - 12:14
#7
Отправлено 19 июня 2013 - 12:38
Человек отвечает за тестирование. Его попросили оценить выгоду от автотестов. Тестовое покрытие своих текущих тестов ему знать совсем не обязательно?А зачем мне, как заказчику или ПМ-у тестовое покрытие?
Как понять что это болезнь если мы отказались от тестов которые перестали находить баги?Это указывает на системную проблему. Скорее всего, в архитехтуре. Так же возсожно есть проблемы в управлении версиями. Не надо лечить симптом. Лечите болезнь.
Возможно, понадобятся воспитательные меры, вроде увольнения.
#8
Отправлено 19 июня 2013 - 13:42
грош цена такому ПМ, которого интересует только количество багов.А зачем мне, как заказчику или ПМ-у тестовое покрытие? Мне нужно, чтобы количество багов отнормировнных по функции Тагути в продакшее было в определенных пределах
#9
Отправлено 19 июня 2013 - 14:55
#10
Отправлено 19 июня 2013 - 18:47
1. http://www.ozon.ru/c...il/id/18820179/
2. http://www.ozon.ru/c...ail/id/3281934/
Без этого очень сложно. Вы будете продолжать делать правильно неправильные вещи. Также прочитайте 15-ю главу http://www.ozon.ru/c...ail/id/3327206/
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#11
Отправлено 19 июня 2013 - 19:44
Вот не надо приписывать мне то, что я не говорил. Да меня интересует количество багов в продакшене. Это логично. потому как большое число багов при расчете НДС это не слишком хорошо.грош цена такому ПМ, которого интересует только количество багов.А зачем мне, как заказчику или ПМ-у тестовое покрытие? Мне нужно, чтобы количество багов отнормировнных по функции Тагути в продакшее было в определенных пределах
И если вы считаете, что грош цена тому ПМ, которого НЕ интересует число багов в продакшене, то ... считайте что хотите. Надеюсь не увидеть этого софта.
Да, да. Файлик с расчетами это прекрасно. Пришлите.Мы (отдел автоматизации функц. тестирования) для каждого проекта проводим стоимостный анализ, учитывающий время работы автоматизатора (закладывается 2 рабочих дня на разработку одного теста, поверьте — это не много), количество тестов, время ручного тестирования и количество релизов в год. В дальнейшем собираем статистику с учетом реально затраченного на поддержку тестов времени для расчета возврата инвестиций. Могу экселевский файлик с расчетами дать.
Вот смотрите пример расчета. Статистическими методам установлено, что приложении будет около 10 000 дефектов из которых до продакшена нужно выявить и устранить порядка 9 000. Мой отдел из пяти тестировщиков ищет дефекты со скоростью около 700 багов в месяц (не слишком много, потому что я уделяю много времени обучению), с коэффициентом пропущенных дефектов менее 1%. Отдел программирования правит дефекты ориентируясь на отдел тестирования, с отставанием в месяц. Вопрос: когда можно будет выпускать продукт?
2cryofrost. А если у вас будет отдел из 10 автоматизаторов, то когда?
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#12
Отправлено 19 июня 2013 - 20:36
Да, да. Файлик с расчетами это прекрасно. Пришлите.
Вот смотрите пример расчета. Статистическими методам установлено, что приложении будет около 10 000 дефектов из которых до продакшена нужно выявить и устранить порядка 9 000. Мой отдел из пяти тестировщиков ищет дефекты со скоростью около 700 багов в месяц (не слишком много, потому что я уделяю много времени обучению), с коэффициентом пропущенных дефектов менее 1%. Отдел программирования правит дефекты ориентируясь на отдел тестирования, с отставанием в месяц. Вопрос: когда можно будет выпускать продукт?
2cryofrost. А если у вас будет отдел из 10 автоматизаторов, то когда?
Файлик решает поставленную задачу, а рассуждения о 10000 сферических багов в вакууме - нет.
А задача, напоминаю, состоит в том, чтобы посчитать затраты на автоматическое тестирование и сравнить их с затратами на аналогичное по покрытию ручное.
Если в тех проектах, в которых работаете вы автотесты не выгодны, это не значит, что не существуют ситуации, когда без автотестов просто никак.
#13
Отправлено 20 июня 2013 - 06:24
Вот смотрите пример расчета. Статистическими методам установлено, что приложении будет около 10 000 дефектов из которых до продакшена нужно выявить и устранить порядка 9 000. Мой отдел из пяти тестировщиков ищет дефекты со скоростью около 700 багов в месяц (не слишком много, потому что я уделяю много времени обучению), с коэффициентом пропущенных дефектов менее 1%. Отдел программирования правит дефекты ориентируясь на отдел тестирования, с отставанием в месяц. Вопрос: когда можно будет выпускать продукт?
Цифры близки к реальным? Все найденные 35 багов в день - только в новых фичах? Все 35 исправляются через месяц? Вы уверены, что в данном случае не стоит уделить время автоматическому регрессионному тестированию?
2cryofrost. А если у вас будет отдел из 10 автоматизаторов, то когда?
Вы утрируете, если группа тестирования занимается только автоматизацией, то это либо специфика либо глупость.
#14
Отправлено 20 июня 2013 - 06:38
Не стоит сравнивать автотесты и ручное тестирование. Это разные виды деятельности. Чаще всего с разными целями.На днях меня озадачили "сверху" - попросили оценить, а выгодны ли нам автотесты, которые мы пишем?
И не лучше ли потратить ресурсы, затраченные на их написание и поддержку, на аналогичное тестирование вручную?
Куда направить больше ресурсов - на ту цель, которая в данный момент важней для вас. Мы хотим купить переднеприводный автомобиль или зеленый? На что лучше потратить ресурсы?
Вам нужна регрессия и скорость, у вас дофига денег - автоматизируйте. Ваши проекты длятся по месяцу - тестируйте руками.
Гм. Интересно было бы поработать вместе с SALar, посмотреть, что ж он так не любит автоматизацию, что за продукт и программисты с 35 багами в день.
#15
Отправлено 20 июня 2013 - 07:45
Обратите внимание на слово только. Постом выше вы писали что ПМ по барабану покрытие тестами. Допустим у нас есть use case модель. Мы покрываем его тестами допустим только на 70%. Т.е. вам, судя по посту выше, как заказчику или ПМ не интересно, что 30% функционала никто не тестирует?Вот не надо приписывать мне то, что я не говорил. Да меня интересует количество багов в продакшене. Это логично. потому как большое число багов при расчете НДС это не слишком хорошо.
грош цена такому ПМ, которого интересует только количество багов.А зачем мне, как заказчику или ПМ-у тестовое покрытие? Мне нужно, чтобы количество багов отнормировнных по функции Тагути в продакшее было в определенных пределах
И если вы считаете, что грош цена тому ПМ, которого НЕ интересует число багов в продакшене, то ... считайте что хотите. Надеюсь не увидеть этого софта.
#16
Отправлено 20 июня 2013 - 11:51
Это нормальная ситуация в реальных проектах. Тому может быть масса причин.Допустим у нас есть use case модель. Мы покрываем его тестами допустим только на 70%. Т.е. вам, судя по посту выше, как заказчику или ПМ не интересно, что 30% функционала никто не тестирует?
* Эту часть функционала "оттестируют" пользователи.
* Некритичная часть + хорошие программисты. Нечего время терять.
* Система на выброс. Проверьте только сценарии ПМИ.
И т.д. и т.п. В реальых, а не мифических проектах встречается сплошь и рядом.
PS. Насколько мне известно яндекс, баду, варгейминг очень широко используют ручное тестировние производительности. Правильно. Экономят деньги.
PSS. Я не против автоматизации. Я против неправильного ее использования.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#17
Отправлено 20 июня 2013 - 12:20
Пожалуйста выпишите эти цели.Не стоит сравнивать автотесты и ручное тестирование. Это разные виды деятельности. Чаще всего с разными целями.
Мой контртезис: у этих видов тестирования одинаковая цель. В байке для оруженосца я ее озвучил.
Пожалуйста выпишите эти цели, если они различны.
Мой контртезис: важнее приемлемый уровень бездефектности, частота релизов и стоимость нахождения бага разными методами. Атласиан может себе позволять годами рпродавать Jira с кучей неисправленных критикал багов. Ну потеряли они какой то процент покупателей. Это их выбор.Вам нужна регрессия и скорость, у вас дофига денег - автоматизируйте. Ваши проекты длятся по месяцу - тестируйте руками.
Я специализирусь на больших системах. Реально больших. И 10 тысяч дефектов в продукте - это не запредельная цифра. Может быть и 50 тысяч.Гм. Интересно было бы поработать вместе с SALar, посмотреть, что ж он так не любит автоматизацию, что за продукт и программисты с 35 багами в день.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#18
Отправлено 20 июня 2013 - 17:52
#19
Отправлено 21 июня 2013 - 04:46
К примеру.Мой контртезис: у этих видов тестирования одинаковая цель. В байке для оруженосца я ее озвучил.
Пожалуйста выпишите эти цели, если они различны.
Быстро (минуты) удостовериться, что большой объем (тысячи фич) функциональности работает VS Быстро (часы) удостовериться, что одна фича обладает нужным уровнем качества.
Вы говорите не со мной. Способом достижения целевых "уровень бездефектности, частота релизов и стоимость нахождения" могут быть "регрессия и скорость", способом достижения которых может быть автоматизация.Мой контртезис: важнее приемлемый уровень бездефектности, частота релизов и стоимость нахождения бага разными методами.
Вам нужна регрессия и скорость, у вас дофига денег - автоматизируйте.
Я верю, что большие. И мне действительно интересно, что за система. Это не секрет? Если я умею гуглить, то это colvir, получается заказной корпоративный crm, erp, биллинг, бухучет, расчет бюджетов? И госсектор. А у вас проектная или продуктовая разработка?Я специализирусь на больших системах. Реально больших. И 10 тысяч дефектов в продукте - это не запредельная цифра. Может быть и 50 тысяч.
#20
Отправлено 21 июня 2013 - 04:58
Буду много думать.
Если у кого-то есть возможно выслать файлик с примерами подобных расчётов - вышлите пожалуйста на anyutka_d собака ngs.ru
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных