Стратегия Автоматизации Тестирования Для Agile-проектов

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

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

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

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

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

Пирамида Автоматизированного Тестирования

Чаще всего работа с ними организована через использование API запросов. Например, для API с типами запросов POST, GET, PUT и DELETE мы можем написать автотесты на проверку каждого типа запросов. Причем наши тесты будут проверять как позитивные, так и негативные типы сценариев, при которых некорректный запрос возвращает соответствующий код ошибки.

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

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

• Низкий показатель ошибок после релиза – красноречивая демонстрация того, насколько сплоченно и качественно трудилась над проектом группа QA специалистов, а также это показатель эффективности взаимодействия отдела контроля качества и отдела разработки.
• Чтобы протестировать приложение в целом, обычно требуется интерфейс для взаимодействия между различными его компонентами, а значит, тестирование лучше проводить с использованием браузера или GUI.
• В случае с интеграционными тестами редко когда требуется наличие UI, чтобы его проверить.
• API — это интерфейс, который позволяет общаться напрямую с программой, минуя пользовательский интерфейс.
• Внедрение процесса автоматизации в проект должно учитывать наиболее распространенные метрики, выбранные как базовые измерители качества проверки (к примеру, число ручных проверок по отношению к запрограммированным тестам системы).

Например, если есть требование к системе, что GET-запрос никогда не должен занимать дольше двух секунд, то при превышении этого ограничения автотест вернет ошибку. Время загрузки web-интерфейса также можно измерять с помощью тестов производительности. Стратегия автоматизации также позволяет понять, получает ли компания пользу от использования подобной формы тестирования и есть ли смысл развивать это направление в дальнейшем. В прошлом году в компании ввели новую инициативу — “Focus Fridays”.

Минусы Автоматизации Тестирования:

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

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

Например, вместо того, чтобы зайти на сайт, выбрать нужный товар и положить его в корзину, автотесты могут напрямую сказать сайту, отправив запрос “положи товар в корзину”. Например, чтобы протестировать работу формы авторизации, мы сами заходим на сайт и вручную заполняем поля «Имя» и «Пароль». https://deveducation.com/ Предлагая более 20 видов услуг тестирования, мы в состоянии охватить абсолютно все потребности в тестировании. Подобная метрика являет собой актуальное соотношение числа багов, найденных после релиза, к числу ошибок, которые были обнаружены во время непосредственной процедуры тестирования.

Рекомендации Для Эффективной Автоматизации

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

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

В ходе разработки новой фичи мы обсуждаем и проверяем тесты со всех уровней. Этот процесс предваряет фазу активной разработки и подразумевает создание «набросков» предполагаемых тестов. На проекте есть какое-то количество модульных тестов, может быть, даже есть какой-то объём интеграционных тестов, но нет или мало системных тестов. Либо есть, но они слабо формализованные (только в голове ведущего разработчика или руководителя команды).

Как члену команды, вам важно понимать приложения и внутреннюю работу вашей команды при подготовке вашей стратегии автоматизации. Пирамида автоматизации тестирования Майка Кона помогла многим командам с начала 2000-х годов.С тех пор мы немного подкорректировали её, чтобы уточнить наши цели, добавили облако сверху, чтобы показать, что не все регрессионные тесты можно автоматизировать. Иногда нам нужны тесты, ориентированные на человека, которые включают в себя исследовательские тесты (ИТ – exploratory tests).Мы рассматриваем их как инструмент размышлений, который поможет командам создать эффективную стратегию автоматизации тестирования. Внедрение пирамиды тестирования — это итеративный и динамический процесс, который требует внимания к деталям и готовности к адаптации. При правильном подходе это может значительно повысить эффективность процесса разработки и качество конечного продукта. В рамках стратегии автоматизации тестирования нам необходимо минимизировать количество автоматизированных тестов на уровне GUI.

Это приводит не только к неправильному распределению тестов по уровням пирамиды (потому что некоторые сценарии автоматизируются на нескольких разных уровнях), но ещё и к дублированию действий. Некоторые ошибки регрессии возникают только при наличии двух или более уровней приложения. Для этого могут потребоваться тестирование приложения через пользовательский интерфейс, которые включают сервер, базу данных и/или внешнюю систему. В большинстве случаев лучше минимизировать количество end-to-end тестов. Эти тесты проводятся медленно, часто являются наиболее хрупкими и обычно требуют наибольшего обслуживания.

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

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

Вполне может случиться так, что однажды после переработки сквозной сценарий попадёт в набор тестов визуальной регрессии. Сегодня я расскажу об автоматизации тестирования в iOS, потому что на протяжении всей своей карьеры в Badoo я плотно занимался тестированием наших нативных iOS-приложений, которые написаны на Objective-C и Swift. Хотя кое-где я буду упоминать характерные для iOS инструменты и термины (например, XCTest), общие принципы и подходы универсальны.

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