testomat.io управление авто тестамиВ условиях, когда новые версии программного обеспечения появляются одна быстрее другой, требуя сокращения времени выхода на рынок и повышения качества, открыт путь для автоматизированного регрессионного тестирования. Почему же, даже несмотря на все преимущества, автоматизация тестирования все еще не является обычным подходом к регрессионному тестированию?
В этой статье я сосредоточусь на автоматизации регрессионного тестирования и подходе для успешной реализации автоматизированного инструмента тестирования с фреймворком, управляемым сценариями. Это можно реализовать для почти всех видов автоматизированных инструментов для выполнения тестирования (коммерческих или бесплатных) и всех типов интерфейсов, в зависимости от вашего выбора инструмента.
Зачем автоматизировать выполнение теста?
Существует несколько причин для того, чтобы автоматизировать выполнение тестов. Вот короткий обзор наиболее обычных причин.
Последовательное выполнение тестов
При автоматизации выполнения тестов человеческий фактор можно вычеркнуть из уравнения. Несмотря на все усилия тестировщика, сложно неоднократно выполнить тесты точно таким же образом при тех же самых условиях. Дело в том, что не каждый шаг теста выполняется таким же образом, которым он выполнялся во время более раннего теста. Такие различия в выполнении могут привести к ошибкам и влиять на результат теста. При маленьких ошибках во вводе могут быть серьезные последствия в сценарии тестирования.
Оптимизация использования времени
Для тестировщиков, оптимизация использования времени является, вероятно, важнейшей причиной автоматизации выполнения тестов. В идеальном мире тестировщики могут выполнить свой недавно выполненный скрипт автоматически немедленно. Таким образом, они не должны выполнять его вручную и начинать с других (тестовых) действий. После автоматизированного теста они могут проанализировать результаты и интерпретировать полученные данные, а также повторить тест снова, при необходимости.
Сокращение времени тестирования, также хороший мотив для автоматизации выполнения тестов. ‘Тестовый Робот’ может выполнять запланированные тесты круглосуточно и семь дней в неделю. Это поможет существенно сократить общее время тестирования, а также увеличить емкость тестов. Имея возможность выполнять более обширные тесты, одновременно, вы сократите Время выхода на рынок и/или увеличите Качество при выходе на рынок.
Более высокое качество результатов и конечного продукта
Поскольку выполнение регрессионных тестов вручную может быть рутинной и монотонной работой для тестировщиков, высока возможность ошибок в выполнении, а соответственно и в результатах. Это может привести к низкому качеству произведенного программного обеспечения, такой эффект легко устранить с помощью автоматизированного регрессионного тестирования.
Ловушки в автоматизированном регрессионном тестировании
Многие организации видят в автоматизированном тестировании решение, помогающее уменьшить время выполнения тестов и их емкость, но при некорректной реализации, можно получить противоположный эффект. Организации, которые не знакомы с автоматизацией тестирования и имели опыт некорректного выбора инструменты или если он не производился вообще, часто не понимают положительного воздействия реализации автоматизации тестирования. Наиболее распространенные подходы: выбрать инструмент, на основе некоторого опыта тестировщика, обзора инструмента в сети, хорошего коммерческого призыва или услышанного отзыва. Выбрать одного или больше «технических» членов команды, занимающейся тестированием, который занимался бы внедрением этого инструмента и началом автоматизации тестирования, кроме другой работы, связанной с тестированием.
Несмотря на большое количество преимуществ, которые обеспечивает автоматизация тестирования, многие организации не способны реализовать ее структурированным, эффективным способом. Зачастую, проблемы с реализацией - результат недостаточных познаний в автоматизации тестирования и неправильное использование этих познаний. При таких обстоятельствах, автоматизация тестирования будет интенсивным, автоматизированным решением для обнаружения ошибок, которое стоит много, но дает мало результатов, или же не дает их вообще.
Когда же именно все пошло неправильно? Существует несколько «ловушек», из-за которых внедрение автоматизации тестирования не будет эффективным.
Высокие эксплуатационные расходы
Одна из наиболее распространенных ошибок: взять тестовые случаи, выполняемые вручную, и преобразовать их непосредственно в сценарий для автоматизированного тестирования, используя запись и воспроизведение. Сначала может показаться, что достигнуто много, ведь теперь все случаи могут выполняться автоматически, ура!!! Однако, что если изменятся объекты в тестируемой системе (System Under Test (SUT) или же если новые технологии будут использоваться для новой версии SUT? Вам необходимо будет обновить все сценарии автоматизации тестирования (записать их снова). Проект автоматизации тестирования, так, становится проектом разработки программного обеспечения, который может быть остановлен, и закончит тем, что будет храниться вместе на полке с ненужными вещами. Я видел много проектов по автоматизации, которые закончили именно так.
Именно таким образом автоматизация тестирования становится дорогой, неэффективной и трудоёмкой и дает не слишком хорошие результаты, или же не дает их вообще.
"Мусор заложишь-мусор получишь"
Распространенное заблуждение в отношении автоматизации тестирования: сценарии автоматизированного тестирования более качественны, чем сценарии для тестирования вручную. Ок, устраняя человеческий фактор в выполнении сценариев тестирования, вы снизите возможность ошибок из-за повторного выполнения сценария во время повторного теста или регрессионного теста. Но, тем не менее, автоматизированный сценарий тестирования хорош настолько, насколько хорош тестировщик, создавший его. Например, если Вы устанавливаете автоматизированный тест с плохим покрытием, или имеющий не слишком высокое качество, автоматизация этого теста только ускорит его выполнение, в итоге вы быстро получите плохой результат. Таким образом, автоматизация тестирования начинается с разработки тестовых случаев, благодаря чему можно получить хорошие тестовые случаи, которые затем можно автоматизировать.
Недостаток знаний и опыта
Многие организации начинают автоматизацию тестирования как часть проекта по тестированию, с целью усовершенствования тестирования. У них уже есть политика и хорошая методика в области тестирования, и они хотят запустить следующий шаг - автоматизацию тестирования. Зачастую, все начинается с кого-то, кто услышал об автоматизации тестирования как об оптимальном решении для повышения качества при снижении необходимых трудозатрат и денежных затрат.
Так без каких-либо познаний в области автоматизации тестирования, получив зеленый свет, некоторые тестировщики начинают заниматься автоматизацией тестирования. Выбирает инструмента также этот тестировщик, и в большинстве случаев в результате получаем инструмент, уже использующийся разработчиками, или инструмент - часть широкого набора инструментов, который уже является частью среды программного обеспечения организации. Тестировщик должен внедрить этот инструмент вместе с другими тестовыми действиями. Самая большая ошибка - считать, что вам удастся реализовать автоматизацию тестирования параллельно с другими действиями. Вы должны думать об этом как об отдельном проекте. Тестировщик должен заниматься исключительно установкой автоматизации тестирования. Он/она, должен иметь связь с инструментами и техническим фоном, большой плюс, если это будет бывший разработчик. Такой тестировщик должен знать язык тестировщиков, а также разработчиков. Тестировщик, занимающийся автоматизацией тестирования, является специалистом.
Если тестировщик не может сфокусироваться полностью на задаче автоматизации тестирования, существует высокая вероятность того, что автоматизация тестирования не будет удачной. Что, если тестировщик только частично занимается автоматизацией тестирования и тратит время еще и на обычные действия, необходимые для тестирования? При изменениях в SUT, тестировщик должен заниматься двумя задачами, и из этих двух, приоритетным будет автоматизация тестирования. Если дело обстоит не так из-за нехватки времени, качество тестирования может ухудшиться, а также тестирование может занять больше времени, потому что автоматизированное выполнение тестов будет невозможным.
Недостаточная структурированность процесса и фреймворка для автоматизации тестов
Как уже говорилось ранее, организации начинают работу с автоматизацией тестирования с выбора инструмента и затем пытаются автоматизировать максимально возможное количество сценариев. К сожалению, обычно, не слишком много внимания уделяется тому, как установить автоматизацию тестирования так, чтобы ее использование было простым, удобным для обслуживания и имело возможности для расширения. Через некоторое время такие организации приходят к заключению, что сотни или даже тысячи сценариев тестирования были выполнены, не обращая внимания, на использование внешних данных тестирования, допускающих повторное использование тестов или установку универсальной платформы для автоматизации тестирования. Упустив это, вы упускаете успешную автоматизацию тестирования. Поддержка программного обеспечения автоматизации и создание новых сценариев будут трудоёмкими. Таким образом, от команды автоматизации тестирования потребуется больше усилий, затраты возрастут, а значительных результатов получить не удастся.
Таким образом, очень важно думать о структурированности процесса для автоматизации тестирования (тестирование на основе ключевых слов, данных или сценариев), а также о том, как внедрить оптимальный фреймворк для автоматизации тестирования.
Как начать со структурированным и универсальным подходом к автоматизации тестирования
В этой части мы сфокусируемся на создании структурированного, универсального подхода к автоматизации тестирования. Я постараюсь, за несколько шагов объяснить, каким образом можно сделать фреймворк для автоматизации, который поможет усовершенствовать автоматизацию тестирования.
Первым важным шагом является:
Выбор подходящего исполнителя этого задания
Как уже говорилось в описании одной из упомянутых выше ловушек, вы должны выбрать правильного человека для выполнения этого задания. Для автоматизации тестирования необходим специалист, обладающий правильными навыками и знаниями. Ему/ей необходим опыт в тестировании, навыках разработки, навыки планирования и т.д. Вам необходим кто-то, кто будет заниматься исключительно созданием вашего фреймворка для автоматизации, а не сотрудник, который может заниматься этим параллельно с выполнением другой работы.
Выбор подходящего инструмента
Существуют сотни инструментов, предназначенных для того, чтобы автоматизировать выполнение тестов. От простых бесплатных веб-инструментов для автоматизации до очень сложных, многоплатформных и мультитехнологических инструментов (инструменты, использующие запись и воспроизведение, инструменты для написания сценариев и т.д.). Самое важное правило, которое необходимо иметь в виду состоит в том, чтобы выбрать инструмент, подходящий для задания. Начните с определения требований, которые вы выдвигаете к инструменту и запустите проект выбора инструмента. Не стоит недооценивать эту часть автоматизации тестирования; это - ключевая составляющая успеха.
Создание нового образа мышления
Мы выбрали один или несколько инструментов для выполнения задания. Следующая вещь, которую я хочу, чтобы вы сделали, состоит в создании нового образа мышления в отношении взаимодействия с любым приложением.
Мы хотим протестировать цепочку приложений от веб фронт-энда до основного бэк-энда. У нас есть множество экранов, для тестирования. Во фронт-энде мы создаем новую учетную запись для онлайн страховой компании. Для этого, у нас есть несколько экранов для взаимодействия:
- Нажать ссылку Создать новую учетную запись (Create new account) на экране Home
- Заполнить и представить данные в экране Информация об учетной записи (My account information)
- Проверить создание новой учетной записи
Теперь нам необходимо модифицировать некоторую информацию в бэк-энде через терминальную эмуляцию. Для этого нам опять необходимы несколько экранов:
- Поиск учетной записи на экране Поиск (Search)
- Модификация информации учетной записи и сохранение информации учетной записи
- Проверка того, что информация учетной записи была изменена
Мы только что создали учетную запись во фронт-энде и изменили информацию в бэк-энде. Мы идентифицировали несколько экранов, а также две различных технологии, но есть ли различие для нас? Нет, нет никакой разницы, экран - это экран, независимо от технологии или среды. Это - истина для большинства объектов, которые находятся в SUT. Почти в каждом приложении мы ожидаем того же, мы заполняем поля на экране и делаем некоторое действие (Enter или F4), и переходим в новое состояние. Это новое состояние может быть новым экраном или существующим экраном, который был изменен.
Теперь, когда мы достигли этого мышления, в отношении взаимодействия с приложением, любое приложением, является для нас одинаковым, независимо от его типа или технологии, и мы можем перейти к следующему шагу.
Форматирование тестового случая
Если вы хотите начать установку автоматизации тестирования структурированным и универсальным способом, вы должны сосредоточиться на двух сторонах, а именно, проекте тестового случая, с одной стороны и его автоматизации с другой. Должен быть универсальный способ создать новые тестовые случаи, таким образом, чтобы они сами могли быть универсальным вводом для скриптов автоматизации тестирования.
Один из таких способов - использование ключевых слов или слов действия для проекта тестового случая. Вы создаете свой тестовый шаг со словом действия, например, “Нажать Submit”, и в программном обеспечении автоматизации вы программируете все шаги, необходимые для нажатия кнопка Submit в SUT. Проблема состоит в том, что у вас есть еще много различных слов действия в вашем тестовом случае, из-за чего он может быть слишком сложным для автоматизации.
Возможный лучшим способом будет преобразование бизнес-процесса, который должен быть протестирован в отдельные шаги. Давайте вернемся к учетной записи, которую мы только создали. Для создания учетной записи потребовалось несколько шагов:
- Нажать ссылку Создать новую учетную запись (Create new account) на экране Home
- Заполнить и представить данные в экране Информация об учетной записи (My account information)
- Проверить создание новой учетной записи
После того, как шаги были определены, мы переводим их в логический бизнес поток (в большинстве случаев Happy Flow) и создаем их, например, в Microsoft Excel™ или Open Office Calc™. Я предпочитаю программы обработки крупноформатных таблиц, в которых можно получить общую картину по строкам и колонкам и которые также дают возможность производить манипуляции с данными, например, различные даты и т.п.
Последовательность состоит из различных шагов, а каждый шаг представляет экран или часть экрана с вводом, проверкой и действиями.
Например:
- Указать в поле Имя (Name) имя (First Name)
- Проверить значение по умолчанию в поле со списком Страна (Country)
- Нажать Продолжить (Continue)
После того, как мы установили эту вертикальную последовательность, вы увидите, что это легко читаемый и понятный способ установить ваши тестовые случаи. Этот тестовый случай может читаться тестировщиком, специалистом по автоматизации тестирования, а также и бизнес-пользователями. Это очень большое преимущество, потому что он может использоваться в качестве коммуникации со всеми вовлеченными сторонами или средой, мы можем запустить процесс автоматизации непосредственно в процессе тестирования. Благодаря программам для работы с электронными таблицами новые альтернативные последовательности могут быть разработаны очень быстро, таким образом можно достигнуть высокой степени покрытия.
Теперь, когда у нас есть этот универсальный способ создания тестовых случаев и осознание того, что все экраны одинаковы, независимо от технологии или среды, мы можем начинать сам процесс автоматизации.
Для автоматизации мы используем выбранный инструмент из-за его уникальной возможности управлять объектами в SUT. Таким образом, это может быть коммерческий многоплатформный инструмент, или бесплатный инструмент для автоматизации, или любой другой инструмент. Общий подход остается таким же.
Создание функций для взаимодействия широкого применения
Итак, давайте начнем автоматизировать тестовые случаи. Как указано ранее, экран – это экран, а кнопка – это кнопка. Помня это, вы можете начать определять свои первые универсальные функции взаимодействия, чтобы запустить фреймворк для автоматизации тестирования. Простые функции, которые могут нажать на кнопку или заполнить поле редактирования. Вы можете сделать это, с помощью записи или программирования (зависит от выбранного инструмента), единичных шагов “Нажать на кнопку Затем” (“Push Button Next”), и попытаться сделать из них функции широкого применения, таких как "Нажать кнопку (x)" (“Push Button(x)”). Где Кнопка (x) – любая кнопка, доступная в SUT.
Если сделать это для большинства объектов, доступных в SUT, будет создана библиотека со всеми типами таки функций для широкого использования, например,
- Нажать кнопку (x)
- Заполнить редактировать поле (x)
- Сделать выбор в поле для выбора (x), и так далее.
Конечно, вы должны выполнить все виды проверок на объектах, например, проверить страну по умолчанию, выбранную в поле со списком, при получении доступа к веб-странице. Для этого вы создаете ряд функций как указано выше, но теперь только в целях проверки.
Теперь вы можете автоматизировать тестирование всего экрана и проверить значения и т.д., но в чем следующая ловушка?
Взаимодействие с различными типами объектов
Прежде всего, вы должны понимать, как работают эти инструменты тестирования. При попытке взаимодействия с SUT, инструмент тестирования нуждается в технической информации об объекте, с которым он хочет взаимодействовать. Эта информация об управлении крайне важна для инструмента тестирования. Многие инструменты тестирования используют единую базу данных, для хранения этой информации, но я хочу хранить ее за пределами инструмента. Если мы храним эту информацию в пределах XML-файла (объектная карта), мы можем сохранить ее вне инструмента, в случае, когда что-то изменяется. Например, обслуживание может выполняться командой разработки, сотрудники которой знают лучше всего, какая техническая информация необходима, для управления объектом.
Итак, теперь у нас есть вся информация, необходимая для управления объектами в этом XML файле и универсальные функции взаимодействия, которым необходима эта информация также доступны. В самом фреймворке необходимо встроить функционал для чтения технической информации из XML файла и использовать его в функциях, которым необходима такая информация.
Функционал XML будет использоваться также для других частей фреймворка (это объясняется ниже).
Обработка ошибок и отчеты
Что, если имеет место неожиданное поведение, или объекты на вашем экране, изменились? Вам нужно построить адекватную обработку ошибок. Создание функций для обработки ошибок является важной частью вашего фреймворка для автоматизации тестирования
В этот момент давайте оглянемся назад на основную цель автоматизированного тестирования: “Автоматизация тестовых случаев”. Когда мы вручную выполняем тестовые случаи, которые мы только что создали, мы будем проверять их, и если что-то будет неправильным, мы зарегистрируем дефект. Однако, в случае автоматизированного выполнения тестов, тест может выполняться на системе на другом этаже, или даже в другой стране. Как мы узнаем об ошибках или дефектах. Мы нуждаемся в создании каких-то отчетов в этой сфере, таким образом, следующим необходимым шагом необходимо встроить функционал отчетности в ваш фреймворк автоматизации тестирования.
Скорее всего, вы захотите знать что произошло, на каком шаге, на котором экране и на каком объекте этого экрана. Я полагаю, что оптимальный вариант - создать функционал для создания отчетов, который хранил бы результаты в XML-файле для каждого выполняемого шага теста. Почему XML? Потому, что таким образом вы сможете импортировать его в большое количество разнообразных доступных инструментов и создать пользовательские отчеты.
Завершающие шаги
Итак, теперь почти все на месте для универсального фреймворка для автоматизации тестирования, который может вам помочь усовершенствовать автоматизированное регрессионное тестирование. Осталось сделать еще несколько вещей:
- перевести информацию, сохраненную в пределах вашего тестового случая в программе для работы с электронными таблицами во фреймворк для автоматизации тестирования;
- выполнить тестовый случай в пределах своего фреймворка автоматизации.
Следующий большой шаг: прочтение тестовых случаев из программы для работы с электронными таблицами, поскольку вся информация, необходимая вам для последовательности, которую вы хотите протестировать, находится в электронной таблице. Есть много способов выполнить это, например, создать файл, разделенный запятой, открыть текстовый поток в инструменте тестирования и читать линию за линией из файла. Однако, учитывая то, что мы используем XML для других частей фреймворка, почему бы не экспортировать электронную таблицу в XML-файл. Поскольку функционал для чтения из XML-файла уже создавался, теперь мы можем объединить тестовую информацию о шаге и управляющую информацию для экранов/объектов и т.д. во время выполнения.
Вот и настал момент, когда универсальный фреймворк для автоматизации тестирования был создан и готов к использованию.
Заключение
Можем ли мы избежать ловушек, которые упоминались ранее? Прежде всего, проблемы обслуживания. При использовании фреймворка, как описано в этой статье, вы можете уменьшить обслуживание, главным образом, потому что вам необходимо только идентифицировать новые или измененные экраны/объекты и добавлять или изменять техническую информацию в карте объектов.
Вторая ловушка, «мусор заложишь – мусор получишь». Благодаря способу создания тестовых случаев в электронной таблице, вы всегда будете получать тот же ввод для автоматизации тестирования. Это уменьшает количество «заложенного мусора», ведь таким образом существует меньше возможностей для ошибок или собственной интерпретации тестовых случаев. Но, орфографические ошибки или дефектные данные тестирования все еще являются зоной риска, потому что тестовые случаи хороши настолько, насколько хорош тестировщик, создающий их.
Ловушка номер три, недостаточность знаний и опыта. Эта часть очень важна, для выполнения задания необходим правильный человек и правильный инструмент. Квалифицированные специалисты по автоматизации тестирования просто жизненно необходимы, но следует также убедиться и в адекватности процесса выбора инструмента. Ваш фреймворк, зависит от обоих факторов в значительной степени.
Последняя ловушка – конечно же, это недостаточная структурированность процесса и фреймворка для автоматизации тестирования. Если вы примете во внимание факторы, упомянутые выше, и у вас есть знания, время и правильные инструменты, вы сможете создать структурированный процесс и фреймворк для автоматизации тестирования.
Теперь вы и ваша организация, занимающаяся тестированием, теперь готовы испытать все преимущества, которые может обеспечить качественная автоматизация тестирования, и при этом улучшить процесс регрессионного тестирования.