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

Программирование на C# для тестировщиков
онлайн, начало 14 мая
Первый Онлайн ИНститут Тестировщиков
онлайн, начало 18 мая
SQL для тестировщиков
онлайн, начало 17 мая
Английский для тестировщиков
онлайн, начало 17 мая
Фотография

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


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

#1 a.dobrinina

a.dobrinina

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

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

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

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

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

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

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

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

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

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

#2 SALar

SALar

    Гуру

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


Отправлено 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 295 сообщений
  • Город:Москва


Отправлено 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 295 сообщений
  • Город:Москва


Отправлено 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 295 сообщений
  • Город:Москва


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

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

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

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

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

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

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

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

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

-- 

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

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

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

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

 


#12 Little_CJIOH

Little_CJIOH

    Гуру

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


Отправлено 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 295 сообщений
  • Город:Москва


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

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

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


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

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

-- 

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

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

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

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

 


#17 SALar

SALar

    Гуру

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


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


Школа Тест-Аналитика
онлайн
Организация автоматизированного тестирования
онлайн
Школа тест-менеджеров v. 2.0
онлайн
Тестирование юзабилити (usability)
онлайн



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

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

Яндекс.Метрика
Реклама на портале