Автор: Никита Филонов
Оригинальная публикация

Вступление

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

Сразу хочу подчеркнуть: в этой статье мы будем говорить исключительно о концепции процесса, а не о технической реализации. Здесь не будет примеров кода, конфигураций CI/CD, или привязки к конкретным инструментам и фреймворкам. Цель статьи — описать качественную архитектуру процесса автоматизации, которая может быть адаптирована под любой технологический стек.

Ведь в каждой компании свои инструменты, процессы, команды и особенности CI/CD. Универсального "рецепта" не существует — но существует направление движения и принципы, к которым стоит стремиться. Если же вас интересуют технические детали, реализация автотестов или настройка пайплайнов, рекомендую ознакомиться с другими моими статьями:

• API автотесты на Python с запуском на CI/CD и Allure отчетом

• UI автотесты на Python с запуском на CI/CD и Allure отчетом. PageObject, PageComponent, PageFactory

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

Автор: Томаш Балог (Tamás Balog)
Оригинал статьи
Перевод: Ольга Алифанова

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

В ходе моей карьеры значительная часть моей тест-автоматизации включала применение какого-либо BDD-фреймворка – например, инструменты вроде Cucumber или JBehave. Как человек, который программирует, я всегда интересовался рефакторингом, сокращающим количество стандартного или дублирующего кода – кода становится меньше, и он становится понятнее. Это включает и сокращение стандартного кода в методах определения шагов и прочем связующем коде. Как их упростить? Или вообще от них избавиться?

Автор: Сарит Вакрат (Sarit Vakrat)
Оригинал статьи
Перевод: Ольга Алифанова

Javascript – прекрасный язык программирования: он легок, быстр, и располагает ресурсами для решения практически любых приходящих в голову вопросов. Он профессионально управляется с бэкендом через Node.js. Однако если в вашем javascript-коде попался баг, дебаг может сильно выматывать и раздражать, а иногда это глупые, легко предотвратимые баги.

TypeScript пользуется всеми преимуществами JavaScript и NodeJS и усиливает их – он поможет писать код, который легче читать и проще поддерживать. У него статическая типизация, классы, интерфейсы, типы, декораторы и поддержка IDE в режиме реального времени вроде Visual Studio Code.

Автор: Сарит Вакрат (Sarit Vakrat)
Оригинал статьи
Перевод: Ольга Алифанова

В динамическом мире разработки ПО очень важна способность эффективно масштабировать и оптимизировать процессы. Работая над улучшением инфраструктуры нашей автоматизации в Glassbox, мы пришли к применению возможностей DevOps, Groovy, скриптов DSL и AWS EC2 Jenkins-агентов. Эта комбинация позволила создать масштабируемую и устойчивую систему, способную на запуск более чем 1000 задач в день, что дает нам высокую производительность и надежность.

Автор: Игорь Авдонин

С момента своего появления и по сей день подход Test-Driven Development (TDD) вызывает оживленные дискуссии в сообществе разработчиков, и до сих пор нет единого мнения о ее эффективности.

Но что будет, если совместить TDD и AI-генерацию кода? В статье я покажу:

• Как соединить TDD и AI;

• Как AI-driven TDD улучшает процесс разработки;

• Как TDD влияет на качество сгенерированного AI кода.

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

Кратко о TDD

Разработка через тестирование (Test-Driven Development, TDD) — это методология программирования, при которой тесты пишутся до написания кода. Процесс строится на коротких итерациях: сначала создается тест, затем реализуется минимальный код для его прохождения, после чего код рефакторится. Утверждается, что такой подход помогает создавать надежное и поддерживаемое программное обеспечение, снижая вероятность ошибок и улучшая архитектуру кода.

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

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

Автор: Валентин Агапитов (Valentin Agapitov)
Оригинал статьи
Перевод: Ольга Алифанова

Всем привет. Хочу рассказать об отличных способах применения ИИ в вашей IDE.

Сейчас диалоговые ИИ вроде ChatGPT напрямую встраиваются в наиболее популярные IDE – например, в Visual Studio Code, Visual Code, и семейство IDE от JetBrains.

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

Автор: Штефан Дирнштофер (Stefan Dirnstorfer)
Оригинал статьи
Перевод: Ольга Алифанова

Представьте на минутку, что вы тест-робот, задача которого – тщательно следовать тест-скрипту. Ваша ключевая проблема – это выполнить текстовую инструкцию в графическом интерфейсе пользователя. Если вы тестируете веб-приложения, то ваши инструкции могут выглядеть, как строка CSS – нечто вроде ".posts:n-th(3) button:has(.pencil)." Это можно интерпретировать, как кнопку редактирования третьей записи, но в структуре приложения зависимость более глубокая.

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

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

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

Привет! На связи Никита, QA Surf! И я три или четыре раза сталкивался с мнением, что навыки программирования опциональны для QA. Но работа QA — это не просто тестирование, это полноценное обеспечение качества продукта. И умение писать код — мощный инструмент для совершенствования и автоматизации процессов тестирования.

Разберёмся, как автоматизация помогает решать проблемы QA, на примере матрицы покрытия устройств для конфигурационного тестирования. Звучит непросто, но нас не испугать сложными задачами!

Автор: Шрай Шарма (Shray Sharma)
Оригинал статьи
Перевод: Ольга Алифанова

Введение

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

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

Возможно ли это? Да, возможно! Эта статья о том, как совместить Playwright, библиотеку тест-автоматизации с открытым исходным кодом, с языковыми моделями ИИ вроде Groq, Llama и Mistral, чтобы:

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