Здравствуйте, дорогие друзья! Сегодня хочу поделиться опытом, который был получен за 2 часа изучения того, как развернуть Gitlab и подключить к нему Gitlab Runner из‑под Docker, и всё это на домашней Fedora 44.
Всё то, что было сделано, вызвано желанием немного потыкать и узнать, что из себя представляет Gitlab как для DevOps, так и для QA. При этом я не ограничивал себя в возможностях бесплатной удалённой версии от самого Gitlab.
Пару месяцев назад я попросил агента проверить форму обратной связи после рефакторинга. Через несколько минут получил отчёт: все проверки пройдены, форма работает корректно. Зелёные галочки, уверенный тон.
Я тогда только начинал отдавать тестирование агенту, поэтому работал по схеме «доверяй, но проверяй»: следом прошёл форму руками, с открытой вкладкой Network. Снаружи всё честно: валидация зелёная, кнопка активная, тост «Спасибо!» показывается, сервер отвечает 200. А в payload вместо темы обращения уходит строка [object Object]. Агент проверил всё, кроме того, что реально уходит на сервер.
Всем привет! Меня зовут Ксюша, и я backend QA-лид нескольких команд в EXANTE.
В начале этой истории я была обычным QA в команде, которая отвечает за ядро нашего backoffice.
Думаю, многие из вас знакомы со Scrum и его ивентами, но если нет — дальше речь пойдет о ретроспективе, одной из ключевых встреч этого фреймворка.
Вначале пути, вскоре после agile-трансформации, мы проводили ретроспективы, которые, в теории, должны были приносить пользу, а на практике ощущались бесполезными. В течение часа мы жаловались и выпускали пар, а через один спринт возвращались к тем же проблемам.
Самый дорогой software-failure в истории — ~$5,4 млрд прямого ущерба. А причина — баг из первой главы учебника по тестированию: рассинхрон «20 против 21 параметра» во внутреннем валидаторе. Разбираем timeline, root cause и — главное — три отдельных провала QA, которые это допустили, плюс уроки, которые забираются в любую команду.
19 июля 2024 года в 04:09 UTC CrowdStrike выкатил обновление контентного файла для своего антивируса Falcon Sensor. За следующие 78 минут 8,5 миллиона Windows-машинЧитать полностью »
Хочется поговорить о том, что происходит с QA в 2026-м и правда ли, что «нас вот-вот заменит ИИ». Но не в формате очередного треда в духе «всё пропало» или «всё отлично, завтра уволим половину отдела». А по-взрослому: с опытом, цифрами, ограничениями и выводами. То есть попробовать не просто порассуждать, а разобрать тему как небольшое исследование: что реально меняется, где ИИ помогает, а где начинается та самая реальность, которая не влезает в красивую презентацию.
Вот есть Postman-коллекция из 40 запросов. Разложена по папкам, и с тестовыми скриптами, которые проверяют статус-коды. Вы потратили на неё время, она хороша.
И ещё у вас есть CI-пайплайн, который про Postman никогда не слышал и слышать не собирается.
Эти две вещи мирно сосуществовали месяцами, потому что никто не хочет быть тем человеком, который вручную переписывает 40 запросов в pytest-функции. Newman, конечно, есть, но Newman гоняет тесты, а не генерирует код, который можно прочитать, отредактировать и нормально положить в систему контроля версий.
Привет! Меня зовут Оля Шнайдер, я QA-инженер в Авито. В начале этого года я провела исследование рынка QA, чтобы понять, как сейчас работают тестировщики: с чем сталкиваются каждый день, что мешает в работе, а что, наоборот, помогает.
За последние годы роль QA заметно изменилась (или мне так хочется думать). От нас ждут большего — не только непосредственно тестирования и ответственности за результат, но и участия в процессах и много чего ещё. При этом сами процессы не всегда становятся лучше.
Когда в проекте появляются сложные сценарии: нестабильный бэкенд, редкие ошибки, зависимость от внешних сервисов, классические инструменты тестирования могут тормозить. Любая правка требует участия сервера, а воспроизведение бага превращается в квест.
В этот момент прокси-инструменты вроде Proxyman начинают играть совсем другую роль. Это уже не просто «посмотреть запросы», а полноценный слой управления трафиком.
Меня зовут Станислав, я Test-инженер в KODE, в этой статье разберу, как использовать Proxyman Scripts не как вспомогательную фичу, а как инструмент автоматизации тестирования.
Тестирование «отстаёт» от разработки, автотесты не успевают за сценариями, а увеличение бюджета на QA ситуацию не спасает. Знакомо?
Привет! Меня зовут Михаил Федоров, я руковожу центром компетенций QA. Мы решили не нанимать ещё двух тестировщиков, а написать систему AI-агентов, которая берёт на себя 80% рутины QA-инженера – от анализа требований до Merge Request с готовыми автотестами. В этой статье расскажу, как устроена архитектура, какие грабли мы собрали, и что из этого вышло на практике.
Проблема: почему тестирование буксует
Идея: QA-инженер как оператор AI-ассистента
