Перейти к содержимому

Фотография

Как оценить пользу автотестов?


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 29

#1 a.dobrinina

a.dobrinina

    Новый участник

  • Members
  • Pip
  • 2 сообщений
  • ФИО:Анна
  • Город:Новосибирск

Отправлено 19 июня 2013 - 09:39

На днях меня озадачили "сверху" - попросили оценить, а выгодны ли нам автотесты, которые мы пишем?
И не лучше ли потратить ресурсы, затраченные на их написание и поддержку, на аналогичное тестирование вручную?

В теории, я примерно представляю, что нужно посчитать, сколько времени мы потратили на написание теста, сколько тратим на его поддержку, что он проверяет и много ли багов находит.
Но на практике, все это очень грубо и примерно.
Допустим, я посчитаю, что на написание теста мы потратили неделю и тратим по 10 часов в месяц на поддержку.
И тест нам находит к пример 2 бага в неделю.

И что из того? Могу ли я знать, найдем ли мы эти два бага, если будем вместо поддержки теста проверять всё руками?

А что если тест не находит багов? Вот раньше когда-то находил, а сейчас больше не находит, т.к. разработчики им уже "натренированы". Значит ли это что тест больше не нужен и мы можем отказаться от его поддержки?

Пока у меня вопросов больше, чем ответов.

Проблема еще в том, что у нас с разработкой автотестов не всё складывается гладко. Делаем ошибки, собираем грабли и действительно порой тратим время зря. Банально не хватает опыта и практики. Но чутьё мне подсказывает, что опускать руки рано, и что в перспективе автотесты нам нужны.

Подскажите, как и что можно рассчитать, чтобы убедить руководство, что автотесты нам нужны (или всё-таки убедиться самой, что не нужны)? В какую сторону думать?
  • 0

#2 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 19 июня 2013 - 10:18

На днях меня озадачили "сверху" - попросили оценить, а выгодны ли нам автотесты, которые мы пишем?
И не лучше ли потратить ресурсы, затраченные на их написание и поддержку, на аналогичное тестирование вручную?

по моей статистике, автотесты это выкинутые деньги.

И тест нам находит к пример 2 бага в неделю.

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

Такие проблемы лечатся не автотестеми, а огнеметом. Из которого расстреливают архитектора. Или программиста.
  • 2

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#3 Keiga

Keiga

    Постоянный участник

  • Members
  • PipPipPip
  • 174 сообщений
  • ФИО:Евгений
  • Город:Москва


Отправлено 19 июня 2013 - 10:18

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

А что если тест не находит багов? Вот раньше когда-то находил, а сейчас больше не находит, т.к. разработчики им уже "натренированы". Значит ли это что тест больше не нужен и мы можем отказаться от его поддержки?

Опять же Вам нужны баги или чтобы продукт работал так как надо? Сегодня он не находит баг, а завтра внесли изменение в какую то часть продукта и теперь этот тест не проходит, но Вы от него решили отказаться.

Подскажите, как и что можно рассчитать, чтобы убедить руководство, что автотесты нам нужны (или всё-таки убедиться самой, что не нужны)? В какую сторону думать?

Мой совет - оценить покрытие, сколько функционала Вы покрываете текущими автотестами, сколько ручными. Потом оцените сколько времени тратится на автотесты и сколько на ручные. Исходя из графика релизов и сроков оцените что выгоднее тратить Х дней и Х людей на прохождение Х ручных тестов или потратить Х часов и написать для этого дела автотесты которые будут выполнять бОльшую часть проверок.
  • 0

#4 checo

checo

    Опытный участник

  • Members
  • PipPipPipPip
  • 400 сообщений
  • Город:Н.Новгород

Отправлено 19 июня 2013 - 11:04

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

А что если тест не находит багов? Вот раньше когда-то находил, а сейчас больше не находит, т.к. разработчики им уже "натренированы". Значит ли это что тест больше не нужен и мы можем отказаться от его поддержки?

Опять же Вам нужны баги или чтобы продукт работал так как надо? Сегодня он не находит баг, а завтра внесли изменение в какую то часть продукта и теперь этот тест не проходит, но Вы от него решили отказаться.


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


Подскажите, как и что можно рассчитать, чтобы убедить руководство, что автотесты нам нужны (или всё-таки убедиться самой, что не нужны)? В какую сторону думать?

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


Скажу то же самое другими словами. Главные моменты здесь - скорость и повторяемость. Автотесты должны давать возможность делать всё быстрее, чем руками, и они должны позволять проводить проверки чаще. Иначе говоря, у вас должен быть набор тестов, который постоянно присутствует в тест-плане, постоянно дает примерно одинаковые результаты, но время на него всё равно тратится, т.к. в вашей системе контроля качества необходимо каждый раз подтверждать, что эти тесты проходят. И если в результате автоматизации время выполнения этих тестов сократится с нескольких человеко-дней до нескольких часов + ставка автоматизатора, а мануальщики освободятся для более творческой работы, то это и будет основанием.
  • 0

#5 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 19 июня 2013 - 11:34

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

А зачем мне, как заказчику или ПМ-у тестовое покрытие? Мне нужно, чтобы количество багов отнормировнных по функции Тагути в продакшее было в определенных пределах. Прочитайте статьи: http://blog.shumoos.com/archives/281 и http://blog.shumoos.com/archives/271

А что если тест не находит багов? Вот раньше когда-то находил, а сейчас больше не находит, т.к. разработчики им уже "натренированы". Значит ли это что тест больше не нужен и мы можем отказаться от его поддержки?

Опять же Вам нужны баги или чтобы продукт работал так как надо? Сегодня он не находит баг, а завтра внесли изменение в какую то часть продукта и теперь этот тест не проходит, но Вы от него решили отказаться.

Это указывает на системную проблему. Скорее всего, в архитехтуре. Так же возсожно есть проблемы в управлении версиями. Не надо лечить симптом. Лечите болезнь.
Возможно, понадобятся воспитательные меры, вроде увольнения.

Подскажите, как и что можно рассчитать, чтобы убедить руководство, что автотесты нам нужны (или всё-таки убедиться самой, что не нужны)? В какую сторону думать?

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

Это отвратительный метод рассчета.
Попробуйте прочитать "Цель" Голдратта.
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#6 cryofrost

cryofrost

    Новый участник

  • Members
  • Pip
  • 6 сообщений
  • ФИО:Александр Полунин


Отправлено 19 июня 2013 - 12:14

Мы (отдел автоматизации функц. тестирования) для каждого проекта проводим стоимостный анализ, учитывающий время работы автоматизатора (закладывается 2 рабочих дня на разработку одного теста, поверьте — это не много), количество тестов, время ручного тестирования и количество релизов в год. В дальнейшем собираем статистику с учетом реально затраченного на поддержку тестов времени для расчета возврата инвестиций. Могу экселевский файлик с расчетами дать.
  • 0

#7 Keiga

Keiga

    Постоянный участник

  • Members
  • PipPipPip
  • 174 сообщений
  • ФИО:Евгений
  • Город:Москва


Отправлено 19 июня 2013 - 12:38

А зачем мне, как заказчику или ПМ-у тестовое покрытие?

Человек отвечает за тестирование. Его попросили оценить выгоду от автотестов. Тестовое покрытие своих текущих тестов ему знать совсем не обязательно?

Это указывает на системную проблему. Скорее всего, в архитехтуре. Так же возсожно есть проблемы в управлении версиями. Не надо лечить симптом. Лечите болезнь.
Возможно, понадобятся воспитательные меры, вроде увольнения.

Как понять что это болезнь если мы отказались от тестов которые перестали находить баги?
  • 0

#8 tab15

tab15

    Активный участник

  • Members
  • PipPip
  • 128 сообщений

Отправлено 19 июня 2013 - 13:42

А зачем мне, как заказчику или ПМ-у тестовое покрытие? Мне нужно, чтобы количество багов отнормировнных по функции Тагути в продакшее было в определенных пределах

грош цена такому ПМ, которого интересует только количество багов.
  • 1

#9 neman

neman

    Активный участник

  • Members
  • PipPip
  • 142 сообщений
  • ФИО:Антон


Отправлено 19 июня 2013 - 14:55

Не, ну а что, отличная стратегия. Тесты, которые не находят баги - не нужны. Выкинем их! А если в старом функционале всплывает бага - уволим программиста. Русская разработка, бессмысленная и беспощадная.
  • 1

#10 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 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/
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#11 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 19 июня 2013 - 19:44

А зачем мне, как заказчику или ПМ-у тестовое покрытие? Мне нужно, чтобы количество багов отнормировнных по функции Тагути в продакшее было в определенных пределах

грош цена такому ПМ, которого интересует только количество багов.

Вот не надо приписывать мне то, что я не говорил. Да меня интересует количество багов в продакшене. Это логично. потому как большое число багов при расчете НДС это не слишком хорошо.

И если вы считаете, что грош цена тому ПМ, которого НЕ интересует число багов в продакшене, то ... считайте что хотите. Надеюсь не увидеть этого софта.

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

Да, да. Файлик с расчетами это прекрасно. Пришлите.

Вот смотрите пример расчета. Статистическими методам установлено, что приложении будет около 10 000 дефектов из которых до продакшена нужно выявить и устранить порядка 9 000. Мой отдел из пяти тестировщиков ищет дефекты со скоростью около 700 багов в месяц (не слишком много, потому что я уделяю много времени обучению), с коэффициентом пропущенных дефектов менее 1%. Отдел программирования правит дефекты ориентируясь на отдел тестирования, с отставанием в месяц. Вопрос: когда можно будет выпускать продукт?

2cryofrost. А если у вас будет отдел из 10 автоматизаторов, то когда?
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#12 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 19 июня 2013 - 20:36

Да, да. Файлик с расчетами это прекрасно. Пришлите.

Вот смотрите пример расчета. Статистическими методам установлено, что приложении будет около 10 000 дефектов из которых до продакшена нужно выявить и устранить порядка 9 000. Мой отдел из пяти тестировщиков ищет дефекты со скоростью около 700 багов в месяц (не слишком много, потому что я уделяю много времени обучению), с коэффициентом пропущенных дефектов менее 1%. Отдел программирования правит дефекты ориентируясь на отдел тестирования, с отставанием в месяц. Вопрос: когда можно будет выпускать продукт?

2cryofrost. А если у вас будет отдел из 10 автоматизаторов, то когда?


Файлик решает поставленную задачу, а рассуждения о 10000 сферических багов в вакууме - нет.
А задача, напоминаю, состоит в том, чтобы посчитать затраты на автоматическое тестирование и сравнить их с затратами на аналогичное по покрытию ручное.
Если в тех проектах, в которых работаете вы автотесты не выгодны, это не значит, что не существуют ситуации, когда без автотестов просто никак.
  • 0

#13 Wolonter

Wolonter

    Постоянный участник

  • Members
  • PipPipPip
  • 205 сообщений
  • ФИО:Макс
  • Город:Екатеринбург


Отправлено 20 июня 2013 - 06:24

Вот смотрите пример расчета. Статистическими методам установлено, что приложении будет около 10 000 дефектов из которых до продакшена нужно выявить и устранить порядка 9 000. Мой отдел из пяти тестировщиков ищет дефекты со скоростью около 700 багов в месяц (не слишком много, потому что я уделяю много времени обучению), с коэффициентом пропущенных дефектов менее 1%. Отдел программирования правит дефекты ориентируясь на отдел тестирования, с отставанием в месяц. Вопрос: когда можно будет выпускать продукт?


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

2cryofrost. А если у вас будет отдел из 10 автоматизаторов, то когда?


Вы утрируете, если группа тестирования занимается только автоматизацией, то это либо специфика либо глупость.
  • 0

#14 Wolonter

Wolonter

    Постоянный участник

  • Members
  • PipPipPip
  • 205 сообщений
  • ФИО:Макс
  • Город:Екатеринбург


Отправлено 20 июня 2013 - 06:38

На днях меня озадачили "сверху" - попросили оценить, а выгодны ли нам автотесты, которые мы пишем?
И не лучше ли потратить ресурсы, затраченные на их написание и поддержку, на аналогичное тестирование вручную?

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

Гм. Интересно было бы поработать вместе с SALar, посмотреть, что ж он так не любит автоматизацию, что за продукт и программисты с 35 багами в день.
  • 0

#15 tab15

tab15

    Активный участник

  • Members
  • PipPip
  • 128 сообщений

Отправлено 20 июня 2013 - 07:45


А зачем мне, как заказчику или ПМ-у тестовое покрытие? Мне нужно, чтобы количество багов отнормировнных по функции Тагути в продакшее было в определенных пределах

грош цена такому ПМ, которого интересует только количество багов.

Вот не надо приписывать мне то, что я не говорил. Да меня интересует количество багов в продакшене. Это логично. потому как большое число багов при расчете НДС это не слишком хорошо.

И если вы считаете, что грош цена тому ПМ, которого НЕ интересует число багов в продакшене, то ... считайте что хотите. Надеюсь не увидеть этого софта.

Обратите внимание на слово только. Постом выше вы писали что ПМ по барабану покрытие тестами. Допустим у нас есть use case модель. Мы покрываем его тестами допустим только на 70%. Т.е. вам, судя по посту выше, как заказчику или ПМ не интересно, что 30% функционала никто не тестирует?
  • 0

#16 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 20 июня 2013 - 11:51

Допустим у нас есть use case модель. Мы покрываем его тестами допустим только на 70%. Т.е. вам, судя по посту выше, как заказчику или ПМ не интересно, что 30% функционала никто не тестирует?

Это нормальная ситуация в реальных проектах. Тому может быть масса причин.
* Эту часть функционала "оттестируют" пользователи.
* Некритичная часть + хорошие программисты. Нечего время терять.
* Система на выброс. Проверьте только сценарии ПМИ.
И т.д. и т.п. В реальых, а не мифических проектах встречается сплошь и рядом.


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

PSS. Я не против автоматизации. Я против неправильного ее использования.
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#17 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 20 июня 2013 - 12:20

Не стоит сравнивать автотесты и ручное тестирование. Это разные виды деятельности. Чаще всего с разными целями.

Пожалуйста выпишите эти цели.
Мой контртезис: у этих видов тестирования одинаковая цель. В байке для оруженосца я ее озвучил.
Пожалуйста выпишите эти цели, если они различны.

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

Мой контртезис: важнее приемлемый уровень бездефектности, частота релизов и стоимость нахождения бага разными методами. Атласиан может себе позволять годами рпродавать Jira с кучей неисправленных критикал багов. Ну потеряли они какой то процент покупателей. Это их выбор.

Гм. Интересно было бы поработать вместе с SALar, посмотреть, что ж он так не любит автоматизацию, что за продукт и программисты с 35 багами в день.

Я специализирусь на больших системах. Реально больших. И 10 тысяч дефектов в продукте - это не запредельная цифра. Может быть и 50 тысяч.
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#18 neman

neman

    Активный участник

  • Members
  • PipPip
  • 142 сообщений
  • ФИО:Антон


Отправлено 20 июня 2013 - 17:52

SALar, раз уж вы так точно все рассчитали, может поделитесь с автором, да заодно и с нами методикой, а не только выводом - "автотесты на моем проекте не нужны"?
  • 0

#19 Wolonter

Wolonter

    Постоянный участник

  • Members
  • PipPipPip
  • 205 сообщений
  • ФИО:Макс
  • Город:Екатеринбург


Отправлено 21 июня 2013 - 04:46

Мой контртезис: у этих видов тестирования одинаковая цель. В байке для оруженосца я ее озвучил.
Пожалуйста выпишите эти цели, если они различны.

К примеру.
Быстро (минуты) удостовериться, что большой объем (тысячи фич) функциональности работает VS Быстро (часы) удостовериться, что одна фича обладает нужным уровнем качества.


Вам нужна регрессия и скорость, у вас дофига денег - автоматизируйте.

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

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


Я специализирусь на больших системах. Реально больших. И 10 тысяч дефектов в продукте - это не запредельная цифра. Может быть и 50 тысяч.

Я верю, что большие. И мне действительно интересно, что за система. Это не секрет? Если я умею гуглить, то это colvir, получается заказной корпоративный crm, erp, биллинг, бухучет, расчет бюджетов? И госсектор. А у вас проектная или продуктовая разработка?
  • 0

#20 a.dobrinina

a.dobrinina

    Новый участник

  • Members
  • Pip
  • 2 сообщений
  • ФИО:Анна
  • Город:Новосибирск

Отправлено 21 июня 2013 - 04:58

Спасибо всем огромное за такие подробные ответы и советы.
Буду много думать.

Если у кого-то есть возможно выслать файлик с примерами подобных расчётов - вышлите пожалуйста на anyutka_d собака ngs.ru
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных