Баги, которые прячутся от автоматических тестов

Оригинальная публикация
Автор: Bj Rollison
Перевод: Татьяна Зинченко

В комментариях к одной из заметок в моем блоге Шрини Калкарни (Shrini Kulkarni) предложил: “Наверное, тебе стоит написать о тех багах, которые юнит-тесты (или тестирование разработчиками на любом уровне) не могут поймать. Это будет достойный ответ всем, кто безгранично верит в автоматизацию тестирования на юнит и API уровнях”

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

• профилактики дефектов (особенно ошибок в логике вычислений);
• ранней идентификации проблем интеграции;
• создания нагрузки на критические ресурсы (питание, производительность, память);
• эффективного выполнения избыточных проверок (по необходимости или для надежности);
• более эффективных/точных “оракулов” по сравнению с людьми;
• снижения затрат в долгосрочной перспективе.

Читать дальше

Но проведя небольшое дополнительное исследование, я обнаружил другую ненормальность, которая не поддается логике, и которую автотесты, конечно, не нашли бы. Когда я нажал кнопку ALT, я заметил нечто странное – кнопка Cancel исчезает! Однако, с точки зрения системы эта кнопка все еще существует, я могу программно обратиться к ней. Хотя с точки зрения пользователя – ее нет!


Помоему это ошибка написания автотестов.
Обычно у кнопки есть свойство Visible
Если оно будет fALSE, ТО АВТОтест
это определит и выведет ошибку
Ихмо надо правильно писать автотесты

Помоему это ошибка написания автотестов.
Обычно у кнопки есть свойство Visible
Если оно будет fALSE, ТО АВТОтест
это определит и выведет ошибку
Ихмо надо правильно писать автотесты

Нет, автор просто пишет про авт. тестирования используя юнит-тесты или API.
А проверять свойство button-а это уже из области автоматического тестирования GUI.

Увы не всегда наличие свойства visible гарантирует нам что кнопку реально видно. У тебя могут, например, слететь по ивенту стили с кнопки. Или выставиться еще что-нибудь, так что кнопки не будет видно визуально, но при этом visible будет очень ок. Не явно дублирующиеся свойства у разных кастомных контролов во флешике это та еще дискотека.
Ну и там таки написано:

and even trying to automate a test for these types of issues is not just an effort in futility, I would say it is damn near insanity

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

Нет, автор просто пишет про авт. тестирования используя юнит-тесты или API.
А проверять свойство button-а это уже из области автоматического тестирования GUI.

В данных примерах он кажется вполне конкретно разбирает GUI test automation

Описанный пример является демонстрацией тезиса "Я верю, что мы в определенной степени можем автоматизировать случайности или непонятное поведение, но тогда возникает вопрос – должны ли мы это делать?"

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

Кстати, про элементы, расположенные за пределами окна -- это я не придумал. Это реальный прием, который используется, например, в визардах -- все шаги отрисовываются сразу на длинной полосе, а в окне визарда показывается только один. При переходе к следующему шагу полоса сдвигается и в окне появляется следующий шаг. Получается эффект "смены слайдов", а не просто перерисовка окна.

Ещё кстати -- вы не поверите, но в мейл-листе про Selenium в последнее время стали часто появляться вопросы "как кликнуть на невидимую кнопку?" Дело в том, что в Selenium 2 это запретили (а в первой версии было можно) -- и народ страдает. А вы говорите -- проверять свойство видимости перед выполнением действия. Да они наверняка знают, что она невидимая, и всё равно кликают!

То, что даже очень хорошие автотесты никогда не заменят человека, думаю, и ежу понятно.
Однако, если приходится тестировать одно и тоже раз 5 в месяц в течение года, то автотесты очень к месту.
Проблема с "недочеловечностью тестов" у нас решается расширенными методами и дополнительными проверками большинства элементов на странице через Page Objects архитектуру.
Такие подробные автотесты получаются довольно наглядными и простыми в написании. Важно просто изначально понимать в какую сторону двигаться и использовать техники тестирования и программирования.
Кроме того, дополнительно при прогонке автотестов записывается лог и делаются скриншоты. Которыми пользуется уже ответственный человек для дополнительной проверки.

Помоему это ошибка написания автотестов.
Обычно у кнопки есть свойство Visible
Если оно будет fALSE, ТО АВТОтест
это определит и выведет ошибку
Ихмо надо правильно писать автотесты

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

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

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

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

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

Не, можно сразу взять monkey clicker и обозвать это автотестами. Ну допилить еще немного)
Без фанатизма многое ок. Дальше вопрос цены/времени встает.

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

Можно. Но сложность оракулов сразу начинает быстро расти. За всё приходится платить :)

Человек -- как "пьяный компьютер"

Блеск!

Увы не всегда наличие свойства visible гарантирует нам что кнопку реально видно. У тебя могут, например, слететь по ивенту стили с кнопки. Или выставиться еще что-нибудь, так что кнопки не будет видно визуально, но при этом visible будет очень ок. Не явно дублирующиеся свойства у разных кастомных контролов во флешике это та еще дискотека.
Ну и там таки написано:

and even trying to automate a test for these types of issues is not just an effort in futility, I would say it is damn near insanity

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

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

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

Если вы делаете миллион проверок на любой чих, то медленным будет. У части приложений для тестирование извлечение свойств идет через пятую точку, так что может стать критично медленным. Одна проверка и 500 это разница. Пара секунд набежит на каждый экшен и уже совсем не очень. И у вас врятли же в GUI тесте будет "1 экшен" = "1 тест". А если вам еще сравнивать не тупо цифру/строку, а объекты, то начнется дискотека. Ну набежит пара минут на каждый тест. Ничего страшного если их несколько десятков. И если всего пара минут. А если больше?
И при этом никто вам не гарантирует что вы предусмотрели все возможные проверки свойств и все возможные экшены. Ваш тест найдет ALT, но пропустит CTRL+ALT+TAB, например. Хотите сделать все переборы? Ну ок, со странички вы можете выдрать все ивенты. Может быть. А для десктопных приложений уже не получится.

Это плохая логика проверять все, везде и сразу. Избыточные проверки это верный путь в декартов взрыв. Где-то они оправданы, но с ними надо быть аккуратным. Хардкодить эти проверки плохо и в итоге может стать дорого в плане поддержки. Делать их умными несколько дороже в плане реализации, но уже лучше. Но это дополнительные риски.

Нельзя закрыть тестами все. Более того - это не очень умно. Можно закрыть достаточно. Это утверждение верно и для мануальных тестов и для автоматики. И тут еще встает вопрос эвристик. Часть эвристик отлично работает для автоматики. Часть (визуальщина самый частый пример) слишком дорогие.