Subject:

Про вред автоматизации

Issue ID #038 

Reported at 31.08.2011

Reported byNatalya Rukol

Project Тестирование

Severity Major 

Tags

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

Почему так происходит?

Потому что успех автотестов всегда базируется на двух китах: хорошая техническая подготовка и правильный отбор тестов для автоматизации. Если на грамотную автоматизацию не хватает навыков, интерфейсы для автоматизации выбраны не оптимально, в качестве основного подхода используется record and replay, то ждать высоких результатов не приходится. К счастью, почти все это понимают, алилуйя!

Но что с отбором тестов? Я работала в крупных компаниях со стабильной, хорошо отлаженной системой автоматизации, грамотными фреймворками и опытными разработчиками в автоматизаторах. Думаете, автоматизация в этих случаях всегда была успешной? Как бы не так! При автоматизации «чего-нибудь, и побольше» результаты всегда плачевные, и технические навыки вам не помогут — а простого подсчёта ROI, к сожалению, обычно недостаточно.

Только сегодня наткнулась на родном портале для тестировщиков на целый курс, посвящённый отбору тестов: http://software-testing.ru/test_automation/
Наконец-то эта сложная и важная тема не просто освещена, но и выделена в отдельный специализированный курс. И снова: алилуйя! :)

  • http://twitter.com/dzhariy dzhariy

    Ни одна скрытая реклама вовремя создания этого поста не пострадала

    • Noname

      +1

    • Аноним

      скрытой рекламы тут нет :) )

  • Zenturio

    «Если на грамотную автоматизацию не хватает навыков, интерфейсы для автоматизации выбраны не оптимально, в качестве основного подхода используется record and replay, то ждать высоких результатов не приходится. К счастью, почти все это понимают, алилуйя!»

    Чушь написана, попробуйте сделать автоматизацию к примеру новой афины или диасофта.
    Как вы там без подхода Record and Play проживете?

    • Аноним

      Вот уж что точно нельзя автоматизировать R&R, так это крупные приложения с обширной бизнес-логикой, потому что такие тесты — это как роботизированные мартышки.

      Большой объём тестов => необходимость параметризации, расширенная бизнес-логика => необходимость моделирования. Ну а к автоматизации через UI я вообще с негативом отношусь, уже неоднократно считала ROI: протащить обёртку для верхнеуровневого API получается дешевле, чем поддерживать вечно отваливающиеся из-за изменений автотесты.

      Всегда (почти :) ) можно автоматизировать на уровень ниже UI, за счёт параметризации и лёгкой поддержки обеспечить высокое покрытие, а вручную проверять только интеграцию UI и выбранного для автоматизации интерфейса.

      • Zenturio

        Когда мартышек много, они довольно хорошо делают свою работу
        Уровень ниже UI в данном случае это уровень SQL логики. Даже если вы покроете логику SQL это не спасет вас от ошибок в UI которые обязательно всплывут, поскольку и меняется UI и логика.
        Да и как вы будете тестировать отчеты уровнем ниже? запускать, хранимку и сравнивать результат работы хранимки? а если у вас шаблон съехал?

        Тестировали ли вы хоть одну АБС или систему биллинга?

        • Аноним

          «Когда мартышек много, они довольно хорошо делают свою работу» — это скорее религиозный вопрос, чем объективный и имеющий единственно правильный ответ. Я всегда выберу одного профессионала вместо трёх мартышек, но спорить не буду, вопрос подходов.

          «Уровень ниже UI в данном случае это уровень SQL логики. Даже если вы покроете логику SQL это не спасет вас от ошибок в UI которые обязательно всплывут, поскольку и меняется UI и логика.» — у вас что, UI в базу лезет? Есть бизнес-логика гуя, есть вызываемые гуём функции, которые в свою очередь генерируют отчёты, лезут в базы и т.д. Гую возвращаются данные для формирования отчёта, их корректность и надо проверять.

          «Да и как вы будете тестировать отчеты уровнем ниже? запускать, хранимку и сравнивать результат работы хранимки? а если у вас шаблон съехал?» — работу логики можно проверить передаваемыми гую данными. Её можно и нужно проверять на различных периодах, выборках, значениях и т.д. А после этого нам необходимо интеграционное тестирование гуя:
          * при нажатии кнопки дёргается то, что нужно
          * передаваемые данные отображаются в отчёте там, где нужны
          Это можно проверить на одном значении, т.к. функциональная комбинаторика уже пройдена.

          «Тестировали ли вы хоть одну АБС или систему биллинга?» — я не знаю что такое АБС и я совсем мало работала с тестированием биллинга. Я тестировала коммерческие ОС и системы документооборота в правительственные организации на 30+ тысяч пользователей — поверьте мне, ни одному оператору сотовой связи такие объёмы информации даже не снились.

          • Zenturio

            Наталья, мартышка в данном случае это автотест GUI который будет работать на каждой из виртуальных машин, на которой я задам.
            Есть система Клиент сервер с GUI клиентом на Delphi or C##
            Логика в хранимках на серверной стороне.
            И клиент и сервер постоянно меняются
            Вы так и не ответили на вопрос, будете ли вы делать тесты UI или же сделаете тесты логики на уровне SQL?
            Для первого допустим я смогу научить человека за пол года делать нормальные тесты используя Record and Play, для второго большой вопрос…

            И сможете ли вы мне проверив логику на SQL не сделав ни одного GUI теста сказать, что данный отчет формируется и данные вылидны?
            Я думаю вряд ли.

            Поэтому для определенного класса системы тесты через GUI не имеют альтернативы поскольку покрывают и логику и взаимодействие логики с GUI
            Даже если они ломаются каждую неделю.

          • Сирожа

            Альтернатива зачастую есть, только она требует серьезной переработки проекта, что не оправдает себя по трудозатратам. То есть то что вы описали — пример плохого Testability, вот и все.

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

  • Alexey Bulat

    1. Реклама на лицо… может она и не была целью, но она удалась… Прочитав последний абзац, про себя плюнул и решил, что зря потратил время…

    Однако взялся прочитать комменты…

    Письками мериться каждый горазд!!!

    Одни говорят: «автоматизация Уууу», — другие говорят: «она Ээээ»… А третьи её делают и она работает!!!

    Хотите живую автоматизацю через ГУИ? — пишите тесты после того, как весь этот гуй утвержден и не будет меняться. Используйте удобные инстурменты и фреймворки. Делайте правильную архитектуру тестов, чтобы в случае изменения ГУЯ не надо было переписывать все, что было до этого написано.

    Хотите спуститься уровнем ниже и тестить бэкенд и бизнес логику, да пожалуйста… просите делать для вас «дырки» в этом самом приложении, пишите свои системные, интеграционные и юнит тесты… Кто Вам запрещает???

    Главное, чтобы было на пользу!!!

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

  • Эдуард Галиаскаров

    Наталья, а если у Вас такая ситуация. Три релиза, два кастома + транк. Ежедневный мониторинг регрессии.
    Или другими словами — нужно протестировать жизненные циклы документов, причем каждый раз после обнаружения ошибок нужно повторять весь список тестов (ну нельзя их сделать независимыми, марковская цепь никак не получается, только автомат с памятью и порой глубокой).
    Если бы я только ручками заставлял тестировать у меня все тестеры уволились бы через месяц.
    Я считаю — ручное тестирование — исследовательское, новое, то что действительно быстрее прогнать руками.
    Автоматом — всю рутину.

    Но я с Вами согласен «автоматизация и круто, и сложно», но не согласен «при этом абсолютно бесполезно». Все Ваши установки имеют частное значение, и не обобщаются.

  • garryname

    …и при этом абсолютно бесполезно…Вы (автор статьи) волнуетесь! Не пропадет их (более опытных тестировщиков) скорбный труд…Во время автоматизации (выполненной качественно) будут выявлены изъяны реализации и архитектуры, получены необходимые метрики, найдены баги, пропущенные кликерами, а девелоперы будут иметь отлаженные/протестированные библиотеки для использования в других проектах.

  • Pingback: FUT14 Coins

  • Pingback: View Bay Colony Naples Fl Pinterest Pictures

  • Pingback: Elder Scrolls Online Gold EU

  • Pingback: アトランティカ RMT

  • Pingback: FIFA 14 RMT

Social Widgets powered by AB-WebLog.com.