🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 15.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks
Перевод статьи «Why QA Is More Than Just Testing in Agile Projects».
Давайте по-честному: когда я говорю, что работаю в тестировщиком, большинство людей представляют меня охотником на опечатки или занудой с вечными вопросами к разработчикам:
«Эта кнопка и правда должна… ничего не делать?»
А что внутри тех команды?
Некоторые думают, что QA в Agile это когда ты просто «тыкаешь» по кнопкам после разработки и орёшь «БАГ!» — как на TV шоу.
Но в реальности всё иначе:
Я не просто тестирую → я планирую, задаю вопросы, ищу слабые места, ломаю и помогаю чинить. Я что-то вроде «терапевта» команды перед релизом.
«QA — это тот человек, который видит айсберг до того, как “Титаник” в него врежется. А не после.»
В этом блоге я расскажу, чем на самом деле занимаюсь во время спринта, помимо смены статусов в тикетах и драм в Jira.
Без воды. Только реальная кухня того, как тестировщик помогает проекту плыть гладко (а иногда избегать полного хаоса за пять минут до демо).
Планирование спринта: где рождаются баги (если не быть внимательным)
Официально проект начинается с планирования, но для меня как QA это уже этап, где я представляю, что может пойти не так.
Речь не о том, чтобы просто кивать, а о том, чтобы мысленно пройтись по фиче, как подозрительный пользователь, который хочет её сломать.
Пока все обсуждают стори поинты и scope creep, я вникаю в каждый тикет с вопросами:
«Погодите… в описании сказано, что пользователи могут “загрузить файл”. Ок. А какой именно файл? Есть ограничение по размеру? А если загрузят PDF, переименованный в .jpg? А если попробуют залить 5 ГБ на 3G?»
Да-да. Именно так я и думаю.
Я читаю пользовательские истории, как юридические договоры
После 3+ лет работы с расплывчатыми требованиями и отмашками типа «потом разберёмся», я научилась читать их как тестировщик и юрист в одном лице:
- Если нет критериев приемки или они неполные? Уточняю
- Если требования звучат как допущения? Задаю вопросы
- Если не учтены edge кейсы? Начинаю их перечислять
«QA — это человек, который уверен: пользователь всегда сделает то, чего не должен. И почему-то всегда оказывается прав.»
Я думаю шире задачи: риски регрессии
Ещё до первого коммита я уже размышляю: «Что ещё сломается, когда это выкатят?»
- Новый фильтр может сломать загрузку данных в дашборде?
- Изменения в бэкенде не поломают ли email уведомления?
- Как это повлияет на интеграции?
- Что будет, если у пользователя 5000 записей — сработает пагинация или браузер заплачет?
Опыт научил: даже малейшее изменение может вызвать цепную реакцию багов. И чаще всего про регрессионные тесты забывают.
Итак, планирование спринта для QA — это…
- Читать задачи как параноидальный юрист
- Находить и уточнять расплывчатые формулировки
- Продумывать edge кейсы
- Оценивать риски регрессии ещё до начала разработки
- Планировать тестовое покрытие: автоматизация, моки, exploratory тесты
- Постараться, чтобы меня не ждал сюрприз в середине спринта
«Я не жду начала тестирования. Я планирую заранее, чтобы предотвратить баги ещё до первого коммита.»
Во время спринта: сотрудничаем, тестируем, повторяем
Пишу тест кейсы заранее, потому что ждать — для новичков
Как только разработчики начинают писать код, я начинаю писать тест кейсы. Это не паранойя, а подготовка.
Я разбиваю критерии приемки на четкие сценарии:
- Happy path (основные сценарии).
- Edge кейсы, которые все упускают.
Но не останавливаюсь на этом. Опыт подсказывает: пользователи обожают находить неочевидные способы сломать систему. Поэтому я добавляю те самые «хитрые» кейсы, о которых никто не просил, но которые гарантированно вызовут хаос.
Например:
- Что, если в текстовое поле вставят HTML или JS код?
- Что, если загрузят файл на 100 МБ при лимите в 1 МБ? (Спойлер: пользователи так делают!)
- Я также проверяю негативные сценарии, например: валидацию форм, которую, как все надеятся, никто не заметит.
Потому что, когда фича выходит в прод, там только я и пользователи, без страховки и кнопки «отмена».
«Писать тест кейсы — как собирать аптечку для похода: надеешься, что не пригодится, но радуешься, когда она есть.»
Ни один билд не остаётся без внимания: синхронизация с разработчиками
Я не сижу в углу и не жду сборку. Я постоянно на связи с разработчиками:
Уточняю:
- «Бэкенд готов, или я снова тестирую заглушки?»
- «Можешь скинуть моки данных? А то я не хочу забивать прод тестами.»
- «Это точно должно быть хардкодом?»
- «Давай сегодня же подключим это!»
«Лучше быть занудой сегодня, чем извиняться за баги завтра.»
Ручное тестирование — начинается охота на баги
Когда фича попадает ко мне, начинается самое интересное. Под «интересным» я подразумеваю мое превращение в детектива, стресс тестера и адвоката пользователя.
Функциональное тестирование
Сначала проверяю: работает ли фича как задумано?
- Кнопка «Отправить» должна отправлять, а не просто красиво дрожать
- Каждое поле, клик и сообщение проверяются по критериям приемки
Негативное тестирование
Подсказки? Валидация? Пользователи их игнорируют, как и «Условия использования».
Я проверяю, что произойдёт, если:
- Ввести эмодзи в числовое поле
- Оставить все обязательные поля пустыми и нажать «Отправить»
- Загрузить картинку на 50 МБ (потому что кто-то обязательно попробует)
Адаптивность
- Тестирую на мобильных, планшетах и даже на том ультрашироком мониторе продакта
- Ищу наложения элементов, невидимые кнопки или «разваливающиеся» интерфейсы
Исследовательское тестирование
Тут включаю интуицию:
- Пропускаю шаги
- Жму «Назад» в неподходящий момент
- Открываю несколько вкладок и действую параллельно
Я тестирую как:
- Рассеянный пользователь
- Разработчик, забывший про null проверки
- Злобный QA, который хочет всё сломать
Юзабилити тесты
- Даже если фича технически работает, удобна ли она?
- Не слишком ли много шагов для простого действия?
- А что это за кнопка?
Я ставлю себя на место пользователя, который видит фичу впервые. Если мне нужна инструкция, чтобы разобраться, как ей пользоваться, значит, мы уже потеряли половину аудитории.
Базовые проверки безопасности
- Можно ли получить доступ не к тем данным через URL?
- Соблюдается ли разграничение ролей?
- Не раскрывают ли ошибки лишнюю информацию?
Производительность (ручные проверки)
- Зависает ли при 100 строках?
- Долго ли загружаются компоненты?
- Формы откликаются моментально или как будто через портал?
«Хороший QA — это не тот, кто просто тестирует. А тот, кто умеет симулировать хаос до того, как его устроят пользователи.»
Принципы QA на данном этапе:
- Ничего не предполагай — даже если что-то работает один раз, это не значит, что будет работать всегда
- Думай сквозь фичу: как эта фича влияет на другие части системы? Какие будут побочные эффекты?
- Будь адвокатом пользователя — твоя задача находить проблемные места до того, как их обнаружат пользователи
- Терпение и настойчивость — тестирование может быть монотонным и раздражающим, но упорство окупается
- Документируй как профессионал — четкие и подробные баг репорты экономят время и ускоряют фиксы
Автоматизирую, если возможно. Если нет — документирую
- Если задача стабильна и важна в долгосрочной перспективе, пишу автотесты (например, в Cypress)
- Если нет, то пишу подробные тест кейсы, чтобы регрессию мог повторить кто угодно (даже я сама через 3 недели, когда всё забуду).
«Автоматизация — мой способ сказать будущему себе: “Пожалуйста”.»
Регрессия — это не для галочки, это мини путешествие во времени
Перед релизом я проверяю не только новые фичи, но и то, что не должно было сломаться, но, скорее всего, сломалось.
«У каждой строчки кода есть брат, которого она случайно задела.»
Я проверяю:
- Не сломала ли новая фича старый функционал?
- Не перестал ли профиль пользователя сохранять изменения?
- Работает ли «восстановление пароля» или тихо сломалось?
Я использую чек лист релиза — подробный документ, который покрывает все критические сценарии.
«И это не формальность — это страховка. Если я его прошла, мы выпускаемся без страха.»
Демо спринта: камео QA
Я не всегда провожу демо, но когда делаю,то прихожу во всеоружии.
Приятно показывать фичу, которую я протестила, не только потому, что помогла её выпустить, а потому, что она выжила после всех моих edge кейсов.
Я демонстрирую:
- Happy path (как должно работать).
- А затем что будет, если пользователь ошибётся (и система должна справиться).
Потому что красивый сценарий — это хорошо, но устойчивость к хаосу — настоящая гордость QA.
Релиз: момент истины для QA
К релизу у меня уже:
- Открыт Slack
- Чек лист наполовину пройден
- В голове карта всех критичных фич
Если всё чисто, я даю финальный зеленый свет. Но не просто «ок, норм», а с чёткой документацией:
- Все известные баги заведены, привязаны к эпикам, приоритизированы
- Нет блокеров
Если есть блокеры — релиз приостанавливается.
- Баг фиксят
- Проверяю исправление
- Только тогда даю добро
Тестировщик не тот, кто просто проверил. А тот, кто сказал: «можно релизить, все работает чётко и стабильно».
«Релиз — не конец моей работы. Это момент, когда все мои тесты либо окупаются, либо возвращаются бумерангом.»
Финальные мысли
Agile команды работают быстро, но качество требует не скорости, а человека, который:
- Думает как пользователь
- Планирует, как продакт
- Спрашивает, как юрист
- Ломает, как хакер
- Документирует, как аудитор
- И заботится, как будто его имя в релизных титрах
Если QA сделал свою работу хорошо — этого никто не заметит. Но поверьте, если не сделал — заметят все.
Так что в следующий раз, когда тестировщик задаст «очередной вопрос» или найдет баг в последний момент, помните: мы не тормозим процесс. Мы делаем так, чтобы релизом можно было гордиться.
А если ты сам QA — продолжай копать, спрашивать и переживать. Ты не просто тестировщик. Ты причина, по которой ПО остаётся качественным.