Новое видео на YT!
Пробую новый формат: смотрю вакансии для Junior QA с hh.ru и комментирую их, рассказывая подробно про плюсы, минусы и подводные камни.
Будет полезно для новичков, которые только вышли на рынок. Заодно даст понимание, на разобранных примерах, какого рода вакансии сейчас есть на рынке, и какие требования к кандидатам сейчас выдвигаются.
👉 ссылка на видео
PS
Подписчики Boosty получают доступ к новым видео раньше.
#анонс #видео
—
💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️♂️ Тренажеры для практики тестирования |🧑💻Практикум для начинающих по тестированию API
Пробую новый формат: смотрю вакансии для Junior QA с hh.ru и комментирую их, рассказывая подробно про плюсы, минусы и подводные камни.
Будет полезно для новичков, которые только вышли на рынок. Заодно даст понимание, на разобранных примерах, какого рода вакансии сейчас есть на рынке, и какие требования к кандидатам сейчас выдвигаются.
👉 ссылка на видео
PS
Подписчики Boosty получают доступ к новым видео раньше.
#анонс #видео
—
💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️♂️ Тренажеры для практики тестирования |🧑💻Практикум для начинающих по тестированию API
❤4👍2🔥2
Друзья, привет! Я к вам с новинкой. 🆕
Разработал новый учебный продукт в формате локальной песочницы, который поможет получить практику по работе с базой данных PosgreSQL. Тренажёр разворачивается у вас локально через Docker и представляет собой небольшую систему с базой данных, API и интерфейсом, на которой можно отрабатывать различные сценарии работы QA.
> ссылка на песочницу
📦 Что ждет внутри:
🔹 PostgreSQL база с готовой структурой системы по работе с заказами
🔹 UI, через который можно создавать и изменять данные, а также отслеживать изменения, внесенные напрямую в базу данных (включая возможность вернуть базу к начальному состоянию)
🔹 API + Swagger для понимания поведения системы
🔹 36 заданий разного уровня сложности - ответы с подробным разбором
🔹 отдельная страница с теорией по SQL
Песочница будет актуальна для новичков и тех QA, у которых нет доступа к базе в их проектах. Она даст необходимую практику, в рамках которой вы сможете тренировать:
♦️ уверенную работу с SELECT, JOIN, GROUP BY
♦️ изменение данных через UPDATE / DELETE без ошибок
♦️ понимание связей между таблицами
♦️ проверку консистентности данных
♦️ анализ бизнес-логики через понимание устройства базы данных
Работа с тренажером позволит:
🔸 подготовиться к собеседованиям на позицию QA и не сыпаться на вопросах по написанию запросов на соединение таблиц и группировку
🔸 научиться манипулировать данными (CRUD операции) с помощью DBeaver и SQL запросов
🔸 освежить теорию и систематизировать имеющиеся навыки
Для работы понадобятся лишь:
- Docker (для запуска среды)
- DBeaver или любой другой SQL-клиент
Вся информация по установке и запуску указана внутри.
> Приобрести доступ можно по ссылке
По всем вопросам пишите в ТГ (или другие доступные каналы связи).
#анонс #практика #sql #qa
Разработал новый учебный продукт в формате локальной песочницы, который поможет получить практику по работе с базой данных PosgreSQL. Тренажёр разворачивается у вас локально через Docker и представляет собой небольшую систему с базой данных, API и интерфейсом, на которой можно отрабатывать различные сценарии работы QA.
> ссылка на песочницу
📦 Что ждет внутри:
🔹 PostgreSQL база с готовой структурой системы по работе с заказами
🔹 UI, через который можно создавать и изменять данные, а также отслеживать изменения, внесенные напрямую в базу данных (включая возможность вернуть базу к начальному состоянию)
🔹 API + Swagger для понимания поведения системы
🔹 36 заданий разного уровня сложности - ответы с подробным разбором
🔹 отдельная страница с теорией по SQL
Песочница будет актуальна для новичков и тех QA, у которых нет доступа к базе в их проектах. Она даст необходимую практику, в рамках которой вы сможете тренировать:
♦️ уверенную работу с SELECT, JOIN, GROUP BY
♦️ изменение данных через UPDATE / DELETE без ошибок
♦️ понимание связей между таблицами
♦️ проверку консистентности данных
♦️ анализ бизнес-логики через понимание устройства базы данных
Работа с тренажером позволит:
🔸 подготовиться к собеседованиям на позицию QA и не сыпаться на вопросах по написанию запросов на соединение таблиц и группировку
🔸 научиться манипулировать данными (CRUD операции) с помощью DBeaver и SQL запросов
🔸 освежить теорию и систематизировать имеющиеся навыки
Для работы понадобятся лишь:
- Docker (для запуска среды)
- DBeaver или любой другой SQL-клиент
Вся информация по установке и запуску указана внутри.
> Приобрести доступ можно по ссылке
По всем вопросам пишите в ТГ (или другие доступные каналы связи).
#анонс #практика #sql #qa
❤4🔥3
SQL EXISTS (ч1)
На собеседованиях по SQL и в практической работе QA внимание обычно сосредоточено на
Общий синтаксис выглядит так:
Такую конструкцию удобно читать следующим образом: выбрать строки из основной таблицы только в том случае, если для них существует хотя бы одна связанная запись, подходящая под условие во вложенном запросе.
Рассмотрим пример на базе данных с покупателями и заказами. Пусть нужно найти покупателей, у которых есть хотя бы один заказ. Одно из типичных решений строится через
Этот запрос корректен, но его логика связана именно с соединением таблиц. Кроме того, если у одного покупателя несколько заказов, после
Ту же задачу можно выразить через
В этом случае запрос читается более буквально: выбрать тех покупателей, для которых существует хотя бы один заказ. Для каждой строки таблицы
Именно в таких сценариях
Например, если нужно найти заказы, по которым существует хотя бы один платёж, можно написать:
Здесь не требуется выводить данные из таблицы
Полезно помнить и о том, что
Отдельно стоит обратить внимание на то, что в подзапросе часто пишут
Число
На собеседованиях по 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 лучше подчёркивает намерение автора запроса.❤4👍3
SQL EXISTS (ч2)
1 часть см. в предыдущем посте. 👆
Таким образом,
Знание
#sql #qa
—
💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️♂️ Тренажеры для практики тестирования |🧑💻Практикум для начинающих по тестированию API
1 часть см. в предыдущем посте. 👆
Таким образом,
EXISTS полезен в ситуациях, где нужно проверить наличие связанных записей и выразить это в SQL явно и читаемо. Для тестировщика это особенно актуально в запросах на проверку консистентности данных, при анализе состояний сущностей и в задачах, связанных с пониманием бизнес-логики системы. Если JOIN отвечает на вопрос «как соединить данные из двух таблиц», то EXISTS часто отвечает на другой вопрос: «существует ли для этой строки нужная связь вообще».Знание
EXISTS полезно не только для прохождения собеседований, но и для практической работы с базой данных. Это одна из тех конструкций, которые показывают, что специалист понимает не только базовый синтаксис SQL, но и умеет выбирать подходящий инструмент под конкретную задачу.#sql #qa
—
💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️♂️ Тренажеры для практики тестирования |🧑💻Практикум для начинающих по тестированию API
🔥5
Всем привет. Вы наверняка слышали про конференцию Heisenbug (https://heisenbug.ru/).
В этот раз хотел бы обсудить её здесь, ведь сам приму в ней участие в качестве слушателя. Хоть и онлайн, но доклады стоят того, чтобы подключаться к трансляции из любой точки мира. Тем более программа ожидается весьма насыщенной.
Вот что мне будет особенно интересно послушать:
🔸"Как не превратить автотесты в объект ненависти: ред флаги в инфраструктуре". Актуальная тема, поскольку инфраструктура и архитектура тестов напрямую влияют на их работу и поддерживаемость.
🔸"Автотесты как точка входа для атак: вы даже не заметите" — так как безопасность — это то, чем нельзя пренебрегать. А в случае с open source библиотеками уязвимости могут быть абсолютно неочевидными для QA.
🔸"Практичный вайбкодинг без инфоцыганства" — так как сам регулярно использую ИИ для разработки новых тренажёров и уже успел столкнуться с циклом постоянных правок, хотелось бы узнать хорошие практики в подобной работе.
И это только малая часть из докладов, которые будут.
Конференция пройдёт 27–28 апреля в Москве с возможностью подключиться онлайн.
В программе также будут доклады про инструменты, архитектуру тестовой инфраструктуры, безопасность, производительность и реальные кейсы из продакшена. Также расскажут про применение AI в QA и тесты ИИ-агентов.
А что вы думаете насчёт программы в этом сезоне? Что зацепило и вызвало интерес? И вообще, планируете ли принять участие в конференции?)
В этот раз хотел бы обсудить её здесь, ведь сам приму в ней участие в качестве слушателя. Хоть и онлайн, но доклады стоят того, чтобы подключаться к трансляции из любой точки мира. Тем более программа ожидается весьма насыщенной.
Вот что мне будет особенно интересно послушать:
🔸"Как не превратить автотесты в объект ненависти: ред флаги в инфраструктуре". Актуальная тема, поскольку инфраструктура и архитектура тестов напрямую влияют на их работу и поддерживаемость.
🔸"Автотесты как точка входа для атак: вы даже не заметите" — так как безопасность — это то, чем нельзя пренебрегать. А в случае с open source библиотеками уязвимости могут быть абсолютно неочевидными для QA.
🔸"Практичный вайбкодинг без инфоцыганства" — так как сам регулярно использую ИИ для разработки новых тренажёров и уже успел столкнуться с циклом постоянных правок, хотелось бы узнать хорошие практики в подобной работе.
И это только малая часть из докладов, которые будут.
Конференция пройдёт 27–28 апреля в Москве с возможностью подключиться онлайн.
В программе также будут доклады про инструменты, архитектуру тестовой инфраструктуры, безопасность, производительность и реальные кейсы из продакшена. Также расскажут про применение AI в QA и тесты ИИ-агентов.
А что вы думаете насчёт программы в этом сезоне? Что зацепило и вызвало интерес? И вообще, планируете ли принять участие в конференции?)
❤3
Forwarded from egor mironov
Хочу выразить благодарность Алексею за тренажер по БД! Отличный продукт и материал, который позволяет подтянуть знания по базам данных до приличного уровня. Понравилось, что есть Swagger и UI для работы с БД, наличие которых создаёт условия реального проекта (за такой прайс - это вообще находка).
Лично я прошёлся по задачам за два дня, а на следующий день уже был на техническом интервью на позицию Fullstack QA. На интервью было 3 задачи по SQL, которые практически дублировали задачи из курса Алексея. По итогу: все задачи решил успешно и получил оффер.
Также хочу отметить, что есть исходный код API для взаимодействия с БД, который можно почитать и порефакторить под свои задумки - это просто супер.
Со своей стороны хотел бы посоветовать автору расширить формулировки задач: иногда приходилось немного подумать, проанализировать условия, но минусом это назвать не могу, так как пользователь курса учится правильно понимать не совсем содержательные задачи, что часто встречается на реальных проектах.
Лично я прошёлся по задачам за два дня, а на следующий день уже был на техническом интервью на позицию Fullstack QA. На интервью было 3 задачи по SQL, которые практически дублировали задачи из курса Алексея. По итогу: все задачи решил успешно и получил оффер.
Также хочу отметить, что есть исходный код API для взаимодействия с БД, который можно почитать и порефакторить под свои задумки - это просто супер.
Со своей стороны хотел бы посоветовать автору расширить формулировки задач: иногда приходилось немного подумать, проанализировать условия, но минусом это назвать не могу, так как пользователь курса учится правильно понимать не совсем содержательные задачи, что часто встречается на реальных проектах.
❤1🔥1
Алертинг. (часть 1)
Недавно у меня возникла бытовая ситуация, которая хорошо показывает, зачем вообще нужен алертинг. Водосчётчик горячей воды перестал считать потребление воды. Но заметил я это не сразу, а только в следующем месяце, в день, когда пришло время передавать показания. Новое значение оказалось таким же, как и месяц назад. До этого момента всё выглядело штатно: вода есть, пользоваться ей можно, ничего явно не менялось. Проблема существовала, но оставалась незамеченной, потому что я не смотрел на неё регулярно и не получал никакого сигнала о том, что что-то пошло не так.
Если перенести эту ситуацию в более формальную плоскость, становится видно, что проблема была не только в самом счётчике, но и в отсутствии механизма уведомления. Система продолжала существовать, но не сообщала о том, что важный для меня процесс фактически остановился. Если бы был настроен простой контроль: например, проверка, что показания, при потреблении горячей воды (когда открыт кран) не менются, - можно было бы узнать о неисправности гораздо раньше. Не в момент, когда уже подошёл срок передачи данных, а почти сразу после появления отклонения.
Именно в этом и состоит смысл алертинга. Алертинг - это механизм, который сообщает о значимом событии или отклонении в системе, чтобы человек не обнаруживал проблему случайно, слишком поздно или по косвенным признакам. Само по себе наличие данных, логов, метрик или журналов ещё не решает задачу. Важно, чтобы система не просто фиксировала состояние, а умела вовремя обратить внимание на то, что требует реакции.
На практике алертинг обычно строится вокруг наблюдения за некоторыми признаками. У системы есть ожидаемое поведение: сервис должен отвечать, запросы должны обрабатываться за допустимое время, ошибки не должны резко расти, данные должны обновляться, фоновые задачи должны выполняться, интеграции должны присылать результат. Если фактическое состояние начинает заметно отличаться от ожидаемого, срабатывает сигнал. Этот сигнал может прийти в виде сообщения в чат, письма, push-уведомления, звонка, события в системе мониторинга или задачи в трекере.
Важно понимать, что алертинг не существует сам по себе. Он опирается на наблюдаемость системы. Сначала нужно измерять что-то полезное: количество ошибок, время ответа, загрузку ресурсов, успешность бизнес-операций, состояние очередей, наличие новых записей, результат фоновых расчётов. Затем для этих показателей определяются условия, при которых нужно подать сигнал. Например, если доля ошибок превышает порог, если сервис недоступен несколько минут подряд, если число заказов внезапно падает до нуля, если платёжная интеграция перестаёт возвращать ответы, если данные в витрине давно не обновлялись.
Здесь полезно вернуться к примеру с водосчётчиком. Само по себе наличие счётчика - это ещё не контроль. Контроль начинается там, где появляется проверка: изменяются ли значения, не остановился ли учёт, нет ли нетипично долгого периода без движения. В системах работает тот же принцип. Недостаточно просто иметь сервис, базу данных или фоновую задачу. Нужно понимать, какие признаки говорят о том, что всё идёт штатно, а какие - что процесс уже нарушен, хотя внешне это может быть ещё неочевидно.
Особенно полезен алертинг в тех ситуациях, где человек физически не может постоянно проверять состояние вручную. В реальной работе почти никто не открывает каждые пять минут логи, не запускает вручную тестовые запросы и не сравнивает значения в таблицах. Это слишком дорого по времени и плохо масштабируется. Поэтому задача алертинга - снять с человека необходимость постоянно дежурить глазами у системы и заменить это автоматическим контролем ключевых состояний.
Недавно у меня возникла бытовая ситуация, которая хорошо показывает, зачем вообще нужен алертинг. Водосчётчик горячей воды перестал считать потребление воды. Но заметил я это не сразу, а только в следующем месяце, в день, когда пришло время передавать показания. Новое значение оказалось таким же, как и месяц назад. До этого момента всё выглядело штатно: вода есть, пользоваться ей можно, ничего явно не менялось. Проблема существовала, но оставалась незамеченной, потому что я не смотрел на неё регулярно и не получал никакого сигнала о том, что что-то пошло не так.
Если перенести эту ситуацию в более формальную плоскость, становится видно, что проблема была не только в самом счётчике, но и в отсутствии механизма уведомления. Система продолжала существовать, но не сообщала о том, что важный для меня процесс фактически остановился. Если бы был настроен простой контроль: например, проверка, что показания, при потреблении горячей воды (когда открыт кран) не менются, - можно было бы узнать о неисправности гораздо раньше. Не в момент, когда уже подошёл срок передачи данных, а почти сразу после появления отклонения.
Именно в этом и состоит смысл алертинга. Алертинг - это механизм, который сообщает о значимом событии или отклонении в системе, чтобы человек не обнаруживал проблему случайно, слишком поздно или по косвенным признакам. Само по себе наличие данных, логов, метрик или журналов ещё не решает задачу. Важно, чтобы система не просто фиксировала состояние, а умела вовремя обратить внимание на то, что требует реакции.
На практике алертинг обычно строится вокруг наблюдения за некоторыми признаками. У системы есть ожидаемое поведение: сервис должен отвечать, запросы должны обрабатываться за допустимое время, ошибки не должны резко расти, данные должны обновляться, фоновые задачи должны выполняться, интеграции должны присылать результат. Если фактическое состояние начинает заметно отличаться от ожидаемого, срабатывает сигнал. Этот сигнал может прийти в виде сообщения в чат, письма, push-уведомления, звонка, события в системе мониторинга или задачи в трекере.
Важно понимать, что алертинг не существует сам по себе. Он опирается на наблюдаемость системы. Сначала нужно измерять что-то полезное: количество ошибок, время ответа, загрузку ресурсов, успешность бизнес-операций, состояние очередей, наличие новых записей, результат фоновых расчётов. Затем для этих показателей определяются условия, при которых нужно подать сигнал. Например, если доля ошибок превышает порог, если сервис недоступен несколько минут подряд, если число заказов внезапно падает до нуля, если платёжная интеграция перестаёт возвращать ответы, если данные в витрине давно не обновлялись.
Здесь полезно вернуться к примеру с водосчётчиком. Само по себе наличие счётчика - это ещё не контроль. Контроль начинается там, где появляется проверка: изменяются ли значения, не остановился ли учёт, нет ли нетипично долгого периода без движения. В системах работает тот же принцип. Недостаточно просто иметь сервис, базу данных или фоновую задачу. Нужно понимать, какие признаки говорят о том, что всё идёт штатно, а какие - что процесс уже нарушен, хотя внешне это может быть ещё неочевидно.
Особенно полезен алертинг в тех ситуациях, где человек физически не может постоянно проверять состояние вручную. В реальной работе почти никто не открывает каждые пять минут логи, не запускает вручную тестовые запросы и не сравнивает значения в таблицах. Это слишком дорого по времени и плохо масштабируется. Поэтому задача алертинга - снять с человека необходимость постоянно дежурить глазами у системы и заменить это автоматическим контролем ключевых состояний.
❤1🔥1
Алертинг (часть 2).
Отдельно стоит отметить, что хороший алертинг помогает не только узнавать о технических сбоях, но и замечать бизнес-проблемы. Например, сервис формально работает, серверы доступны, ошибок в логах почти нет, но за последний час не было ни одного успешно оформленного заказа. Или письма пользователям продолжают отправляться из приложения, но не доходят до адресатов из-за сбоя внешнего провайдера. Или интеграция с платёжной системой отвечает кодом 200, но фактически не проводит операции. Во всех этих случаях инфраструктурные признаки могут выглядеть нормально, а реальная проблема уже существует. Поэтому алертинг строят не только по техническим метрикам, но и по бизнес-сценариям.
Для тестировщика понимание алертинга полезно сразу в нескольких смыслах. Во-первых, это помогает лучше видеть систему целиком, а не только отдельный запрос или экран. Во-вторых, это даёт возможность задавать правильные вопросы ещё на этапе анализа требований: как команда узнает, что процесс перестал работать, какие сигналы должны появляться, кто получит уведомление, что считается критичной проблемой, а что допустимым отклонением. В-третьих, это влияет на качество тестирования. Если в системе вообще не предусмотрены способы быстро обнаруживать сбои, это уже риск, даже если функционально всё работает.
На практике тестировщик может участвовать в проверке алертинга по-разному. Можно уточнять, какие события должны мониториться. Можно проверять, формируются ли нужные метрики и логи. Можно моделировать сбои и смотреть, возникает ли уведомление. Можно анализировать, не слишком ли шумный алертинг, не приходят ли сигналы по незначительным поводам, не теряются ли действительно важные проблемы среди большого числа второстепенных сообщений. Хороший алертинг - качественно настроенная система сигналов, которая помогает реагировать вовремя и по делу.
Это особенно важно, потому что плохой алертинг тоже является проблемой. Если уведомления приходят слишком часто и по любому поводу, команда начинает к ним привыкать и перестаёт воспринимать их всерьёз. Если сигналы приходят слишком поздно, ценность алертинга снижается: проблему всё равно замечают уже по последствиям. Если условия срабатывания выбраны неудачно, можно либо пропускать реальные инциденты, либо создавать постоянный шум. Поэтому при настройке алертов всегда приходится искать баланс между чувствительностью и практической пользой.
В зрелых системах алертинг - это не просто техническая настройка, а часть эксплуатационной культуры. Команда заранее решает, что именно для неё критично, какие состояния считаются аварийными, как быстро нужно узнавать о сбоях, кто и как реагирует на сигнал. То есть алертинг связан не только с мониторингом, но и с процессом реагирования. Если уведомление пришло, но никто не понимает, что делать дальше, система оповещения будет работать лишь наполовину.
Если снова вспомнить историю со счётчиком, проблема была не в том, что у меня совсем не было данных. Проблема была в том, что я узнал о неисправности слишком поздно, в момент плановой ручной проверки. В программных продуктах подобная ситуация происходит постоянно. Что-то ломается и не всегда заметно. Иногда процесс просто перестаёт двигаться, данные перестают обновляться, сообщения перестают уходить, задача зависает в очереди, а внешне всё выглядит вполне спокойно. И именно для таких случаев нужен алертинг: чтобы отклонение становилось заметным не случайно, а автоматически.
Поэтому алертинг можно рассматривать как способ сократить расстояние между моментом возникновения проблемы и моментом, когда о ней узнаёт команда. Чем меньше это расстояние, тем меньше последствий успевает накопиться. Для бизнеса это означает снижение потерь, для команды - более быструю реакцию, для тестировщика - лучшее понимание надёжности продукта. А для обычной жизни, как показывает пример с водосчётчиком, - возможность заметить поломку тогда, когда она только возникла, а не тогда, когда уже пришло время разбираться с последствиями.
#qa #infra
Отдельно стоит отметить, что хороший алертинг помогает не только узнавать о технических сбоях, но и замечать бизнес-проблемы. Например, сервис формально работает, серверы доступны, ошибок в логах почти нет, но за последний час не было ни одного успешно оформленного заказа. Или письма пользователям продолжают отправляться из приложения, но не доходят до адресатов из-за сбоя внешнего провайдера. Или интеграция с платёжной системой отвечает кодом 200, но фактически не проводит операции. Во всех этих случаях инфраструктурные признаки могут выглядеть нормально, а реальная проблема уже существует. Поэтому алертинг строят не только по техническим метрикам, но и по бизнес-сценариям.
Для тестировщика понимание алертинга полезно сразу в нескольких смыслах. Во-первых, это помогает лучше видеть систему целиком, а не только отдельный запрос или экран. Во-вторых, это даёт возможность задавать правильные вопросы ещё на этапе анализа требований: как команда узнает, что процесс перестал работать, какие сигналы должны появляться, кто получит уведомление, что считается критичной проблемой, а что допустимым отклонением. В-третьих, это влияет на качество тестирования. Если в системе вообще не предусмотрены способы быстро обнаруживать сбои, это уже риск, даже если функционально всё работает.
На практике тестировщик может участвовать в проверке алертинга по-разному. Можно уточнять, какие события должны мониториться. Можно проверять, формируются ли нужные метрики и логи. Можно моделировать сбои и смотреть, возникает ли уведомление. Можно анализировать, не слишком ли шумный алертинг, не приходят ли сигналы по незначительным поводам, не теряются ли действительно важные проблемы среди большого числа второстепенных сообщений. Хороший алертинг - качественно настроенная система сигналов, которая помогает реагировать вовремя и по делу.
Это особенно важно, потому что плохой алертинг тоже является проблемой. Если уведомления приходят слишком часто и по любому поводу, команда начинает к ним привыкать и перестаёт воспринимать их всерьёз. Если сигналы приходят слишком поздно, ценность алертинга снижается: проблему всё равно замечают уже по последствиям. Если условия срабатывания выбраны неудачно, можно либо пропускать реальные инциденты, либо создавать постоянный шум. Поэтому при настройке алертов всегда приходится искать баланс между чувствительностью и практической пользой.
В зрелых системах алертинг - это не просто техническая настройка, а часть эксплуатационной культуры. Команда заранее решает, что именно для неё критично, какие состояния считаются аварийными, как быстро нужно узнавать о сбоях, кто и как реагирует на сигнал. То есть алертинг связан не только с мониторингом, но и с процессом реагирования. Если уведомление пришло, но никто не понимает, что делать дальше, система оповещения будет работать лишь наполовину.
Если снова вспомнить историю со счётчиком, проблема была не в том, что у меня совсем не было данных. Проблема была в том, что я узнал о неисправности слишком поздно, в момент плановой ручной проверки. В программных продуктах подобная ситуация происходит постоянно. Что-то ломается и не всегда заметно. Иногда процесс просто перестаёт двигаться, данные перестают обновляться, сообщения перестают уходить, задача зависает в очереди, а внешне всё выглядит вполне спокойно. И именно для таких случаев нужен алертинг: чтобы отклонение становилось заметным не случайно, а автоматически.
Поэтому алертинг можно рассматривать как способ сократить расстояние между моментом возникновения проблемы и моментом, когда о ней узнаёт команда. Чем меньше это расстояние, тем меньше последствий успевает накопиться. Для бизнеса это означает снижение потерь, для команды - более быструю реакцию, для тестировщика - лучшее понимание надёжности продукта. А для обычной жизни, как показывает пример с водосчётчиком, - возможность заметить поломку тогда, когда она только возникла, а не тогда, когда уже пришло время разбираться с последствиями.
#qa #infra
❤1🔥1
Друзья, я к вам с важными обновлениями по практикуму по работе с Kafka. 📚
В связи с тем, что хостинг-провайдер ощутимо поднял цены на свои услуги, чтобы также резко не увеличивать цену, было принято решение изменить формат развертывания и работы тренажера.
Теперь для вас доступна версия, развертываемая локально с помощью Docker🖥 . Таким образом:
🔸вы не будете зависеть от работы хостинга
🔸 тренажер будет запускаться и работать у вас локально, изолированно от других учащихся
Для локального развертывания вам будет нужен Docker Desktop (и может потребоваться VPN). Весь процесс по установке и запуску описан в документации, которая прилагается к тренажеру. В остальном работа с тренажером останется прежней.
Старая веб-версия будет поддерживаться до 17.05.2026 и затем прекратит свою работу. 🏁
Успевайте приобрести практикум по старой цене до 27.04.
#анонс #практикум #kafka
—
💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️♂️ Тренажеры для практики тестирования |🧑💻Практикум для начинающих по тестированию API
В связи с тем, что хостинг-провайдер ощутимо поднял цены на свои услуги, чтобы также резко не увеличивать цену, было принято решение изменить формат развертывания и работы тренажера.
Теперь для вас доступна версия, развертываемая локально с помощью Docker
🔸вы не будете зависеть от работы хостинга
🔸 тренажер будет запускаться и работать у вас локально, изолированно от других учащихся
Для локального развертывания вам будет нужен Docker Desktop (и может потребоваться VPN). Весь процесс по установке и запуску описан в документации, которая прилагается к тренажеру. В остальном работа с тренажером останется прежней.
Старая веб-версия будет поддерживаться до 17.05.2026 и затем прекратит свою работу. 🏁
Успевайте приобрести практикум по старой цене до 27.04.
#анонс #практикум #kafka
—
💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️♂️ Тренажеры для практики тестирования |🧑💻Практикум для начинающих по тестированию API
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥1
Курсорная пагинация.
В новом материале рассказываю про курсорную пагинацию и ее отличия от обычной, а также показываю сильные и слабые стороны обеих на различных примерах.
Ссылка на статью
Ставьте🔥 если хотите больше подобных лонгридов.
#qa #api
—
💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️♂️ Тренажеры для практики тестирования |🧑💻Практикум для начинающих по тестированию API
В новом материале рассказываю про курсорную пагинацию и ее отличия от обычной, а также показываю сильные и слабые стороны обеих на различных примерах.
Ссылка на статью
Ставьте
#qa #api
—
💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️♂️ Тренажеры для практики тестирования |🧑💻Практикум для начинающих по тестированию API
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
Шпаргалка по техникам тест-дизайна.
#ифнографика
—
💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️♂️ Тренажеры для практики тестирования |🧑💻Практикум для начинающих по тестированию API
#ифнографика
—
💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️♂️ Тренажеры для практики тестирования |🧑💻Практикум для начинающих по тестированию API
❤13
Всем отличных выходных, коллеги!
По данному случаю запустил распродажу у себя на Boosty. Это отличная возможность приобрести мои платные продукты по хорошим ценам!
Акция продлится по 03 мая включительно. Так что в эти дни можно будет не только отдохнуть, но и прокачать различные аспекты тестирования.
> Ссылка на Boosty
—
💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️♂️ Тренажеры для практики тестирования |🧑💻Практикум для начинающих по тестированию API
По данному случаю запустил распродажу у себя на Boosty. Это отличная возможность приобрести мои платные продукты по хорошим ценам!
Акция продлится по 03 мая включительно. Так что в эти дни можно будет не только отдохнуть, но и прокачать различные аспекты тестирования.
> Ссылка на Boosty
—
💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️♂️ Тренажеры для практики тестирования |🧑💻Практикум для начинающих по тестированию API
❤2🔥2
Forwarded from QA Aklimenko reviews
#Отзыв на курс "Интенсив по тестированию API"
https://stepik.org/course/257014/reviews
https://stepik.org/course/257014/reviews
Хочу оставить отзыв об интенсиве по тестированию API.
В первую очередь хочу поблагодарить Алексея, автора курса, за честную и подробную обратную связь ещё до старта обучения.
Перед покупкой я внимательно изучил описание курса, но у меня осталось несколько вопросов. Я написал Алексею и получил развёрнутые ответы по каждому пункту.
Для меня это было важно, потому что раньше уже был негативный опыт с другим курсом: в описании обещали одно, на консультации подтвердили то же самое, а по факту в программе оказалось совсем другое. То, ради чего я туда шёл, там почти не затрагивалось. В итоге - деньги и время были потрачены впустую.
Здесь ситуация оказалась обратной: описание курса соответствует содержанию, а по некоторым темам интенсив даёт даже больше, чем я ожидал.
Курс хорошо подходит тем, кто хочет прокачать именно практическое понимание API testing, а не просто посмотреть, как отправлять запросы в Postman.
На курсе разбираются и отрабатываются такие темы, как:
- сложные цепочки запросов - например, получение id из одного запроса и использование его в следующих, построение end-to-end API-сценариев;
- auth flows - login, refresh token, обработка невалидных или просроченных токенов, проверка доступа;
- idempotency - повторная отправка одного и того же запроса и поведение системы при дублирующих операциях;
- negative scenarios / negative design - невалидные данные, отсутствующие поля, некорректные типы, проверка обработки ошибок;
- schema validation - проверка структуры ответа, типов данных, обязательных и опциональных полей;
- auto-run collections - подготовка коллекций, которые можно запускать не только вручную, но и как связанный сценарий;
- bug reports - оформление найденных дефектов с понятным описанием, шагами и результатами.
Отдельно отмечу практическую часть. Есть возможность пройти полный цикл тестирования API: разобраться в документации, составить проверки, выполнить их, оформить результаты и получить обратную связь.
Для меня ценность интенсива в том, что он даёт не разрозненные приёмы, а системный подход к API testing: как анализировать документацию, строить проверки, связывать запросы в сценарии, проверять авторизацию, негативные кейсы, структуру ответа и фактическое поведение системы.
Это хороший формат для тех, кто хочет не просто “потрогать Postman”, а прокачать практический навык API testing и дальше применять его в рабочих задачах, пет-проектах и на технических интервью.
На мой взгляд, курс хорошо подойдёт Junior+/Middle QA-специалистам, которые хотят системно прокачать практическое API testing: от базовой работы с запросами до auth flows, chained requests, negative scenarios, schema validation, auto-run collections и оформления bug reports по найденным дефектам.
Из небольших замечаний: было бы здорово, если бы секции с тестами были чуть обширнее, а варианты ответов - немного каверзнее.
Алексей, спасибо за проделанную работу!
👍2
В новой статье рассказываю про то как читать gRPC-контракт. Материал написан на простом примере: аналитический сервис, который считает агрегированные показатели и отдаёт их другим сервисам через gRPC. Будет полезно тем, кто уже работал с REST API и хочет понять, как устроены контракты в gRPC.
👉 Ссылка на статью
А после прочтения все желающие могут закрепить знания на мини-тренажере: изучив контракт и бизнес-контекст, ответить на вопросы квиза.
🧑💻Ссылка на тренажер
PS. добавил материалы в свой курс "Интенсив по тестированию API".
#grpc #api #backend
—
💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️♂️ Тренажеры для практики тестирования |🧑💻Практикум для начинающих по тестированию API
👉 Ссылка на статью
А после прочтения все желающие могут закрепить знания на мини-тренажере: изучив контракт и бизнес-контекст, ответить на вопросы квиза.
🧑💻Ссылка на тренажер
PS. добавил материалы в свой курс "Интенсив по тестированию API".
#grpc #api #backend
—
💼 Мои услуги и проекты |📺 Канал на YouTube |📝 Канал с отзывами |☕️ Поддержать автора на Boosty |🏋️♂️ Тренажеры для практики тестирования |🧑💻Практикум для начинающих по тестированию API
❤3👍3🔥1