Плагины для автотестов в 👩‍💻 IntelliJ IDEA и 🌊 Aqua

Зачастую при написании автотестов на помощь приходят различные плагины для IDE. Сегодня поговорим про некоторые из них👇

✏️ CheckStyle-IDEA
Один из полезнейших плагинов для проверки кода на соответствие различным правилам. К примеру, можно выставить соответствие стандартам Sun Code или Google Java Style.
Можно удобно настроить кастомные проверки. К примеру, проверить наличие аннотаций @Epic, @Feature, @Story для Allure Report. Или например, плагин CheckStyle-IDEA предупредит, если вы не убрали какие-то временные строки (например, параметр invocationCount из аннотации @Test)

Из-за ограничений обработки файлов Checkstyle не позволяет реализовать такие проверки, как:
— проверки избыточности приведения типов или нахождения неиспользуемых публичных методов
— проверки, которые проверяют, что кастомный класс Exception наследуется от java.lang.Exception

⭐️ Советую к использованию всегда. Но, хотел бы отметить, что внедрять правила следует постепенно, иначе можно нарваться на огромное количество изменений, которые придётся как-то разгребать 😁

❇️ Allure TestOps Support
Полезный плагин при работе с платной версией обычного Allure Report'а.
С помощью плагина можно, например:
— отправлять результаты тестов на сервер
— назначать тестам AllureID
— синхронизовать данные из ручных тестов

⭐️ Советую использовать на максимум возможности плагина, особенно для генерирования AllureID, т.к. это сокращает ресурсы на ручное заведение тестов 💪

Три кита: 🤖 Test Automation, 💾 Test Data, 🕹 Test Management

Все три плагина входят в состав набора для автоматизации от JetBrains.
Ранее 🤖 Test Automation плагин назывался Selenium UI Testing, но затем была добавлена поддержка 🎭 Playwright и 💻 Cypress, что очень круто)
В целом плагин помогает с написанием UI тестов:
— инспектор для генерации CSS и XPath локаторов (лично у меня из-за большого количества элементов на странице эта фича так и не прижилась в использовании 😔)
— подсветка и проверка локаторов
— всевозможные действия с аннотациями Allure Report'а
— улучшенный вывод консольки (ура, можно кликнуть прям по пути к файлу и он откроется, чтобы смотреть наши любимые скриншотики)

🕹 Test Management позволяет использовать подход «Test as Text Approach» , интегрируется с TestRail и предоставляет следующие возможности:
— просматривать тест-кейсы и запуски
— добавлять ссылки на TMS
— генерировать тесты из TMS тест-кейсов
— помогает в фильтрации автоматизированных/неавтоматизированных тестов и нахождении неактуальных автотестов

⭐️ Я бы начал писать тест-кейсы именно через код, потому что это действительно здравый подход.
Но из минусов тут сразу бы отметил, что пока реализована поддержка только TestRail. Пока я был на Zephyr, то поддержку не добавили, спустя 3 года ничего не изменилось) Я даже писал про это здесь в 2021 году)

💾 Test Data позволяет сгенерировать простые тестовые данные: имена, адреса, предложения, числа, даты, email, UUID, URL, IP-адреса.

⭐️ Сгенерить рандомную строку, не выходя из IDE, как минимум это удобно. Ну а в целом для автотестов в динамике обычно я советую использовать библиотеки по типу Datafaker.

Вот такой вышел обзор) А какими плагинами пользуетесь вы? Расскажите в комментариях 👇

#автотесты #автоматизация #CheckStyle #AllureTestOps #ide #aqua

Как поддерживать архитектуру автотестов?

Когда-то наткнулся на такую библиотеку ArchUnit (https://www.archunit.org).
С помощью неё можно можно писать unit-тесты для вашего фреймворка автотестов, например:

@Test
public void checkLayers() {
    layeredArchitecture()
        .layer("Tests")
        .definedBy("..tests..")

        .layer("Steps")
        .definedBy("..steps..")

        .layer("Pages")
        .definedBy("..pages..")
        
        .whereLayer("Tests")
        .mayNotBeAccessedByAnyLayer()

        .whereLayer("Steps")
        .mayOnlyBeAccessedByLayers("Tests")

        .whereLayer("Pages")
        .mayOnlyBeAccessedByLayers("Steps")
        .check(classes);
}

В данном примере проверяется, что слой тестов Tests не вызывается из других слоёв, слой Steps вызывается только из Tests и слой Pages вызывается только из Steps. Таким образом проверяется простая вложенная структура проекта.

Рассмотрим ещё один пример:

@Test
public void checkSteps() {
    methods()
        .that().arePublic()
        .and()
        .areDeclaredInClassesThat()
        .resideInAPackage("..steps..")
        .should()
        .beAnnotatedWith(Step.class)
        .check(classes);
}

Здесь мы для всего пакета steps у публичных методов проверяем наличие аллюровской аннотации @Step
Как по мне это полезная проверка, чтобы в отчётиках всегда было видно описание шага)

⭐️ Преимущества использования ArchUnit:
— поддержание архитектурных стандартов на всём протяжении проекта
– упрощение рефакторингов
— повышение качества кода

💡 Из особенностей, на которые стоит обратить внимание:
— скорость работы (чем больше проект, тем нужно больше времени на анализ всех файлов)
— сложности при использовании в связке с Groovy (данная библиотека предназначена только для Java, но при определённом желании потратить свои силы и нервы можно настроить и для Groovy)

Есть также аналоги на других языках:

👩‍💻 pytestarch

👩‍💻 konsist

🟪 NetArchTest

#автотесты #архитектура #ArchUnit

✏️ Как осуществить качественное код-ревью на нескольких платформах

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

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

Хороший тон — скидывать ссылки на документации или какие-то примеры из других подобных случаев. Человек сразу видит, на что опираться, откуда это взялось. 🖥

Ещё я понимаю, что мои комментарии увидят другие, и я также могу почитать комментарии других и учиться на них, запоминая какие-то повторяющиеся моменты, которые, к слову, можно затем систематически отлавливать анализаторами кода (если это, конечно, возможно).

На разных платформах могут быть свои правила, которые нужно соблюдать. Для одного языка можно выработать общие правила, это унифицирует правила и не нужно запоминать для каждого свои)
На разных языках какие-то синтаксические различия — это понятно. Но общие концепции тоже можно сохранить, к примеру, концепцию AAA (arrange, act, assert).

💡 Можно сделать чек-лист код-ревью для каждого языка/платформы, он поможет ничего не забыть при проведении код-ревью.

🔍 Про анализаторы кода. Настроить их по максимуму, чтоб убрать рутину по форматированию, обязательным элементами, неиспользуемому коду и т.д.
Нужно проверять код автотеста на логику шагов, а так ли тест должен выглядеть?
Может быть что-то излишне или чего-то наоборот не хватает? Может быть что-то не будет работать при определённых условиях? 💡Подсвечивайте такие моменты, ведь в дальнейшем тест будет гоняться в таком виде и, возможно, нескоро заметится, что что-то не так ⚡️
📁 Тестовые данные, это большая тема, про которую стоит не забывать, часто используется в тестах и может быть в самих данных уже кроется какой-то нюанс. Очищаются ли все данные? Почему тут используется именно эти данные? Почему мы берём эти данные, а не другие? Эти и другие вопросы могут прийти во время ревью)

📖 Смотреть и впитывать себя особенности платформ/языков — бесценный опыт. Благодаря нему ты видишь общую картинку. Где-то не применяют какое-то правило или интерпретируют его по-другому? 📈 Есть места, что можно улучшить.
Собирайте такие моменты и улучшайте вместе с командой.

👀 Все ревьеры поставили апрув, но ты видишь какой-то момент, который нужно подправить прямо сейчас? Не откладывай на потом — напиши. У всех случается, что что-то не замечается, это жиза. Этот момент запомнят и скорее всего уже будут обращать на это внимание)

📌 Это лично моё видение, я верю, что качественное ревью помогает всем членам команды и проекту, что это не только рутина, это целая история, опыт,
Я сам не идеальный ревьюер, но стараюсь идти к этому:
— вхожу в команду ревьюеров своего БЮ на трёх платформах (Web, API, Android)
— за 1 год поревьюил где-то 180+ MR-ов, не знаю даже, это много или мало)) 💬Напишите в комменты, пожалуйста, сколько вы ревьюите обычно)

#статьи #кодревью #автотесты

Никогда, слышите, никогда не пишите такие ассёрты!

Иногда попадаются вот такие «информативные» описания при падении теста:

expected [true] but found [false]

Меня вгоняют в печаль такие падения) Из этого описания мало что понятно слёту 😞

Такое можно встретить, если не было добавлено описание к проверке. Например, в AssertJ:

assertThat(setting).is(true);

Для улучшения контекста ошибки можно добавить пояснения, например, через as():

assertThat(setting).as("Настройка должна быть включена для расширенной версии").is(true);

Рассмотрим примеры на других языках и библиотеках:

В 🧬 Selenide есть возможность уточнять причину падения с помощью because():

saveButton.shouldBe(visible.because("Кнопка сохранения должна снова появиться")

✅ XCTest:

XCTAssertTrue(condition, "Условие должно быть true, потому что...")

И в пакете ✅ Swift Testing:

#expect(false, "Какое-то кастомное сообщение")

💡 TestNG и 5️⃣ JUnit:

assertTrue(condition, "Условие должно быть true, потому что...")

В Kotlin в ✅ Kotest используется «clues» (подсказки), например, withClue:

withClue("Name should be present") {
  user.name shouldNotBe null
}

И asClue:

{ "Name should be present (user_id=${user.id})" }.asClue {
user.name shouldNotBe null
}

📊 pytest:

assert price > 0, "Price should be greater than zero"

🎭 Playwright:

await expect(page.getByText('Name'), 'should be logged in').toBeVisible();

⭐️Нужно стараться всегда указывать описание, чтобы лучше понимать причину падения, это помогает не только тебе, но и другим коллегам 👌
И, конечно, не используйте комментарии для описания, их никто не увидит при падении 😁

#автотесты

Про 🎨Compose Preview Screenshot Testing (CPST)

Периодически изучаю и пробую новые инструменты, на свой страх и риск, в этот раз наткнулся на 🎨Compose Preview Screenshot Testing для Android тестов) Если интересно и хотите больше такого, то ставьте свои реакции 👍

https://telegra.ph/Compose-Preview-Screenshot-Testing-09-18

#android #compose

2019 -> 2024, спустя 5 лет, Heisenbug

Вспомню доклады, которые мне понравились тогда:
— Selenide брандашмыг от Алексея Виноградова
— Визуализация покрытия от Артёма Ерошенко

Доклады, которые останутся в памяти навсегда, как бы пафосно это не звучало)

swagger-coverage для API я каким-то чудом смог применить) О чём, кстати, писал здесь) webdriver-coverage как ни старался, завести не получилось, но я хотя бы попытался))

Selenide я применяю до сих пор, кто бы что не говорил, это одна из самых классных библиотек для UI автотестов)

— Асинхронное тестирование производительности от Вячеслава Смирнова
Нагрузочное тестирование я чуть-чуть успел применить на практике, но эта область так и осталась для меня неизученной до конца, но в принципе эта тема мне интересна и периодически на что-то интересное в НТ натыкаюсь)

Сегодня уже другие доклады, новые люди) Но некоторые остаются)) Особенно интересен доклад, который заканчивается в прошлом) Вечный вопрос: фича или баг? 😅

😉 AI помощники для написания автотестов
#автотесты@qa_relia #ai@qa_relia

https://telegra.ph/Generiruyu-avtotesty-02-05

👨‍💻В статье поделился своим опытом использования ChatGPT/подобных, Postbot и Explyt.

А какими AI решениями для автотестов используете вы? Поделитесь, пожалуйста, в комментариях👇

State of Testing 2025

Ежегодный отчёт о состоянии тестирования в мире от PractiTest: ссылка на отчёт

За 2024 год итогами делился здесь.
Давайте же рассмотрим ключевые моменты🔹

👩‍💻 Популярные инструменты

В этом году в топе инструментов оказались: Jira, GitHub, Jenkins, Cypress, Xray, Zephyr, TestRail, PractiTest, Playwright, Selenium и Postman (интересно, что в 2024 году Postman был на третьем месте)

📱 Использование AI

🔹40% опрошенных используют ChatGPT, 10% — Claude, 6% — Gemini, 5% — собственные инструменты. Напомню, что в 2024 году около 60% не использовали AI инструменты.

🔹46% не применяют AI для тестирования, 41% используют его для создания тест-кейсов. Также AI применяется для планирования, репортинга, оптимизации тест-кейсов и управления данными.

🔒 Барьеры для внедрения AI

56% — проблемы с приватностью данных и безопасностью
33% — недостаток квалифицированных сотрудников
29% — неуверенность в преимуществах

✨ Ожидания от AI в автоматизации

39% ожидают уменьшения ручной работы
38% предвидят новые вызовы в тестировании AI систем
37% рассчитывают на улучшение обслуживания тестов и их самовосстановление
37% ожидают изменения требований к навыкам тестировщиков, включая грамотность в области AI

🧠 Преимущества внедрения AI

46% — повышение
эффективности автоматизации тестирования
35% — улучшенная генерация реалистичных тестовых данных
27% — снижение зависимости от ручного тестирования

🔥 Роль команд тестирования

В 86% случаев команды тестирования участвуют в принятии решений о готовности к релизу, что на 5% больше, чем в 2024 году.

🕯 Метрики

56% — тестовое покрытие
54% — метрики багов
45% — метрики запусков тестов
34% — скорость устранения багов
25% — показатели эффективности тестирования, которые выросли на 5%, что свидетельствует о сдвиге в сторону оценки качества тестов.

🌡 Навыки и компетенции

🔹Значимость коммуникативных навыков выросла до 75% (с 59%). Навыки межличностного общения становятся всё более важными в обеспечении качества.

🔹Актуальность остальных навыков снизились: API тестирование (с 41% до 34%), написание автотестов (с 47% до 41%), шаблонов и практики автоматизации (с 46% до 45%).
Это указывает на то, что они становятся базовыми компетенциями, а не отличительными чертами. Теперь команды могут сосредоточиться на более высокоуровневых навыках, таких как стратегия тестирования и коммуникация.

🔹Интерес к Agile-методологиям снизился с 49% в 2023 году до 28% в 2025 году, так как Agile-практики уже хорошо интегрированы в рабочие процессы.

🔹Актуальность машинного обучения и тестирования с использованием AI увеличилась с 7% в 2023 году до 16% в 2025 году, что отражает растущий интерес к использованию AI для автоматизации тестирования, прогнозирования дефектов и аналитики.

#тестирование@qa_relia #stateoftesting@qa_relia

🤑 Зарплаты тестировщиков во второй половине 2024

🔹Зарплата менеджеров по обеспечению качества по медиане увеличилась на 30К по сравнению с предыдущим полугодием.
Инженер по автоматизации тестирования прибавил 27К, далее идёт инженер по производительности (+25К), инженер по обеспечению качества (+20К) и инженер по ручному тестированию (+19К).

🔹Медианная зарплата тестировщиков 150К (выросла на 20%), у разработки - 205К, далее идёт менеджемент - 200К и аналитика - 175К.
Самый высокий прирост у специалистов по информационной безопасности - 157К (+21%).

Топ-5 по компаниям: Авито, Иннотех, Райффайзен Банк, 🔹VK и Альфа-Банк.

🔼Медианная зарплата в IT — 180 000 ₽, это на 19% больше первого полугодия 2024.

🔗 Посмотреть результаты полностью можно здесь.

#зарплаты@qa_relia

📌 5 вопросов тестировщика на собеседовании, или Красные флаги

Хочу поделиться статьёй моего коллеги по функции QA Владислава:
https://habr.com/ru/companies/vk/articles/883334

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

🧑‍🎓 На своём опыте понял, что не всегда можно успеть задать все вопросы, потому что по времени собеседования ограничены, поэтому после собеса я составил список вопросов и отправил их HR-у (у меня вышло 15 вопросов). Затем в спокойном режиме мне на них ответили, я почитал и был уже более информирован и подготовлен.

👀 Не забывайте спрашивать, лучше заранее подготовить какой-то список вопросов.

#статьи@qa_relia #собеседования@qa_relia

🗂 Папка с лучшими Telegram каналами про QA

🥳 В том году мой канал добавили супер-полезную подборку каналов о тестировании:
https://news.1rj.ru/str/addlist/PNmSaWa9ktw2YjRi

Ребята проделали большую работу по созданию этой папки! Все каналы прошли экспертное ревью и получили зелёный цвет - каналы живые, интересные и уникальные.

🙏 Надеюсь, что каждый найдёт для себя полезные каналы, добавляйте папку к себе =)

👩‍💻 Про код-ревью автотестов

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

🔹Первоначальное ревью
Первым ревьюером является сам автор. Написав код, необходимо тщательно его проверить. Полезно составить чек-лист, учитывающий особенности проекта. Проходя по чек-листу можно детально проверить различные моменты, дабы ничего не упустить. Составление типовых ошибок на ревью также будет хорошей практикой 📝
Можно ещё попросить 📱 AI выполнить ревью кода, чтобы получить стороннее мнение на раннем этапе.

🔹Ревью коллегами
На первом этапе часть моментов можно улучшить, но не всегда, поэтому далее код-ревью проводят коллеги. Некоторые компании внедряет многоуровневую систему ревью, чтобы как можно больше людей посмотрело, тем самым минимизируя количество проблем в будущем.
Со стороны ревьюера важно видеть картину целиком, а не только несвязанные кусочки кода 🌐
В Merge Request (MR) обязательно должно быть описание, прикреплённая задача, вспомогательные лейблы и другая ценная информация, которая даёт контекста происходящего. Изучение всего материала – маст хэв, иначе вы просто можете не понять что-то важное.
Код обязательно должен проходить через несколько Quality Gate, такие как статические анализаторы кода, юнит-тесты и другие проверки, запуски самих автотестов и т.д.
Благодаря этим проверкам процесс ревью упрощается, оставляя сложную работу ревьюерам. Максимально автоматизируйте то, что можно и нужно автоматизировать 😉

В процессе ревью автотестов важно знать сценарий, который покрывается автотестом. Нужно проверить полноту покрытия, логику работы теста, все ли шаги и проверки правильно описаны.
Стабильность автотеста можно проверить запусками, но не всегда это возможно. Здесь я бы посоветовал обращать внимание на ожидания элементов перед действиями. Желательно видеть UI и нужно знать, как этот функционал выглядит вживую и отрабатывает. И про стабильные локаторы не забывать 😁
Ещё должны быть правила, по которым изменения считаются блокирующими или нет для влития. Моменты, которые не блокируют, можно выносить в отдельные задачи.

🔹Ревью комментария
Немаловажную роль играет сам комментарий, так что нужно самостоятельно проревьюить комментарий к ревью 😃
Никогда не критикуйте автора, пишите только про сам код.
Подача комментария должна быть доброжелательной и конструктивной. Рекомендуется подкреплять комментарий ссылкой на доку или другие ресурсы.

🔹Как развиваться в ревью?
Смотреть другие MR-ы, как и на что обращают внимание другие ревьюеры.
Зафиксировать часто встречающиеся моменты в доке, чтобы другие знали, на что обращать внимание, попробуйте их отлавливать через линтеры.
Делайте побольше качественного ревью, в том числе в других MR, если вы видите какие-то моменты.

Что в итоге:

✅Самопроверка, чек-листы, AI
✅Коллективное ревью
✅Конструктивные комментарии
✅Постоянное развитие

#автотесты@qa_relia #ревью@qa_relia

🔥 Ребят, я очень давно не писал, потому что... начал работать в новой роли QA лида)

🤔 Я очень хочу поделиться своим опытом, но мне хочется понять, что бы Вы хотели услышать?

📝 Пишите в комментарии или в личку канала/мне

Всем хорошего дня и успехов 💟

❇️ Как я стал QA лидом и что теперь делаю каждый день

Часть 1. История моего перехода в QA лида

Я работаю ❤️ ВКонтакте с 2023 года - наша команда делает фичи для покупателей в соцсети и помогает бизнесу продавать.
Раньше у нас был сильный QA лид — с ним было легко и приятно работать. Но в прошлом году он решил уйти, и для меня это стало неожиданным. Тогда я впервые всерьёз задумался о роли лида.
К тому моменту у меня уже был опыт: на предыдущем проекте я интересовался темой лидерства, прошёл курс по управлению командой тестирования и даже начал делать первые шаги.
Я высказал своё желание руководителю - и стал ждать. Вскоре наше направление отделилось в самостоятельную структуру, и когда встал вопрос о QA лиде, мне предложили взять на себя эту функцию. Прежний лид с нами не перешёл - и вот я принял вызов 💪

🔃 Что делает QA лид на практике?
В первую очередь - планирование. Это был вызов: раньше этим занимались другие, и мне пришлось на ходу разбираться, как собрать и сформулировать задачи для команды, а также организовать слаженную и качественную работу.

Основные обязанности QA лида:
📊 планирование квартала и оценка ресурсов
💡 участие в планировании техдолга и приоритизации задач
🧩 помощь тимлиду в составлении ИПР
⚒ помощь с автоматизацией
❓ точка входа по вопросам QA внутри команды и для внешних коллег
〰️ организация регулярных командных встреч
〰️ отслеживание статусов ключевых задач

🔃 Неформальные, но важные задачи:
〰️ поддержка неформального общения внутри команды
〰️ налаживание связей с другими лидами
〰️ решение бытовых вопросов: например, помощь с заменой тестовых устройств

🔃 Делегирование - must-have
Очень быстро приходит понимание, что всё сам не сделаешь. Учишься делегировать, передавать задачи и вовлекать ребят - и это классно, потому что помогает им расти.

↘️ Ответственность становится шире
Теперь ты отвечаешь не только за себя, но и за всю команду. Это непросто, особенно если ты активно участвуешь во всём процессе тестирования. Но, как «играющий тренер», я понимаю: всё реально, если правильно планировать и распределять нагрузку.

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

🔥 - как совмещать работу в команде и QA лида
❤️ - как планировать работу QA
👍 - как делегировать и не бояться

🔹 ISTQB выпустила новую сертификацию — CT‑GenAI
(Certified Tester – Testing with Generative AI)

На днях ISTQB представила новую сертификацию уровня Specialist: Certified Tester – Testing with Generative AI (CT‑GenAI).
Это первая в мире программа, полностью посвящённая практическому применению LLM (типа ChatGPT) в тестировании ПО.

Вот что важно знать👇

🔹Что покрывает CT‑GenAI?

🔹Основы GenAI и LLM
— Что такое языковые модели (GPT, Claude и др.), как они работают: токены, окно контекста, temperature, zero/few-shot.
— Чем отличаются foundation models, fine-tuned, multimodal.

🔹Prompt Engineering для QA
Да, в будущем мы все станем промпт инженерами 😂
— Как правильно формулировать промпты: шестикомпонентная структура (роль, контекст, инструкция, вход, ограничения, формат).

— Техники:
🔹zero-shot — без примеров,
🔹few-shot — с примерами,
🔹chain-of-thought — пошаговое рассуждение,
🔹meta-prompt — генерация промптов.

— Как использовать LLM для генерации:
🔹тест-кейсов,
🔹чек-листов,
🔹edge-сценариев,
🔹баг-репортов.

🔹Риски и ограничения
— Галлюцинации, непредсказуемость, bias (предвзятость), утечки данных.
— Как снизить риск: temperature=0, проверка валидности, аудит результата.
— Приватность: нельзя передавать в промпт чувствительные данные (PII, логи с юзер-данными).

🔹LLM‑инфраструктура и LLMOps
— Что такое RAG (Retrieval Augmented Generation) и как он повышает точность ответов.
— Версионирование промптов, наблюдение за качеством генерации, управление стоимостью (inference cost).
— Использование AI-агентов - например, генерация тестов + запуск + отчёт.

🔹Внедрение в команду
— Как создавать шаблоны промптов для команды.
— Как измерять эффективность: ускорение подготовки, рост покрытия, снижение дефектов.
— Обучение QA-команды промптингу и ревью.

🔹 Примеры задач, которые можно делать с GenAI
✅ Сгенерировать чек-лист по user story
✅ Предложить edge‑cases, о которых забыли
✅ Оформить Gherkin-сценарии
✅ Составить баг-репорт на основе скриншота
✅ Сгруппировать баги по причинам (root-cause analysis)
✅ Сгенерировать отчёт по тест‑прогону
✅ Создать синтетические тестовые данные без PII

🔹 Зачем это нужно QA
LLM‑модели - уже не тренд, а реальность.
Их можно использовать не только как игрушку, а как ассистента: для ускорения анализа требований, тест‑дизайна, документации.
Но чтобы это делать грамотно и безопасно, нужен системный подход.
И именно его даёт CT‑GenAI от ISTQB.

💬 Что думаешь об этой сертификации? Пиши в комментарии) Надеюсь AI боты не придут в комментарии 😅

На мой взгляд выглядит интересно, думаю войдёт в базовый набор знаний и навыков для базового уровня.

#istqb@qa_relia #llm@qa_relia #prompt_engineering@qa_relia