QA AK

Шпаргалка по техникам тест-дизайна. #ифнографика — 💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️‍♂️ Тренажеры для практики тестирования |🧑‍💻Практикум для начинающих по тестированию API

Курсорная пагинация. В новом материале рассказываю про курсорную пагинацию и ее отличия от обычной, а также показываю сильные и слабые стороны обеих на различных примерах. Ссылка на статью Ставьте🔥если хотите больше подобных лонгридов. #qa #api — 💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️‍♂️ Тренажеры для практики тестирования |🧑‍💻Практикум для начинающих по тестированию API

Друзья, я к вам с важными обновлениями по практикуму по работе с Kafka. 📚 В связи с тем, что хостинг-провайдер ощутимо поднял цены на свои услуги, чтобы также резко не увеличивать цену, было принято решение изменить формат развертывания и работы тренажера. Теперь для вас доступна версия, развертываемая локально с помощью Docker 🖥. Таким образом: 🔸вы не будете зависеть от работы хостинга 🔸 тренажер будет запускаться и работать у вас локально, изолированно от других учащихся Для локального развертывания вам будет нужен Docker Desktop (и может потребоваться VPN). Весь процесс по установке и запуску описан в документации, которая прилагается к тренажеру. В остальном работа с тренажером останется прежней. Старая веб-версия будет поддерживаться до 17.05.2026 и затем прекратит свою работу. 🏁 Успевайте приобрести практикум по старой цене до 27.04. #анонс #практикум #kafka — 💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️‍♂️ Тренажеры для практики тестирования |🧑‍💻Практикум для начинающих по тестированию API

Алертинг. (часть 1) Недавно у меня возникла бытовая ситуация, которая хорошо показывает, зачем вообще нужен алертинг. Водосчётчик горячей волы перестал считать потребление воды. Но заметил я это не сразу, а только в следующем месяце, в день, когда пришло время передавать показания. Новое значение оказалось таким же, как и месяц назад. До этого момента всё выглядело штатно: вода есть, пользоваться ей можно, ничего явно не менялось. Проблема существовала, но оставалась незамеченной, потому что я не смотрел на неё регулярно и не получал никакого сигнала о том, что что-то пошло не так. Если перенести эту ситуацию в более формальную плоскость, становится видно, что проблема была не только в самом счётчике, но и в отсутствии механизма уведомления. Система продолжала существовать, но не сообщала о том, что важный для меня процесс фактически остановился. Если бы был настроен простой контроль: например, проверка, что показания, при потреблении горячей воды (когда открыт кран) не менются, - можно было бы узнать о неисправности гораздо раньше. Не в момент, когда уже подошёл срок передачи данных, а почти сразу после появления отклонения. Именно в этом и состоит смысл алертинга. Алертинг - это механизм, который сообщает о значимом событии или отклонении в системе, чтобы человек не обнаруживал проблему случайно, слишком поздно или по косвенным признакам. Само по себе наличие данных, логов, метрик или журналов ещё не решает задачу. Важно, чтобы система не просто фиксировала состояние, а умела вовремя обратить внимание на то, что требует реакции. На практике алертинг обычно строится вокруг наблюдения за некоторыми признаками. У системы есть ожидаемое поведение: сервис должен отвечать, запросы должны обрабатываться за допустимое время, ошибки не должны резко расти, данные должны обновляться, фоновые задачи должны выполняться, интеграции должны присылать результат. Если фактическое состояние начинает заметно отличаться от ожидаемого, срабатывает сигнал. Этот сигнал может прийти в виде сообщения в чат, письма, push-уведомления, звонка, события в системе мониторинга или задачи в трекере. Важно понимать, что алертинг не существует сам по себе. Он опирается на наблюдаемость системы. Сначала нужно измерять что-то полезное: количество ошибок, время ответа, загрузку ресурсов, успешность бизнес-операций, состояние очередей, наличие новых записей, результат фоновых расчётов. Затем для этих показателей определяются условия, при которых нужно подать сигнал. Например, если доля ошибок превышает порог, если сервис недоступен несколько минут подряд, если число заказов внезапно падает до нуля, если платёжная интеграция перестаёт возвращать ответы, если данные в витрине давно не обновлялись. Здесь полезно вернуться к примеру с водосчётчиком. Само по себе наличие счётчика - это ещё не контроль. Контроль начинается там, где появляется проверка: изменяются ли значения, не остановился ли учёт, нет ли нетипично долгого периода без движения. В системах работает тот же принцип. Недостаточно просто иметь сервис, базу данных или фоновую задачу. Нужно понимать, какие признаки говорят о том, что всё идёт штатно, а какие - что процесс уже нарушен, хотя внешне это может быть ещё неочевидно. Особенно полезен алертинг в тех ситуациях, где человек физически не может постоянно проверять состояние вручную. В реальной работе почти никто не открывает каждые пять минут логи, не запускает вручную тестовые запросы и не сравнивает значения в таблицах. Это слишком дорого по времени и плохо масштабируется. Поэтому задача алертинга - снять с человека необходимость постоянно дежурить глазами у системы и заменить это автоматическим контролем ключевых состояний.

Алертинг (часть 2). Отдельно стоит отметить, что хороший алертинг помогает не только узнавать о технических сбоях, но и замечать бизнес-проблемы. Например, сервис формально работает, серверы доступны, ошибок в логах почти нет, но за последний час не было ни одного успешно оформленного заказа. Или письма пользователям продолжают отправляться из приложения, но не доходят до адресатов из-за сбоя внешнего провайдера. Или интеграция с платёжной системой отвечает кодом 200, но фактически не проводит операции. Во всех этих случаях инфраструктурные признаки могут выглядеть нормально, а реальная проблема уже существует. Поэтому алертинг строят не только по техническим метрикам, но и по бизнес-сценариям. Для тестировщика понимание алертинга полезно сразу в нескольких смыслах. Во-первых, это помогает лучше видеть систему целиком, а не только отдельный запрос или экран. Во-вторых, это даёт возможность задавать правильные вопросы ещё на этапе анализа требований: как команда узнает, что процесс перестал работать, какие сигналы должны появляться, кто получит уведомление, что считается критичной проблемой, а что допустимым отклонением. В-третьих, это влияет на качество тестирования. Если в системе вообще не предусмотрены способы быстро обнаруживать сбои, это уже риск, даже если функционально всё работает. На практике тестировщик может участвовать в проверке алертинга по-разному. Можно уточнять, какие события должны мониториться. Можно проверять, формируются ли нужные метрики и логи. Можно моделировать сбои и смотреть, возникает ли уведомление. Можно анализировать, не слишком ли шумный алертинг, не приходят ли сигналы по незначительным поводам, не теряются ли действительно важные проблемы среди большого числа второстепенных сообщений. Хороший алертинг - качественно настроенная система сигналов, которая помогает реагировать вовремя и по делу. Это особенно важно, потому что плохой алертинг тоже является проблемой. Если уведомления приходят слишком часто и по любому поводу, команда начинает к ним привыкать и перестаёт воспринимать их всерьёз. Если сигналы приходят слишком поздно, ценность алертинга снижается: проблему всё равно замечают уже по последствиям. Если условия срабатывания выбраны неудачно, можно либо пропускать реальные инциденты, либо создавать постоянный шум. Поэтому при настройке алертов всегда приходится искать баланс между чувствительностью и практической пользой. В зрелых системах алертинг - это не просто техническая настройка, а часть эксплуатационной культуры. Команда заранее решает, что именно для неё критично, какие состояния считаются аварийными, как быстро нужно узнавать о сбоях, кто и как реагирует на сигнал. То есть алертинг связан не только с мониторингом, но и с процессом реагирования. Если уведомление пришло, но никто не понимает, что делать дальше, система оповещения будет работать лишь наполовину. Если снова вспомнить историю со счётчиком, проблема была не в том, что у меня совсем не было данных. Проблема была в том, что я узнал о неисправности слишком поздно, в момент плановой ручной проверки. В программных продуктах подобная ситуация происходит постоянно. Что-то ломается и не всегда заметно. Иногда процесс просто перестаёт двигаться, данные перестают обновляться, сообщения перестают уходить, задача зависает в очереди, а внешне всё выглядит вполне спокойно. И именно для таких случаев нужен алертинг: чтобы отклонение становилось заметным не случайно, а автоматически. Поэтому алертинг можно рассматривать как способ сократить расстояние между моментом возникновения проблемы и моментом, когда о ней узнаёт команда. Чем меньше это расстояние, тем меньше последствий успевает накопиться. Для бизнеса это означает снижение потерь, для команды - более быструю реакцию, для тестировщика - лучшее понимание надёжности продукта. А для обычной жизни, как показывает пример с водосчётчиком, - возможность заметить поломку тогда, когда она только возникла, а не тогда, когда уже пришло время разбираться с последствиями. #qa #infra

#отзыв о работе с SQL-песочницей https://t.me/QA_AKlimenko/293

Хочу выразить благодарность Алексею за тренажер по БД! Отличный продукт и материал, который позволяет подтянуть знания по базам данных до приличного уровня. Понравилось, что есть Swagger и UI для работы с БД, наличие которых создаёт условия реального проекта (за такой прайс - это вообще находка). Лично я прошёлся по задачам за два дня, а на следующий день уже был на техническом интервью на позицию Fullstack QA. На интервью было 3 задачи по SQL, которые практически дублировали задачи из курса Алексея. По итогу: все задачи решил успешно и получил оффер. Также хочу отметить, что есть исходный код API для взаимодействия с БД, который можно почитать и порефакторить под свои задумки - это просто супер. Со своей стороны хотел бы посоветовать автору расширить формулировки задач: иногда приходилось немного подумать, проанализировать условия, но минусом это назвать не могу, так как пользователь курса учится правильно понимать не совсем содержательные задачи, что часто встречается на реальных проектах.

Всем привет. Вы наверняка слышали про конференцию Heisenbug (https://heisenbug.ru/). В этот раз хотел бы обсудить её здесь, ведь сам приму в ней участие в качестве слушателя. Хоть и онлайн, но доклады стоят того, чтобы подключаться к трансляции из любой точки мира. Тем более программа ожидается весьма насыщенной. Вот что мне будет особенно интересно послушать: 🔸"Как не превратить автотесты в объект ненависти: ред флаги в инфраструктуре". Актуальная тема, поскольку инфраструктура и архитектура тестов напрямую влияют на их работу и поддерживаемость. 🔸"Автотесты как точка входа для атак: вы даже не заметите" — так как безопасность — это то, чем нельзя пренебрегать. А в случае с open source библиотеками уязвимости могут быть абсолютно неочевидными для QA. 🔸"Практичный вайбкодинг без инфоцыганства" — так как сам регулярно использую ИИ для разработки новых тренажёров и уже успел столкнуться с циклом постоянных правок, хотелось бы узнать хорошие практики в подобной работе. И это только малая часть из докладов, которые будут. Конференция пройдёт 27–28 апреля в Москве с возможностью подключиться онлайн. В программе также будут доклады про инструменты, архитектуру тестовой инфраструктуры, безопасность, производительность и реальные кейсы из продакшена. Также расскажут про применение AI в QA и тесты ИИ-агентов. А что вы думаете насчёт программы в этом сезоне? Что зацепило и вызвало интерес? И вообще, планируете ли принять участие в конференции?)

SQL EXISTS (ч2) 1 часть см. в предыдущем посте. 👆 Таким образом, EXISTS полезен в ситуациях, где нужно проверить наличие связанных записей и выразить это в SQL явно и читаемо. Для тестировщика это особенно актуально в запросах на проверку консистентности данных, при анализе состояний сущностей и в задачах, связанных с пониманием бизнес-логики системы. Если JOIN отвечает на вопрос «как соединить данные из двух таблиц», то EXISTS часто отвечает на другой вопрос: «существует ли для этой строки нужная связь вообще». Знание EXISTS полезно не только для прохождения собеседований, но и для практической работы с базой данных. Это одна из тех конструкций, которые показывают, что специалист понимает не только базовый синтаксис SQL, но и умеет выбирать подходящий инструмент под конкретную задачу. #sql #qa — 💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️‍♂️ Тренажеры для практики тестирования |🧑‍💻Практикум для начинающих по тестированию API

SQL EXISTS (ч1) На собеседованиях по SQL и в практической работе QA внимание обычно сосредоточено на JOIN, поскольку именно через него чаще всего связывают данные из нескольких таблиц. Однако помимо JOIN полезно знать и оператор EXISTS. Он применяется в тех случаях, когда необходимо не получить данные из связанной таблицы, а проверить сам факт их наличия. EXISTS - это логический оператор, который используется вместе с подзапросом. Его смысл сводится к простой проверке: если подзапрос возвращает хотя бы одну строку, условие считается истинным. Если подзапрос не возвращает ни одной строки, условие считается ложным. Важно понимать, что в этом случае нас интересуют не сами данные из подзапроса, а наличие или отсутствие результата. Общий синтаксис выглядит так:

    
        SELECT column_name(s)
FROM table_name
WHERE EXISTS (
    SELECT 1
    FROM another_table
    WHERE condition
);{}
    

Такую конструкцию удобно читать следующим образом: выбрать строки из основной таблицы только в том случае, если для них существует хотя бы одна связанная запись, подходящая под условие во вложенном запросе. Рассмотрим пример на базе данных с покупателями и заказами. Пусть нужно найти покупателей, у которых есть хотя бы один заказ. Одно из типичных решений строится через JOIN:

    
        SELECT DISTINCT c.id, c.full_name
FROM customers c
JOIN orders o ON o.customer_id = c.id;{}
    

Этот запрос корректен, но его логика связана именно с соединением таблиц. Кроме того, если у одного покупателя несколько заказов, после JOIN появятся дубликаты строк, поэтому приходится дополнительно использовать DISTINCT. Ту же задачу можно выразить через EXISTS:

    
        SELECT c.id, c.full_name
FROM customers c
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.customer_id = c.id
);{}
    

В этом случае запрос читается более буквально: выбрать тех покупателей, для которых существует хотя бы один заказ. Для каждой строки таблицы customers база данных выполняет проверку вложенного условия. Если находится хотя бы один заказ, где o.customer_id = c.id, покупатель попадает в результат. Именно в таких сценариях EXISTS оказывается особенно полезен. Если задача формулируется как проверка наличия связанных данных, а не как получение полей из нескольких таблиц в одном наборе результата, использование EXISTS может сделать запрос более понятным по смыслу. Он хорошо подходит для условий вида «у пользователя есть заказы», «у товара есть продажи», «у заказа есть платежи», «у записи есть связанные комментарии». Например, если нужно найти заказы, по которым существует хотя бы один платёж, можно написать:

    
        SELECT o.id, o.status, o.total_amount
FROM orders o
WHERE EXISTS (
    SELECT 1
    FROM payments p
    WHERE p.order_id = o.id
);{}
    

Здесь не требуется выводить данные из таблицы payments. Нужно лишь убедиться, что для заказа найдена хотя бы одна связанная запись. В этом случае EXISTS выражает задачу точнее, чем JOIN, поскольку в логике запроса сразу отражено, что нас интересует именно факт существования платежа. Полезно помнить и о том, что EXISTS нередко рассматривается как альтернатива JOIN не вообще, а в определённом классе задач. Если нужно получить, например, имя покупателя и одновременно дату его последнего заказа, одного EXISTS будет недостаточно, потому что он не предназначен для извлечения связанных значений. В таких случаях по-прежнему нужен JOIN или другие конструкции, позволяющие соединять и выводить данные из нескольких таблиц. Если же задача состоит только в проверке наличия связи, EXISTS может оказаться более удачным выбором. Отдельно стоит обратить внимание на то, что в подзапросе часто пишут SELECT 1:

    
        SELECT c.id, c.full_name
FROM customers c
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.customer_id = c.id
);{}
    

Число 1 здесь не имеет самостоятельного смысла как данные. Это просто распространённый способ показать, что подзапрос используется только для проверки существования строк. Можно было бы написать и SELECT *, но SELECT 1 лучше подчёркивает намерение автора запроса.