Обновить
256K+

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

Семь раз оттесть, один раз деплой

131
Рейтинг
Сначала показывать
Порог рейтинга
Уровень сложности

Ваши тесты медленные не из-за базы данных. Я измерил

Уровень сложностиПростой
Время на прочтение9 мин
Охват и читатели7.7K

Есть устойчивое поверье: интеграционные тесты медленные, потому что ходят в настоящую базу. «Подними SQLite в памяти», «замокай репозитории», «не гоняй Postgres в CI» — стандартный набор советов. Мокать я не люблю, но крыть упрёк «настоящая база — это медленно» было нечем. Поэтому я сел, спрофилировал и померил: 3316 интеграционных тестов, прогон 30 минут. После трёх правок инфраструктуры — 109 секунд. База оказалась ни при чём, а совет «чисти базу через TRUNCATE, это быстрее DELETE» у меня работал ровно наоборот — обидно вдвойне, потому что эта рекомендация уже лежала в черновике моей следующей статьи.

Читать далее

Новости

Как починить блокировку легальных сайтов РКН ТСПУ одной строчкой в Chrome

Уровень сложностиПростой
Время на прочтение2 мин
Охват и читатели68K

Мне очень хотелось разобраться в этой ситуации с блокировками..
Не мог с Chrome зайти на beget.com - там CDN блокировался. Тыкался тыкался..

Вставляете в строку браузера chrome://flags/

Ищите Cryptography Compliance (CNSA) (#cryptography-compliance-cnsa)

Читать далее

Race Condition в веб-приложениях: три типа уязвимости и как их находить

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели7.7K

Для начала разберёмся, что такое Race Condition и почему эта уязвимость заслуживает внимания.

Race Condition — это класс уязвимостей, которые возникают из-за того, что сервер обрабатывает несколько запросов одновременно без должной синхронизации. Когда два или более запроса приходят на сервер в один и тот же момент и затрагивают одни и те же данные, между ними происходит коллизия.

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

Перейдём к тому, какие виды этой уязвимости вообще бывают.

Можно выделить 3 вида:

Читать далее

Резервное копирование БД без влияния на потребителя. Тестируем Direct I/O в CopyWala

Уровень сложностиСредний
Время на прочтение14 мин
Охват и читатели7K

Тестирование функциональности Direct I/O — задача сама по себе нетривиальная. Сложность возрастает, если проверить работу функциональности можно только на ненагруженной базе данных, а тестируемое приложение предназначено для работы с высоконагруженными системами.

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

Меня зовут Наталья Лабчук, я занимаюсь тестированием Platform V CopyWala — системы резервного копирования и восстановления данных от СберТеха. Расскажу, как мы убедились в том, что функциональность Direct I/O в CopyWala при снятии резервной копии с высоконагруженной базы не ухудшает производительность кластера. Надеюсь, что почитать об этой задаче будет полезно тем, кто работает в разработке и тестировании Postgres-подобных баз данных, а также инженерам, которые отслеживают производительность и администрируют PostgreSQL.

Читать далее

Почему в Go больно писать автотесты (и дело не в синтаксисе)

Время на прочтение15 мин
Охват и читатели7.6K

testing в Go даёт только примитивы. Разбираем, почему автотесты в Go быстро превращаются в боль, и какого слоя исполнения в нём не хватает.

Читать далее

Про конструкторы сайтов с ИИ – что реально уже работает, а что только для пиара

Уровень сложностиПростой
Время на прочтение17 мин
Охват и читатели8.5K

Не совсем пятничное чтиво, но…

Как-то так случилось, что решил разобраться для себя лично – какие подвижки появились в вопросе внедрения искусственного интеллекта в сфере сайтостроительства. ИИ действительно показал себя неплохо в отдельных задачах, но есть у него и минусы. Всё это тема для отдельного обсуждения, но здесь – только обзор реальной картинки. Делюсь бесплатно и без SMS ))

Читать далее

Webhook в TestY заставил переписать приложение с нуля: от Flask-костылей к FastAPI

Время на прочтение14 мин
Охват и читатели9.5K

Привет, Хабр! Меня зовут Станислав Кулагин, я ведущий инженер отдела сертификационного тестирования компании YADRO. Я разработал ATS Studio — Flask-приложение, которое позволяло запускать автотесты в TestY TMS из браузера, не проставляя статусы руками. За полгода приложение стало популярным в нашей компании теперь экономит по 40 часов в месяц коллегам из KVADRA. 

Но я заметил, что у ATS есть потенциал стать лучше, поэтому начал разрабатывать вторую версию. Теперь ATS умеет обрабатывать до 400 тестов одновременно и подходит для совместного использования. В статье расскажу, как появился ATS Framework и почему TestY остается краеугольным камнем этой истории.

Читать далее

Тестирование ипотечного процесса в мобильном приложении СБОЛ

Уровень сложностиПростой
Время на прочтение10 мин
Охват и читатели7.1K

и как не утонуть между БКИ, Госуслугами и тремя платформами одновременно?

Один QA. Три платформы. Шесть внешних сервисов. Легаси-код. И огромное количество неопределённости — в требованиях, в поведении интеграций, в том, что вообще считать корректным результатом. Рассказываю, как выстроить тестирование сложного финансового процесса так, чтобы до релиза добиралось не более 5–7 багов — и все они были известны заранее.

Читать далее

Избегаем парадокса пестицида, или Как мы внедрили систему рекомендаций «забытых» тест‑кейсов

Время на прочтение6 мин
Охват и читатели9.7K

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

Меня зовут Александра Атаман, я QA‑инженер в команде веба Яндекс Такси. В этой статье я расскажу, как мы оптимизировали процесс формирования регрессионного тестирования для ручного прогона, внедрив систему весов для тест‑кейсов. Этот подход помогает прицельно отбирать наиболее «опасные» сценарии: самые старые, забагованные или потенциально проблемные.

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

Читать далее

Git для QA Engineer

Уровень сложностиПростой
Время на прочтение6 мин
Охват и читатели11K

Git — один из базовых инструментов современного QA Engineer. Даже если тестировщик не пишет production-код, ему всё равно приходится работать с репозиториями, ветками, pull request и merge conflict.

В статье разберём:
— как устроен Git;
— какие команды реально нужны тестировщику;
— как работать с ветками;
— как не ломать чужой код;
— и как Git помогает QA в ежедневной работе.

Материал подойдёт начинающим и middle QA, а также будет полезен при подготовке к собеседованиям.

Читать далее

Моки, стабы и фейки: в чем разница и что выбрать для автотестов?

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели7.4K

Разбираемся с терминологией Test Doubles без лишней воды. В чем реальная разница между Mock, Stub и Fake? В статье разберем классификацию на живых примерах: поднимем умный стаб-сервер на FastAPI, напишем мок-шпион для проверки сайд-эффектов и ускорим тесты с помощью фейковых БД.

Читать далее

Как я сократил рутину QA до пары кликов: генератор API-тестов и тест-кейсов на LLM, которым хочу поделиться

Уровень сложностиПростой
Время на прочтение7 мин
Охват и читатели13K

Привет, Хабр! Меня зовут Илья, я работаю Manual QA в команде, которая отвечает за качество продукта с большим количеством микросервисов, API и регулярными релизами. Если вы хоть раз писали тест-кейсы по тикету из Jira, потом руками собирали Postman-коллекцию по OpenAPI-спецификации, а после ревью документации обнаруживали, что половину сценариев забыли — эта статья для вас.

Я собрал инструмент, который автоматизирует три самых рутинных задачи QA-инженера: генерацию тест-кейсов, генерацию API-тестов и ревью документации. Всё это под одной крышей, с поддержкой любого OpenAI-совместимого LLM (включая локальные модели), с интеграциями в Jira, Confluence, TestRail, TestIT и Zephyr Scale.

Проект называется Test Generator Suite (TGS), и в этой статье я расскажу, какие проблемы он решает и как устроен внутри. Сразу оговорюсь: я не разработчик, я QA, и большую часть кода писал «как умею» — поэтому если в архитектурных решениях вам что-то покажется странным, я заранее согласен. Это инструмент для коллег по цеху, а не образец Python-инженерии.

Читать далее

GPT-шорткаты: что работает, а что нет

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели12K

Привет! Разобрал популярные шорткаты GPT вроде EL5, /REDTEAM, /BULLET — какие реально выручают каждый день, какие работают через раз, а какие лучше не тратить время.
Смотри шпаргалку! 🚀

Читать далее

Ближайшие события

Мы пытались заменить QA нейросетью. Не получилось

Время на прочтение10 мин
Охват и читатели19K

Мы попытались построить MCP-сервер, который сам читает спеки, пишет автотесты и коммитит код. На практике выяснилось, что токены — не главная проблема, а QA — это не «делатели тестов», а носители контекста и ответственности.

Читать далее

Как составить ИПР, который работает

Уровень сложностиПростой
Время на прочтение7 мин
Охват и читатели7.8K

Всем привет! Когда-то на старте карьеры мне на собеседовании пообещали одну очень заманчивую вещь — развитие. Мне казалось, что я попаду в среду, где меня будут постепенно учить, направлять и поддерживать. Вряд ли кого-то удивлю, сказав, что ожидания начинающего специалиста и реальность не совпали. С тех пор я научилась брать развитие в свои руки, составлять рабочий ИПР (индивидуальный план развития) и добиваться заметных результатов за короткие циклы. Делюсь опытом в своей первой статье.   

Меня зовут Анастасия Новожилова, я Head of QA в Sminex, в IT — с 2012 года. Я работала в разных компаниях и командах: где-то процессы уже были выстроены, а где-то QA и саму логику развития приходилось выстраивать с нуля. Думаю, многие выбирают компанию не только из-за зарплаты, задач или бренда, но и потому, что там обещают рост, обучение и перспективы. Это особенно цепляет начинающих, также было и у меня – на первую работу я шла за профессиональным развитием. А дальше выяснилось, что всё это «развитие» на практике выглядит примерно так: тебя никто не поддерживает, ничего не объясняют, а просто кидают в воду и смотрят, выплывешь или нет. Не сразу, но в какой-то момент я всё чаще ловила себя на мысли, что здесь что-то не так. А потом — на другой: похоже, если я хочу расти, пора перестать ждать готовую систему и начать собирать её самой.

Сейчас я работаю в Sminex и на контрасте особенно заметно, насколько легче двигаться вперёд, когда у тебя есть ориентиры и регулярная поддержка. У нас развитие встроено в работу: есть понятные ИПР, более ясный вектор роста и внимание к тому, как человек двигается дальше. Но мне хочется поговорить не только о том, как хорошо, когда система уже есть. Гораздо чаще всё устроено иначе: развитие вроде обещано, но по факту человеку приходится выстраивать его для себя самому. И вот в такой ситуации ИПР может стать полезным рабочим инструментом, даже если идеальных условий вокруг нет.

Читать далее

Троянский форк: от шалости до крита

Время на прочтение5 мин
Охват и читатели9.5K

Форк репозитория — операция настолько привычная, что на нее редко смотрят с подозрением. Но что, если через обычный форк можно запустить произвольный код на CI/CD-воркере чужой приватной компании? 

Именно такую цепочку мы обнаружили в GitFlic — отечественной платформе для совместной разработки ПО и хранения исходного кода от компании «РеСолют». 

GitFlic во многом похож на GitLab — что логично, ведь создавался как его альтернатива. И получилось у разработчиков сносно: если вы работали с GitLab, то GitFlic вызовет у вас приятное чувство дежавю.

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

Обнаруженные нами уязвимости были оперативно исправлены разработчиками компании «РеСолют» и зарегистрированы в БДУ ФСТЭК: BDU:2025-12462, BDU:2025-12463, BDU:2025-12464.

Читать далее

Шум или ущерб: как заранее отличить громкий негатив от материального кризиса

Уровень сложностиСредний
Время на прочтение14 мин
Охват и читатели8.9K

Теги: product management, risk management, marketplace, telecom, customer experience, pre-mortem

Коротко о главном

У меня возникла идея для сервиса Интуицын — предзапусковую репетицию риска. Он превращает спорное коммерческое решение (изменение тарифа, новые правила для партнёров, комиссия за способ оплаты, ребрендинг) в карту риска: кто отреагирует, насколько это материально, через какие каналы пойдёт распространение недовольства и что можно изменить до публичного контакта с рынком.

В этой части (1 из 2) — продуктовый и аналитический разбор без технических деталей. Я покажу, как сервис отработал на 3 реальных кейсах из недавней истории российского рынка: тарифы у мобильных операторов, штрафы для партнёров маркетплейса и одновременный ребрендинг с запуском премиального направления. Два из трёх кейсов в реальности закончились публичным конфликтом, действиями ФАС, забастовкой партнёров или их сочетанием. Третий — на бумаге выглядел как идеальный кандидат на скандал и был так помечен сравнительным baseline-прогнозом обычной языковой модели — но в реальности прошёл без материального ущерба. Сервис правильно отранжировал материальные кейсы в верхней части риска, а спорный «двойной» — в нижней, и всё это до того, как ему сообщили исход.

Сервис проверяли на двух последовательных ретроспективных слепых прогонах: первый — 6 кейсов, расширенный — 20, всего 26 кейсов российского рынка. Cуммарно когортный слой правильно классифицировал 26 из 26 исходов; обычный сравнительный baseline-прогноз большой языковой моделью — 22 из 26, в остальных 4 случаях принял громкий, но переносимый негатив за материальный провал. На последнем 20-кейсовом расширении ранжирование разделило набор без ошибок: верхние 10 — все материальные кейсы, нижние 10 — все без материального ущерба. Это пилотный сигнал, а не финальное доказательство.

Читать далее

180к MAU, 43% детей и „филькина грамота“: как я искал уязвимости, а нашёл бизнес-схему

Уровень сложностиСредний
Время на прочтение14 мин
Охват и читатели11K

Представьте себе «Матрицу» – сервис, где создана иллюзия безопасности путем обмана пользователей. Через юридидические документы, которые должны защищать пользователей, но по факту все наоборот: они защищают создателя сервиса.

В «Матрице» обещают данные на «защищенных серверах», но хранят их в публичном облаке. Пишут «только для совершеннолетних», но почти половина анкет – дети и подростки.

История про то, как багхантинг перерастает в расследование о халатности в обращении с персональными данными юзеров.

12340 анкет, 24 тысячи чужих файлов на 7 GB – все оказалось доступным без единого взлома.

Результат – весьма неожиданный…

Пройти через зеркало

QA в 2026 году: почему лёгкого входа в IT больше нет

Уровень сложностиПростой
Время на прочтение10 мин
Охват и читатели21K

Рынок QA изменился: конкуренция выросла, требования стали жёстче, а старые сценарии входа больше не работают. В статье — честный разбор рынка, требований и иллюзий, которые до сих пор продают новичкам.

Читать далее

Quality Gates в разработке: делаем качество частью процесса

Уровень сложностиСредний
Время на прочтение23 мин
Охват и читатели8.9K

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

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

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

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

Читать далее
1
23 ...