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

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

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

Все пишут посты о том, что 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️⃣ Знать конкретный стек ком

Что 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, найти нужную запись, понять взаимосвязи между таблицами — да. Оптимизировать сложные зап

Что 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 и ещё десяти направлениям. Он должен поним

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

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