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

📱Как тестировать биометрию - Face ID и Touch ID

Кажется простой фичей. Нажал - сработало. Не сработало - ввел пароль.
Но там намного больше сценариев чем кажется.

📍 Базовые сценарии

Это минимум, который проверяют все:
• биометрия успешно авторизует пользователя
• при неудачном сканировании появляется повторный запрос
• после нескольких неудач предлагается альтернатива
Но это только верхушка.

📍 Что проверить на самом деле

1. Первый вход
Пользователь только установил приложение. Биометрия ещё не настроена на устройстве. Что видит пользователь? Есть ли подсказка как включить биометрию в настройках?

2. Биометрия отключена в настройках устройства
Пользователь сам отключил Face ID для приложения. Приложение должно корректно предложить альтернативный вход, а не просто сломаться.

3. Смена биометрических данных
Пользователь добавил новый отпечаток или лицо в настройках телефона. Приложение должно это заметить и попросить повторную авторизацию. Это требование безопасности.

4. Возврат после сворачивания
Пользователь свернул приложение и вернулся через 5 минут. Запрашивается ли биометрия снова? Зависит от настроек сессии - но поведение должно быть предсказуемым.

5. Несколько неудачных попыток
Face ID не распознал лицо 3 раза подряд. Что происходит? Блокируется ли биометрия? Предлагается ли пароль? Сколько попыток до блокировки?

6. Биометрия в фоне
Приложение запросило биометрию. В этот момент пришёл звонок. Пользователь ответил и вернулся. Что происходит с запросом биометрии?

7. Разные устройства
Face ID на iPhone работает иначе чем Touch ID. Android-сканеры отпечатков у каждого производителя свои. Поведение может отличаться.

⚠️ Частые ошибки

❌ Проверять только успешный сценарий
❌ Не проверять поведение при отключенной биометрии
❌ Забыть про смену биометрических данных
❌ Тестировать только на одном устройстве

Биометрия это не просто удобство. Это безопасность. И сломанный сценарий здесь - это не просто баг, а потенциальная уязвимость.

👇 А вы тестируете биометрию или ограничиваетесь базовым сценарием? Пишите в комменты 🙂

📓 Заметки тестировщика

🤖 Заменит ли AI тестировщиков? Отвечаю честно

Этот вопрос мне как лиду задают все чаще.На собесах, в чатах, в комментариях.

🔍 Что же AI уже умеет делать в тестировании?

🔸Генерировать тест-кейсы по описанию фичи. 🔸Писать баг-репорты.
🔸Подсказывать edge cases.
🔸Помогать с SQL запросами и настройкой инструментов.

Это реально работает. Я сама использую каждый день.

🙅‍♀️ Что AI не умеет

✍️ Понимать контекст бизнеса
👀 Чувствовать, что что-то "не так", даже когда все технически работает
😵‍💫 Задавать неудобный вопрос продакту в нужный момент
✌️Принимать решение - выкатываем или нет

AI не знает твой продукт. Не знает пользователей. Не несет ответственности за релиз.

💔 Где реальная угроза

Джуны, которые делают только механическую работу - писать тест-кейсы по шаблону, кликать по скрипту, копировать баг-репорты.
Вот это AI заменит. Уже заменяет.

🧘‍♀️🌿Где угрозы нет

QA, который думает о рисках, понимает архитектуру, разговаривает с командой и принимает решения - это не автоматизируется.
Это экспертиза. А не набор действий.

AI не заменит тестировщика. Но тестировщик который умеет работать с AI заменит того, кто не умеет.
Это уже происходит.

👇 А вы используете AI в работе или пока с осторожностью? Пишите в комменты 🙂

📓 Заметки тестировщика

🔍 Что делать, когда баг только на одном устройстве

Воспроизвести не можешь. Разработчик не может. Тимлид смотрит скептически.

А пользователь пишет что у него всё ломается.

Вот что делать.

📍 1. Собери максимум информации об устройстве

Не "старый Android". А конкретно:

• модель и производитель
• версия ОС
• версия приложения
• свободная память
• язык и регион системы

Иногда баг живет именно в комбинации этих параметров.

📍 2. Проверь версию ОС

Android 9 и Android 14 - это разные операционные системы. Разные разрешения, разный lifecycle, разное поведение WebView.

Один и тот же код может работать по-разному.

📍 3. Проверь специфику производителя

Samsung, Xiaomi, Huawei - у каждого своя оболочка поверх Android. Свои настройки батареи, свои ограничения фоновых процессов, свое поведение уведомлений.

То, что работает на чистом Android, может ломаться на кастомной оболочке.

📍 4. Проверь условия воспроизведения

• какой интернет был в момент бага - Wi-Fi или LTE
• сколько приложений было открыто
• был ли телефон на зарядке
• какой язык и регион стоит в системе

Баги любят прятаться в условиях, которые никто не проверял.

📍 5. Попроси логи с устройства

Если есть доступ - попроси пользователя или воспроизведи на похожем устройстве и сними логи. Часто там видно то чего нет в UI.

📍 6. Используй облачные фермы устройств

BrowserStack, Firebase Test Lab - реальные устройства в облаке. Можно запустить на том самом Xiaomi с Android 9 не покупая его.

⚠️ Частые ошибки

❌ Закрыть баг как "не воспроизводится" без проверки условий
❌ Тестировать только на своём устройстве
❌ Игнорировать кастомные оболочки производителей
❌ Не собирать логи с проблемного устройства

Баг на одном устройстве - это не повод закрыть тикет) Это повод копнуть глубже.

Иногда за ним стоит целый сегмент пользователей, о котором никто не думал..

📓 Заметки тестировщика

📱 Симулятор vs реальное устройство. В чём разница для QA?

"Я проверила на симуляторе - всё работает."

А потом пользователь пишет, что приложение падает.

Давай разберёмся почему.

📍 Что такое симулятор

Это программа, которая имитирует устройство. Работает на твоём компьютере. Удобно, быстро, бесплатно.

Но это не телефон.

🧨 Что симулятор не умеет

1. Реальная сеть

Симулятор использует интернет твоего компьютера - стабильный Wi-Fi без потерь. А пользователь едет в метро, где сеть пропадает каждые 30 секунд.

2. Реальная производительность

Симулятор берёт ресурсы твоего MacBook. У пользователя - старый Android с 2GB RAM и 10 приложениями в фоне. Приложение тормозит или падает.

3. Реальные разрешения

Пользователь первый раз открывает приложение и нажимает "запретить" на доступ к камере. Ты это проверяешь на симуляторе?

4. Жизненный цикл

Входящий звонок прямо во время оплаты. На симуляторе это не воспроизвести так, как на реальном устройстве.

5. Датчики и железо

Гироскоп, Face ID, NFC - симулятор имитирует. Реальное устройство живёт.

📍 Когда симулятор ок

Быстрая проверка UI, дымовое тестирование, вёрстка на разных экранах.

📍 Когда нужно реальное устройство

Перед релизом, тестирование сети, производительность, пуши, разрешения и всё, что связано с железом.

🎯 Симулятор
- это черновик. Реальное устройство - финальная проверка. Выпускать без тестирования на реальном железе это риск, который всегда выстреливает не вовремя.

👇 А вы тестируете на реальных устройствах или в основном на симуляторе? Пишите в комменты 🙂

📓 Заметки тестировщика

🗄️ Как найти баг, который никто не видит - через данные

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
- появляются таймауты
- увеличиваются очереди
- начинает отваливаться кеш
- база начинает блокироваться

И только потом происходит падение.

Хороший нагрузочный тест не ищет точку падения.
Он находит момент, когда система начинает вести себя неправильно.

И это намного ценнее.

📓 Заметки тестировщика