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

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

Собрал для вас подборку шпаргалок для изучения и написания локаторов. Хpath и CSS. QApedia | QApedia в MAX