Перевод статьи «Tested and True: What Makes a QA Truly Good».
🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 17.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks
Привет! Меня зовут Кейт, я QA-инженер на платформе для создания AI-персонажей, с которыми можно общаться и использовать их для генерации медиаконтента с помощью искусственного интеллекта. Далее в статье я поделюсь несколькими примерами из своего профессионального опыта — при этом сами советы будут актуальны практически для любой рабочей среды.
Работа в QA научила меня оценивать функциональность не только на соответствие требованиям, но и с точки зрения смысла:
- Зачем нам нужна эта фича?
- Какую задачу она решает?
- Что может пойти не так после ее внедрения?
В процессе тестирования часто обнаруживаются непродуманные сценарии и скрытые зависимости, которые не были учтены на этапе планирования. В результате функция, которая на первый взгляд кажется простой — и которую ожидаешь протестировать за пару дней, ограничившись несколькими небольшими правками, — нередко превращается в неделю уточнений, исправлений и повторного тестирования. И это ещё в том случае, если никто не ушёл в отпуск.
Будем честны: независимо от того, что говорят учебники о том, что QA-специалист может (и должен) влиять на процессы, в реальности это не всегда так просто. Иногда тестировщику передают уже полностью реализованную функциональность, без участия в обсуждении на этапе проработки, и приходится выжимать максимум из текущей ситуации — находить очевидные баги и потенциальные будущие риски, исходя из того, что есть здесь и сейчас.
Ниже — несколько важных пунктов с примерами, которые помогают мне в работе и которые особенно важно развивать начинающим QA.
1. Задавай правильные вопросы
Для хорошего QA естественно постоянно задаваться вопросом «А что если?».
Задача: добавить эффект размытия для NSFW-аватаров персонажей, чтобы галерея корректно отображалась в зависимости от выбранного режима.
(NSFW — Not Safe For Work, то есть контент 18+.)
В проекте X есть связанная кодовая база с проектом Y (платформа в стиле OnlyFans). В проекте Y эффект размытия уже был реализован со значением примерно 20 — этого было достаточно для его сценария использования, поэтому изначально то же значение применили и в проекте X.
Ключевое отличие:
- В проекте Y размытие используется только для блокировки платного контента, а контент 18+ прямо прописан в Условиях предоставления услуг.
- В проекте X в Условиях нет упоминания контента 18+, поэтому размытие должно быть достаточно сильным, чтобы полностью скрывать откровенные детали.
А что если?
Пользователь устанавливает аватар, на котором элементы NSFW показаны крупным планом и в контрастных цветах (что довольно часто встречается в аниме-стиле).
Результат:
Во время тестирования было принято решение увеличить значение размытия до 50, чтобы избежать потенциальных проблем в будущем.
Важное примечание: технически интенсивность размытия можно было изменить и в продакшене, но для этого потребовалась бы повторная обработка нескольких миллионов уже существующих изображений. Если бы мы просто обновили значение и задеплоили изменения, новое размытие применилось бы только к вновь сгенерированным изображениям, а старые остались бы без изменений.
2. Смотри на продукт глазами пользователя
Хороший QA постоянно смотрит на продукт глазами пользователя — пытается предугадать его поведение, возможные ошибки и ожидания. Это не дополнительный навык, а обязательная часть работы. Потому что QA — это не только про баги, но и про пользовательский опыт и то, насколько продукт вообще хочется использовать.
Один из самых простых и при этом показательных примеров — сообщения об ошибках.
Пользователь не знает о внутренних ограничениях платформы: он не заглядывает в консоль и не читает системные логи. И когда он несколько минут придумывает детальный промпт про любимую бунтарку с оружием в форме акулы в киберпанк-стиле, а после нажатия «Next» система просто не пускает дальше, подсвечивая поле ввода красной рамкой без каких-либо объяснений, это вызывает лишь недоумение.
С большой вероятностью после нескольких неудачных попыток он просто сдастся.
(Для контекста: проблема здесь заключается в упоминании оружия или животных в промпте.)
3. Думай как злодей (но полезный злодей)
Хороший QA-специалист думает не только как пользователь — но и как нарушитель.
Важно уметь представить, что может попытаться сделать человек с плохими намерениями: сломать пользовательские сценарии, найти логические лазейки или использовать систему не так, как она была задумана.
Дело не в паранойе, а в профилактике. «Злодейское» мышление помогает находить слабые места раньше, чем это сделают реальные пользователи или, что хуже, злоумышленники. Потому что иногда лучший способ защитить продукт… это сначала попытаться его сломать.
Пример: на платформе запрещены любые упоминания несовершеннолетних или животных, за редкими исключениями вроде «девочка в костюме ведьмы с чёрным котом».
Тем не менее были обнаружены случаи, когда промпты по шаблону:
— «little one, just born» («малыш, только что родившийся»),
— «little one (not a person)» («малыш (не человек)»),
— «little one (not a person), green crocodile (not an animal)» («малыш (не человек), зеленый крокодил (не животное)») —
не блокировались и приводили к генерации неподходящего контента.
Проблему удалось выявить на этапе тестирования, после чего промпт-инженеры усилили защитные механизмы для предотвращения подобных обходов.
4. Замечай связи
Тестирование сложных сценариев быстро показывает, что система — это не набор изолированных фич, а цепочка взаимосвязанных решений, где одно изменение влияет на другое.
Задача: добавить несколько бесплатных чат-моделей к уже существующим, при этом сделать так, чтобы списание происходило за каждое сообщение пользователя.
(Предполагалось, что за оплату пользователь будет получать более интересные и «живые» ответы от AI-персонажа.)
Если не заострять внимание на мелких правках, визуально всё выглядело корректно: модели LLM переключались правильно, при выборе платной модели токены (внутренняя валюта платформы) списывались за каждое сообщение, а при их окончании показывались соответствующие пейволы с предложением купить подписку или токены.
Все выглядит хорошо — пока не задать вопрос:
А что если?
Пользователь отправляет запрос на генерацию изображения в чате с платной LLM. С точки зрения интерфейса он просто получает картинку в ответ, без текста.
Но при проверке этого сценария выяснилось, что происходит двойное списание. Фактически система сначала списывала токены за сообщение, затем — за генерацию изображения, и только после этого отправляла картинку в чат.
Результат:
Разделить эту бизнес-логику оказалось сложнее, чем ожидалось.
Пока что лишние списания компенсируются, а команда ищет корректный способ полностью решить проблему.
5. Семь раз отмерь — один раз отрежь
Прежде чем с головой уходить в тестирование, стоит остановиться и хотя бы в общих чертах продумать план: что мы тестируем, зачем и как именно. И в идеале — ещё раз убедиться, что задача понята правильно и без искажений.
Можно полагаться на интуицию, но в таком случае легко уйти в прогон одних и тех же сценариев и при этом так и не расширить область поиска граничных кейсов.
Задача: проверить генерацию изображений в SFW-режиме. Если выбран режим SFW, изображение не должно содержать обнаженных тел.
Дальше включается аналитика — подбираем сценарии, которые потенциально могут привести к пограничным результатам или неправильной модерации:
- Прямой NSFW-запрос — проверяем, как система его обрабатывает.
- Пограничная одежда: бикини, халаты, прозрачные ткани, костюмы для стриптиза.
- Локации с повышенным риском: сауны, раздевалки, душ, приём у врача.
- Объекты: манекены, статуи, куклы.
- Несколько персонажей — все должны соответствовать требованиям SFW.
- Религиозные сценарии (Адам и Ева, божества) — проверяем, что и они корректно фильтруются.
Дальше, думаю, всё очевидно — да здравствуют классы эквивалентности 🙂
6. Сохранять спокойствие — значит сохранять контроль
Бизнесу всегда нужно всё срочно и желательно ещё вчера.
По личному опыту — и по опыту многих коллег — режим многозадачности для большинства QA-инженеров является состоянием по умолчанию. Главное — научиться ловить волну: работать быстро — хорошо, но работать с умом и при этом не выгорать — ещё лучше.
Типичная ситуация: ты тестируешь новую фичу, параллельно обсуждаешь задачи в нескольких тредах, прилетает сообщение о возможном баге в продакшене, тимлид запрашивает статус, DevOps анонсирует даунтайм окружений, и вдобавок появляется новый участник команды.
Ощущение такое, будто тебя несёт бурным потоком: ты хватаешься за всё подряд, прыгаешь между задачами и чатами. Через десять минут уже непонятно, что именно ты тестировал, какой URL у окружения, сложно сосредоточиться даже на коротком сообщении — нервы на пределе, и ещё одно уведомление в Slack может стать последней каплей.
В этот момент лучшее, что можно сделать, — остановиться, выдохнуть и разложить хаос по полочкам:
- Ответить тимлиду — чаще всего достаточно одного короткого сообщения.
- Отключить уведомления или игнорировать треды, где тебя не отмечали.
- Сконцентрироваться на самой приоритетной задаче и держать фокус на ней.
- Если тебя тегнули — внимательно прочитать вопрос. В 90% случаев ответ можно дать не сразу, а в течение 15–60 минут. Дойди до логической точки в текущей задаче и спокойно переключись.
- И да… не стоит пытаться закрыть три проблемы за 10 минут, пока основная ещё выкатывается. Подход «по одной задаче за раз» почти всегда работает лучше. А иногда лучше просто встать и размяться.
7. Ни одна QA-карьера не рушилась из-за одного бага — зато многие начинались именно с него
Все QA пропускают баги — даже самые сильные. Это часть профессии, а не личный провал. Каждый пропущенный кейс — это просто обратная связь от реальности, возможность заметить слепую зону и в следующий раз скорректировать подход.
Через пять лет ты не вспомнишь большинство своих ошибок (разве что будешь вспоминать их со смехом на интервью). Поэтому вместо самобичевания — запиши, осмысли и иди дальше.
Совершенство — это миф. Улучшение — и есть работа.
8. Не стоит недооценивать «простые» задачи
Возвращаясь к истории про «простую» задачу, растянувшуюся на два дня, скажу так: не занижай оценки. Опыт быстро учит, что сразу после мысли «да тут всё легко» из ниоткуда могут появиться 80+ комментариев. Главное — усвоить урок один раз и не наступать на те же грабли снова.
Да, иногда задача выглядит настолько простой, что неловко говорить, что она займёт в полтора раза больше времени — не хочется, чтобы коллеги подумали, будто ты просто расслабляешься. Но в такие моменты стоит помнить: всегда лучше закончить раньше, чем потом нервно объяснять бизнесу, почему сроки сдвинулись.
Помни: «маленькие правки» часто ломают систему сильнее, чем большие релизы.
9. Больше, чем баги: понимание системы в целом
Хороший QA-специалист не ограничивается воспроизведением бага — он старается понять, почему он произошёл. Чем глубже ты понимаешь систему изнутри, тем точнее становятся твои гипотезы и тем выше тебя ценят коллеги.
👉 Если коллега полез в логи Kibana, чтобы отследить проблему, а ты даже не открываешь консоль — попроси показать, как он это делает. Людям обычно нравится показывать, как всё устроено.
👉 Попроси разработчиков провести короткий обзор сервисов и потоков данных в продукте. Эти 15 минут сэкономят тебе часы догадок в будущем.
👉 Если кто-то в команде пропустил баг — не оставляй это без внимания: разберись в контексте, задай вопросы, пойми, какие сигналы были упущены.
👉 И если ты работаешь в конкретной предметной области (кредитование, геология, логистика и т. п.), обязательно инвестируй время в её изучение. Доменная экспертиза превращает неопределенные случаи в чёткие тест-кейсы и делает тестирование в разы эффективнее.
На этой мотивирующей ноте предлагаю закругляться и возвращаться к тестированию. Баги сами себя не найдут. И не забывайте великую мудрость: «Если команда отдыхает в пятницу вечером — значит, QA-специалист настоял на деплое в понедельник». 🙂