Home

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

Об этом в подборке докладов по автоматизированному тестированию со 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-командам, работающим над одним и тем же набором продуктов. Они регулярно встречались для обмена идеями, но их автотесты начали сильно различаться. Все тестировщики учились в основном независимо друг от друга.

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

Оригинал публикации: 

http://bytextest.ru/2017/06/20/autotest-vs-reality/#more-5727

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

Ожидание №1: Можно тратить время на изучение фреймворка и тест-кейсов при автоматизации нового приложения.

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

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

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

"Конечно отдельная!", — ответит большая часть читающих. Такой ответ укладывается в их картину мира, потому что “так работали всегда”.

Так работали всегда

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

Компания понимает, что обойтись без страховочной сети нельзя, поэтому создается QA-отдел, который обычно не обеспечивает качество продукта, а лишь контролирует его. С QA-отделом разработчик может спокойно заниматься любимым делом — писать код, ведь ответственность за качество теперь несет выделенный отдел! Происходит классическое “перебрасывание кода через стену” в отдел тестирования:

Нажмите на картинку, чтобы увеличить изображение

Оригинальная публикация: https://habrahabr.ru/company/jugru/blog/329372/

Тестирование программного кода — кропотливый и сложный процесс. Львиную долю работы в нем совершают unit-тесты. Пока они не «загорятся зеленым», тестировать дальше смысла нет. 

Как же писать unit-тесты правильно? Стоит ли гнаться за 100% покрытием? С какими сложностями приходится сталкиваться инженерам на практике? Своим опытом делятся Marc Philipp и Всеволод Брекелов. 

Marc Philipp – один из основных разработчиков фреймворка JUnit 5 – инструмента для Java-тестировщиков. В данный момент работает в качестве инженера в немецкой компании LogMeIn над облачными SaaS-решениями.

Всеволод Брекелов — Senior QA Engineer в компании Grid Dynamics, более 5 лет занимается тестированием, имеет опыт построения автоматизации тестирования с нуля.

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

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

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

На протяжении прошлой недели я работал с простым, но мощным софтом — Katalon Studio. Он вмещает в себя UI возможности, которых мне так не хватает в Selenium WebDriver и гибкость, которой не может похвастаться UFT. И да, он абсолютно бесплатный.

=> Если вам интересно узнать больше, мы уже сделали один обзор этого бесплатного инструмента: Katalon Studio review.