Subject:

Находишь баги автотестами — теряешь время!!!

Issue ID #109 

Reported at 02.07.2013

Reported byNatalya Rukol

Project Тест-Менеджмент

Severity Major 

Tags

Оля написала провокационную статью, которую я не могу не прокомментировать :)

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

Итак, давайте рассмотрим пример:

У меня есть 2 теста, которые можно было бы автоматизировать. Оба требуют 2 часа для написания и отладки, а вручную оба проходятся за 20 минут. Оба важны и требуют прогонов каждый регрессионный цикл. В одном из них часто бывают баги, в другом — редко.

1. Автоматизирую «бажный» тест Автоматизирую «безбажный» тест
Трачу 120 минут на автоматизацию
После этого, за 10 последующих прогонах, в нём 8 раза возникают ошибки, мне каждый раз надо их перетестировать ручками, чтобы локализовать и завести + подправить тесты. 		Трачу 120 минут на автоматизацию.
После этого, при последующих прогонах, я не трогаю этот тест, т.к. его результат «passed», и мне не нужно дублировать работу «ручками».
Итого суммарно затрачено:
* 120 на автоматизацию 1го теста,
* 160 на перезапуски 1го теста вручную и локализацию ошибок,
* 200 на ручные запуски 2го теста.
480 минут, 8 часов		 Итого суммарно затрачено:
* 120 на автоматизацию 2го теста,
* 200 на ручные запуски 1го теста с локализацией и заведением ошибок.
320 минут, 5 часов и 20 минут.

Если бы я гоняла тесты вручную и не автоматизировала, то у меня бы ушло 200 + 200 = 400 минут на 10-ти запусках. В таком случае, 1-й сценарий автоматизации НЕВЫГОДНЫЙ, а 2-й ВЫГОДНЫЙ.

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

  • Антон Khayrutdinov

    Давайте продолжим рассуждения, чего на полпути-то останавливаться :) . Какие ручные тесты проходят быстрее — бажные или безбажные? Конечно вторые — не надо регистрировать баги, уточнять требования и т.п. В результате выгодно отбирать наименее «бажные» ручные тесты, чтобы по результатам их прогонов не было необходимости в дополнительных телодвижениях :) .

    • http://natalyarukol.ru Natalya Rukol

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

      Так что предлагаю не рассматривать такие ситуации, как бы ни хотелось потроллить, входные данные не меняются: оба теста НАДО гонять перед каждым релизом.

      • Антон Khayrutdinov

        Ну так если надо гонять оба — какая разница, сколько каждый из них стоит? А если выбирать — я бы выбрал тот, который найдет больше багов. Потому что при одинаковом тестовом покрытии в первом случае мы за 8 багов заплатили 480 минут, а во втором — за 0 багов 320 минут :) . Согласна?

        • http://natalyarukol.ru Natalya Rukol

          Нет, во-м случае за 320 минут мы нашли те же 8 багов, мы же гоняли 1-й сценарий вручную, и заодно баги заводили. В 1-м и 2-м случае результаты тестирования будут одинаковые, отличаются только трудозатраты.

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

          • Alex Nikulin

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

          • http://natalyarukol.ru Natalya Rukol

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

          • Alex Nikulin

            В моей практике, 80% багов заводились в ходе отладки самих тестов, а дальше их запуск говорил чаще только о том, что регресии, как обычно, нет.

          • http://natalyarukol.ru Natalya Rukol

            То есть, вы автоматизировали безбажные сценарии, что как раз и считается за «правильно». У меня есть проекты, где много регрессионных ошибок всплывает, и вот на них автоматизировать нестабильные сценарии — это самоубийство, что и показано в цифрах выше.

          • Alex Nikulin

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

  • Maxim Zakharov

    В фразе «В одном из них часто бывают баги», ключевое слово «часто».

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

    «Часто ломают фичу» на мой взгляд — это ближе к раз в 4-20 недель. На мой взгляд это раз в 50-1000 коммитов (4-10 релизов).

    И это немного меняет дальнейшие вычисления.

    Впрочем, идея поста достаточно, но я бы сделал другой вывод.

    Нужно исключить из цепочки tests — tester — coder лишнее звено, а именно — тестеров, тогда им не нужно будет вручную прогонять тесты.

  • Maxim Zakharov

    И, если мне не изменяет память, то Канер говорит о принципиальной некорректности сравнения с помощью частоты прогона. Это в 109 уроке.

    А в 108 уроке прямо говорит, что и сравнивать не нужно.
    Считаю, что он прав.

  • Sergey Martynenko

    2Антон Khayrutdinov, Alex Nikulin, Maxim Zakharov

    +1. Я думаю, вы правы. Я думаю примерно также.

    2Natalya Rukol

    Мое скромное мнение: очень плохая статья. Обсуждаемо.

    • http://natalyarukol.ru Natalya Rukol

      Серёж, я не буду спорить :) Я наблюдала так много случаев неуспешной и бесполезной автоматизации, когда её создатели ею гордились. И неоднократно мне приходилось разгребать эти завалы, когда я меняла правила отбора тестов в автоматизацию, и в итоге у нас автопокрытие с теми же ресурсами увеличивалось в 4-5 раз.

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

      А можно не соглашаться, даже не проанализировав — мне-то что :)

    • Аноним

      Сергей, я даже удивился — с чем именно ты не согласен?

      Неужели с выводом, который звучит так: «при регрессионном тестировании, в автоматизацию выгодно отбирать наименее «бажные» тесты, чтобы по результатам их запусков не было необходимости в ручных дополнительных телодвижениях»

      Что-то я не верю, что ты предлагаешь выбирать «наиболее бажные тесты» :)

      • Sergey Martynenko

        Зря. Для существенной части продуктов, я бы даже сказал для преобладающей, достаточно чтобы продукт был «достаточно хорош». В этом случае относительно безбажный модуль не надо тестировать совсем.

        Похоже тезисов вполне набралось на круглый стол (или «К барьеру»). Можно сделать в онлайне.

        PS. Пока получал доступ к порталу госуслуг, обнаружил две дыры в безопасности (не тестировал, просто воспользовался услугой). Но продукт признан «достаточно хорошим», находится в эксплуатации и я находясь как в роли тестировщика, так и в роли пользователя считаю, что сначала нужно было запустить сервис а отловить эти баги можно и потом.

        • Аноним

          Но ведь статья про другое совсем :)

          Конечно, если не надо тестировать, то и автоматизировать не надо.

          Но если какой-то тест решено выполнять — тогда возникает дилемма — автоматизировать или нет, вот только они и рассматриваются в предложенной модели.

          • Sergey Martynenko

            Мои тезисы:

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

            А расчет полностью неверен, так как исходит из ложных посылок.

          • http://natalyarukol.ru Natalya Rukol

            Серёж, давайте подробнее. Ляля «посыл неверен» кто угодно и про что угодно сказать может. Давайте верные «посылки», это будет полезно!

          • Аноним

            Алексей. Так модели-то нету. Предложено считать время в конкретной ситуации с конкретными ограничениями (одинаковое время, например). Достаточно изменить соотношение времен, и ситуация будет другая.

            Ну и… тут уже писали. На 10 прогонах подряд один и тот же тест валится 8 раз — это уже необходимость искать и исправлять причину.

          • Аноним

            >> Предложено считать время в конкретной ситуации с конкретными ограничениями (одинаковое время, например)

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

            >> На 10 прогонах подряд один и тот же тест валится 8 раз — это уже необходимость искать и исправлять причину.

            Всё верно, и Наташа пишет про то, что __не надо__ автоматизировать такие тесты, а надо идти искать и устранять причину такого количества багов. То есть Вы подтверждаете выводы статьи, а не возражаете против них :)

          • http://natalyarukol.ru Natalya Rukol

            Лена, вот ты сначала споришь с обобщениями, потом — с конкретной ситуацией. Определись! В ЭТОЙ КОНКРЕТНОЙ ситуации автоматизировать сценарий 1 не выгодно, сценарий 2 — выгодно.

            Похожие рассчёты можно использовать в других условиях, и получить другие результаты.

          • Аноним

            Я-то про одно и тоже. Именно про то, что в отсутствии модели (про которую написал Алексей «вот только они и рассматриваются в предложенной модели») делать обобщения нельзя.

            Просто вывод корректней написать для этой данной, конкретной ситуации, не обобщая на вообще регрессионное тестирование вообще проектов.

  • Аноним

    А я предлагаю второй тест вообще не проходить, он ведь безбажный — смысла нет. (-20 мин).

    А первый кейс сократить, распечатать и повесить на рабочее место всем разработчикам. Велика вероятность что кто-то на него посмотрит и проверит.
    (- 5 ч.)

    Вот и все. Сегодня можно не работать :D

  • Аноним

    Нельзя переносить опыт, набранный на нескольких проектах, на все проекты. В принципе неверный подход.

    • http://natalyarukol.ru Natalya Rukol

      Бездумное обобщение, конечно, зло. Но это ещё не повод говорить «прошлые 5 раз, когда я наступила на грабли, я получила по лбу. Теперь, когда передо мной лежат шестые, мне нельзя переносить опыт прошлых граблей на эти. А вдруг эти грабли окажутся добрыми и милыми?»

      • Аноним

        Наташ. Ну это если грабли (т.е. объект отнесен к классу «грабли» по каким-то критериям), то можно попробовать перенести опыт. Хотя…. грабли могут быть с короткой ручкой. Или лежать зубьями в землю. Или еще что. А уж попытки перенести грабельный опыт на другие предметы (тазики с водой, кирпичи, кучи веток) — ну никак. хм..Т.е. нужно как минимум объявить в каких именно проектах (не знаю — как их классифицировать, увы…) , т.е. на какой выборке — «выгодно отбирать наименее «бажные» тесты»

  • Антон Khayrutdinov

    Ну ок, в принципе это имеет смысл. Если надо разделить задачи между ручным и автоматизированным тестированием, причем заранее известно, что так или иначе успеем прогнать все тесты — понятно лучше отдать автоматизаторам самые стабильные сценарии.
    А вот если проект с недельным релизным циклом, то тут либо прогоняем автотесты перед релизом, либо ничего не делаем. И в этом случае я бы предпочел при прочих равных иметь тесты на самые бажные фичи.

    • http://natalyarukol.ru Natalya Rukol

      Мы рассматриваем конкретный кейс, при котором гонять надо ВСЕ тесты из вышеописанных.

      Может, ещё какие-нибудь вводные додумаем, чтоб найти повод поспорить? Так будет веселее!

      • Антон Khayrutdinov

        В этом КОНКРЕТНОМ кейсе конечно не надо автоматизировать — надо дать по рукам программистам, которые в 8 коммитах из 10 ломают один и тот же сценарий. И горе-автоматизаторам, у которых разбор ошибок в одном и том же тесте занимает по 20 минут. А вообще мне кажется дискуссию на этом лучше завершить. Не люблю такие нервные выпады.

        • http://natalyarukol.ru Natalya Rukol

          Так вы не нервничайте :)

  • Алексей Булат

    А вот мы пишем автотесты на самые высокоприоритетные кейсы… И всем побоку есть там баги или нет, но тест на фичу должен быть написан…

    Как это уложить в формулу: «при регрессионном тестировании, в автоматизацию выгодно отбирать наименее «бажные» тесты, чтобы по результатам их запусков не было необходимости в ручных дополнительных телодвижениях» ?

    Мне кажется вопрос в специфике… ИМХО: лучше чтобы тест был, чем его не было…

  • Alsu Vadimovna

    Может быть уже поздно, но у меня есть мысли по поводу статьи :)
    Мне кажется, что неправильно ставить целью автоматизации нахождение багов или краткосрочная экономия времени.
    Возьмем 1 проект в вакууме. С определенной периодичностью делается релиз, перед релизом делается смоук-тест, в смоук-тесте 100 кейсов. из 100 кейсов 5 являются наиболее бажными, 20 средне-бажными, остальные практически без багов. И в данном случае, я считаю, некорректно высчитывать время разработки +время ручных прогонов и прочее. При смоук-тесте нам нужно как можно быстрее узнать о том, что что-то сломано. И автотесты позволят нам быстрее об этом узнать, чем прогонять все эти тесты вручную.

    и еще :)
    автоматизированный кейс != ручной кейс. В примере в посте кейс вручную проходится за 20 минут. Когда я автоматизирую, то я большой кейс разбиваю на мелкие. То есть из одного большого кейса получается например 10 мелких, и тогда, если какой-то тест падает, то воспроизводить руками мне нужно не 20 минут, а 2 минуты :)

Social Widgets powered by AB-WebLog.com.