QApedia | Тестирование

🎥 Вебинар: «Стабильность команды и взаимозаменяемость людей» На уроке разберём,  как построить устойчивую команду, где люди взаимозаменяемы, а лидер может делегировать и развивать будущих лидеров. Разберём, кто такие T-shaped специалисты, как работает шаринг знаний и почему важно растить «свою замену», чтобы команда сохраняла продуктивность даже в кризисных ситуациях. О чем поговорим: - Основы взаимозаменяемости и устойчивости команды - T-shaped специалисты и их роль в QA  -Шаринг знаний и делегирование - Рост своей замены и гибкий старт внедрения практик 🧠 Вебинар приурочен к старту курса «Руководитель группы тестирования (QA Lead)». Вы научитесь формировать команду, оценивать эффективность сотрудников, выстраивать процессы тестирования, рассчитывать трудозатраты, внедрять практики контроля качества, работать с метриками и оценивать результат изменений. Отдельное внимание уделяется взаимодействию с руководством, заказчиками и другими участниками проектов. 👉 Для участия зарегистрируйтесь: https://clck.ru/3WXKkR Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Объем российского рынка больших данных и искусственного интеллекта в 2025 году — 520 млрд ₽. По оценке аналитиков, к 2030 году вырастет почти в три раза Вокруг этой сферы складываются новые профессии и расширяются существующие. Аналитик данных — одна из них. Работа с цифрами и систематизация информации — то, что в этих ролях нужно каждый день. Как устроена эта работа и насколько она близка к вашей разберут 7 октября в 19:00 мск karpovꓸcourses на бесплатном вебинаре «Как работает аналитик данных: пробуем инструменты и типовые задачи». На вебинаре вы:  - разберетесь в особенностях профессии и специализациях внутри аналитики;  - на конкретных примерах познакомитесь с задачами аналитика данных; - на практике в Excel посмотрите, как решают типовые запросы бизнеса. Ведет Ксения Колодницкая — продуктовый аналитик в компании «Звук», преподаватель karpovꓸcourses. Раньше работала старшим аналитиком данных в Ozon Fresh и старшим продуктовым аналитиком в Invitro. Проверьте, ваше ли это, на реальных задачах: https://clc.to/erid_2W5zFK8gSHP  Участникам — гид по профессиям в сфере данных и запись эфира Реклама. ООО «КАРПОВ КУРСЫ». ИНН 7811764627. erid: 2W5zFK8gSHP 

Я QA-инженер с опытом работы более 10 лет, и я считаю, что… (часть 2, первая вам очень понравилась) 🫶 1️⃣ Тестировщик не обязан находить все баги. Он должен помогать команде понимать, какие риски мы пропускаем и чем это грозит. 2️⃣ Хороший тестировщик — не тот, кто пишет больше тест-кейсов, а тот, кто умеет находить проблемы с минимальными затратами времени. 3️⃣ 100% покрытия автотестами не гарантируют качество продукта. Можно покрыть тестами весь код и при этом упустить главную проблему пользователя. 4️⃣ Умение воспроизвести баг — это ещё не умение его исследовать. Настоящая работа начинается, когда ты пытаешься понять закономерности и сузить круг возможных причин. 5️⃣ Тестировщик, который не умеет объяснять свои выводы простым языком, может проиграть в эффективности тому, кто технически знает меньше, но умеет доносить суть. 6️⃣ Тест-кейсы могут устаревать быстрее, чем приносить пользу. Если команда годами прогоняет один и тот же набор проверок и не пересматривает его, это уже не гарантия качества, а привычка. 7️⃣ Знать SQL, API и инструменты автоматизации полезно. Но умение разобраться, что именно может пойти не так в продукте, часто ценнее знания очередного инструмента. 8️⃣ Тестировщик, который всегда соглашается с разработчиком, не обязательно командный игрок. А тот, кто спорит, не обязательно конфликтный. Важнее аргументы, факты и общая цель. 9️⃣ Хорошее тестирование иногда означает не добавить новые проверки, а удалить десятки бесполезных. Количество тестов само по себе ничего не говорит об их ценности. 🔟 QA не должен быть единственным человеком, ответственным за качество. Если вся команда считает, что качество — это задача тестировщика, проблема уже не в тестировании, а в культуре разработки. QApedia | QApedia в MAX

Сам себя завалил на собеседовании 😢 Я провёл довольно много собеседований, и когда меня спрашивают, как успешно пройти собес, мне сложно дать какой-то универсальный совет. У всех разные требования, а у каждого интервьюера — свои ожидания. Кто-то ценит инициативность, кто-то — скорость реакции, кто-то обращает внимание на ход мыслей, а кому-то важнее конкретные технические знания. Поэтому клишированные советы вроде «будьте уверены в себе», «проявляйте инициативу» работают далеко не всегда. Но за время работы я накопил несколько историй, одной из них хочу сегодня поделиться. На первый взгляд, это может показаться очевидными, но, как мне кажется, здесь кроется простая и важная мысль о собеседованиях, о которой мы часто забываем. Как-то я проводил собеседование с несколькими коллегами. Всё шло отлично: кандидат на вопросы отвечал уверенно, с задачами справлялся, контакт с нами нашёл. В общем, я думал, что оффер у него в руках. И вот собеседование подходит к концу. Интервьюеры спрашивают, есть ли что добавить. И он решает немного усилить свою позицию: — Кстати, я ещё с SQL работал! Мы оживились: — О, SQL! А мы как раз забыли тебя про него спросить! И понеслось…👊 Вопросы, запросы, нюансы — а уверенность с каждым ответом тает на глазах. Оказалось, что SQL он знает не настолько хорошо, чтобы уверенно отвечать на всё, о чём его начали спрашивать. Итог? Собеседование, которое шло очень хорошо, закончилось отказом. По обратной связи, именно SQL стал решающим фактором. ✅ Мораль: отвечай только на то, о чем тебя спрашивают. Чем больше ты начинаешь расширять «программу собеседования», тем выше вероятность, что тебе зададут вопрос, на который ты не сможешь ответить. Если тебя не спросили про технологию, не всегда нужно самому поднимать эту тему — особенно если знания пока поверхностные. Не создавай себе дополнительные сложности там, где их могло и не быть. Вот такой вас совет) Если было полезно, ставь реакцию 👍

Сам себя завалил на собеседовании Я провёл довольно много собеседований, и когда меня спрашивают, как успешно пройти собес, мне сложно дать какой-то универсальный совет. У всех разные требования, а у каждого интервьюера — свои ожидания. Кто-то ценит инициативность, кто-то — скорость реакции, кто-то обращает внимание на ход мыслей, а кому-то важнее конкретные технические знания. Поэтому клишированные советы вроде «будьте уверены в себе», «проявляйте инициативу» работают далеко не всегда. Но за время работы я накопил несколько историй, одной из них хочу сегодня поделиться. На первый взгляд, это может показаться очевидными, но, как мне кажется, здесь кроется простая и важная мысль о собеседованиях, о которой мы часто забываем. Как-то я проводил собеседование с несколькими коллегами. Всё шло отлично: кандидат на вопросы отвечал уверенно, с задачами справлялся, контакт с нами нашёл. В общем, я думал, что оффер у него в руках. И вот собеседование подходит к концу. Интервьюеры спрашивают, есть ли что добавить. И он решает немного усилить свою позицию: — Кстати, я ещё с SQL работал! Мы оживились: — О, SQL! А мы как раз забыли тебя про него спросить! И понеслось… Вопросы, запросы, нюансы — а уверенность с каждым ответом тает на глазах. Оказалось, что SQL он знает не настолько хорошо, чтобы уверенно отвечать на всё, о чём его начали спрашивать. Итог? Собеседование, которое шло очень хорошо, закончилось отказом. По обратной связи, именно SQL стал решающим фактором. Мораль: отвечай только на то, о чем тебя спрашивают. Чем больше ты начинаешь расширять «программу собеседования», тем выше вероятность, что тебе зададут вопрос, на который ты не сможешь ответить. Если тебя не спросили про технологию, не всегда нужно самому поднимать эту тему — особенно если знания пока поверхностные. Не создавай себе дополнительные сложности там, где их могло и не быть. Вот такой вас совет) Если было полезно, ставь реакцию)

7 шагов, как стать вайб-тестировщиком 1️⃣ Разобраться с ИИ Для начала советую разобраться с ChatGPT, Claude или другой LLM. Учитесь не просто задавать вопросы, а давать контекст, ставить задачу, прикладывать требования, логи, API-ответы, куски кода и получать от ИИ что-то действительно полезное. На этом этапе можно уже использовать ИИ для: 🟡 анализа требований; 🟡поиска неочевидных сценариев; 🟡 генерации тестовых данных; 🟡составления чек-листов; 🟡анализа багов и логов. 2️⃣ Научиться тестировать вместе с ИИ Здесь уже интереснее. Берём обычную задачу тестировщика и пытаемся пройти её вместе с ИИ. Например, есть форма регистрации. Мы делаем запрос не просто: «Напиши тесты для регистрации». А заставляем ИИ подумать вместе с нами: «Какие здесь могут быть риски? Что я мог не учесть? Какие edge cases стоит проверить? Какие негативные сценарии ты бы предложил?» То есть ИИ становится не генератором тест-кейсов, а второй парой глаз. 3️⃣ Подключить API, SQL и DevTools Если ты пока плохо дружишь с API, SQL и DevTools — самое время подтянуть эти вещи. Причём здесь ИИ очень хорошо помогает. Можно попросить объяснить HTTP-запрос, написать SQL, разобрать response, найти проблему в логах или объяснить ошибку. Главное — не просто копировать ответ, а понимать, что именно происходит. 4️⃣ Перейти к автотестам Вот здесь начинается самое интересное. Берём Playwright, Cypress, Selenium или другой инструмент и начинаем писать автотесты вместе с ИИ. Ты описываешь, что хочешь проверить ➡️ ИИ предлагает код ➡️ ты запускаешь ➡️ получаешь ошибку ➡️ отдаёшь её ИИ ➡️ разбираетесь, что произошло. Постепенно ты начинаешь понимать код, даже если раньше программирование было не твоей сильной стороной. 5️⃣ Перейти из чата в AI IDE Следующий уровень — Cursor, Claude Code, GitHub Copilot и другие инструменты. Вместо того чтобы постоянно копировать куски кода в чат, ты работаешь непосредственно с проектом. Например: «Посмотри существующие тесты и добавь тесты для нового endpoint». ИИ изучает проект, предлагает изменения, а ты их проверяешь и направляешь. 6️⃣ Начать давать ИИ большие задачи Вот тут уже можно почувствовать настоящий вайб. Например: «Изучи этот функционал. Найди потенциальные риски. Составь стратегию тестирования. Предложи набор проверок для API и UI. После этого создай автотесты для наиболее критичных сценариев». Ты уже не просишь ИИ сделать одну маленькую задачу, ты управляешь процессом, а ИИ выполняет большую часть технической работы. 7️⃣ Сделать свой pet-project И вот это я бы точно не пропускал. Берём какой-нибудь небольшой проект и самостоятельно проходим весь путь: требования ➡️ анализ ➡️тест-дизайн ➡️ API ➡️ UI ➡️ автотесты ➡️ поиск багов ➡️ анализ результатов с помощью ИИ. Именно на практике становится понятно, чего тебе реально не хватает. А дальше можно усложнять. Добавлять CI/CD, работу с Git, генерацию тестовых данных, анализ падений, отчёты и постепенно собирать собственный AI QA workflow. Очень часто думают, что вайб-тестирование для тех, кто не умеет программировать, поэтому ждут, что ИИ все сделает за них. На самом вы должны знать, что нужно проверять, уметь поставить задачу ИИ, оценить результат и знать, когда он ошибается. Поэтому я бы не советовал бросаться сразу в Cursor и пытаться построить «автономного AI-тестировщика». 1️⃣Сначала база QA 2️⃣Потом ИИ 3️⃣Потом автоматизация 4️⃣Потом AI IDE 5️⃣И только после этого полноценный вайб-тестинг.

🎥 Вебинар: «Онбординг QA-инженера: воркшоп по планированию первых 90 дней» На уроке разберём, как выстроить онбординг QA-инженера с учётом задач команды, особенностей проекта и потребностей нового сотрудника. О чем поговорим: • Онбординг и адаптация: в чём разница • Модель 30–60–90 дней • Что необходимо подготовить для онбординга QA-инженера • Материалы, инструменты и ресурсы для нового сотрудника • Первые рабочие активности и критерии готовности к самостоятельной работе • Как учитывать ограничения при планировании онбординга • Как отслеживать прогресс сотрудника • Как представить и аргументировать план онбординга ⚠ Это будет не лекция, а практический воркшоп: участники вместе с экспертом пройдут основные этапы разработки плана онбординга и в процессе создадут собственный вариант для выбранной роли и проекта. Поработаем с моделью 30–60–90 дней, определим необходимые материалы, инструменты и первые рабочие активности, а затем сформулируем критерии готовности сотрудника к самостоятельной работе. 🧠 Вебинар приурочен к старту курса «Руководитель группы тестирования (QA Lead)». Вы научитесь формировать команду, оценивать эффективность сотрудников, выстраивать процессы тестирования, рассчитывать трудозатраты, внедрять практики контроля качества, работать с метриками и оценивать результат изменений. Отдельное внимание уделяется взаимодействию с руководством, заказчиками и другими участниками проектов. 👉 Для участия зарегистрируйтесь https://clck.ru/3WBtJJ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

⚡️⚡️Тестирование, ИИ и автоматизация: о чем будут говорить на Heisenbug 2026 16–17 октября в Санкт-Петербурге и онлайн пройдет Heisenbug 2026 Autumn — крупнейшая в России конференция по тестированию программного обеспечения. В программе — доклады для QA-инженеров, разработчиков, тимлидов и руководителей, с фокусом на практические инженерные задачи. За десять лет QA успел автоматизировать тесты, потом часть разработки, а теперь отдает часть задач агентам. Поэтому сегодня важно не только ускорять тестирование, но и понимать, насколько можно доверять его результатам. В программе Heisenbug этой осени — быстрые интеграционные тесты, Data Quality, AI-агенты для QA, тестирование ИИ-систем, надежность и ограничения тестового покрытия.  Полная программа и расписание — в карточках и на сайте конференции. Также приглашаем принять участие в опросе State of Testing — масштабном исследовании о том, что тормозит развитие QA и как индустрия использует ИИ. Первые результаты представят на открытии конференции, а затем пришлют подробный отчет с графиками всем участникам на email. Среди участников опроса пройдёт розыгрыш билетов на Heisenbug 2026 Autumn. 🌟А если вы хотите приобрести персоанльнй билет уже сейчас, то по промокоду [ПРОМОКОД] можно его купить со скидкой Купить билет

😎 Команда тестирования тратит слишком много времени на создание автотестов, а автоматизация не успевает за разработкой? На вебинаре покажем, как с помощью ИИ пройти путь от тест-кейса до готового автотеста за 10 минут и разберём, какие этапы тестирования можно ускорить в разы. ⌨ На практикуме разберём: — как быстро превратить тест-кейс в готовый автотест; — как меняется работа инженера по тестированию; — как ИИ стабилизирует сценарии на основе данных прошлых запусков; — как оптимизировать работу команды без увеличения нагрузки. Спикеры — Иван Степнов, руководитель продукта в Test AI и Павел Никулин (BDM). Более 10 лет в IT, работали над внедрениями для IKEA, GAP, Tesla, Agilent, Joom. 📅 Дата: 10.09 ⏰ 16:00 (мск) 💻 Онлайн ⏱️ Длительность: 45мин Для руководителей QA и специалистов по тестированию: покажем на практике, как оптимизировать время команды, быстрее создавать автотесты и ускорить весь процесс тестирования. 👉 Зарегистрироваться: https://clck.ru/3VckhH Реклама. ООО «СмартДев». ИНН: 9727099535. erid: CQH36pWzJqVKj6KkyXS2czMAHpEZdGpZmuii6EfQNgrA9j

Твоему проекту нужен AI-агент, если… 🤔 Я не из тех тестировщиков, кто будет советовать внедрять AI в проект, потому что он сейчас в тренде, у этого должен быть смысл, например, если в проекте есть процессы, которые уже давно хочется автоматизировать, но обычных скриптов для них недостаточно. Несколько признаков, что ваш проект нуждается в AI-агенте: 1️⃣ В проекте есть процессы, которые запускаются по одному и тому же сценарию Например: появляется новая задача, нужно собрать контекст, изучить требования, найти связанные изменения, проверить существующие тесты и подготовить список проверок. Если каждый раз приходится проходить примерно один и тот же маршрут, стоит задуматься: обязательно ли этот маршрут должен проходить человек? Агент может самостоятельно пройти большую часть этого пути, а тестировщик подключится там, где нужны экспертиза и финальное решение. 2️⃣ На подготовку тестов уходит слишком много времени Иногда сама проверка занимает 10 минут, а подготовка к ней — час. Нужно прочитать требования, разобраться в изменениях, найти похожие тесты, вспомнить старые баги и подумать об edge cases. В таком случае агент может собрать необходимый контекст, предложить сценарии и подсветить потенциальные проблемные места. А QA уже решает, что действительно стоит тестировать. 3️⃣ Чтобы ответить на простой вопрос, приходится искать информацию в пяти местах Jira, Confluence, Git, Swagger, тестовая документация, история багов… Если на вопрос «что здесь должно происходить?» приходится открывать несколько систем и собирать информацию вручную — это хороший кандидат для агента. Он может сам найти нужный контекст в доступных источниках и собрать его в одну понятную картину. 4️⃣ Вы постоянно принимаете одни и те же решения по одним и тем же правилам Например: «Если баг воспроизводится на двух окружениях — повышаем приоритет». Если опытный QA может сказать новичку: «в таких случаях делай вот так», значит часть этой логики уже можно формализовать. А формализуемую логику потенциально можно передать агенту. 5️⃣ Агент может не просто ответить, а выполнить целую цепочку действий И вот это, пожалуй, самый важный критерий. Чат-бот может сказать:«Похоже, автотест упал из-за изменения API». А агент потенциально может сам: 🟤получить информацию о падении 🟤найти задачу в Jira 🟤посмотреть изменения в Git 🟤изучить логи 🟤сравнить с предыдущими запусками 🟤сформировать гипотезу 🟤подготовить комментарий или баг-репорт. То есть агент не просто генерирует ответ, а действует внутри вашего процесса. Но есть важный нюанс: не каждую рутину стоит превращать в AI-агента. Если задачу можно надёжно решить обычным скриптом или автоматизацией — возможно, они будут проще, дешевле и стабильнее. А вот если процесс требует контекста, нескольких шагов, работы с разными источниками и принятия решений по ходу выполнения — тогда уже действительно стоит присмотреться к AI-агенту. Если было полезно, буду рад реакции 👍

9 ситуаций из работы тестировщика, где ИИ реально помогает 😈 1️⃣ Мне дали новую фичу, а требования сырые Кидаю ИИ user story и прошу найти противоречия, пропуски и вопросы, которые нужно задать аналитику. 2️⃣ Не понимаю, что именно тестировать в сложной бизнес-логике Описываю правила и прошу разложить их на классы эквивалентности, границы и комбинации условий. 3️⃣ У меня уже есть тест-кейсы, но я боюсь что-то пропустить Передаю их ИИ и прошу выступить в роли «враждебного ревьюера»: найти непокрытые сценарии и слабые проверки. 4️⃣ Нужно быстро придумать негативные сценарии Даю happy path и спрашиваю: «Как можно сломать этот сценарий? Какие данные и последовательности действий пользователь может использовать?» 5️⃣ Пришел непонятный API-ответ Передаю request, response, статус-код и логи. Прошу построить несколько гипотез причины и сказать, какие проверки помогут их подтвердить. 6️⃣ Нужно проверить данные в БД Описываю, что должно происходить с данными после действия пользователя, и прошу написать SQL для проверки. Потом вручную проверяю сам запрос. 7️⃣ Пишу или поддерживаю автотесты Даю ИИ тест и требования и спрашиваю: какие assertions отсутствуют, где тест может быть flaky и что он на самом деле проверяет. 8️⃣ Есть странный баг, который проявляется только иногда Прошу ИИ помочь построить матрицу условий, учитывая браузер, операционную систему, тестовые данные, последовательность действий пользователя, состояние аккаунта и время выполнения сценария. Это помогает системно перебрать возможные комбинации и найти условия, при которых возникает проблема. 9️⃣ Перед релизом нужно понять, где самые большие риски Даю список изменений и прошу оценить, какие области продукта могут быть затронуты косвенно и что проверить в первую очередь. QApedia | QApedia в MAX

Что Senior QA НЕ обязан знать в 2026 году? Продолжаю тему про уровни QA. После постов про Junior и Middle логичный вопрос: а что тогда с Senior? Потому что требования к Senior QA иногда выглядят примерно так: «Нам нужен человек, который пишет автотесты, знает 3 языка программирования, администрирует Kubernetes, разбирается в Kafka, умеет проводить нагрузочное тестирование, знает security, умеет строить CI/CD, понимает микросервисы, облака, базы данных, Scrum, DevOps и умеет читать мысли разработчиков» 🙄 Но Senior QA тоже НЕ ОБЯЗАН: 1️⃣ Знать абсолютно все технологии Senior — это не энциклопедия технологий. Он может не знать конкретный инструмент, фреймворк или технологию, с которой раньше не сталкивался. Гораздо важнее способность быстро разобраться: 🟡как это работает; 🟡какие здесь риски; 🟡что и как нужно тестировать; 🟡где искать информацию; 🟡когда нужно привлечь другого специалиста. Senior отличается скоростью и качеством решения новых задач. 2️⃣ Быть лучшим автоматизатором в команде Senior QA может отлично разбираться в автоматизации, но Senior ≠ Automation Engineer. Если в команде есть сильный Automation QA, Senior не обязан писать больше всех автотестов или самостоятельно строить весь automation framework. Его задача шире — понимать, где автоматизация действительно принесёт пользу, как она должна быть встроена в стратегию тестирования и какие проблемы качества она должна решать. 3️⃣ Знать DevOps на уровне DevOps-инженера Senior QA должен понимать инфраструктуру настолько, насколько это необходимо для качественного тестирования продукта. Docker, Kubernetes, CI/CD, логи, мониторинг, окружения — да, понимать принцип работы очень полезно. Но проектировать production-инфраструктуру, поддерживать Kubernetes-кластеры и решать все DevOps-задачи Senior QA не обязан. 4️⃣ Быть экспертом во всех видах тестирования Senior не обязан одновременно быть специалистом по Performance, Security, Accessibility, Mobile, API, Automation и ещё десяти направлениям. Он должен понимать ограничения разных подходов и уметь определить, какая экспертиза нужна конкретной задаче. 5️⃣ Никогда не ошибаться Senior — не человек, который всегда принимает идеальные решения. Гораздо важнее, чтобы Senior умел: 🟤признать ошибку; 🟤понять, почему она произошла; 🟤исправить ситуацию; 🟤сделать выводы; 🟤изменить процесс так, чтобы проблема не повторялась. 6️⃣ Знать продукт лучше всех Senior QA действительно должен глубоко понимать продукт. Но он не обязан знать каждую бизнес-деталь лучше Product Manager или каждую техническую деталь лучше разработчика. Его задача — видеть продукт с точки зрения качества: 🟡где пользователь может столкнуться с проблемой; 🟡какие сценарии критичны; 🟡какие изменения могут повлиять на другие части системы; 🟡где находятся основные риски. 7️⃣ Быть руководителем Senior QA может быть отличным техническим специалистом и при этом не хотеть становиться Team Lead или Manager. Senior может влиять на команду через экспертизу, решения, инициативу и помощь другим, не имея формальной руководящей роли. 8️⃣ Постоянно писать код У Senior QA может быть меньше кода, чем у Middle. И это нормально. Чем выше уровень, тем больше времени может уходить на: 🟢анализ рисков; 🟢планирование тестирования; 🟢исследование сложных проблем; 🟢работу с архитектурой; 🟢улучшение процессов; 🟢обсуждение решений с командой; 🟢менторинг; 🟢предотвращение проблем, а не только их поиск. Количество написанного кода само по себе не определяет уровень QA. Поэтому главный показатель Senior QA в 2026 году опять же не количество технологий в резюме, а способность: ✅ видеть систему целиком; ✅ управлять рисками; ✅ принимать решения в условиях неопределённости; ✅ влиять на качество продукта; ✅ замечать проблемы ещё до этапа тестирования; ✅ влиять на технические и продуктовые решения; ✅ помогать команде становиться сильнее; ✅ брать ответственность за результат; ✅ понимать, когда нужно копать глубже, а когда достаточно простого решения. Senior QA — это специалист, который отвечает не только за качество своей работы, но и за качество подхода команды к продукту 👍 QApedia | QApedia в MAX

Айтишников начали проверять на полиграфе, а за отказ грозят увольнением. Здравствуйте, приехали! Причиной стали участившиеся случаи завышения опыта и упоминания несуществующих проектов в резюме. В одной из российских компаний сотрудника уже заподозрили в фальсификации опыта, утечке информации и злоупотреблении удалённой работой. Теперь проверки на детекторе лжи могут стать более распространённой практикой в IT-сфере. QApedia | QApedia в MAX

🔥 Хотите ускорить создание автотестов и понять, как использовать ИИ без лишней зависимости от облачных сервисов? 20 августа в 20:00 МСК на открытом уроке разберём, как применять локальные большие языковые модели для генерации тест-кейсов под задачи автоматизации тестирования. Покажем, какие сценарии стоит передавать локальным моделям, как встроить их в рабочий процесс и распределять задачи между локальными и облачными ИИ-инструментами. Вы также узнаете, как сократить рутинную работу и быстрее переходить от тестового сценария к автотесту. ⏰Открытый урок пройдёт в преддверии старта курса «Автоматизатор тестирования на Python». Регистрируйтесь, чтобы эффективнее использовать ИИ в тестировании и внедрить современные подходы в ежедневную практику: https://clck.ru/3VBvgF Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Что Middle QA НЕ обязан знать в 2026 году?😮 Продолжаю тему прошлой недели: мы обсуждали, что не должен знать Junior, сегодня обсудим Middle. Иногда смотришь требования к Middle QA и создаётся ощущение, что ищут универсального инженера, который одновременно должен писать автотесты, администрировать Kubernetes, настраивать CI/CD, разбираться в Kafka, облаках, DevOps, безопасности и ещё желательно знать 5 языков программирования. Но на самом дела Middle НЕ ОБЯЗАН: 1️⃣ Быть экспертом в автоматизации Middle QA должен понимать автоматизацию и, в зависимости от роли, уметь работать с автотестами. Но Middle не обязан строить с нуля огромный automation framework, писать собственные библиотеки и разбираться во всех паттернах автоматизации. Гораздо важнее понимать: 🟡что и зачем автоматизировать; 🟡какие проверки лучше оставить ручными; 🟡как поддерживать существующие автотесты; 🟡почему тесты падают и что с этим делать. 2️⃣ Знать несколько языков программирования Знание Python + Java + JavaScript + C# выглядит красиво в резюме. Но хороший Middle QA вполне может глубоко знать один язык и использовать его в работе. Гораздо важнее не количество языков, а способность читать код, понимать логику приложения и при необходимости самостоятельно разобраться в новом инструменте. 3️⃣ Уметь администрировать Kubernetes Да, Middle QA может работать с Docker, Kubernetes и другими инфраструктурными инструментами. Но от него не обязательно ждать навыков полноценного DevOps-инженера. Понимать, где запущено приложение, как посмотреть логи, как работает контейнер и куда смотреть при проблеме — отлично. Самостоятельно проектировать Kubernetes-кластер — уже совсем другой уровень ответственности. 4️⃣ Быть экспертом в SQL Middle QA действительно должен уверенно работать с базами данных. Но знать SQL на уровне разработчика базы данных — совсем не обязательное требование. Уметь проверить данные, написать JOIN, найти нужную запись, понять взаимосвязи между таблицами — да. Оптимизировать сложные запросы и проектировать структуру базы — уже не обязательно входит в задачи QA. 5️⃣ Знать все виды тестирования Middle QA не обязан быть одновременно экспертом по Performance, Security, Accessibility, Mobile, API, Automation и ещё десятку направлений. Он должен понимать основные подходы к тестированию и уметь выбрать подходящий под конкретную задачу. Глубокая экспертиза во всех направлениях невозможна. Да и не нужна 🙄 6️⃣ Иметь опыт именно с вашим стеком Если человек работал с PostgreSQL, а у вас MySQL — это не значит, что он не сможет разобраться. На уровне Middle уже важна не только конкретная технология, но и способность переносить свои знания на новые инструменты. 7️⃣ Уметь делать абсолютно всё самостоятельно Вот это, пожалуй, один из самых больших мифов о Middle QA. Middle — это не человек, который никогда не задаёт вопросов. Наоборот, умение вовремя спросить, обсудить проблему с разработчиком или попросить помощи — это нормальная часть работы. Middle отличается не тем, что знает абсолютно всё, а тем, что умеет самостоятельно двигать задачу вперёд и понимать, когда нужна помощь. 8️⃣ Знать все процессы разработки наизусть Знать термины полезно. Но хороший Middle QA — это не человек, который может провести лекцию по Scrum. Важнее понимать, как реально устроен процесс в команде, какую роль QA играет в нём и как влиять на качество продукта, а не просто правильно произносить названия методологий. На мой взгляд, главный показатель Middle QA в 2026 году — не количество технологий в резюме. А способность: ✅самостоятельно разбираться в задачах; ✅находить и анализировать риски; ✅понимать продукт, а не только требования; ✅эффективно взаимодействовать с разработчиками и командой; ✅расследовать проблемы, а не просто заводить баги; ✅выбирать подход к тестированию; ✅объяснять, почему что-то нужно тестировать именно так; ✅быстро осваивать новые инструменты и технологии. Middle QA — это не человек, который знает всё, а тот, кто уже умеет думать как специалист и приносить пользу команде без постоянного контроля по сравнению с Junior)

Все пишут посты о том, что Junior QA обязан знать в 2026 году, чтобы его взяли на работу, а я решил пойти против течения, поэтому сегодня мы обсудим… Junior QA НЕ обязан знать в 2026 году? 🤔 Иногда я смотрю требования к вакансиям и кажется, что от начинающего тестировщика хотят сразу получить Middle: Python, Selenium, Docker, Kubernetes, Kafka, CI/CD, SQL, Linux, облака… И всё это — на стартовую позицию. Но далеко не всё из этого действительно необходимо Junior QA. 1️⃣ Писать автотесты Да, автоматизация — это большой плюс. Но Junior QA не обязан приходить на первую работу уже с опытом написания сложных автотестов. Гораздо важнее понимать: 🔵 зачем нужна автоматизация; 🔵 какие тесты имеет смысл автоматизировать; 🔵 какие риски она закрывает. 2️⃣ Знать несколько языков программирования Python, Java, JavaScript, C# — всё это полезно. Но знать сразу несколько языков не нужно. Лучше хорошо понимать один инструмент, который используется в проекте, чем поверхностно знать пять. 3️⃣ Разбираться в Docker и Kubernetes Сейчас эти технологии часто встречаются в вакансиях. Но Junior QA не обязан уметь поднимать Kubernetes-кластер или писать сложные Dockerfile. Понимать базовые вещи — отлично. Администрировать инфраструктуру — уже другая роль. 4️⃣ Знать все инструменты мониторинга Grafana, Kibana, Prometheus, Splunk… Хорошо, если QA знаком с ними. Но отсутствие опыта работы с конкретным инструментом не делает человека слабым тестировщиком. Главное — понимать, где искать информацию и какие данные могут помочь найти проблему. 5️⃣ Быть экспертом в SQL Уметь сделать SELECT и проверить данные — полезный навык. Но Junior не обязан писать сложные запросы с десятком JOIN и оптимизировать базы данных. Для этого есть другие специалисты. 6️⃣ Иметь опыт со всеми видами тестирования Performance, Security, Accessibility, Mobile, Automation… Невозможно в начале карьеры глубоко разбираться во всём. Лучше хорошо освоить базу и постепенно расширять кругозор. 7️⃣ Знать конкретный стек компании "У нас Angular, Kafka и PostgreSQL — значит нужен человек с опытом именно в этом". Для Junior это спорный подход. Хороший тестировщик способен изучить новый продукт и технологии, если есть фундамент. 8️⃣ Иметь сертификат ISTQB Сертификаты могут быть полезны. Но сертификат сам по себе не делает человека хорошим QA. Я бы выбрал кандидата, который умеет мыслить, задавать вопросы и искать проблемы, а не просто знает определения из учебника. На мой взгляд, главная задача Junior QA в 2026 году — построить крепкую базу: ✅ понимать процесс разработки; ✅ уметь тестировать; ✅ работать с основными инструментами; ✅ анализировать проблемы; ✅ постоянно учиться. Остальное приходит с опытом. Если был полезен, ставь реакцию!) 👍 QApedia | QApedia в MAX

Вчера я выложил факты, которые получили большой отклик, и решил разобрать один из них… 👇 «Если кандидат после собеседования оказался слабым QA, возможно, дело не в его навыках, а в плохом онбординге.» Я однажды наблюдал ситуацию, когда человек пришел в компанию с хорошим опытом и уверенно прошел все этапы отбора. Я был от него в восторге и вообще бы не подумал, что у нас могут возникнуть сложности в работе. Через некоторое время мнение в команде о нем резко изменилось: «не тянет, слабый тестировщик». Меня это удивило 🤔. Потому что человек, которого мы нанимали, и человек, которого обсуждали спустя время, будто были двумя разными людьми. Когда начали разбираться глубже, оказалось, что проблема была совсем не в его навыках, а в слабом онбординге. Никто не объяснил архитектуру продукта, не рассказал о внутренних процессах, не показал, как в команде принимаются решения и почему тестирование построено именно так. От человека ожидали результата, хотя не дали ему контекста. Новому сотруднику давали задачу и отправляли искать ответы в документации (только документация местами была устаревшей, лол 👎). Если он обращался к коллегам, те не всегда могли помочь и часто перенаправляли его к кому-то другому. В итоге значительная часть времени уходила не на тестирование и решение задачи, а на попытки найти актуальную информацию и понять, как вообще здесь всё устроено. В результате, сроки срывались, где-то страдало качество, а команда делала вывод: «Он работает недостаточно эффективно». Поэтому я считаю правильным, прежде чем делать выводы об эффективности сотрудника, выслушать его, разобраться, почему у него возникают сложности. Ведь онбординг нужен не просто для того, чтобы «показать проект». Он нужен, чтобы специалист мог как можно быстрее начать приносить пользу, а не тратить недели на поиск ответов, которые команда давно должна была систематизировать. Если пост был полезен, буду рад реакции!) 👍 QApedia | QApedia в MAX