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

🔍 Как за 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/ 📓 Заметки тестировщика