🧪 Тестируем стул, карандаш и чайник: шпаргалка для QA-инженеров
Источник: Владлен Цыганенко

На собеседованиях QA частая «ловушка» когда просят протестировать не сайт и не приложение, а бытовой предмет: карандаш, стул, кружку и т. д. Цель: проверить не технические знания, а мышление, структурность и умение задавать вопросы.

Как отвечать правильно

▫️Не теряйтесь
Это задание не про реальные баги, а про то, как вы рассуждаете.

▫️Начинайте с уточнений
— Для кого предмет? (дети, взрослые, офис, школа)
— В каких условиях используется? (дом, улица, экстремальные условия)
— Цель использования? (стул для сидения, карандаш для письма/рисунка)
Такие вопросы показывают, что вы умеете собирать требования.

▫️Думайте категориями тестирования
— Функциональность - выполняет ли предмет свою основную задачу?
— Юзабилити - удобно ли им пользоваться?
— Надежность - выдерживает ли нагрузки, не ломается ли слишком быстро?
— Безопасность - не причиняет ли вреда (например, у стула острые углы)?
— Совместимость/условия эксплуатации - работает ли в разных средах (карандаш пишет на бумаге, картоне, стене).

▫️Примеры подхода
— Стул: проверю устойчивость, прочность, удобство спинки, высоту, материалы, безопасность (нет ли заноз).
— Карандаш: пишет ли, ломается ли грифель, стирается ли резинка, удобно ли держать, оставляет ли след на разных поверхностях.
— Кружка: выдерживает ли кипяток, удобно ли держать ручку, можно ли мыть, не трескается ли.

▫️Используйте знакомые техники тест-дизайна
— Эквивалентные классы (разные типы пользователей: ребёнок/взрослый).
— Граничные значения (макс. вес для стула, минимальная температура для кружки).
— Негативные сценарии (сидеть на стуле на одной ножке, пытаться писать карандашом на мокрой бумаге).

❓Стоит ли задавать уточняющие вопросы?

Да, обязательно. Это показывает, что вы:
— Умеете уточнять требования;
— Не тестируете «в вакууме»;
— Мыслите как QA в реальном проекте.

Как себя вести
— Будьте спокойны и структурны;
— Разбейте рассуждения на блоки (условия → категории тестов → примеры);
— Не стремитесь перечислить «все баги мира», главное, показать системность.

Итог:
Когда просят протестировать предмет, не ищут реальные дефекты, а хотят увидеть логику, структурность, внимательность и умение задавать правильные вопросы.
Хороший ответ звучит не как «сломается/не сломается», а как чек-лист из разных категорий проверки с предварительными уточнениями. Эта техника работает и с ПО: вы показываете одинаковый QA-подход в любой ситуации.

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

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

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

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

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

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

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

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

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

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

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

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

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

❓Как сформировать стратегию тестирования?

На открытом уроке разберём, как QA-лид может формировать стратегию тестирования, чтобы связать задачи команды с бизнес-целями и управлять качеством продукта системно.

Результаты на выходе:

- Участники поймут, чем стратегия отличается от плана тестирования.
- Получат готовую «канву» для построения своей стратегии.
- Увидят примеры метрик, SLA и quality gates, которые можно адаптировать под свои проекты.

👉 Регистрация и подробности о курсе: https://vk.cc/cPNars

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

Нужно было в своё время начинать в тик-токе танцевать. Было бы ещё больше тысяч долларов на счету и здоровая спина 😁

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

Я проверил новые задания по SQL и в целом они мне понравилось - это не очередная проверка знания базового синтаксиса и основных операторов (вроде SELECT и JOIN), а комплексный тест по разным темам.Как мне объяснили, для ревью собрали задачи всех уровней: от базовых до продвинутых. В реальных же тестах для каждого уровня будут свои блоки: выбрал базовый – получаешь соответствующие задания. Есть вопросы на знание тонкостей, на которых можно задуматься даже опытным разработчикам - вроде нетривиальных моментов, где надо помнить про особенности троичной логики SQL, разницу в поведении JOIN-ов.

Чтобы вы представляли себе уровень заданий, ниже вопрос, на котором завалился я ⤵️
Рассмотрим запрос:

SELECT name FROM customers WHERE customer_id NOT IN (SELECT customer_id FROM orders WHERE status = 'canceled') Какое нетривиальное поведение будет у этого запроса, если хотя бы одна строка во вложенном подзапросе содержит значение NULL в customer_id?

На первый взгляд кажется, что он просто отберёт всех клиентов без отменённых заказов. Но как только во вложенном подзапросе появляется хотя бы один NULL в customer_id, результат ломается — запрос не вернёт вообще ничего. Это нетривиальный момент, который легко пропустить, если не помнить про особенности трёхзначной логики в SQL (TRUE, FALSE, UNKNOWN).

Как видите, есть вопросы про глубокое понимание логики SQL. В реальных проектах незнание таких моментов может привести к очень неприятным багам.
Подытоживая: хороший проект и отличный пример того, как с привлечением сообщества можно сделать инструмент точнее и полезнее.

🔥 «Яндекс» запустит новый дата-центр во Владимирской области

В начале 2026 года Yandex Cloud запустит новую зону доступности – на базе нового дата-центра во Владимирской области. Его мощность превысит 40 МВт, а задержка между соседними зонами составит менее 1 мс при пропускной способности канала 25,6 Тб/с. Такой уровень инфраструктуры позволит ускорить критичные для бизнеса процессы — от транзакций до обработки запросов в базах данных.

📈 Также компания запустила новые вычислительные платформы – производительность выросла втрое при сопоставимой стоимости, на одной виртуальной машине теперь доступно до 288 vCPU и 1,7 ТБ памяти.

Читать подробнее

продуктивной недели 🙌

🔥 Как находить фатальные ошибки в приложении ещё до кода?

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

Что рассмотрим на уроке:
- Основы тестирования требований для мобильных приложений
- Как находить противоречия и недочёты в ТЗ
- Приёмы задавания «правильных» вопросов
- Как раннее тестирование требований экономит время и бюджет проекта

👉🏻 Регистрация и подробности о курсе: https://vk.cc/cPZPdZ

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

🔥 Большая подборка ресурсов для работы с cookies для QA, разработчиков и не только

Cookies используются для:
▪️авторизации,
▪️сохранения сессий,
▪️персонализации пользователя,
▪️аналитики и рекламы.

Именно здесь часто скрываются проблемы и уязвимости: от «вечных» сессий до нарушений безопасности.

Подборка ресурсов, которые помогут прокачать навыки работы с cookies:

1. Инструменты для работы с cookies в браузере

▫️Cookie-Editor (Chrome)
https://cookie-editor.cgagnier.ca/

▫️Cookie Quick Manager (Firefox)
https://addons.mozilla.org/en-US/firefox/addon/cookie-quick-manager/

Также удобно работать с cookies через DevTools.

2. Практика безопасности и уязвимостей

▫️OWASP Juice Shop — тренажёр по веб-безопасности, где можно экспериментировать с cookies.
https://owasp.org/www-project-juice-shop/

▫️PortSwigger Web Security Academy — интерактивные лаборатории по cookies, сессиям и токенам.
https://portswigger.net/web-security

3. API и HTTP-эксперименты

▫️HTTPBin — сервис для проверки запросов и работы с cookies.
https://httpbin.org/

▫️Postman Echo — инструмент для тестирования cookies в запросах.
https://www.postman-echo.com/

4. Ресурсы для соответствия GDPR / CCPA

▫️CookieYes — генератор баннеров согласия на использование cookies.
https://www.cookieyes.com/

▫️Termly — готовые политики использования cookies.
https://termly.io/products/cookie-consent-manager/

5. Статьи и справочники для QA

▫️OWASP Cheat Sheet — Secure Cookie Practices
https://cheatsheetseries.owasp.org/cheatsheets/SecureCookieAttributes.html

▫️MDN Web Docs — Cookies (подробная документация с примерами)
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

Все перечисленные материалы предназначены для обучения и практической работы.

Мобильным тестировщикам посвящается.

Надо было загадывать яхту 😁

Шпаргалка для QA инженеров: как получить оффер, используя поиск работы как запуск теста?

Начинаем, конечно, с изучения требований – смотрим, какие вакансии есть на рынке, что хотят от кандидата и что ему предлагают. Дальше настраиваем тестовую среду – готовим резюме и себя к предстоящему собеседованию. Непосредственное выполнение тестов, тут и так понятно, проходим собесы и ждем ответ. Но что делать, если ответа нет? Карьерная стратегия – новая реальность, хотите вы этого или нет. И тот, кто первый это поймет сможет не только не умереть в канаве, но и повысить грейд и зарплату даже на сегодняшнем рынке работодателя.

В Карьерном Цехе сопровождают кандидатов до оффера с HR-ами и профильными экспертами, которые подбираются персонально под ваш стек.

В программу поддержки входит:

💫Стратегическая консультация с профильным HR (калибровка с рынком по компенсации, задачам и навыкам)
💫Встреча с HR и профильным экспертом для корректировки резюме, чтобы сделать его понятным для нанимающего менеджера и HR
💫Тренировочные собесы, мок-интервью с топовыми нанимающими с рынка с развернутым фидбеком
💫 Ну и конечно, постоянный HR-надзор от Леси Набоки, соосновательницы Карьерного Цеха, которая специализируется на подборе персонала со времен египетских пирамид
💫Огромное коммьюнити и рефералки по всему рынку, Карьерный цех настоящая кадровая кузница топовых российских компаний

Приходите выстраивать карьеру в КЦ по понятному плану со знакомыми этапами.

🙃 Почему вы не довольны AI в тестировании? Возможно, вы делаете одну из этих 6 ошибок.

Источник

Я сам проходил через них все, внедряя AI-решения в тестировании - от первых экспериментов до пилотов в продакшене.

И часто вижу, как мои команды ловят те же ошибки.

Давайте по порядку

1. Неструктурированные промпты
- Когда AI не понимает, чего от него хотят - не потому что он тупой, а потому что промпт расплывчатый.
- Нет чётких шагов, нет сценария, нет указания формата ответа.
- На выходе: вода, пространные рассуждения, «ни рыба ни мясо».

2. Нет примеров
- Вы просите: "Сделай как надо", но не показываете, что такое "надо".
- Few-shot prompting (несколько примеров input → output) помогает AI лучше уловить формат и суть.
- Без них он будет гадать.

3. Пустая база знаний
- AI не экстрасенс, он работает с тем, что знает.
- Пара примеров - не база. Если вы не загрузили контекст, он будет лепить дубликаты или уходить в сторону.
- Нужна или ручная работа по сбору контекста, или интеграции с системами, или нормальный RAG.

4. Один промпт = много задач
- Типичная ошибка: в одном промпте попросить и ревью требований, и чеклист, и генерацию тестов.
- В итоге всё получается плохо.
- Один промпт - одна задача.
- Разбейте процесс и получите нормальный результат на каждом шаге.

5. Хотите всё и сразу
- "Сгенерируй 50 тест-кейсов на эту фичу".
- А потом удивляетесь, что они поверхностные и однообразные.
- AI ≠ волшебная палочка. Большие задачи - только итеративно. Один промпт - один кейс.
Да, дольше. Зато качественно. Даже для 50 шагов в тест-кейсе

6. Вы не используете AI, чтобы писать промпты
- Это иронично, но факт: промпты, написанные вручную, часто хуже.
- Я давно уже не пишу промпты сам.
- Я описываю, что хочу получить, даю примеры, и прошу AI сам составить промпт.
- Потом валидирую - и в бой.

🎯 Хотите качественный результат - относитесь к промптингу как к инженерной задаче.
И не забудьте: промпт - это тоже часть системы. Его можно (и нужно) тестировать.

🚀 Автоматизация API: Выбираем фреймворк-лидеров

Источник

🥇 Мой ТОП-выбор: Playwright
Да, он давно перестал быть еще одним UI-фреймворком. Для API - это мощный и современный инструмент.

Почему он?
▪️Единая экосистема: Один инструмент для E2E (UI + API) тестов. Больше не нужно поддерживать два стека.
▪️Простота: Лаконичный синтаксис для запросов и assertions. Все асинхронные операции под капотом.
▪️Мощь контекста: Легкая работа с аутентификацией (JWT, Cookies). Контекст браузера можно использовать для API-запросов и наоборот.
▪️TypeScript: Идеальная поддержка из коробки для надежных тестов.

Альтернативы? Конечно!

🔹 REST Assured (Java)
Идеален для Java-команд. Предоставляет fluent DSL для написания очень читаемых и выразительных тестов. Стандарт де-факто в enterprise-среде на Java.

🔹 Requests + Pytest (Python)
Связка классической библиотеки requests и мощного pytest — это гибкость и полный контроль. Вы сами строите каркас под свои нужды. Выбор многих Python-разработчиков.

🔹 Supertest (JavaScript/Node.js)
Лучший друг разработчиков Node.js. Идеально подходит для тестирования Express-приложений «изнутри», но справляется и с любыми другими API.

Итог:

▪️Новый проект/Полный стек? - Смотрите в сторону Playwright.
▪️Монолитный Java-стек? - REST Assured ваш выбор.
▪️Любите Python и контроль? - Requests + Pytest.
▪️Разрабатываете на Node.js? - Supertest будет естественным расширением вашего стека.

Как стабилизировать команду и взаимозаменять в ней людей?

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

Что рассмотрим на уроке:
- Основы взаимозаменяемости и устойчивости команды
- T-shaped специалисты и их роль в QA
-Шаринг знаний и делегирование
- Рост своей замены и гибкий старт внедрения практик

👉 Регистрация и подробности о курсе: https://vk.cc/cQ6PiA

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

🚀 «Тестируем с ИИ» — курс для начинающих и опытных тестировщиков.

https://qa-road.com/

💡 Какие боли решаем:
- Тратите 3-5 часов на написание тест-кейсов, чек-листов и баг-репортов вручную 
- Низкая скорость работы
- Анализ требований и ТЗ на 50 страниц занимает уйму времени
- Проблемы с качеством баг-репортов
- Нехватка экспертизы

Что конкретно получаешь:
-  Промты для анализа требований, тест-кейсов, баг-репортов
- Промты для API тестирования, тест-плана, UI/UX
-  Примеры разбора ежедневных задач
-  Как быстро писать качественные промты    
-  Как разбираться с задачами, даже если не знаешь, с чего начать  
-  Как писать автотесты в Cursor
-  Чат для общения и поддержки

🛠️ Изучаем топовые ИИ инструменты в действии:
- Perplexity — лучший помощник для поиска и исследований  
- Cursor — редактор кода с топовыми нейросетями

Курс уже прошли 200+ тестировщиков

Автор курса: Дима Алексеев — 5+ лет в QA, занимаюсь ручным и авто‑тестированием. Веду канал @qa_road_channel

💰 Цена всего 4990 2990 рублей по акции ко дню тестировщика

⚡ 5 часов изучения спасут недели жизни!

Купить курс: @qa_road_bot
Оплата через систему Робокасса принимает СБП, карты РФ и международные карты

Курс в стиле «бери и повторяй» — всё как мы любим! 😎

Подборка ресурсов для практики SQL для QA-инженеров, BA, DA и не только

Знания SQL необходимы как начинающим специалистам, так и тем, кто уже работает в IT: QA, BA, DA и другим. Ниже приведены ресурсы, которые помогут отработать навыки написания запросов, подготовиться к собеседованиям и проверить знания.

1. Практика SQL-запросов онлайн

▪️SQLBolt
https://sqlbolt.com/

▪️Mode SQL Tutorial
https://mode.com/sql-tutorial/

▪️LeetCode — SQL Problems
https://leetcode.com/problemset/database/

▪️HackerRank — SQL Practice
https://www.hackerrank.com/domains/sql

▪️StrataScratch — SQL Practice
https://platform.stratascratch.com/coding

▪️DB-Fiddle
https://www.db-fiddle.com/

2. Подготовка к техническому интервью по SQL

▪️InterviewBit — SQL Interview Questions
https://www.interviewbit.com/sql-interview-questions/

▪️Mindmajix — Top 100 SQL Interview Questions
https://mindmajix.com/sql-interview-questions

▪️DataCamp — SQL Interview Questions
https://www.datacamp.com/blog/sql-interview-questions

▪️GeeksforGeeks — Top 50 SQL Questions for Data Analyst Interview
https://www.geeksforgeeks.org/sql-for-data-analyst-interview-questions/

3. Симуляторы интервью

▪️Pramp — SQL Interview Practice
https://www.pramp.com/#/

▪️Exercism — SQL Track
https://exercism.org/tracks/sql

4. YouTube-каналы с практикой SQL и разбором задач

▪️Data School — SQL for Data Analysis
https://www.youtube.com/@dataschool

▪️Alex The Analyst — SQL Projects and Practice
https://www.youtube.com/@AlexTheAnalyst

▪️Programming with Mosh — SQL Tutorial
https://www.youtube.com/watch?v=9Pzj7Aj25lw

5. Основы SQL — квизы и тесты

▪️W3Schools SQL Quiz
https://www.w3schools.com/quiztest/quiztest.asp?qtest=SQL

▪️TutorialsPoint SQL Quiz
https://www.tutorialspoint.com/sql/sql_online_quiz.htm

▪️GeeksforGeeks — SQL Basics Quizzes
https://www.geeksforgeeks.org/sql-mcq/

Эти ресурсы помогут как в ежедневной практике, так и в подготовке к собеседованиям.

Приёмы в работе с нейросетями. Шпаргалка для QA инженеров

Источник

Работа с ChatGPT и другими нейросетями может стать настоящим ускорителем для QA. Но многое зависит от того, как именно формулировать запросы. Ниже набор практичных приёмов, которые помогут получать более точные, полезные и структурированные ответы если добавлять их в начало промпта.

🥎 1. only code
Если нужно только решение в коде (без воды и комментариев), начинайте запрос с этого слова. Удобно для сниппетов автотестов или SQL-запросов.

🎾 2. explain code
Используйте, когда хотите понять незнакомый участок кода или SQL. Нейросеть разберёт всё построчно и объяснит, что и зачем используется. Отлично подходит для изучения автотестов или чужих скриптов.

🎈 3. best practice
Добавляйте к запросу, если хотите получить решение по лучшим практикам: например, как правильно оформить Page Object в Playwright или структуру API-тестов.

⚾️ 4. senior mode
Формулируйте запрос так, будто вам отвечает синьор QA/разработчик. Ответы будут глубже и с пояснениями «почему именно так».

🍬 5. simple 10
Если тема сложная (например, про SLA/OLA или баг-трекинг), добавьте это и получите объяснение простыми словами, как для 10-летнего ребёнка.

🍪 6. fix my bug
Подходит, когда у вас падает автотест или SQL-запрос. Нейросеть предложит исправления. Работает не всегда идеально, но может подсветить, где ошибка.

💠 7. optimize for performance
Нужен для случаев, когда вы сомневаетесь, что ваш тест или скрипт написан оптимально. Сеть предложит более быстрые или лаконичные варианты.

🍭 8. add comments
Приём для длинных кусков кода. Нейросеть разобьёт их на логические блоки с комментариями, что облегчает ревью и поддержку автотестов.

🐙 9. generate test cases
Нейросеть умеет быстро накидывать тест-кейсы по описанию функционала. Достаточно написать:
generate test cases for password recovery form
И вы получите набор позитивных и негативных сценариев.

🧊 10. bug report format
Если нужно красиво оформить дефект, пишите:
bug report format: login button not clickable
И получите баг-репорт с шагами, фактическим/ожидаемым результатом.

🍩 11. qa checklist
Запрос вида:
qa checklist for e-commerce cart page
Сгенерирует список проверок для функционала, экономя время на подготовке.

🧁 12. compare
Хорошо работает для сравнения инструментов:
compare Cypress vs Playwright for e2e testing
В результате получите таблицу с плюсами и минусами.

🍼 13. mock data
Используйте для генерации тестовых данных: пользователей, заказов, JSON-ответов. Особенно удобно для нагрузочного или интеграционного тестирования.

⚡️ Примечание:
only code (с пробелом, в нижнем регистре) работает наиболее стабильно.
CodeOnly тоже понимается, но иногда GPT добавляет лишние слова.
code_only срабатывает хуже, и может появляться объяснение вместе с кодом.