Home

Автор: Пол Меррил (Paul Merrill)

Оригинал статьи: https://techbeacon.com/5-ways-simplify-your-automated-test-cases

Перевод: Ольга Алифанова

Поддержка автотестов может занимать много времени, как и понимание отчетности по ним. К счастью, эти процессы можно ускорить.

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

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

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

Ниже представлена подборка докладов по автоматизированному тестированию со SQA Days 21, которая проходила в Москве в конце мая.

1. Ядро автоматизации под микро-сервисную архитектуру, Дмитрий Химион, Avito, Москва

2. Тестирование распределенных систем или Jepsen это совсем не сложно, Илья Сунцов, GridGain Systems, Санкт-Петербург

3. Тестирование REST-сервисов с применением инженерных практик, Илья Сизов, AlfaLab, Москва

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

Ниже представлена подборка докладов по автоматизированному тестированию со SQA Days 21, которая проходила в Москве в конце мая.

1. Kubernetes, Roman Krankus и Alexey Borisov, Lazada group, Москва

2. Selenium grid on-demand, Анатасия Асеева, Альфа-Лаборатория, Москва

3. Как тестирование погружалось в Docker, Roman Zhuravskiy, Lamoda, Москва

Автор: Команда нагрузочного тестирования компании "Инфосистемы Джет"

Оригинальная публикация: habrahabr.ru/company/jetinfosystems/blog/329014/?utm_source=software-testing

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

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

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

В чем плюсы и минусы определенных инструментов? Каковы их функциональные возможности и способы применения?

Об этом в подборке докладов по автоматизированному тестированию со SQA Days 21, которая проходила в Москве в конце мая.

1. Автоматизация UI тестирования в неконтролируемо улучшаемой внешней среде, Denis Markovtsev, Inflectra Corporation, Москва

2. Let's Talk About Junit 5, Артем Соковец, АО Сбербанк-Технологии, Санкт-Петербург

3. WPF Automation – внедрение теста в тестируемое приложение, Владимир Перевалов, Технологический Центр Дойче Банка, Москва

4. BDD girls Battle: Cucumber VS. JBehave, Юлия Ковалева, Альфа-Лаборатория, Москва; Анна Чернышева, Аплана, Москва

Оригинальная публикация: https://www.testingexcellence.com/test-automation-strategy-for-agile-projects/

Перевод статьи: https://tproger.ru/translations/test-automation-strategy-for-agile-projects/

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

Описанная в этой статье стратегия автоматизации тестирования предполагает модель постоянной поставки с несколькими командами, работающими по методологии Agile.

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

Автор: Сергей Морет (Serghei Moret)

Оригинал статьи: http://www.waysoftesting.com/2017/06/05/often-run-automation/

Перевод: Ольга Алифанова

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

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

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

Об этом и многом другом в подборке докладов по автоматизированному тестированию со SQA Days 21, которая проходила в Москве в конце мая.

1. Внедрение автоматизации тестирования на Сервисной Шине, Никита Иванов, АКБ «РосЕвроБанк» (АО), Москва

2. Автоматизация тестирования приёмников цифрового телевидения, Александр Иванов, ООО «Цифра»(GS group), Санкт-Петербург

3. Первый шаг на пути к тестированию белого ящика для сложных систем, Аркадий Дементьев, АО «Сбербанк-Технологии», Новосибирск

4. Автоматизированное тестирование - от сложного к простому, или Запускаем автотесты из браузера, Александр Зуев, BPC Group, Москва

5. Автоматизация тестирования: взгляд в будущее, Антон Семенченко, COMAQA.by; CoreHard.by; DPI.Solutions; EPAM, Минск

Автор: Сергей Жирков, senior frontend developer, Algoritmika.org

Оригинальная публикация: https://habrahabr.ru/post/329660/

Представьте: вы работник стартапа, сварганили по-быстрому прототип и постепенно начинаете его развивать. И вот вам уже хочется, чтобы во время очередного спешного релиза не приходилось перепроверять все разделы сайта вручную (руками директора по продукту). Конечно, можно нанять отдельного тестировщика, но на это в вашем LEAN-стартапе бюджета не дают — «лучше давайте купим наконец-то кофе-машину». Знакомо?

И тут кто-то произносит слово «автотесты».

И сразу начинается: это целая история, это очень сложно, это очень дорого, от этого будет больше вреда, чем пользы и вообще это кровавый Enterprise и СЕЛЕНИУМ.

А вам всего-то надо, чтобы какая-то программа открывала браузер и там тыкала ссылки, вбивала тексты и смотрела, что получится. Неужели это так сложно и дорого?

Теперь можно с уверенностью сказать: нет.

Оригинал статьи: http://katrinatester.blogspot.ru/2017/07/test-automation-canvas.html

Автор: Катрина Клоки (Katrina Clokie)

Перевод: Ольга Алифанова

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

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

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