Home

Автор: Дмитрий Ручко

Данная статья была подготовлена на основе доклада, сделанного автором на конференции SQA-2 (http://sqa2conf.blogspot.com/) в октябре 2007 года.

Целью данной статьи является желание дать людям верное представление о том, что же такое «автоматизированное тестирование» и с чем его «едят».

Введение

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

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

Что такое автоматизированное тестирование

Один из наиболее популярных мифов состоит в том, что:

Миф 1. Автоматизированное тестирование – это только проверка регресса.

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

Миф 2. Автоматизированное тестирование – это только функциональное тестирование через GUI. 

И то и другое – это в корне неверные представления о нашей теме. Попробуем для начала понять: что же такое автоматизация?

 «Автоматизация – это комплекс мероприятий, направленный на повышение производительности труда человека посредством замены части этого труда работой машин.» Информатика. Энциклопедический словарь-справочник [1].

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

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

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

Контроль ошибок. Сюда относятся багтрекинговые системы всевозможных вариаций.

Создание тестов. Имеется в виду предварительная автогенерация: на основе кода - для unit-тестов, на основе функциональных требований - для ручных тестов, генерация по принципу record’n’play и т.п.

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

Выполнение тестов. Запуск тестовых скриптов и анализ полученных результатов.

Данный список каждый может продолжить сам в зависимости от специфики своей работы.

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

Для каких же целей может применяться автоматизированное тестирование?

Первое, и наиболее популярное, – это тестирование производительности во всех своих инкарнациях: нагрузочное, стрессовое, на стабильность… Популярное по той причине, что без автоматизации его выполнить невозможно. По этой же причине имеется широкий выбор инструментария от разных производителей и столь же высокие цены, даже в случае неудобного и слабофункционального инструмента.

Следующим идёт регрессионное тестирование. Что означает проверку ПО на корректность функциональности, выпущенной и тщательно протестированной в предыдущей версии. Выполняется с регулярной частотой, задаваемой в зависимости от условий: у кого-то с каждым новым билдом, у кого-то с каждой версией для заказчика.

Конфигурационное тестирование – выполнение одних и тех же тестов в разных условиях. То есть когда один или несколько компонентов архитектуры системы требуется проверить в разном окружении, обычно заявленном в изначальных требованиях. Например: поддержка СУБД от разных производителей, работа в разных клиентских браузерах, использование в нескольких ОС и т.п. То есть некий аналог регрессионного тестирования, но в рамках одной версии системы. Кроме средств контроля за выполнением работ, в данном случае, нелишней бывает возможность автоматического сравнения полученных результатов выполнения сценариев в разных конфигурациях.

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

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

И так далее… Если скрипты создаются для одной из видов тестирования, то по мере развития никто не мешает их использовать и в других целях: релизном, приемочном… Почти везде.

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

Во-первых, это всем известное unit-тестирование. Не модульное в общем понимании, а техника написания тестов разработчиками на основе и для исходного кода. Наиболее активно сейчас о ней говорится в разных agile-методологиях. Хотя и в классических процессах разработки может приносить много пользы, если правильно начать использовать.

Тестирование API (программных интерфейсов, в которые входят как публичные методы для локальных вызовов от обычных dll, так и для COM+, win- и web- сервисы, обращения через очередь и т.п). Обычно применяется на уровне модульного тестирования продукта и позволяет не отвлекаться на исследование характеристик методов при последующей интеграции.

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

Тестирование CLI (программ со строкой командного ввода). Позволяет применять простую таблицу для анализа вводимых значений и получаемых результатов. И затем без особых усилий запрограммировать.

Тестирование GUI (пользовательского интерфейса) – то, о чём обычно идёт больше всего разговоров. И что далеко не всегда удается успешно внедрить. Обычно применяется на уровне системного тестирования для поиска регрессионной зависимости.

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

Как оно работает

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

Следующее заблуждение свойственно людям, желающим счастья и сразу:

Миф 3. В автоматизированном тестировании всё выполняется само

Вспоминается закон Мёрфи: «Создай систему, которую сможет использовать даже дурак. И только дурак захочет ей пользоваться».

Посмотрим снова в словарь Информатики [1]:

«Автоматизированный технический объект: это устройство, система или процесс, в котором используются автоматы или другие средства автоматизации. В отличие от понятия "автоматический" в работе указанных средств или в выполняемом ими процессе предполагается участие человека.»

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

1. Выбор скриптов для запуска. При большом объёме вполне может возникнуть ситуация, что все их одновременно запускать не нужно. Вполне техническая – когда инструмент пишет весь лог в память, и значит при длинном сценарии очень вероятно её переполнение. Или функциональная – когда выполнение части тестов не требуется из-за ещё неисправленных ошибок. Чисто ручная работа.
2. Подготовка тестовых данных. Может быть как автоматической, так и ручной. В удачном случае данные могут остаться неизменными от предыдущего запуска, если тесты просто не меняют данные либо по окончанию тестирования приводят их в исходное состояние. В неудачном – перед каждым запуском данные нужно готовить заново.
3. Собственно запуск и выполнение скриптов. Данный этап может быть полностью автоматическим, если фреймворк позволяет настроить планировщик для запуска тестов при сохранении созданного списка.
4. Анализ полученных результатов. Чисто ручная работа, которая может быть слегка автоматизирована в плане сравнения результатов с иными запусками или фильтрации изучаемых логов.
5. Публикация результатов. Если напрячься, также поддается автоматизации. Но обычно выполняется вручную с использованием данных, полученных на предыдущем этапе.

Сколько стоит

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

Миф 4. Автоматизация позволяет сократить расходы

Миф 5. Автоматизация решает проблему с нехваткой ресурсов

Первый миф из этих двух обычно вспоминается руководителем проекта, который рассчитывает бюджет при изначальном планировании, вспоминает о тестировании, об автоматизации и решает съэкономить за счёт неё. И это ещё не самая плохая ситуация.

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

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

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

И при расчёте расходов нужно учитывать следующие элементы:

• Инструмент;
• Обучение/наём опытных сотрудников;
• Разработка;
• Сопровождение;
• Выполнение;
• Новые задачи, связанные с автоматизацией (по сравнению с ручным тестированием).

Инструментарий не всегда вам может подойти бесплатный в силу специфики построенных процессов или других обстоятельств. Но обычно это малая часть от стоимости автоматизации. Что обучение, что наём новых сотрудников – эти процессы занимают не один день и обычно влетают в копеечку. Особенно, если время хочется сократить. Разработка и сопровождение – два процесса, по стоимости обратных друг другу. В начале проекта создание тестов съедает большую часть выделенного времени, а их сопровождение равно нулю, поскольку скриптов попросту ещё нет, а от тестировщиков требуеся определиться с тестовым окружением и инфраструктурой. Возможно даже потребуется сперва разработать свой фреймворк (одна из дополнительных задач).

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

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

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

Так что объём задач в одном и другом случае просто не сравним. Это означает, что при ручном тестировании продукт был недоисследован с одного бока, а при автоматизированном – забудут про другой. Или осмотрят с каждой стороны, но совсем коротенько.

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

Что происходит с ошибками

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

Миф 6. Автоматизация позволяет найти больше ошибок.

Миф 7. Автоматизация уменьшает количество человеческих ошибок.

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

Канер, Бах, Петтикорд в своей книге [7], приводят следующую статистику: «при любом виде автоматизированного тестирования находится не более 30% ошибок в самом удачном случае. И только при конфигурационном тестировании можно найти до 80% от общего числа ошибок.»

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

Автоматизированное тестирование всегда имеет как плюсы:

• Большее покрытие кода;
• Тест не будет пропущен;
• Тесты содержит одни и те же шаги;

так и минусы:

• Ошибки в основном находятся при создании скрипта;
• Скрипты не позволяют отклонений;
• Скрипты также могут содержать ошибки.

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

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

Так сколько же нужно автоматизировать

Ещё одна крайность, в которую бросаются люди, приняв решение о начале автоматизации – это:

Миф 8. Чем больше автотестов, тем лучше.

В результате возникает стремление закодировать как можно больше ручных тестов. А лучше все. Это неправильно. В реальности объём автоматизации определяется контекстом проекта. Какова архитектура системы? Какие требования к качеству у заказчика? Какой бюджет проекта, в том числе и сроки?

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

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

• сложной алгоритмизации проверки;
• нестандартной конфигурации стенда, которую нужно менять для разных тестов;
• стороннее ПО, создающее дополнительные проблемы;
• и прочие причины…

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

Маловато будет…

Данный список мифов можно ещё долго продолжать, постепенно опускаясь от крупных заблуждений к менее серьёзным ошибкам. Которые однако могут привести к серьёзным проблемам.

Однако хотелось бы закончить на оптимистичной ноте. Поэтому напоследок вместо мифов я хотел бы привестя ряд утверждений, содержащих Правду об автоматизированном тестировании:

1. Автоматизация может применяться в большинстве процессов и на всех уровнях тестирования.
2. Ручное и автоматизированное тестирование – это взаимодополняющие технологии.
3. Автоматизированное тестирование подразумевает участие человека.
4. Автоматизированное тестирование требует дополнительных инвестиций, но позволяет повысить качество продукта.
5. Автоматизированное тестирование – это разработка (программирование).
6. Автоматизированное тестирование гарантирует детерминированную проверку функциональности.
7. Сопровождение автоматизированных тестов требует больших дополнительных расходов при активном изменении тестируемой системы.

Что почитать

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

1. Воройский Ф. С.
   Информатика. Энциклопедический словарь-справочник: введение в современные информационные и телекоммуникационные технологии в терминах и фактах.
   2006, ФИЗМАТЛИТ.
2. Elfried Dusting, Jeff Rashka, John Paul.
   Automated Software Testing: Introduction, Management and Performance.
   1999, Addison-Wesley.
   Выпущена в русском переводе:
   Элфрид Дастин, Джефф Рэшка, Джон Пол.
   Автоматизированное тестирование программного обеспечения: Внедрение, управление и эксплуатация.
   2003, Лори.
3. Mark Fewster, Dorothy Graham.
   Software Test Automation: effective use of test execution tools.
   1994, Addison-Wesley.
4. Kanglin Li, Mengqi Wu.
   Effective GUI Test Automation: Developing an Automated GUI Testing Tool.
   2005, SYBEX.
5. Jerry Zeyu Gao, H.-S. Jacob Tsao, Ye Wu.
   Testing and quality assurance for component-based software.
   2003, Artech House.
6. James D. McCaffrey.
   .NET Test Automation Recipes: A Problem-Solution Approach.
   2006, Apress.
7. Cem Kaner, James Bach, Bret Pettichord.
   Lessons Learned in Software Testing: a context driven approach.
   2002 г., Wiley Computer Publishing.