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

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

Я QA-инженер с опытом работы более 10 лет и я считаю, что… 1️⃣ Если тестировщик остался в ручном тестировании и не ушел в автоматизацию, это не значит, что он застрял в карьере. 2️⃣ Есть проекты, где автоматизация приносит больше «вреда», чем пользы. 3️⃣ Некоторые баги лучше оставить как есть. 4️⃣ ИИ не заменил тестировщиков и не уменьшил их работу, а местами даже добавил ее. 5️⃣ Soft skills влияют на карьеру сильнее, чем знание еще одного инструмента. 6️⃣ Большинство ошибок начинаются не в коде, а в требованиях. 7️⃣ Ты можешь быть сильным тестировщиком, но не разбираться в конкретной предметной области проекта, и из-за этого быть слабым сотрудником. 8️⃣ Если кандидат после собеседования оказался слабым QA, возможно, дело не в его навыках, а в плохом онбординге (сам был свидетелем такой ситуации). 9️⃣ Задавать базовые теоретические вопросы на собеседовании не нужно. 🔟 Релиз - это не отсутствие багов, это управление рисками. QApedia | QApedia в MAX

⚡️Хотите понять, как объединить UI и API-тесты в одном инструменте и писать надёжные автотесты на Python без лишних сложностей? 30 июля в 20:00 МСК разберём Playwright: от ключевых сущностей до реальных примеров. На уроке покажем, как написать UI-тест и API-тест на Python, объясним, где Playwright выигрывает и как ускорить проверку приложения. Урок полезен инженерам по автоматизации на Python, специалистам с других языков и новичкам — получите чёткие шаблоны и понимание, как применять Playwright в реальных проектах. ⏰Открытый урок пройдёт в преддверии старта курса «Автоматизатор тестирования на Python». Это возможность оценить глубину и практическую пользу обучения. Зарегистрируйтесь: https://clck.ru/3UuFNF Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

🤔 Тестировщиков скоро заменит искусственный интеллект? Этот вопрос всё чаще задают те, кто только выбирает профессию или планирует перейти в сферу обеспечения качества. Но реальность намного интереснее громких прогнозов. 16 июля в 20:00 МСК приглашаем вас на открытый урок, где мы разберём, что искусственный интеллект уже умеет в тестировании, где ошибается и почему роль специалиста по качеству становится не менее, а более значимой. На занятии поговорим о новых инструментах, ИИ-агентах, изменении требований работодателей, востребованных навыках и новых направлениях развития. Вы получите объективную картину рынка без мифов и страшилок, а также поймёте, на что делать ставку уже сейчас. 👉Открытый урок проходит в преддверии старта курса «Инженер по тестированию». Если хотите осознанно вкатиться в профессию и понимать её перспективы в ближайшие годы — примите участие: https://clck.ru/3Uck4V Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Всем привет, решил в середине недели порадовать вас рубрикой #фильмыQApedia . Сегодня на повестке дня «Blackhat» - фильм исследует мир глобальной киберпреступности через историю осуждённого хакера, которого привлекают к международной охоте на опасного кибертеррориста. QApedia | QApedia в MAX

Работать тестировщиком в аутстаф-компании в 2026 году — стрём или норм? Кажется, рынок снова разделился на два лагеря… Одни говорят: «Аутстаф — это лучший способ быстро расти. Разные проекты, разные команды, нет застоя.» Другие: «Ты просто "арендованный разработчик". Сегодня проект есть, завтра нет. Никакой стабильности и ощущения, что ты часть продукта.» Я за последние годы увидел обе стороны и сегодня хочу выделить несколько плюсов и минусов работы в аутстафе, не поддерживая ни одну из сторон. Что мне реально нравится в аутстафе: 😊 Можно за пару лет набраться опыта на нескольких проектах. 😊 Обычно выше зарплата, чем в продукте на аналогичной позиции. 😊 Есть шанс поработать с крутыми международными командами. 😊 Не успеваешь выгореть от одного и того же продукта. Что бесит: Ты часто "не свой" в команде. 😟 На многих проектах QA воспринимают как расходник. 😟 Постоянно нужно адаптироваться к новым процессам. 😟 Если клиент режет бюджет — именно аутстаф часто первым попадает под сокращение. Лично для себя я не рассматриваю аутстаф, потому что я реально проникаюсь продуктом. Мне тяжело каждый раз прыгать с проекта на проекта и закладывать время и энергию на адаптацию. Мне интересно ваше мнение. Если бы вы сегодня выбирали работу, что бы предпочли: аутстаф с зарплатой на 20–30% выше или продукт с более спокойной жизнью и долгосрочной перспективой. Голосуйте 👇🏻

📚 Приложение может работать без ошибок, но всё равно раздражать пользователей: непонятная навигация, неудобные формы, неочевидные жесты, странные сообщения об ошибках. Такие проблемы редко находят обычные функциональные проверки. 30 июня в 20:00 МСК приглашаем вас на открытый урок, где разберём, как системно оценивать удобство мобильного приложения без сложных программ и долгой подготовки. На занятии покажем, чем UI отличается от UX, какие ошибки чаще всего мешают пользователям и как проверять навигацию, жесты, формы ввода, сообщения об ошибках и адаптивность. Участники получат готовый список проверок для практики. Открытый урок проходит в преддверии старта курса «Инженер по тестированию». 👉Зарегистрируйтесь, чтобы научиться видеть приложение глазами пользователя и аргументировать UX-проблемы перед командой: https://clck.ru/3ULkkd Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Я заметил, что опытные тестировщики реже ходят на собеседования 🤔 Часто после 3–5 лет работы появляется ощущение стабильности: есть знакомый проект, понятные процессы, команда, хорошая зарплата. И постепенно собеседования уходят из жизни. Но есть одна проблема. Собеседование — это навык и если не использовать его несколько лет, он начинает проседать. Можно быть сильным специалистом, отлично разбираться в продукте, автоматизации и процессах, но растеряться на интервью из-за простых вопросов. Я видел ситуации, когда человек не проходил собеседования не потому, что ему не хватало знаний, а потому что он давно не рассказывал о своем опыте и не был готов к формату интервью. Поэтому я считаю полезным хотя бы иногда выходить на рынок: 1️⃣ понимать, какие технологии сейчас востребованы; 2️⃣ узнавать свою рыночную стоимость; 3️⃣ видеть, каких навыков не хватает; 4️⃣ поддерживать навык прохождения собеседований. Это не значит, что нужно срочно менять работу. Но иногда одно собеседование может дать больше информации о рынке, чем десятки статей и постов. Если было полезно, буду рад реакции 👇