Существует простое правило: чем раньше найден баг, тем он дешевле.
Представим проект, где тестирование есть только на production. Баг находят уже после релиза. Фича, которая приносит деньги, становится недоступна. Мы теряем прибыль, тратим время на дебаг, фикс и доставку — а вместе с тем время на post mortem и многочисленные созвоны по инциденту.
Привет! Сейчас покажу штуку, которую я довольно долго доводил до ума, и мне кажется, она может пригодиться не только мне.
Задача звучит скучно: нагенерировать тестовые карточки людей. Пол, имя, диагноз. Скучно ровно до того момента, пока не посмотришь, что получилось:
женский, Ольга, Аденома простатыФормально придраться не к чему. Пол настоящий, имя настоящее, диагноз из справочника. Просто вместе они дают человека, которого не бывает. Каждое поле правильное по отдельности — неправильно то, что вышло из них вместе.
Здравствуйте, дорогие друзья! Сегодня хочу поделиться опытом, который был получен за 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 заметно изменилась (или мне так хочется думать). От нас ждут большего — не только непосредственно тестирования и ответственности за результат, но и участия в процессах и много чего ещё. При этом сами процессы не всегда становятся лучше.