ИИ для тестировщика: инструменты, которые уже меняют профессию

ИИ уже генерирует тест-кейсы, создаёт тестовые данные и помогает писать автотесты. Но какие инструменты действительно экономят время QA-инженера, а какие пока остаются скорее маркетингом?

2 сентября в 20:00 МСК на открытом вебинаре OTUS вместе с Татьяной Березенцевой разберём, как использовать ИИ в ручном и автоматизированном тестировании и какие задачи уже сегодня можно передать AI-ассистентам.

На практике рассмотрим:
— генерацию тест-кейсов и тестовых данных;
— помощь ИИ при написании автотестов;
— сценарии, где AI действительно ускоряет работу тестировщика;
— возможности Testim, Mabl и GitHub Copilot;
— навыки, которые становятся особенно важными для QA-инженера в эпоху ИИ.

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

Урок проходит в преддверии старта курса «Автоматизатор тестирования на JavaScript».

👉 Регистрируйтесь: https://vk.cc/d13Wn6

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Хороших выходных!

🔥 ТОП-10 бесплатных расширений Chrome, которые упрощают работу QA

Собрали 10 действительно полезных расширений Chrome, которые делают работу QA гораздо проще👇

▫️ Postman Interceptor
Перехватывает HTTP-запросы из браузера и отправляет их напрямую в Postman — удобно для тестирования API.
🔗 https://www.postman.com/product/postman-interceptor

▫️ JSON Formatter
Форматирует JSON-ответы в удобную читаемую структуру — must-have для валидации API.
🔗 https://chrome.google.com/webstore/detail/json-formatter/bcjindcccaagfpapjjmafapmmgkkhgoa

▫️ SelectorGadget
Помогает быстро получать CSS-селекторы элементов — незаменимо для UI-тестирования и автоматизации.
🔗 https://selectorgadget.com

▫️ Lighthouse
Генерирует подробные отчёты о производительности, доступности и SEO прямо в браузере.
🔗 https://developer.chrome.com/docs/lighthouse/overview/

▫️ Window Resizer
Меняет размеры окна браузера — идеально для проверки адаптивности.
🔗 https://chrome.google.com/webstore/detail/window-resizer/kkelicaakdanhinjdeammmilcgefonfh

▫️ Checkbot
Сканирует сайт на технические ошибки: битые ссылки, SEO-проблемы, вопросы безопасности.
🔗 https://www.checkbot.io

▫️ Web Developer
Добавляет в браузер мощный набор инструментов для работы с HTML, CSS, cookies и многим другим.
🔗 https://chrome.google.com/webstore/detail/web-developer/bfbameneiokkgbdmiekhjnmfkcnldhhm

▫️ Session Buddy
Сохраняет все открытые вкладки и позволяет в один клик восстановить сессию — незаменимо, если у вас «100+ вкладок» 🤯
🔗 https://sessionbuddy.com

▫️ ColorZilla
Позволяет брать цвета с любого участка страницы — удобно для проверки UI-консистентности.
🔗 https://www.colorzilla.com/chrome/

▫️ uBlock Origin Lite
Блокирует рекламу и сторонние трекеры, делая тестирование интерфейса чище и стабильнее.
🔗 https://chrome.google.com/webstore/detail/ublock-origin-lite/ddkjiahejlhfcafbddmgiahcphecmpfh

Какие расширения в Chrome помогают вам больше всего?

⏳ Эстимация в тестировании. Шпаргалка QA-инженера

Вы тестировщик. Вам дают задачу и спрашивают: "Сколько времени займёт тестирование?" Если вы растерялись или назвали "на глаз" то эта шпаргалка для вас.

Что такое эстимация?
Эстимация это оценка времени, усилий или ресурсов, необходимых для выполнения задачи.

🎯 Цель: спрогнозировать сроки с учётом реалий проекта, не быть вечно "в тестировании" и не торопиться в ущерб качеству.

Виды эстимации:
▫️Грубая (Rough Estimate): ещё нет деталей, называют вилку: 3–5 дней, неделя и т.д.
▫️Точная (Detailed Estimate): задача проработана, можно оценить каждую часть.
▫️Оценка на основе опыта (Expert Judgment): делается вручную, с опорой на прошлые задачи.
▫️Planning Poker / Wideband Delphi: командные методы, где оценки обсуждаются коллективно.

Что влияет на эстимацию?
▫️Объём и сложность фичи
▫️Доступность тестовой среды
▫️Готовность документации
▫️Время на регрессию
▫️Количество поддерживаемых платформ
▫️Интеграции с другими сервисами
▫️Риски и неопределённость
Не забывайте про багфиксы и ретесты!

Формулы и техники:

Three-Point Estimate (PERT)
Это метод оценки задач, основанный на трёх сценариях:
▫️(Optimistic) оптимистичная оценка: если всё пойдёт идеально, сколько займёт времени?
▫️(Most likely) наиболее вероятная оценка: сколько времени займёт задача при обычных условиях?
▫️(Pessimistic) пессимистичная оценка: если всё будет плохо (баги, блокеры), сколько максимум может занять?
Формула:

(O + 4×M + P) / 6

То есть, основное влияние оказывает реалистичная оценка, но риски и удача тоже учитываются.

Пример:
Вы оцениваете задачу по тестированию фильтра товаров.
▫️(оптимистично) = 2 часа
▫️(наиболее вероятно) = 4 часа
▫️(пессимистично) = 10 часов
Estimation = (2 + 4×4 + 10) / 6 = (2 + 16 + 10) / 6 = 28 / 6 ≈ 4.67 часа

Когда использовать PERT?
▫️Когда много неопределённостей
▫️Когда нет достаточной статистики из прошлого
▫️Когда задача может зависеть от сторонних факторов (дизайн, API, баги и т.д.)

Work Breakdown Structure (WBS):
Разбиваем задачу на подзадачи → оцениваем каждую → суммируем.

Buffer (буфер):
Добавьте 15–25% времени на непредвиденные задачи, если это допустимо проектом.

Как улучшить эстимацию?
▫️Делайте разбор задачи и не оценивайте "вслепую"
▫️Уточняйте требования и тест-кейсы
▫️Учитывайте риски: нестабильность билда, баги, блокеры
▫️Ведите учёт времени и он пригодится для будущих оценок
▫️Общайтесь с командой: Dev, PM, дизайнеры, BA
▫️Документируйте свою эстимацию: что учитывали, чего нет и почему

Что НЕ стоит делать:
▫️Давать оценку, не прочитав задачу
▫️Согласовываться на словах, лучше фиксируйте эстимейт письменно
▫️Обещать закончить быстрее "на всякий случай"
▫️Игнорировать командные дедлайны и приоритеты

💬 Ваша эстимация это прогноз на основе текущей информации. И как любой прогноз, он может меняться.

Насколько этично и допустимо обсуждать свою ЗП, как думаете?

Как правильно отчитываться на дейли-митингах / стендапах / летучках?
Источник: Максим Азаров, Software Testing QA Lead в SAM Solutions

За много лет работы я заметил одну и ту же особенность в командах.

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

Есть другая категория людей, которые, наоборот, любят говорить долго, погружают всех окружающих в кучу технических деталей, рассказывают свои мысли, о том, как они думали, какие решения принимали, где ошиблись, а где, наоборот, придумали гениальные решения. Так минут на 10–15. Эти товарищи часто очень обижаются, если их прерывают и просят сформулировать статус в 2–3 предложениях. И тут обратная ситуация: идёт перегруз информацией, и человек вне контекста очень быстро теряет смысл происходящего, а у человека, собирающего статус и оценивающего общую ситуацию на проекте, начинает кипеть мозг от лишней информации.

Так нужен ли на самом деле алгоритм? И для кого на самом деле эти митинги? Для менеджера, чтобы собрать статус, или для членов команды, чтобы понимать, что вообще происходит и кто что делает на проекте?

Короткий ответ: Митинг этот для всей команды, но с разными целями для разных ролей.

Для команды (разработчиков, тестировщиков, дизайнеров и т.д.) это синхронизация:
а) Узнать, что сделали другие, чтобы не работать в вакууме.
б) Обнаружение блокеров: услышать, у кого возникли проблемы, и предложить помощь («Я сталкивался с такой ошибкой, посмотри вот в этот конфиг»).
в) Понимание контекста: увидеть общую картину движения к цели спринта.
г) Обмен знаниями: узнать о новых подходах, технологиях или проблемах, с которыми столкнулись коллеги.

Для менеджера / тимлида / скрам-мастера это:
а) Сбор статуса: получить общее представление о прогрессе.
б) Выявление рисков: увидеть препятствия, которые мешают команде, и оперативно их устранить.
в) Оценка нагрузки: понять, всё ли по плану или нужны корректировки.

Главная ошибка здесь - считать, что дейли - это просто отчёт менеджеру. Это время синхронизации команды, которую организует менеджер / скрам-мастер.

Предположительно правильный алгоритм отчёта должен укладываться в 3-4 предложения и длиться не более 1-2 минут. Он должен содержать ответы на три ключевых вопроса:
1. Что я сделал вчера? (По отношению к цели спринта)
2. Что я планирую сделать сегодня? (Опять же, для движения по задачам)
3. С какими трудностями столкнулся? (Блокеры, риски, вопросы)

Плохо: «Я кодил, потом тестил, потом ещё покодил».

Хорошо: «Вчера я завершил разработку API для модуля платежей и написал для него юнит-тесты. Сегодня планирую начать интеграцию с банковским шлюзом. Пока блокеров нет».

А как это работает в ваших командах ?