(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Блеск и нищета автоматизации тестирования

Источник: habrahabr
Дмитрий Мамонов

image


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

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

Преимущества автоматических тестов


Автоматизированное тестирование имеет ряд существенных преимуществ по сравнению с ручным тестированием.

Дешевизна -  прогон  автоматических тестов всегда дешевле ручной проверки на несколько порядков.  Разработка  автоматических тестов конечно дороже  разового  ручного тестирования.

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

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

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

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

 

Преимущества ручного тестирования


Ручное тестирование, тем не менее, превосходит автоматизированное по многим аспектам.

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

Гибкость - ручное тестирование можно проводить гораздо разнообразнее, и изменение способа тестирования практически ничего не стоит. Давайте протестируем в Safari - пожалуйста, на Chromebook - нет проблем, IE6 - придется запустить виртуальную машину, но тоже можно. 

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

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

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

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

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

Блеск парадоксов тестирования


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

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

Потратив на тестирование 1 день, мы добьемся 90% довольных пользователей. Тестируя неделю - 99%, тестируя месяц 99.5%. На достижение все меньшего и меньшего результата мы тратим все больше времени. Это нецелесообразно.

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

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

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

Ситуация в корне меняется в длительной перспективе. Код приложения необходимо рефакторить, чтобы он не умер. Когда программисты все переделали - тестировщики должны все проверить. Полный цикл регрессионных тестов. Неделя? Две? Месяц? Или еще хуже: программисты обновили версию ключевой библиотеки. День работы, вроде все компилируется - отлично! И все равно тестировщики должны проверить все. Безумие. Пройдя через такое несколько раз, любой будет готов пойти на что угодно, лишь бы избежать подобных ситуаций в будущем. Для обеспечения стабильного базового уровня качества необходимо вкладываться в автоматизацию тестирования. 

К сожалению, автоматические тесты не всегда являются решением, иногда они сами становятся проблемой.

Нищета автоматизации тестирования


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

Решение: написать автоматические тесты, которые все это делают.

Но не все так просто.

Написание тестов - это разработка, точно такая же, как и разработка основной бизнес-логики. Она требует ресурсов и квалификации. Обеспечивая качественное покрытие кода приложения тестами мы одновременно замедляем разработку как таковую. И замедляем не на 10%, а вдвое, втрое или даже больше.

Скорость - понятие относительное. Каждый конкретный тест, конечно, выполняется очень быстро, особенно чистые unit-тесты, когда все проверки происходят локально. Интеграционные тесты, REST-тесты тоже сравнительно быстрые. Что такое 100 миллисекунд, ну пусть даже 1 секунда, даже десятки секунд для selenium тестов - ерунда по сравнению с ручным тестированием. Но когда количество тестов хоть сколько-нибудь существенно, быстрые тесты оказываются очень даже медленными. Прогон тестов за 5 минут? Полчаса? Три часа? Два дня? Еще даже не добившись полноценного покрытия бизнес-логики, всерьез встает вопрос о том как запускать не все тесты, или запускать тесты не каждый раз - иначе уже автоматические тесты начинают тормозить разработку.

Примечание : Тесты можно существенно ускорить, вложившись в железо - выделить под них отдельный сервер, 10 серверов, 50 и т. д. Некоторые компании могут позволить себе и 1000 тестовых серверов, но далеко не все.

Инструментарий плох. Ни одна из мейнстримных платформ программирования не проектировалась с целью обеспечить возможность максимально просто и полноценно разрабатывать тесты. В Java все тестовые фреймворки являются сторонними библиотеками. Запуск тестов, осуществление проверок, создание mock-объектов - все это есть, но по частям и вне платформы. В Go тестовый фреймворк уже добавили в экосистему языка изначально, но это только запуск тестов. Выбор подходящего инструментария для написания тестов это отдельная проблема, требующая решения. 

Не такие уж они и хорошие. Тесты - такой же код, написанный такими же разработчиками. Они тоже содержат ошибки и все те же проблемы, что и любой другой код. Бывает, что тест ничего не проверяет. Бывает, что тесты тоже нужно рефакторить. Бывает, что по упавшему тесту очень трудно понять, в чем проблема. Бывает, что тесты падают просто так, когда ошибки на самом деле нет.

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

Ограничивают рефакторинг. Тесты тоже нужно рефакторить, даже если бизнес-логика не меняется, и в коде происходят лишь косметические изменения. Это может привести к тому что нужно поправить 5 мест в основном коде и еще 80 в тестах. Каждый в такой ситуации задумается: а стоит ли делать что-то большее, чем переименование метода. 

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

Количество тестов обманчиво: 3000 тестов в сумме - на веб-интерфейс, REST API, бизнес-логику и юнит-тесты - могут проверять с натяжкой 1000 ситуаций. Все остальное - дублирование.

Автоматическая регрессия не отменяет ручную вопреки главной задумке. Все потому что автоматические тесты проверяют много чего, но далеко не все. Но что конкретно они проверяют, а что нет - никто не знает. Нам нужно проверить регистрацию. А еще у нас есть 18 927 тестов. Если какой-то из них красный - "все хорошо", можно вернуть задачу к разработчикам - пусть разбираются. Если все тесты зеленые - это ничего не значит до тех пор, пока человек, отвечающий за ручное тестирование, не будет уверен, что из логики регистрации проверяется автоматически, а что все еще нужно проверить вручную. А тестов почти двадцать тысяч - в этом невозможно разобраться. Результат - проверить вручную нужно все.

Неудивительно что некоторые уходят из разработки продавать пластиковые окна, обучать бильярду или варить кофе (и это все реальные случаи).

Ссылки по теме


 Распечатать »
 Правила публикации »
  Обсудить материал в конференции Дискуссии и обсуждения общего плана »
Написать редактору 
 Рекомендовать » Дата публикации: 09.02.2017 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
VMware Workstation 14 Pro for Linux and Windows, ESD
Купить WinRAR : 5 : Академическая лицензия 1 лицензия
Купить CommView for WiFi 1 лицензия
Business Studio 4.2 Enterprise. Конкурентная лицензия + Business Studio Portal 4.2. Пользовательская именная лицензия.
Kerio Operator - Server (incl 5 users, 1 yr SWM)
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Поиск курсов
 
 
Интересные факты

Учебный центр "Интерфейс" - в десятке ведущих учебных центров России в сфере IT.

  • У нас преподают такие известные эксперты, как Пржиялковский В.В., Леоненков А.В., Новичков А.Н., Золотухина Е.Б., Зайцев А.Л., Зайцев Р.А., Большаков О.Н., Мирончик И.Я., Саксонов А.А., Пригодина Н.Ю.
  • Учебный центр "Интерфейс" проводит авторизованные курсы по продуктам компаний Microsoft, ERwin, Embarcadero (CodeGear), Postgres Professional
  • Подтвердить полученные знания можно, сдав сертификационные экзамены. Учебный центр "Интерфейс" является авторизованным центром тестирования Pearson VUE
  • Учебный центр "Интерфейс" оказывает консалтинговые услуги по построению моделей бизнес-процессов, проектированию информационных систем, разработке структуры баз данных и т.д.
  • Возможна корректировка программ курсов по желанию заказчиков! Мы расскажем Вам о том, что интересует именно Вас, а не только о том, что жестко зафиксировано в программе курса.
  • Где Вам удобнее учиться? В Москве? Санкт-Петербурге? Подмосковье? В вашем собственном офисе? Позвоните нам по тел.:+7 (495) 925-0049 и мы обсудим удобный для Вас вариант обучения.

Горячая линия:
+ 7 (495) 925-0049
mail@interface.ru
Отправить быстрое сообщение

Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Обучение для IT-профессионалов
Обучение и сертификация Microsoft
IT сертификация
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Пишу программы на заказ профессионально (2183)
Пишу программы на заказ на языках Pascal (численные методы, списки, деревья, прерывания) под...
 
Пишу программы на заказ для студентов (176)
Пишу для студентов на с, с++, паскаль в средах ms visual studio, qt, builder, borland c, delphi....
 
Ищу программиста для написания программы (15)
Ищу программиста ,владеющего Вижуал Бэйсик и программированием в Экселе, для написания...
 
И я там был (2)
И я там был, мед пиво пил, по усам текло, а в рот не попало.
 
Пишу программы на Lazarus (19)
Предлагаю разработку программ на заказ. Примеры программ: www.itproportal.ru
 
 
 



    
rambler's top100 Rambler's Top100