Для чего необходима автоматизация доу тест

Обновлено: 07.07.2024

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

Последовательные циклы разработки, особенно в крупных компаниях (Google, Facebook, Альфа-Банк, Газпром нефть и т.д.) потребуют многократного выполнения одного и того же набора тестов. Используя инструмент автоматизации тестирования, можно записать этот набор тестов и при необходимости воспроизвести его. После автоматизации набора тестов вмешательство человека не требуется. Это улучшило ROI автоматизации тестирования. Цель автоматизации – уменьшить количество тестовых примеров, которые нужно запускать вручную, а не полностью исключить ручное тестирование.

  • Зачем нужна автоматизация?
  • Какие тестовые случаи стоит автоматизировать?
  • Процесс автоматизированного тестирования
  • Выбор инструмента тестирования
  • Определяем объем автоматизации
  • Планирование, проектирование и разработка
  • Выполнение теста
  • Обслуживание автоматизированного тестирования
  • Платформа для автоматизации
  • Рекомендации для эффективной автоматизации тестирования
  • Преимущества автоматизации тестирования
  • Типы автоматизированного тестирования
  • Как выбрать инструмент автоматизации?
  • Инструменты автоматизации тестирования

  • Ручное тестирование всех рабочих процессов, полей и негативных сценариев требует больше времени и денег (при определенных условиях).
  • Сложно тестировать многоязычные сайты вручную.
  • Не требует вмешательства человека. Запускаете и переходите к другим задачам.
  • Увеличивает скорость выполнения тестов.
  • Помогает увеличить охват тестированием.
  • Ручное тестирование может наскучить, и следствиями станут потеря вовлеченности и появление ошибок.

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

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

В процессе автоматизации выполняются следующие шаги:

Выбор инструмента тестирования

Выбор средства тестирования во многом зависит от технологии, на которой построено тестируемое приложение. Например , QTP не поддерживает Informatica. Таким образом, QTP нельзя использовать для тестирования приложений Informatica . Хорошая идея – провести Proof of Concept of Tool (демонстрация практической осуществимости) на AUT.

Определяем объем автоматизации

  • Функции, важные для бизнеса
  • Сценарии с большим объемом данных
  • Общие функции приложений
  • Техническая осуществимость
  • Частота повторного использования бизнес-компонентов
  • Сложность тестовых случаев
  • Возможность использовать одни и те же тестовые сценарии для кросс-браузерного тестирования

На этом этапе выполняются сценарии автоматизации. Сценариям необходимо ввести тестовые данные, прежде чем они будут запущены. После выполнения они предоставляют подробные отчеты об испытаниях.

Выполнение может быть выполнено с использованием инструмента автоматизации напрямую или с помощью инструмента управления тестированием, который вызовет инструмент автоматизации.

Пример: Центр качества – это инструмент управления тестированием, который, в свою очередь, вызывает QTP для выполнения сценариев автоматизации. Скрипты могут выполняться на одной машине или на группе машин. Для экономии времени тестирование можно проводить ночью.

Обслуживание автоматизированного тестирования

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

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

  1. платформа автоматизации на основе данных;
  2. фреймворк автоматизации на основе ключевых слов;
  3. модульная платформа автоматизации;
  4. гибридная среда автоматизации.
  • Объем автоматизации необходимо детально определить до начала проекта. Это позволит убедиться, что ожидания от автоматизации будут оправданы.
  • Определите правильный инструмент автоматизации: инструмент не должен выбираться на основании его популярности, он должен соответствовать требованиям автоматизации на конкретном проекте.
  • Выберите подходящий фреймворк.
  • Стандарты создания сценариев. При написании сценариев для автоматизации необходимо соблюдать стандарты. Вот некоторые из них:
    • cоздайте единые скрипты, комментарии и отступы кода;
    • разработайте правила наименования тестовых сценариев;
    • прикладывайте необходимые документы, если, например, сложно понять прохождение тестового сценария без скриншота и/или спецификации.

    Преимущества автоматизации тестирования

    • На 70% быстрее, чем при ручном тестировании.
    • Более широкий тестовый охват функций приложения.
    • Надежные в результаты.
    • Обеспечивает согласованность тестовых моделей.
    • Экономит время и деньги.
    • Повышает точность.
    • Позволяет исполнять процесс тестирования без вмешательства человека.
    • Повышает эффективность .
    • увеличивает скорость исполнения тестирования.
    • Повторно использует тестовые скрипты.
    • Позволяет тестировать часто и тщательно.
    • Больший цикл выполнения может быть достигнут за счет автоматизации.
    • Сокращает время выхода продукта на рынок
    • Смоук тестирование
    • Модульное тестирование
    • Интеграционное тестирование
    • Функциональное тестирование
    • Проверка ключевых слов
    • Регрессионное тестирование
    • Тестирование на основе данных
    • Тестирование черного ящика
    • поддержка окружающей среды;
    • легкость использования;
    • тестирование базы данных;
    • идентификация объекта;
    • тестирование изображений;
    • тестирование восстановления после ошибок;
    • отображение объектов;
    • используемый язык сценариев;
    • поддержка различных типов тестирования, в том числе функционального, тестового управления, мобильного и т. д.;
    • поддержка нескольких фреймворков тестирования;
    • легко отлаживать сценарии программного обеспечения автоматизации;
    • умение распознавать предметы в любой среде;
    • обширные отчеты об испытаниях и их результаты;
    • минимизация затрат на обучение выбранным инструментам.

    Инструменты автоматизации тестирования

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

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

    • Функциональный пользовательский интерфейс и сквозное тестирование на ПК, в Интернете и на мобильных устройствах
    • Кроссбраузерное тестирование
    • SAP, ERP, Delphi и унаследованные приложения.
    • iOS и Android
    • Запускайте тесты локально или удаленно, параллельно или распределяйте в Selenium Grid
    • Надежная отчетность

    «Самый быстрый путь к отказоустойчивым сквозным тестам – без кода, с кодированием или и тем, и другим. Testim позволяет создавать удивительно стабильные тесты без кода, которые используют наш ИИ, а также гибкость для экспорта тестов в виде кода. Такие клиенты, как Microsoft, NetApp, Wix и JFrog, ежемесячно проводят миллионы тестов на Testim.

    Это инструмент тестирования программного обеспечения, используемый для регрессионного тестирования. Это инструмент тестирования с открытым исходным кодом, который предоставляет возможность воспроизведения и записи для регрессионного тестирования. Селен IDE поддерживает только Mozilla Firefox веб – браузер.

    Это объектно-ориентированный инструмент автоматизированного функционального тестирования , способный выполнять автоматическое функциональное, регрессионное тестирование, тестирование на основе данных и тестирование графического интерфейса. Основные особенности этого инструмента:

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

    Silk Test предназначен для выполнения функционального и регрессионного тестирования. Для приложений электронного бизнеса шелковый тест является ведущим продуктом для функционального тестирования. Это продукт поглощения Segue Software компанией Borland в 2006 году. Это объектно-ориентированный язык, как и C ++. Он использует концепцию объекта, классов и наследования. Его основная особенность включает

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

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

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


    Зачем тестировать

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

    Дорогостоящие ошибки бывают и в других отраслях, казалось бы, не связанных напрямую с IT. Известный пример – аварии при запуске космической техники, в частности, в 2017 году Роскосмос утратил спутник стоимостью 2,6 млрд рублей.

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

    При создании IT-продуктов для бизнеса обычно сочетают два подхода:

    • осуществляют проверки вручную, с помощью специалистов QA (Quality Assurance);
    • комбинируют ручное тестирование и автоматизацию ключевых тест-кейсов, с помощью экспертов SDET (Software Development Engineer in Test).

    Что дает автоматизация

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

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

    Когда автоматизация обязательна

    • Масштабное приложение с большим количеством бизнес-функций
    • Значительный срок жизни приложения (от 1 года и более)
    • Внедрение CI/CD, регулярные релизы + небольшое количество QA специалистов

    Задачи автоматизации

    Как правило, мы привлекаем экспертов SDET для решения следующих задач:

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

    Результаты

    Автоматизация помогает выстроить баланс:

    • проверять вручную то, что требует человеческого внимания (как правило, до 25% кейсов);
    • автоматизировать остальные кейсы.

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

    Бизнес, благодаря автоматизации, получает возможность в любое время убедиться в том, что ключевые функции системы работают правильно и проверить, нет ли ошибок (а если они есть, то в чем заключаются).

    Пример

    Предположим, что на текущий момент в мобильном банке нужно проходить до 700 кейсов, каждый – от 70 до 100 раз в год. Ручной проверки требуют менее 25% кейсов, остальные 75% можно автоматизировать.

    Затраты времени при ручной проверке:

    Затраты времени при автоматизации:

    Ночной прогон тестов занимает 8 часов, но без участия человека, поэтому не учитывается.

    Прочие затраты времени:

    • 8 часов на ручную проверку кейсов, которые нельзя покрыть автотестами (25%);
    • 6 часов на анализ результатов, а также, если необходимо, на проверку отказов (до 10% тестов).

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

    В среднем, автоматизация экономит от 30 до 50% времени как минимум, позволяя выделить больше времени, например, на развитие и улучшение продукта.

    Как происходит автоматизация тестирования

    У каждой IT-компании есть свои особенности в автоматизации тестирования, как и в других рабочих процессах. Мы в SimbirSoft придерживаемся следующих методов, которые помогают оперативно выстроить работу с проектами наших клиентов.

    Процесс тестирования начинается с разработки стратегии – тест-плана, основы для составления отдельных тест-кейсов. Для автоматизации SDET инженеры выбирают ключевые, часто используемые сценарии работы пользователя с продуктом – такие сценарии дают около 80% бизнес-ценности.

    После этого мы создаем основу для дальнейших автотестов, настраиваем стенды и workflow по работе с ними, CI для регулярного запуска тестов на различных ветках. Мы выбираем, какие подходы к подготовке тестовых данных мы будем использовать (API, доступ к базам данных, генерация синтетических данных, использование данных с прода). Инженеры SDET пишут тесты, которые покрывают ключевые сценарии работы с продуктом, анализируют полученные результаты и необходимость дальнейшей автоматизации.

    Мы разрабатываем автоматизированные тесты, используя все наиболее востребованные языки программирования – Java, Python, Kotlin и др. Наши основные инструменты и технологии – Appium, TestNG | JUnit, RobotFramework | Pytest, Selenium | Senenide, Allure, TeamCity, Jenkins, JMeter.

    Какие тесты нужно автоматизировать в первую очередь – зависит от особенностей конкретного продукта. Большинство компаний автоматизируют smoke тесты, регрессионные тесты для проверки уже готовых функциональностей, а также кейсы для проверки различных параметров (например, валидных и невалидных данных при регистрации).

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

    Подводя итоги

    Баланс ручного и автоматизированного тестирования позволяет постоянно контролировать качество IT-продукта. Некоторые проекты проверяют вручную, другие задачи можно успешнее решить с помощью автоматизации. Тестирование вручную используют в тех случаях, когда люди незаменимы, например, если нужна локализация, описание ошибок, ручная проверка юзабилити. В небольших проектах часто тесты пишут сами разработчики.

    Ручное тестирование в комплексе с автоматизацией проводят при создании крупных IT-продуктов, где работает несколько команд (например, в банковских приложениях), где есть сложные алгоритмы и бизнес-логика. Этот метод помогает выстроить процессы тестирования продукта и снизить риск дорогостоящих ошибок, что бывает особенно важно при работе в условиях жесткого графика релизов.


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

    Быть или не быть

    Вам гарантированно нужна автоматизация тестирования, если:

    Если ваш проект не такой, то вам скорее всего не надо забивать голову мыслями про автоматизацию.

    Зачем вообще нужны авто-тесты

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

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

    Почему ожидания не оправдываются

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

    Управленческие решения — это тема для отдельной статьи, а пока я просто выделю самые вредные ошибки без объяснений:

    Под инженерными решениями я понимаю те решения, которые принимают инженеры при разработке и внедрении стратегии автоматизации. Это выбор инструментов, видов тестирования, фреймворков и т.п.

    Пройдемся по некоторым моментам с инженерной точки зрения.

    Почему автоматизация только UI-тестов — зло

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

    UI-тесты — это то, что делают тестировщики, это естественный путь тестирования приложения. Более того, это симуляция того, как пользователи будут взаимодействовать с приложением. Казалось бы, это идеальный и единственно верный вариант, и именно его надо применять в автоматизации в первую очередь. Но есть, как говорится, нюанс:
    — UI-тесты нестабильны;
    — UI-тесты медленные.

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

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

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

    Что же делать

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

    Первое, что нужно в общем случае — это договориться с разработчиками, чтобы они не забывали прописывать для элементов уникальные атрибуты, по которым инструмент автоматизации может их однозначно идентифицировать. То есть, нужно по максимуму отказаться от пятиэтажных xPath-выражений или CSS-селекторов, и, по возможности, везде использовать уникальные id, name и т.п. Это должно быть явно прописано в девелопмент-гайдах и выступать одним из пунктов в definition of done для разработчиков. Тогда даже в случае капитального переколбаса пользовательского интерфейса у вас есть шанс отделаться легким испугом.

    В ответ можно услышать отмазку, что это оверхед для разработчиков. Возможно так и есть, но им это нужно сделать всего раз и забыть навсегда. Для автоматизаторов же это реальная экономия сотен часов времени.

    Тестируемое приложение должно давать возможность себя протестировать. Если такой возможности нет, то приложение нужно либо модифицировать, либо выбросить.

    Кроме того, не лишним будет, научить инструмент автоматизации грамотно ждать момента, когда элемент становится доступным для взаимодействия или изначально использовать что-то типа Selenide, где такой проблемы нет by design.

    Ускоряемся. Если с нестабильностью всё достаточно просто, то проблема медленных тестов должна решаться комплексно, так как она влияет на процесс разработки в целом.

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

    Третье и самое радикальное — создавать как можно меньше UI-тестов. Меньше тестов — раньше получаем результат их прогона.

    Пирамида тестирования

    Все помнят знаменитую пирамиду тестирования?


    Если под маленькую пирамиду на ночь положить тупую бритву, то к утру она снова станет острой ©.

    Пирамида — это очень удобная метафора, она наглядно показывает желаемое количество автоматизированных тестов относительно каждого из уровней архитектуры системы. Должно быть много низкоуровневых юнит-тестов и совсем мало высокоуровневых UI-тестов. Вопрос в том, почему именно так и почему все так носятся с этой пирамидой?

    Тут всё просто. Вспомним, как обычно выглядит процесс нахождения и исправления проблемы в приложении, когда его тестируют вручную. Сначала разработчик вносит новые изменения в код. Тестировщик ждет сборку и деплой нового билда на тестовый стенд. Тестировщик проводит тестирование, находит проблему и заводит тикет в баг-трекинговой системе. Разработчик моментально реагирует на этот тикет и исправляет проблему. Это новые изменения в код, и потом снова билд, деплой, ретест. Если всё ок — тикет закрывается. Время от выявления проблемы до ее исправления составляет от нескольких часов до нескольких суток или даже недель.

    Что происходит, когда тот же тест автоматизирован через UI? Всё так же надо ждать, пока соберется и задеплоится новая версия, потом ждать, пока завершатся тесты. Потом надо проанализировать результаты прогона. Если были проблемы — определить, где эти проблемы возникли: в самом тесте или в приложении. Потом нужно еще раз прогнать упавший тест руками, чтобы наверняка понять, в чем проблема. Завести тикет, подождать пока пофиксят, перезапустить тест, убедиться, что теперь тест зеленый, закрыть тикет. Опять же — от пары часов до пары дней/недель. Плюс только в том, что этот тест автоматический, и пока он работает, тестировщик тестирует что-то другое.

    Другая история, когда есть автоматизированные тесты, которые используют API для общения с бек-эндом приложения. Тут уже есть вкусные варианты:

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

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

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

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

    Комплексный подход

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

    UI-тесты же тестируют целостную систему, именно то, что будет использовать пользователь. Критически важно иметь такие тесты в наличии.

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

    Test Driven Development — это уже даже не рекомендация, это должно исходить от разработчика по умолчанию. Только тогда можно избежать головняков при рефакторинге и типичных проблем разработки в больших командах.

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

    На уровень UI-тестов выносятся исключительно приемочные тесты, так называемые Happy Path или End-To-End сценарии, которые показываются во время демо. Это относится как к веб-, так и к мобильным приложениям.

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

    Резюме

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

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

    Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно. І підписуйтеся на Telegram-канал редакції DOU

    Управленческая документация является основой деятельности современной организации — в документах сосредоточивается до 85% информационных ресурсов практически любой структуры управления. В связи с этим процессы документирования и документооборота приобрели самодовлеющий характер и требуют собственных автоматизированных систем управления.

    За последние 10-15 лет офисная автоматизация пережила революцию в области работы с документами. Если раньше система автоматизации делопроизводства рассматривалась как система автоматизации деятельности преимущественно технического персонала канцелярий, секретариатов, архивов, связанной с подготовкой, регистрацией, перемещением, контролем исполнения и поиском документов, то теперь составлением и пересылкой документов с помощью ПК, объединенных в сети, занимаются сами авторы и исполнители документов. Они теперь являются непосредственными участниками технологий документационного обеспечения — с момента создания документов до контроля исполнения и работы с документным архивом. Система автоматизации документирования и документооборота стала решающим инструментом повышения эффективности труда сотрудников, участвующих в принятии решений, и, соответственно, деятельности организации в целом.

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

    Организациям, поставившим перед собой цель автоматизировать делопроизводство, приходится решать ряд проблем. Приведем некоторые из них:

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

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

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

    При выборе варианта автоматизации ДОУ организация-заказчик должна сделать выбор между двумя классами систем управления документами - Workflowи Groupware.

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

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

    К типу Groupware относятся системы, в которых отсутствует жестко заданная схемабизнес-процессов и которые предназначены для функционирования в небольшом коллективе — рабочей группе (5—100 чел.). Элементами Groupware являются электронная почта, база документов, коллективный органайзер.

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

    - используемые технологии делопроизводства;

    - соответствие основным задачам делопроизводства;

    - функциональные характеристики систем (функциональная полнота, открытость и др.);

    - программная реализация (поддержка распределенного режима и др.);

    Выше были кратко охарактеризованы технологии делопроизводства, базирующиеся на российской и западной традициях. Коснемся далее кратко характеристик программных систем соответствующего направления.

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

    - система «Золушка-\\'1!\и. Служебная корреспонденция (НТЦ ИРМ, Москва).

    В подпункте 7.8.4 будут подробнее представлены функциональные возможности систем ДЕЛО.

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

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

    К системам данного направления в Российской Федерации широко представлены следующие три класса автоматизированных информационных систем:

    Читайте также: