Тестирование веб-сервисов *

В разработке качество часто ломается не только на самих багах — но и в тех местах, где работа переходит от одного этапа к другому без ясных условий. Задача уже поехала дальше, хотя acceptance criteria ещё сырые. Формально её можно тестировать, но по факту сначала нужно собирать контекст. Пайплайн зелёный, при этом важная проверка вообще осталась за его пределами.

Такие ситуации обычно показывают не частную ошибку, а устройство процесса в целом. Когда важные условия нигде не закреплены, команда расплачивается за это уточнениями, возвратами и лишней синхронизацией. И напротив — если критерии перехода определены заранее, работать проще. Поэтому Quality Gates для нас в Островке — не только способ ничего не упустить, но и понятный маркер того, насколько процесс разработки вообще выстроен и управляем. 

Форма у таких гейтов может быть разной: автоматическая проверка, правило в workflow или простой критерий готовности. Важно не как выглядит гейт, а какую точку неопределённости он закрывает.

Под катом — практический разбор того, что вообще можно считать Quality Gate, где такие механизмы реально работают и как подбирать их под задачи команды.

Привет! Меня зовут Артем Русов. Около 6 лет я занимаюсь обучением будущих теcтировщиков на платформах Stepik, Udemy и YouTube. И каждый день получаю вопросы о том: что там с тестированием и стоит ли начинать его изучать сейчас?

Сам я не смогу дать однозначный ответ: да или нет. Так что предлагаю ознакомиться с этой статьей всем заинтересованным, а уже в конце для себя принять окончательное решение.

Привет! Меня зовут Оля Шнайдер, я QA-инженер в Авито. В начале этого года я провела исследование рынка QA, чтобы понять, как сейчас работают тестировщики: с чем сталкиваются каждый день, что мешает в работе, а что, наоборот, помогает.

За последние годы роль QA заметно изменилась (или мне так хочется думать). От нас ждут большего — не только непосредственно тестирования и ответственности за результат, но и участия в процессах и много чего ещё. При этом сами процессы не всегда становятся лучше. 

Мне захотелось понять, как дела обстоят на самом деле: что именно выматывает в работе, где чаще всего возникают проблемы и какие решения помогут помочь. Всё самое интересное из исследования я собрала для вас в этой статье. 

Большинство UI-тестов флакают, медленно работают и в итоге отключаются в CI. Показываю альтернативу — изоляционные UI-тесты без стендов, таймингов и боли.

Недавно ISTQB выпустили новую версию сертификации Certified Tester AI Testing v2.0.
Я посмотрел обновлённый syllabus и решил разобрать, что там изменилось, куда сместился фокус и насколько новая версия действительно соответствует тому, что сейчас происходит в мире AI testing.

Привет, коллеги! Меня зовут Василь Хамидуллин, и я тестировщик в компании fuse8.

В этой статье я расскажу, как эволюционировал наш подход к визуализации результатов тестирования в k6: от простых HTML-отчетов и экспериментов с нейронками до развертывания «тяжелой артиллерии» в виде связки InfluxDB + Grafana. Покажу, как настроить визуализацию в уже готовых скриптах. И главное: покажу, зачем вообще нужно смотреть на графики в реальном времени, даже если вы тестируете небольшой внутренний сервис.

Как ИИ поменял пентест уже вчера и где взять материалы для подготовки к сертификации по безопасности ИИ на русском языке и в одном месте

С первого взгляда кажется, что для параллельного запуска автотестов достаточно просто нажать кнопку «Вкл.». Однако не всё так просто — различные параллельные действия пользователя приводят к логическим конфликтам: дублирующиеся записи в базах данных, несогласованность одновременно выполняемых операций, невозможность гарантированно воспроизвести некоторые сценарии, и многое другое. 

Меня зовут Марина Скалина, я QA‑автоматизатор в СберТехе, в команде Platform V Kintsugi — это графическая консоль для сопровождения PostgreSQL и всех СУБД, основанных на PostgreSQL (как наша же СУБД Pangolin). Поговорим о том, что стоит учесть, если вашей команде тестирования необходимо перейти на параллельный прогон.

Привет, Хабр.

Многие до сих пор воспринимают собеседования примерно одинаково. Кажется, что всё решает техническая часть: насколько быстро ты соображаешь, как пишешь код, помнишь ли теорию, можешь ли объяснить сложность алгоритма или нарисовать архитектуру на доске.

На практике всё часто работает чуть иначе.

Да, техничка важна. Никто с этим не спорит. Но оффер нередко ломается не на алгоритмах, не на лайвкодинге и даже не на ошибке в каком-нибудь ответе. Очень часто всё решают вопросы, которые на первый взгляд выглядят максимально безобидно. Из серии: “кем вы видите себя через пять лет?”, “что вас мотивирует?”, “почему хотите уйти?” или “какой у вас был самый большой косяк?”.

И вот именно на них люди регулярно сыпятся.

Не потому что они глупые. И не потому что не умеют разговаривать. А потому что воспринимают эти вопросы как формальность. Как будто это просто обязательный HR-блок, который надо пережить перед чем-то действительно важным.

Хотя на деле именно там интервьюер часто и пытается понять главное: как вы мыслите, насколько вы устойчивы, чего хотите от работы и совпадает ли это с реальностью конкретной команды.

Сразу уточню важный момент. Я не пытаюсь доказать, что такие вопросы идеальны или что именно так и нужно проводить собеседования. У многих к ним вполне обоснованные претензии, и я их понимаю. Но пока рынок продолжает их задавать, полезно хотя бы понимать, что именно через них пытаются считать и почему на seemingly простом ответе иногда тихо умирает оффер.

Почему вообще такие вопросы так важны

Потому что технические ответы очень часто показывают только верхний слой.

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

Именно поэтому рынок так любит эти странные вопросы, которые вроде бы не про технологии.

Они не проверяют знания. Они проверяют совместимость.

В своем Telegram-блоге я регулярно пишу про рынок IT, тестирование, автоматизацию и карьеру в индустрии.

Всегда рад новым читателям!

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

Часто встречающийся вопрос звучит так:

Это была пятница, шесть вечера. Я сидел перед монитором и чувствовал себя следователем, который зашёл в тупик.

Три часа назад я нашёл странное поведение в приложении. Открыл Jira, но пока заполнял поля — мысль ушла. На рабочем столе уже лежало 15 скриншотов с именами вроде «Снимок экрана 154312.png». Я открыл их наугад, но уже не помнил, к какому запросу какой относится.

«Я потерял контекст». Баг есть, даже помню, как воспроизвести. Но чтобы восстановить цепочку «действие → реакция сервера → скриншот → вывод» — нужен ещё час.

Знакомо? Я инженер по тестированию, работаю со сложными продуктовыми сценариями, где один баг тянет за собой цепочку из запросов, скриншотов и логов. И с этим сталкиваюсь регулярно.

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

Меня зовут Александр. Я перепробовал Jira, Confluence, Notion и просто папки на диске. Всё либо медленно, либо хаотично, либо зависит от интернета. Поэтому я собрал свой локальный редактор — под себя, под тестирование. Делюсь историей и кейсом.

Инструмент я выложил в открытый доступ, ссылка будет в конце. Это не продажа, не условно-бесплатно и не лидогенерация. Просто рабочий пет-проект, которым я сам пользуюсь каждый день.

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

В нашем арсенале более 2500 скриншотных тестов, поэтому многие выводы сделаны на основе длительного опыта эксплуатации.

Привет! Это снова Михаил Федоров. В первой статье я рассказал про архитектуру QA Assist — системы из 11 AI-агентов для автоматизации тестирования. Во второй — честно показал, как «4 часа подключения» превращаются в неделю корпоративной реальности.

Сегодня поговорим о штуке, которая на первый взгляд не имеет отношения к AI. О пирамиде тестирования. О том, почему классическая теория QA внезапно оказывается критически важной, когда вашим тест-дизайнером становится языковая модель с контекстным окном.

Playwright или Selenium на Java — что выбрать для автотестов в 2026 году? Разбираю историю инструментов, различия в локаторах, ожиданиях, стабильности, стоимости поддержки и объясняю, в каких сценариях каждый из них лучше.

Ранее в статье: Soft Skills для тестировщика: почему «мягкие» навыки важнее «жестких» скриптов я попытался рассказать почему для тестировщика важно развивать Soft Skills, а сейчас разберемся как это реализовать на практике.

Развитие мягких навыков — не разовая акция, а постоянный процесс. Поскольку я работаю QA‑инженером, то данный материал в большей степени будет полезен для QA, но и разработчики и менеджеры и другие участники команды могут найти для себя что-то полезное.  Ниже я привел конкретные, проверяемые методы для прокачки ключевых soft skills.

За последние пару лет AI начал постепенно проникать в инженерные процессы разработки. Сначала это были генераторы кода, затем инструменты анализа логов, а сейчас всё чаще появляются решения, которые помогают автоматизировать аналитическую работу.

В QA эта проблема особенно заметна. Многие думают, что тестирование — это в основном запуск тестов и поиск багов. На практике значительная часть времени уходит на совсем другие вещи: чтение требований, сбор информации из разных источников, попытки понять реальную бизнес-логику и подготовку тестовой документации. Мы решили посмотреть на эту проблему системно и попробовать оптимизировать часть этой работы с помощью AI.

Ваш тест на оформление заказа нажимает «Оформить заказ» и видит зелёный тост. Хорошо. Но вот чего он не проверяет: реально ли записалась строка? Правильно ли записались позиции заказа? Уменьшился ли инвентарь? UI написал «подтверждено», но UI иногда врёт — проглоченная ошибка, откаченная транзакция, очередь, которая молча дропнула сообщение.

Классическое решение некрасиво: нужно подключить ORM или низкоуровневый драйвер базы данных внутри тестового харнеса, управлять отдельными учётными данными, писать SQL-ассерты вручную и надеяться, что схема не изменится. Работает. Но это накладные расходы на поддержку, которые вы платите за каждый тест.

Сейчас есть паттерн лучше. И в нём ноль SQL с вашей стороны.

Что если один AI-агент сможет делать обе половины — управлять браузером при оформлении заказа и затем переключиться в базу данных для проверки записи — используя два MCP-сервера?

Именно это разбирается в статье:

Всем привет! Меня зовут Артем. Я Android QA Engineer в команде Банки.ру.

Было ли у вас такое, что unit-тесты в проекте есть, но на практике ими почти никто не пользуется? Разработчики их пишут, но для QA это “что-то где-то в коде”: нельзя нормально посмотреть результаты, оценить покрытие или использовать в регрессе.

В статье рассказал, как мы решили эту проблему: сделали unit-тесты видимыми через Allure, связали их с тест-кейсами и встроили в реальный процесс тестирования.

Всем привет! Меня зовут Оля Ермолаева, я работаю в сфере обеспечения качества ПО уже больше 17 лет. За это время я успела поработать в самых разнообразных компаниях по очень разным направлениям: от ПО для автозаправок до финтеха, агротеха и ритейла. Пробовала себя и в ручном, и в автоматизированном тестировании. В итоге лет 10 назад ушла с головой в менеджмент и веду свой небольшой ТГ канал про тестирование, менеджмент и всё, что с этим связано.

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

На QA-митапе инженер из крупной продуктовой компании показал: AI-агент пишет тесты — все зелёные, но баги не находят. Моки подогнаны, ассерты подменены, архитектура деградирует. Стек при этом — near-SOTA: свежая модель, топовый open-source агент. Я был комментатором на том митапе и сначала списал проблемы на слабые инструменты. Но при подготовке статьи перепроверил — и вынужден поправиться. Инструменты в порядке. Проблема — в коде и процессе. В статье разбираю формулу из четырёх множителей (модель × агент × процесс × качество кодовой базы), показываю, как any-типы из соседней команды обнуляют LSP-интеграцию, которую OpenCode даёт бесплатно из коробки, и даю пошаговый Spec-Driven Development — процесс, который ломает reward hacking и работает даже на слабых моделях. Плюс чеклист, что внедрить завтра.