Home

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

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

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

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

Сейчас в Microsoft я возглавляю команду замечательных SDET (Software Development Engineers in Test), которые тестируют преимущественно на уровне программных интерфейсов (API). Ежедневно я наблюдаю, насколько важной для всего жизненного цикла продукта является автоматизация регрессионного тестирования на юнит и API уровнях (у нас используется ежедневная сборка). Конечно, тесты, которые мы запускаем, способствуют улучшению качества продукта с точки зрения клиента, но это также помогает уменьшить общие издержки производства. Это особенно важно для крупных корпоративных систем, где неудачные билды или ошибки интеграции могут быть очень дорогостоящими или привести к неоправданным задержкам.

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

Однажды я сказал коллеге, что компьютер действительно плохо эмулирует «меня». Я сказал: «Например, когда я печатаю, иногда я нажимаю не на ту клавишу, или я слишком долго задерживаю палец на кнопке и появляется это дурацкое сообщение о «залипании"; а иногда неудачная позиция рук на ноутбуке приводит к случайному нажатии клавиши, это является причиной перемещения из одной точки текста в другую и приходится возвращаться в нужное место. Ты не можешь автоматизировать всю непредсказуемость моей печати!» Он сказал: «Конечно могу!» Я ответил: «Хорошо… Я верю, что мы в определенной степени можем автоматизировать случайности или непонятное поведение, но тогда возникает вопрос – должны ли мы это делать?»

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

Например, на днях я искал новую программу для своих студентов, чтобы закрепить на практике навыки автоматизации GUI (да, несмотря на то, что в целом я не люблю автоматизировать пользовательский интерфейс, этот навык все же стоит иметь). Я наткнулся на текстовый редактор под названием XINT. Потратив несколько минут на загрузку и изучение особенностей программы, я нашел ошибку в функции, которая вставляет URL в текст.

В качестве простого примера я хотел показать, как мы можем автоматически пройти по структуре меню, чтобы убедиться, что там нет изменений, и по нажатию запускаются необходимые события (например, отображается диалоговое окно). Я собирался разработать автоматический демо-тест, который бы проходил по структуре меню и проверял, что ожидаемое событие вызывается нужным пунктом меню. Автоматизация GUI тестов такого типа может обеспечить более высокую скорость «сверки», чем тестировщик-человек. Кроме того, автоматизация обеспечивает избыточные проверки тестируемого приложения, которые нам бы хотелось проводить при каждой новой сборке. Я не стал бы ожидать, что этот автотест найдет множество багов, но он сможет быстро предупредить нас о любом изменении в структуре меню и о каждом ненормальном поведении основных функций, вызваемых из этого меню. Быстро и просто.

Итак, идем в это меню и программно симулируем «нажатие» на элемент меню через вызов функции SendMessage(), которая вызывает появление «правильного» диалога. До сих пор все хорошо. Мы не тестируем функциональность «вставить URL в текст»; максимальный уровень проверки — это просто проверка того, что произошло правильное событие (в данном случае — появился диалог). Теперь надо отправить сообщение «нажать кнопку Cancel», и ожидаемым результатом будет скрытие диалога и возвращение к тестируемому приложению (XINT). Но на самом деле окно вставки URL перерисовывается: убирается вводимый текст по умолчанию и у окна появляется новая поясняющая надпись. (И это только начало, потому что повторное нажатие Cancel принудительно вставляет в редактор текст по умолчанию. У вас просто нет выбора. Если уж вы захотели вставить URL – он будет вставлен, нравится вам это или нет!) И это — ошибка, которую мой автоматический тест мог бы найти.

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

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

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