Сообщений в теме: 29

[leftCh]

Автоматизировать имеет смысл только регрессионное тестирование в проектах, которые длятся годами, или нагрузочное тестирование. В этом контексте и надо считать

Примерный расчет затрат на ручное регрессионное тестирование:
1. Определиться с формой записи регрессионных тестов
2. Определиться с количеством этих тестов и посчитать затраты на их написание, затраты на ревью
3. Определиться как часто их нужно прогонять, на одной ли конфигурации или на разных, посчитать затраты на запуск тестов
4. Определить сколько времени потребуется на поддержание тест кейсов в актуальном состоянии, посчитать затраты
5. Посчитать затраты на обучение людей при недостаточной детализации тест кейсов
6. Учесть возможные проблемы ручного тестирования: человек может просто не сделать тест (обмануть), может пропустить ошибку (невнимательность)

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

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

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

[ch_ip]

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

Что значит аналогичное тестирование вручную? Те же самые тесты с той же частотой, но руками?

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

Вот тут пример из книжки Lessons Leaarned in software testing с некорректным подсчетом и обоснованием, почему так считать нельзя: http://okiseleva.blo...og-post_21.html

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

Тут Сергей уже все сказал. Могу только смайлик добавить />

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

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

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

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

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

Расскажите нам немного о процессах, и что у вас есть, чтобы понимать, что подсказывать.
Ибо исходя из того, что вы написали, пока складывается ощущение, что действительно лучше прибить у вас автоматизацию, а выделившиеся ресурсы потратить на обучение.
1) Что за система, на чем написана?
2) это продуктовая разработка или под заказчика?
3) как часто релизы?
4) как часто собирается билд?
5) есть ли у вас система автоматической сборки билда?
6) Пишут ли ваши программисты юнит-тесты?
7) есть ли у вас стадарты кодирования и следуете ли вы им?
8) Кто пишет фреймворк для автотестов?
9) сколько времени уже потрачено на фреймворк и какова степень его готовности?
10) Какого рода автотесты вы пишете, на какой функционал? На новый или на устоявшийся?
11) какой фреймворк используете для автотестирования?
12) насколько у вас модульные автотесты? можно ли запустить любой тест отдельно? Можно ли запустить тесты только на часть системы?
14) кто умеет запускать автотесты и понимать их результат?
15) % регрессионных багов?
16) степень критичности регрессионных багов?
17) тестируют ли у вас требования?
18) позволяет ли код вашего приложения автоматизировать его или приходится искать обходные пути?

[negro]

...
12) насколько у вас модульные автотесты? можно ли запустить любой тест отдельно? Можно ли запустить тесты только на часть системы?
14) кто умеет запускать автотесты и понимать их результат?
...
18) позволяет ли код вашего приложения автоматизировать его или приходится искать обходные пути?

ch_ip, прикиньте, 19 июня a.dobrinina пишет, что руководство поручило ей подготовить самооценку её автоматизации (типа срочно помогите).
Все, кто и как смогли оперативно, что-то сделали для её анализа.
Ваша инициатива, спустя неделю (26 июня), не то, чтобы своевременна, но и как бы неадекватна...
Вопросы:
1. ch_ip, уточните, пожалуйста, ваш вопрос № 13 ?!
2. ch_ip, скажите, пожалуйста, с кем вы ведёте диалог и на какую тему, задавая свои вопросы ?!
2.1 Например, a.dobrinina спрашивает, как оценить "выгодны ли нам автотесты, которые мы пишем?" Вы это видите/слышите? Они пишут автотесты! А ваш вопрос № 18: "позволяет ли код вашего приложения автоматизировать его..." - к чему или к кому ?!
2.2 Допустим, если ответить на ваш вопрос № 18 "Нет, не позволяет", тогда какой смысл в ваших предыдущих (почти двух десятках) вопросах ?!
Просьба: ch_ip, беда какая-то, ваш предыдущий комментарий занял много места, а толку? Будьте, пожалуйста, кратки, точны и логичны, высказывайтесь по теме, не сомневаюсь, что вы - Специалист!

[Vasiliy]

negro, давайте вы закончите свой тролинг.
Да, ch_ip специалист. В вопросах автоматизации точно. А вы придираетесь к мелочам и без какой-либо сути.

[Little_CJIOH]

Рассуждения на тему:

http://natalyarukol....eryaesh-vremya/

[ch_ip]

Рассуждения на тему:
http://natalyarukol....eryaesh-vremya/

Little_CJIOH, а что вам понравилось в приведенной статье?

[Little_CJIOH]

Рассуждения на тему:
http://natalyarukol....eryaesh-vremya/

Little_CJIOH, а что вам понравилось в приведенной статье?

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

Коменты тоже хороши.

[SALar]

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

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

Принято. Я полагаю, что ваши цели неверны. После этого все остальные рассуждения смысла не имеют.

Прочитайте "Цель" Эли Годратта. Я его читал раза три. И вам советую.

[Future]

Пока сам не напишешь автотесты, все рассуждения будут простым пуком в воду, извиняюсь за сравнение.

[Wolonter]

Принято. Я полагаю, что ваши цели неверны. После этого все остальные рассуждения смысла не имеют.

Прочитайте "Цель" Эли Годратта. Я его читал раза три. И вам советую.

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

Ну а спорить смысла нет. Без контекста, который можно ощутить полгодика поработав - пустые слова. Вот вы может быть на моем месте делали б точно то же самое что и я. И обоснование под это подвели. Научное.