Заметки тестировщика | QA Notes

🗄️ Как найти баг, который никто не видит - через данные UI зелёный. Тесты проходят. Команда довольна. А баг уже живёт в базе. Тихо. Незаметно. До поры до времени. Вот как его найти. 📍 1. Ищи дубли там, где их не должно быть Пользователь нажал кнопку дважды, UI показал один результат. А в базе - два заказа. SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) > 1 Один запрос - и дубль найден. 📍 2. Ищи "осиротевшие" записи Пользователь удалён. А его заказы остались. И висят в системе без владельца. SELECT * FROM orders WHERE user_id NOT IN (SELECT id FROM users) Никто не жаловался. Но данные уже грязные. 📍 3. Ищи NULL там, где его не должно быть Поле обязательное. А в базе - NULL. SELECT * FROM orders WHERE total_price IS NULL Значит где-то не отработала валидация. Или сценарий который никто не тестировал. 📍 4. Ищи несоответствие статусов Заказ "доставлен". А оплата не проведена. SELECT * FROM orders WHERE status = 'delivered' AND payment_status != 'paid' Бизнес теряет деньги. UI об этом молчит. 📍 5. Ищи аномалии во времени updated_at раньше чем created_at. Или заказ создан в будущем. SELECT * FROM orders WHERE updated_at < created_at Такого быть не должно. Но бывает. ⚠️ Почему это важно UI показывает то, что разработчик решил показать. БД показывает правду. Баги в данных: • не падают с ошибкой • не видны в интерфейсе • накапливаются со временем • всплывают в самый неподходящий момент 🎯 Главная мысль Сильный QA не ждёт когда баг проявится в UI, он идёт в данные. И находит то, что никто не искал. 👇 А вы проверяете данные напрямую или доверяете интерфейсу? Пишите в комменты 🙂 📓 Заметки тестировщика

🎓Почему QA должен понимать архитектуру продукта Многие думают задача QA нажимать кнопки и смотреть, что получается. Но это не тестирование. Это клик-клик. 😳 Что происходит, когда QA не понимает архитектуру Пришёл баг: данные не сохраняются. QA проверил UI, все выглядит ок. Написал "не воспроизводится". А баг был в очереди между сервисами. UI показал успех. А сообщение до consumer не дошло. Без понимания архитектуры этот баг невидим. 📍 Что даёт понимание архитектуры 1. Знаешь где искать Монолит - смотришь в одно место. Микросервисы - понимаешь через какие сервисы прошёл запрос. Очереди - знаешь, что проверить кроме UI. 2. Задаёшь правильные вопросы Не "почему не работает кнопка". А "через какой сервис идёт этот запрос и есть ли там retry логика". Разница огромная. 3. Быстрее локализуешь баг Знаешь архитектуру - знаешь где сломалось. Не знаешь - ходишь по кругу и ждёшь разработчика. 4. Тебя воспринимают как эксперта QA, который понимает как устроен продукт изнутри - это другой уровень разговора с командой. Не "вот баг". А "вот баг, он скорее всего здесь, вот почему". ⚠️ Что надо понимать - минимум 🔸из каких сервисов состоит продукт 🔸как они общаются между собой 🔸где хранятся данные, есть ли очереди и асинхронщина 🔸где логи и как их читать Не надо быть разработчиком. Надо понимать карту. 🎯 Главная мысль Чем лучше QA понимает как устроен продук, тем глубже он тестирует. Баги на поверхности найдёт любой. Баги внутри - только тот, кто знает, где смотреть. 👇 А вы разбираетесь в архитектуре своего продукта? Или пока только UI? Пишите в комменты 🙂 📓 Заметки тестировщика

🔍 Как за 10 минут разобраться в чужом API Новый проект. Новый API. Документации нет или она врёт. И тебе надо тестировать уже сегодня. Знакомо? Вот что делать. 📍 1. Открой DevTools - вкладка Network Просто походи по UI и посмотри какие запросы летят. Что искать: — какие эндпоинты используются — какие методы GET/POST/PUT/DELETE — что передаётся в теле запроса — что возвращает сервер За 2 минуты ты уже знаешь структуру API лучше, чем из доки. 📍 2. Скопируй запрос как cURL Правой кнопкой на запрос → Copy → Copy as cURL. Вставь в Postman. Теперь у тебя живой запрос, который точно работает. Не придуманный из доки - а реальный. 📍 3. Посмотри на заголовки Что там есть: — Authorization - какой тип авторизации — Content-Type - в каком формате данные — кастомные заголовки - подсказка про архитектуру 📍 4. Сломай один запрос Убери токен - что вернёт? Передай пустое тело - что вернёт? Измени метод с POST на GET - что вернёт? За 3 минуты понимаешь как API реагирует на ошибки. Это говорит о качестве бэкенда больше, чем любая дока. 📍 5. Найди паттерн Хороший API предсказуем. /users - список /users/1 - конкретный пользователь /users/1/orders - его заказы Если паттерна нет - это уже красный флаг. ⚠️ Частые ошибки ❌ Верить документации без проверки ❌ Тестировать только happy path сразу ❌ Не смотреть заголовки запроса ❌ Игнорировать коды ошибок 🎯 Итог 10 минут = DevTools + cURL в Postman + сломать один запрос. Этого достаточно, чтобы понять с чем работаешь. И задать правильные вопросы команде. 👇 А как вы разбираетесь в новом API? Есть свой способ - пишите в комменты 🙂 📓 Заметки тестировщика

😏 Почему хороший QA - неудобный человек в команде И это нормально. Есть такой момент в разработке. Задача пришла. Все уже делают. Разработчик пишет код. Дизайнер рисует. Продакт в следующем спринте. И тут QA спрашивает: "А что должно происходить, если пользователь сделает вот это?" Тишина. "А это поведение задокументировано?" Ещё тишина. "А если сеть пропадёт в этот момент, что видит пользователь?" И вот тут становится неловко. Потому что никто не думал об этом. А думать уже надо было вчера. Почему это неудобно: Разработчик уже написал половину. Переделывать никто не хочет. А вопросы QA означают, что придётся. Но вот в чём штука. Лучше неловкая тишина на этапе разработки, чем баг на проде в пятницу вечером. Хороший QA не ждёт готовую фичу. Он приходит раньше. Задаёт неудобные вопросы. Находит дыры в логике до того, как они стали багами. И да, это раздражает) До тех пор, пока не спасает релиз. После этого говорят спасибо 🙂 👇 Было такое? Что ты задал(-а) вопрос и все притихли? Пиши в комменты 🔥 📓 Заметки тестировщика

🧠 Промпты для QA, которые реально работают Не "напиши тест-кейсы" А промпты, которые дают результат. Сохраняй🙂 📍 1. Генерация тест-кейсов ❌ Плохо: "Напиши тест-кейсы для формы авторизации" ✅ Хорошо: "Ты опытный QA. Вот сценарий: [описание]. Составь тест-кейсы включая позитивные, негативные и граничные значения. Отдельно выдели edge cases." Разница: AI получает роль + структуру, что ты хочешь получить на выходе) 📍 2. Поиск дыр в логике "Вот описание фичи: [описание своими словами]. Найди противоречия, неоднозначности и сценарии, которые не описаны. Что может пойти не так?" Особенно спасает, когда задача написана на одном дыхании и выглядит норм, а дыры всё равно есть. 📍 3. Тестирование интеграций "Два сервиса взаимодействуют через [REST/очередь/webhook]. Сервис А делает [действие]. Какие сценарии надо проверить? Включи негативные кейсы: таймауты, дубли, потеря сообщений, недоступность сервиса." AI хорошо знает типовые точки отказа и напомнит то, что легко забыть. 📍 4. Помощь с инструментами "Я использую Postman. Мне нужно [конкретная задача]. Покажи пошагово как это настроить." Работает для Charles, Docker, bash, SQL - всего, где надо быстро и без гугления. 📍 5. Ревью баг-репорта "Вот мой баг-репорт: [текст]. Проверь: понятны ли шаги воспроизведения, достаточно ли информации для разработчика, корректно ли описан ожидаемый результат. Что улучшить?" Особенно полезно джунам перед отправкой. ⚠️ Главное правило: Чем конкретнее промпт, тем лучше результат. Дай AI: • роль ("ты опытный QA") • контекст (что за фича/сервис/инструмент) • формат на выходе (список, таблица, по пунктам) • И не принимай первый ответ как финальный. Уточняй. Переспрашивай. Это диалог, а не команда. 👇 А какой промпт используешь чаще всего? Делись в комментах, соберём базу вместе 🙂 📓 Заметки тестировщика #QA #тестирование #testing

🤖 Как я использую AI в работе QA. Честно. Без хайпа. Без "AI заменит тестировщиков". Просто то, что реально работает у меня каждый день. 📍 1. Генерация тест-кейсов Раньше садилась и думала: "Так, что тут вообще надо проверить..." Теперь описываю фичу своими словами и прошу: "Составь тест-кейсы для этого сценария" Получаю костяк за 2 минуты. Дальше дочищаю, добавляю специфику продукта, убираю очевидное. Не потому что AI пишет идеально. А потому что с чистого листа всегда тяжелее, чем редактировать. 📍 2. Анализ сценария Описываю фичу абстрактно, без деталей и названий. Спрашиваю: "Какие кейсы тут не учтены?" "Что может пойти не так?" AI не заменяет мышление. Но иногда подсвечивает то, что я пробежала глазами. Особенно полезно когда задача написана... скажем так, творчески 📍 3. Практические кейсы интеграций Тестирую API, очереди, интеграции между сервисами. Спрашиваю AI: "Какие сценарии надо проверить при интеграции через определенный сервис?" "Что может сломаться, если сервис не ответил вовремя?" Получаю список углов, которые могла не учесть. Не копирую слепо, думаю головой. Но как чеклист для проверки себя хорошо работает. 📍 4. Помощь с инструментами Вот это вообще магия. Postman, Charles, docker, bash-команды - всё, что надо настроить и не помнишь как. Раньше: гугл - Stack Overflow - 40 минут. Теперь (пример): "Как настроить коллекцию в Postman для авторизации через Bearer token?" и ответ за 30 секунд. AI как очень терпеливый коллега, которому не стыдно задать глупый вопрос. ⚠️ Важно AI ошибается. Иногда уверенно. Я не копирую тест-кейсы без проверки. Не доверяю командам которые не понимаю. Это инструмент. Не замена голове. 🎯 Главный инсайт AI не делает работу за меня. Он убирает рутину и освобождает время думать о том, что важно. А думать всё равно приходится самой 🙂 👇 А вы используете AI в работе? Или пока с осторожностью? Пишите в коммент, интересно у кого какой опыт 🙂 📓 Заметки тестировщика

📱 Проверь себя: готов ли ты к уровню Middle Mobile QA? Если ты думаешь, что уже не junior, давай проверим честно) Без теории. Только то, что реально нужно в работе. 👉🏻 Отметь для себя, сколько пунктов ты действительно делаешь, а не “знаешь, что надо”. 🧠 1. Сеть (не только Wi-Fi) Ты проверяешь: ☐ переключение Wi-Fi, LTE ☐ потерю сети во время запроса ☐ медленный интернет (throttling) ☐ поведение retry ☐ что видит пользователь при таймауте Если нет, ты тестируешь “лабораторию”, а не реальный мир. 🔁 2. Фон и жизненный цикл Ты проверяешь: ☐ сворачивание приложения во время действия ☐ возврат через время ☐ что происходит после удаления приложения системой ☐ восстановление состояния ☐ повторные запросы после возврата Если нет, ты не тестируешь половину мобильного поведения. 🔔 3. Push-уведомления Ты проверяешь: ☐ приходит ли push ☐ приходит ли вовремя ☐ открывает ли правильный экран ☐ что будет, если открыть приложение не из push ☐ поведение при отключённых уведомлениях Если ты проверяешь только “пришёл / не пришёл” — этого недостаточно. 💾 4. Данные и состояние Ты думаешь про: ☐ идемпотентность действий (повторные клики) ☐ дублирование запросов ☐ потерю данных ☐ синхронизацию между экранами ☐ что будет при оффлайне Это уже уровень системного мышления 🙂‍↔️ 📲 5. Устройства и ОС Ты учитываешь: ☐ разные версии Android/iOS ☐ слабые устройства ☐ разные размеры экранов ☐ поведение на старых версиях ☐ ограничения ОС Один девайс это не тестирование.. ⚡️ 6. Скорость и UX Ты проверяешь: ☐ время загрузки экранов ☐ задержки при действиях ☐ блокируется ли UI ☐ есть ли feedback пользователю ☐ можно ли понять, что происходит Работает - не значит удобно 📊 Результат 🟥 0–10 пунктов ты ещё junior (и это нормально) 🟨 11–20 пунктов уверенный junior, почти middle 🟩 21–30 пунктов middle Mobile QA 🟪 30+ ты уже думаешь как senior Делитесь своими результатами в комментариях! ☺️ И не забудьте поставить реакцию за старание! ❤️ 📓 Заметки тестировщика

Ребята, в Wildberries стартует новый поток курса QA, где мы с моими коллегами лидами улучшили программу! Также теперь мы выдаем сертификат об обучении ❤️ Успейте зарегистрироваться! Все подробности по ссылке 🫂 Лучших трудоустраиваем в команду! https://tech.wildberries.ru/qa-engineer

💸 Топ самых дорогих багов в мобильных приложениях Те, которые не падают… но стоят бизнесу миллионы Самые опасные баги - не те, из-за которых приложение крашится. А те, из-за которых пользователь просто уходит. 🧨 1. Двойная оплата Сценарий: - пользователь нажал “Оплатить” - сеть зависла - он нажал ещё раз И… 💥 деньги списались дважды Почему это происходит: 1) нет идемпотентности 2) нет блокировки повторных действий 3) нет состояния “запрос в процессе” Почему это дорогой баг: 💁🏻 прямые финансовые потери 🙅🏼‍♀️ возвраты 👥 поддержка 😕 потеря доверия Один такой баг может стоить больше, чем сотни крашей. 🧨 2. Потерянный заказ (действие) Пользователь: - оформил заказ - увидел “успешно” - закрыл приложение А заказ… не сохранился. Причины: 1) асинхронщина (очереди, API) 2) UI показал успех раньше времени 3) плохая обработка ошибок Цена: 🫣 потерянные деньги 👺 негатив 😷 “приложение обмануло меня” 🧨 3. Баги при плохом интернете Пользователь живёт не в идеальном Wi-Fi. Он: - теряет сеть - переключается между LTE и Wi-Fi - ловит слабый сигнал Что происходит: 1) запрос завис 2) UI завис 3) пользователь не понимает, что происходит Самое страшное: пользователь думает, что приложение “тупит”. И просто удаляет его. 🧨 4. Потеря состояния приложения Сценарий: - пользователь заполняет форму - сворачивает приложение - возвращается И всё пусто. Причины: 1) приложение выгрузилось из памяти 2) нет сохранения состояния 3) неправильная работа lifecycle Цена: ⏱️ потеря времени пользователя 🙊 раздражение 👀 drop воронки 🧨 5. Проблемы с push-уведомлениями Кажется мелочью. На деле огромные деньги. Варианты багов: - уведомление не пришло - пришло дважды - пришло поздно - открывает не тот экран Пример: - акция на 1 час - push приходит через 20 минут 💸 половина пользователей уже не вернётся 🧨 6. Баги только на “редких” устройствах QA протестировал: - iPhone - топ Android А у пользователя: - старый Xiaomi - Android 9 - слабая память Что происходит: 1) приложение тормозит 2) падает 3) не открывается Цена: потеря целого сегмента пользователей 🧨 7. Медленная работа без ошибок Самый недооценённый баг. Приложение не падает и не показывает ошибки. Но экран грузится 3–5 секунд, действия выполняются медленно. Итог: пользователь уходит, но ты не видишь ни одного бага. 🎯 Что объединяет все эти баги: 👌🏼 нет явных ошибок 👌🏼 нет падений 👌🏼 сложно воспроизводятся 👌🏼 проявляются в реальных условиях И они бьют не по системе, а больше по деньгам и доверию.. 🧠 Как думает сильный Mobile QA Он проверяет не: “работает ли экран”, а "что будет при плохой сети", "что будет при повторном действии", "что будет в фоне", "что будет на слабом устройстве" 📓 Заметки тестировщика

📱 Мобильное тестирование: где на самом деле ломаются приложения “У меня всё работает” - говорит разработчик, держа в руках свой iPhone 15 Pro. И в этот момент где-то на Android 9 с плохим интернетом приложение уже падает. 🧠 Главная проблема мобильного тестирования В вебе ты тестируешь приложение. В мобилке ты тестируешь: - устройство - ОС - сеть - батарею - память - уведомления - фоновые процессы И только потом само приложение. 🔍 Где живут настоящие баги 1️⃣ Сеть (самый недооценённый фактор) Пользователь не сидит на идеальном Wi-Fi. Он: - едет в метро - переключается между LTE и Wi-Fi - теряет сеть - ловит слабый сигнал И в этот момент: - запрос зависает - дублируется - отваливается silently 👉 Вопрос к вам: “Что делает приложение, когда сеть пропала на 2 секунды?” 2️⃣ Фон и жизненный цикл приложения Пользователь: - свернул приложение - открыл другое - вернулся через 5 минут А ты получаешь: - потерянное состояние - сломанный экран - устаревшие данные 👉 Классический баг: API уже ответил, а UI не обновился после возврата 3️⃣ Память и слабые устройства Не все сидят на флагманах. На слабых устройствах: - приложение выгружается из памяти - экран пересоздаётся - данные теряются 👉 Вопрос к вам: “Что произойдёт, если ОС убьёт приложение в фоне?” 4️⃣ Версии ОС Android 9 ≠ Android 14 iOS 15 ≠ iOS 17 Различия: - permissions - background tasks - push-уведомления - поведение WebView Один и тот же код может работать по-разному. 5️⃣ Уведомления (push) Самая коварная зона. Проблемы: - приходит с задержкой - приходит дважды - приходит, когда не должен - открывает не тот экран А ещё пользователь может открыть приложение не из него. ⚠️ Самая большая иллюзия QA в мобилке “Я протестировал на своём устройстве” Это почти ничего не значит. Потому что мобильное приложение это комбинация условий, а не один сценарий. 🎯Как мыслит сильный мобильный QA Он не тестирует “экран”. Он тестирует: смену сети, смену состояния приложения, смену устройства, деградацию среды. Он задаёт вопросы: - что будет, если пользователь свернёт приложение в середине операции? - что будет при плохом интернете? - что будет при возврате через время? 💬 Из практики Самые неприятные баги в мобилке: не падают, не дают ошибок и не воспроизводятся стабильно. Они появляются толькона слабом устройстве/при плохой сети/через 5 минут после действия (или бездействия). Тестировщик, который умеет весь этот хаос моделировать, ловит баги, которые никто другой даже не увидит) 📓 Заметки тестировщика

🧠 Почему сильные QA меньше пишут тест-кейсов, но делают больше “Где тест-кейсы?” Вопрос, который часто задают… не тем людям. 🧠 Иллюзия контроля через тест-кейсы В начале карьеры кажется: чем больше тест-кейсов - тем выше качество. 200 кейсов - хорошо 500 кейсов - отлично 1000 кейсов - идеально? Но с опытом приходит понимание: количество тест-кейсов почти не связано с качеством продукта. Можно иметь: - идеальное покрытие - структурированные сценарии - красивые чек-листы И при этом пропускать критичные баги. 🔍 Что меняется у сильного QA Сильный тестировщик перестаёт мыслить: “Что бы ещё проверить?”. Он начинает думать: “Где это сломается?”. Это принципиально другой уровень. ⚙️ Почему кейсов становится меньше 1. Он перестаёт документировать очевидное Нет смысла писать кейс: “Нажать кнопку - проверить, что открылся экран” Это не тестирование - это фиксация очевидного. 2. Он мыслит сценариями, а не шагами Вместо 20 кейсов: - успешный вход - вход с ошибкой - вход с пустым полем Он видит один поток + вариации. 3. Он тестирует на лету (exploratory) Сильный QA: - комбинирует сценарии - меняет порядок действий - проверяет нестандартные состояния И за 30 минут находит больше, чем набор кейсов за день. 4. Он понимает риски Он не проверяет всё подряд. Он проверяет то, что может сломать бизнес. 🧩 Что он делает вместо написания кейсов Вот где происходит магия: - задаёт неудобные вопросы до разработки - находит логические дыры в требованиях - замечает несостыковки между сервисами - проверяет поведение системы во времени - ловит баги, которые нельзя “записать в кейс” И самое главное - он предотвращает ошибки, а не просто фиксирует их. 💬 Из реальной практики Один из самых сильных QA, с которыми я работала, почти не писал тест-кейсы. Но команда боялась его вопросов. Потому что он мог спросить: “А что будет, если пользователь сделает это… во время этого… пока система в таком состоянии?”. И после этого становилось понятно, что половина логики вообще не продумана. ⚠️ Важно: это не значит, что кейсы не нужны Кейсы нужны: для регрессии для онбординга для сложной логики для автоматизации Но: кейсы это инструмент, а не показатель уровня QA. 📓 Заметки тестировщика

Ооочень классный материал, рекомендую 💓 https://habr.com/ru/articles/1007736/ 📓 Заметки тестировщика

📈 Реальный кейс нагрузочного тестирования Как система выдерживает 3000 пользователей… и всё равно ломается Представим проект сервиса оформления заказов. Архитектура выглядит так: Frontend ↓ API Gateway ↓ Order Service ↓ Kafka ↓ Payment Service ↓ PostgreSQL По требованиям система должна выдерживать: 3000 одновременных пользователей в пиковые часы распродаж. 🧪Подготовка нагрузочного теста Сценарий максимально близкий к реальности. Типичный пользователь: 1️⃣ открывает каталог 2️⃣ добавляет товар в корзину 3️⃣ оформляет заказ 4️⃣ оплачивает Think time между действиями: 3–5 секунд Инструмент: k6 Профиль нагрузки: 0 → 500 пользователей (2 минуты) 500 → 2000 пользователей (5 минут) 2000 → 3000 пользователей (5 минут) Метрики: p95 latency error rate throughput CPU Kafka lag DB connections 📊 Первые результаты До 2000 пользователей всё выглядело идеально. Метрики: p95 latency: 180ms errors: 0% CPU: 40% Команда была уверена: “Система выдержит 3000 легко.” Но дальше началось интересное. 🚨 На 2500 пользователей началась деградация Система не падала, но метрики начали ползти. p95 latency: 400ms Kafka lag: растёт DB connections: растут При этом: - ошибок почти нет - CPU не перегружен - Система формально работает. Но что-то явно идёт не так. 🔎 Начали копать глубже Посмотрели метрики Kafka. И увидели: producer rate: 1500 msg/sec consumer rate: 1200 msg/sec Каждую секунду система накапливала 300 сообщений. Это значит: lag растёт очередь растёт задержки растут Но API продолжает отвечать 200 OK. 🧨 Через 15 минут начинается лавина Kafka lag: 0 - 10k - 40k - 120k сообщений Теперь происходит следующее: 1️⃣ Payment Service начинает отставать 2️⃣ пользователи ждут подтверждение оплаты 3️⃣ система делает retry 4️⃣ нагрузка увеличивается ещё сильнее Начинается feedback loop. 💥 Итог через 20 минут теста Метрики: p95 latency: 6 секунд error rate: 12% Kafka lag: 200k сообщений Но что интересно - система не упала. Она просто стала очень медленной. 🧠 Где была реальная проблема После расследования оказалось: Payment Service был bottleneck. Он обрабатывал: 1200 сообщений/сек А система генерировала: 1500 сообщений/сек. Разница: +300 сообщений/сек Это маленькое расхождение и убивало систему. 🛠 Как исправили Решения: 1️⃣ Увеличили количество consumer Kafka consumers: 3 → 6 2️⃣ Добавили batching платежей Вместо: 1 message → 1 DB transaction Сделали: 10 messages → 1 transaction 3️⃣ Ограничили retries Retry storm сильно усиливал нагрузку. 📊 Результат после фикса Повторили тест. Метрики: 3000 пользователей p95 latency: 320ms Kafka lag: стабилен errors: 0.2% Система выдержала нагрузку. 🎯 Самый важный вывод Без нагрузочного теста этот баг проявился бы: только на распродаже только под реальной нагрузкой только через 15–20 минут То есть: в продакшене ⚡️ 💡 Главный урок для QA Нагрузка показывает не только выдержит ли система Она показывает: как система деградирует со временем И самые опасные проблемы - это те, которые: - не падают сразу - не дают ошибок - но медленно убивают систему. 📓 Заметки тестировщика

💐 С 8 марта! Иногда кажется, что этот праздник только про цветы и открытки. Но на самом деле он про гораздо большее. Про женщин, которые умеют держать баланс между мягкостью и силой. Которые принимают сложные решения, ведут команды, запускают проекты, находят самые хитрые баги и делают системы лучше. Про тех, кто не боится брать ответственность, учиться новому и идти вперёд - даже когда путь непростой. Пусть этой весной будет больше: ✨вдохновения для новых идей ✨энергии для больших целей ✨уверенности в своих силах Пусть рядом будут люди, которые поддерживают, ценят и верят в вас. А каждый новый день приносит возможности, которые делают жизнь ещё интереснее. И пусть в жизни, как в хорошем релизе, всё работает стабильно, без критических багов и с отличным настроением. С праздником! ❤️

4 вида нагрузочного тестирования (которые постоянно путают) 1️⃣ Load testing Проверяем работу системы при ожидаемой нагрузке. Например: 1000 пользователей онлайн 200 запросов в секунду Цель - убедиться, что система выдерживает нормальный рабочий режим. 2️⃣ Stress testing Постепенно увеличиваем нагрузку, пока система не начнёт ломаться. Задача - понять: - где предел системы - как она падает 3️⃣ Spike testing Резкий скачок нагрузки. Например: 10 rps - 2000 rps за секунду Это проверяет: - авто-масштабирование - очереди - устойчивость к всплескам 4️⃣ Soak testing (endurance) Длительная нагрузка. Например: 1000 пользователей в течение 12–24 часов. Так ловятся: - memory leaks - накопление соединений - проблемы с кешем 📓 Заметки тестировщика

Слишком часто в последнее время сталкиваюсь с темой нагрузочного тестирования. Давайте разберем эту тему детальнее ✨ В первую очередь, это не про “сломать сервер”. Когда люди слышат “нагрузочное тестирование”, они часто представляют одно: - ты запускаешь тысячи запросов и смотришь, когда всё падает. Но это самое примитивное понимание нагрузки. Настоящая цель нагрузочного тестирования - ответить на три вопроса: 1️⃣ Сколько пользователей система выдерживает? 2️⃣ Как она деградирует? 3️⃣ Где появляется узкое место? Важно помнить: система почти никогда не падает сразу. Она медленно деградирует. Сначала: - растёт latency - появляются таймауты - увеличиваются очереди - начинает отваливаться кеш - база начинает блокироваться И только потом происходит падение. Хороший нагрузочный тест не ищет точку падения. Он находит момент, когда система начинает вести себя неправильно. И это намного ценнее. 📓 Заметки тестировщика

С 23 февраля! ❤️ Мужчины, хочется пожелать вам не только силы и уверенности, но и простого человеческого счастья. Пусть рядом всегда будут люди, которые верят в вас, поддерживают и вдохновляют. Пусть в сердце будет спокойствие, в доме - уют, а в жизни - ощущение, что всё идёт правильно. Пусть любые трудности обходят стороной, а мечты находят дорогу к исполнению ✨

https://roadmap.sh/qa Роудмеп для QA в 2026 году 🙂 📓 Заметки тестировщика

🧠 Почему опытные тестировщики перестают верить "всё работает" И почему это не профессиональная деформация, а навык Есть момент, который почти каждый QA переживает лет через 5–7 в профессии. Когда фраза: "Всё работает" перестаёт звучать успокаивающе. Наоборот - она начинает напрягать. 🔍 Что происходит с мышлением тестировщика со временем В начале карьеры: фича запускается - радуемся; багов нет - значит, всё хорошо; тесты зелёные - можно выдыхать. С опытом мозг перестраивается. Ты начинаешь слышать не слова, а паузы между ними: “всё работает… при каких условиях?” “у кого работает?” “как долго?” “что будет завтра?” Это не цинизм. Это развитие. ⚠️ Почему "всё работает" - опасная фраза Потому что она обычно означает одно из четырёх: 👉🏻 Проверили happy path Всё остальное неизвестно. 👉🏻 Проверили сейчас Во времени поведение может измениться. 👉🏻 Проверили без нагрузки А под реальными объёмами всё может “поплыть”. 👉🏻 Проверили без отказов А система живёт в мире с рестартами, таймаутами и потерями. QA со стажем слышит в этой фразе не уверенность, а слепую зону. 🧠 Что меняется в голове опытного QA Он перестаёт задавать вопрос: "Работает ли?" И начинает задавать другие: - Где это сломается первым? - Как система деградирует? - Что произойдёт при частичном отказе? - Кто об этом узнает и когда? Это уже не тестирование фич. Это тестирование устойчивости. 💬Из реальной практики Самые тяжёлые инциденты, которые я видела, начинались не с ошибок и падений. Они начинались со слов: "Мы всё проверили, у нас всё работает". А потом: - сообщения в очередях зависали, - данные расходились, - пользователи теряли деньги И никто не мог быстро объяснить почему) 💪 Почему этот скепсис - признак зрелости Опытный тестировщик: не верит в “навсегда”; не доверяет разовым проверкам; понимает, что реальность всегда сложнее тестового сценария. Он не пессимист. Он просто знает цену словам ❤️ 📓 Заметки тестировщика

🚨 Прод-инциденты с Kafka/RabbitMQ Типичные сценарии инцидентов и почти каждый из них можно было поймать на тестировании 🧨 Инцидент 1. «Сообщения есть, но они не обрабатываются» Что видел бизнес: - заказы создаются; - UI работает; - деньги не списываются; - пользователи ждут. Что происходило на самом деле: - consumer падал на одном типе сообщения; - сообщение не уходило в DLQ; - очередь забивалась; - все следующие сообщения стояли за “плохим”. Почему это не поймали раньше: - QA не проверял сценарий: “что будет, если consumer упадёт на одном сообщении?” Как QA мог поймать: 1) отправить битый payload; 2) проверить: - consumer жив? - очередь двигается? - сообщение уходит в DLQ? Вывод: одно плохое сообщение может остановить весь бизнес-поток. 🧨 Инцидент 2. Дубликаты, которые никто не заметил сразу Симптомы: - пользователям иногда списывались деньги дважды; - не воспроизводилось стабильно; - “раз в несколько дней”. Реальная причина: - consumer рестартовал; - offset не коммитился вовремя; - сообщение обрабатывалось повторно; - idempotency не было. Почему это ушло в прод: QA тестировал только: “сообщение дошло”, но не: “сообщение дошло второй раз”. 📌Как QA мог поймать: - искусственно рестартить consumer; - проверить повторную обработку; - отправить одно и то же сообщение дважды. Вывод: повторная доставка - не исключение, а норма. 🧨 Инцидент 3. Потерянные события без единого лога Что видел бизнес: - часть действий пользователей “пропадала”; - невозможно понять, где. Реальная причина: - неправильный routing key; - сообщения уходили в никуда; - producer считал, что всё ок. Почему QA не заметил: - проверяли только UI; - не смотрели очереди; - не проверяли exchange → queue binding. Как QA мог поймать: 1) открыть RabbitMQ UI; 2) проверить: - количество сообщений; - биндинги; - routing key; 3) сравнить ожидание vs факт. Вывод: асинхронные потери - самые дорогие. 🧨 Инцидент 4. Нарушенный порядок событий (Kafka) Симптомы: - система периодически переходила в “странные” состояния; - не воспроизводилось на маленьких объёмах. Реальная причина: - сообщения шли без ключа; - попадали в разные партиции; - порядок не гарантировался. Почему QA не заметил: - тесты были линейными; - не было нагрузки; - не проверяли порядок. Как QA мог поймать: - проверить наличие key; - отправить серию связанных событий; - сравнить порядок обработки. Вывод: порядок сообщений - архитектурный контракт, а не “надежда”. 🧨 Инцидент 5. Очередь, которая медленно убивала систему Симптомы: - всё работало; - пользователи не жаловались; - бизнес-метрики падали. Реальная причина: - consumer обрабатывал медленнее, чем producer писал; - lag рос; - задержки доходили до часов. Почему QA не заметил: - не смотрели метрики; - не тестировали под нагрузкой; - ориентировались только на UI. Как QA мог поймать: - проверить lag/unacked messages; - нагрузить producer; - замедлить consumer искусственно. Вывод: “работает” ≠ “успевает”. 🧠 Что объединяет все эти инциденты UI не сигнализировал о проблеме. API отвечал 200 OK. Логи были “чистые”. Бизнес терял деньги. И только очереди знали правду. 🎯 Мышление QA уровня Senior/Lead Такой тестировщик: - тестирует поведение системы во времени; - закладывает сбои как норму; - проверяет деградацию, а не только падения; - думает не “сломается ли”, а “как сломается”. Kafka и RabbitMQ не просто техническая деталь. Это нервная система продукта. И тестировщик, который умеет работать с очередями через Docker: 🔍 раньше видит риски, 🔍 задаёт неудобные вопросы, 🔍 предотвращает инциденты, и реально влияет на бизнес, а не только на баг-репорты. 📓 Заметки тестировщика