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

Но мы – тестировщики и, следовательно, должны уметь находить дефекты не только в программных продуктах, но и в процессах. Рассматривая процессы автоматизации тестирования объективно и непредвзято, мы можем обнаружить подводные камни, заставляющие нас усомниться в радужной картине автоматизации тестирования.

Но давайте по порядку.

Автоматизации тестирования не уменьшает стоимость тестирования

Усомнимся и попробуем опровергнуть.

При использовании автоматизации тестирования:

• Исключаются ошибки, совершаемые человеком

• Увеличивается скорость тестирования

• Увеличивается стоимость тестирования

При ручном тестировании затраты требуются на:

• Тест-дизайн

• Ручное тестирование

При автоматизированном тестировании затраты требуются на:

• Тест-дизайн (скрипт должен делать определенные действия и проверки)

• Разработку автоматизированных скриптов (это понятно)

• Отладку автоматизированных скриптов (в скриптах могут быть ошибки)

• Модификацию и актуализацию автоматизированных скриптов (приложение меняется достаточно часто)

С учетом стоимости инженеров по автоматизации, лицензий и/или поддержки инструментов, затрат на фреймворк увеличение стоимости тестирования вполне реально.

Универсальный инструмент автоматизации тестирования позволяет сократить стоимость тестирования

Усомнимся и попробуем опровергнуть.

Как правило, универсальность – это маркетинговая «фишка» поставщиков инструмента. При детальном рассмотрении и применении инструмента возникают различные ограничения. Как правило, они связаны с конкретными версиями браузеров, продуктов третьих сторон (например, версий MS Office и др.). Хорошо если выпускаются плагины, но тогда возникают дополнительные затраты на их приобретения. Пример – работа HP QTP с различными версиями браузера Mozilla FireFox. Если же нет, то и сделать ничего нельзя.

Автоматизация тестирования сокращает объем и сроки тестирования

Усомнимся и попробуем опровергнуть.

Активностей тестирования стало больше – должны возрасти объем и сроки. К тому же автоматизированное тестирование не вытесняет полностью ручное. Судите сами:

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

• Скрипты могут находить «ложные» дефекты – их тоже надо проверять вручную

• При проверке дефекта надо «копать вокруг него» - скрипты этого делать не умеют

Автоматизированные скрипты находят все дефекты

Усомнимся и попробуем опровергнуть.

Понятно, что все дефекты найти нельзя. Однако представим, что при обширном регрессионном автоматизированном тестировании в какой-то части приложений найдено дефектов меньше, чем ожидалось. При ручном тестировании можно проанализировать ситуацию и, скажем, воспользоваться технологией исследовательского тестирования – попросить квалифицированного тестировщика детально проверить подозрительную функциональность. Как можно в этой ситуации использовать автоматизацию с той же эффективностью (прежде всего скоростью) тестирования? Написать по-быстрому сложные скрипты (простые ведь уже написаны и выполнены)? Маловероятно.

Автоматизированное тестирование позволяет избавиться от ручных тестировщиков

Усомнимся и попробуем опровергнуть.

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

Но есть еще один риск. При использовании инструмента может возникнуть ситуация, когда, например, не все экранные элементы этим инструментом распознаются. Примером может быть объект типа «Календарь» или какой-нибудь хитро устроенный список. Скрипт этот элемент не распознает, ручных тестировщиков нет – кто его тестировать будет?

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

Автоматизированные скрипты пригодны для тестирования сразу после их записи

Усомнимся и попробуем опровергнуть.

Типичная ситуация – проведение нагрузочного тестирования.

Понятно, что необходимо подготовить тестовые данные. Можно ли это сделать максимально быстро? Не всегда.

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

• веб сервера

• сервера приложений

• базы данных

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

Другая ситуация – модификация скриптов нагрузочного тестирования для обеспечения их уникальности. При записи создается один скрипт, а запускаться он будет для, скажем, 3 000 виртуальных пользователей. Значит, перед запуском его нужно модифицировать. Для справки: руководство по такой модификации для скриптов в рамках инструмента от Rational Software занимает 60 страниц текста.

Еще примеры? Следите за публикациями в блоге!

Ваш гуру, Александр