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

Общепринятой практикой в индустрии является использование тест кейсов в качестве основы для автоматизации тестирования. QA инженеры разрабатывают их на основе user stories в рамках обычного тестирования, а затем автоматизируют эти тесты. С каждой итерацией тестируется больше историй, автоматизируется больше тестовых случаев, и набор автоматических тестов становится всё больше. Руководители продвигают такие метрики, как, например, «процент покрытия» и хвалят команды с высокими показателями. Некоторые компании даже специально нанимают «инженеров по автоматизации», чья единственная работа состоит в том, чтобы брать тест кейсы и автоматизировать их.

К сожалению, автоматизация тест кейсов и навязывание «процента покрытия» — это антипаттерн обеспечения качества, который неизбежно приводит к раздутым и сложным в обслуживании наборам тестов, которые приносят мало пользы. Хотя автоматизация имеет решающее значение для agile delivery, этот чрезмерно упрощенный подход «фабрики автоматизации» не является хорошим способом автоматизации тестирования.

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

Издержки и преимущества автоматизации тестирования

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

Всем привет! Меня зовут Сергей, и сегодня я расскажу о том, как я искал носки мы выстраивали процессы тестирования в команде.

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

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

Внедрение автоматизированных тестов, которые тестируют всё приложение, является сложной задачей. От выбора уровней для проверки (API, UI или оба) до управления тестовыми данными и подбора подходящей библиотеки для работы. Основываясь на своем опыте, я подготовил руководство по внедрению автоматизации в ваш проект.

В эпоху вселенского внедрения agile-методологий и Devops уже никто не сомневается в том, что регрессия должна быть автоматизирована. Особенно, если в компании идет речь о Continuous Delivery. Все кинулись хантить разработчиков автотестов, от чего рынок становится перегретым.

В этой статье я расскажу о том, что на самом деле разработчик автотестов — не такая уж и важная роль в команде. Они не нужны, особенно если вы внедряете у себя scrum. И все эти agile-ы и devops-ы можно внедрять и без этих людей. Так что если кто-нибудь вам скажет, что у них в команде все тестируют руками — потому что у них по каким-либо причинам нет разработчика автотестов — не верьте им. Они тестируют руками, потому что по-другому им лень. Или не умеют.

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

При построении автоматизации функционального тестирования (АФТ) в разных командах, проектах, компаниях могут возникать одни и те же проблемы, универсального решения которых не существует. Я, Василий Соколов, руководитель направления разработки ИТ-решений ДОМ.РФ, расскажу, как мы два года назад начали строить АФТ и каких результатов удалось достичь.

Меня зовут Владислав Романенко, я Senior iOS QA Engineer в Badoo и Bumble. Мы регулярно внедряем новые фичи в приложения, и автоматизация тестирования — один из способов не пропустить баги. Фактически автотесты входят в жизненный цикл всех частей наших приложений: бэкенда, сервисов, фронтенда и мобильных клиентов. Чем раньше мы обнаружим ошибку, тем дешевле будет её исправить. 

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

Привет, Хабр! Меня зовут Антон Шкредов, я QA Lead в SuperJob. В День тестировщика хочу поделиться историей о том, как около четырех лет назад мы с командой перешли от ручного тестирования к автоматизации UI и какой профит в итоге получили. Внутри подробности про усталость от ручных тестов, с чего начали автоматизацию, какие инструменты использовали, а также про сложности и бонусы от внедрения.

Одной из самых дорогих по времени операций на CI-сервере является прогон автотестов. Есть множество способов их ускорения, например, распараллеливание выполнения по нескольким CI-агентам и/или эмуляторам, полная эмуляция внешнего окружения(backend/сервисы Google/вебсокеты), тонкая настройка эмуляторов(Отключение анимации/ Headless-сборки / отключение снепшотов) и так далее. Сегодня поговорим про импакт-анализ или запуск только тех тестов, которые связаны с последними изменениями в коде. Расскажу какие шаги нужны для импакт-анализа и как мы реализовали это в нашем проекте.