QA-тестировщик: не «ищет баги», а хранит пользовательский опыт
Знакомый руководитель стартапа однажды сказал: «Зачем нам QA? У нас всё и так работает». Через 11 дней после релиза их приложение упало у 63% пользователей на Android 12. Не из-за бага в коде. Из-за того, что разработчики тестировали только на своих телефонах — Pixel и iPhone. А реальные пользователи — на Xiaomi, Samsung, Huawei с кастомными прошивками. QA бы нашёл это на этапе планирования: просто спросил бы: «Какие ОС и версии у целевой аудитории?». Ответили бы: «Android 10 – 14, 78% — не Pixel». И протестировали бы заранее.
Это не провал тестирования. Это провал мышления.
Другой пример — крупный банк запустил новую форму кредита. Технически всё работало: данные сохранялись, заявка уходила. Но через 2 недели заметили, что 41% пользователей бросали форму на шаге «доход за вычетом налогов». Почему? Потому что поле называлось «ЧД» — сокращение от «чистый доход». Внутри команды это было общепринято. Для клиента — иероглиф. QA, включённый ещё на этапепроектирования интерфейса, предложил: «Проверим 3 варианта подписи — “Чистый доход”, “Доход после налогов”, “Сколько остаётся после НДФЛ” — и проведём A/B‑тест на 5% трафика». Выбрали второй — уходы упали на 57%.
QA не тестирует готовый продукт. Он тестирует гипотезы — ещё до написания кода.
Один из самых частых мифов: «QA = человек с чек-листом». На деле — хороший QA строит сценарии. Не «нажать кнопку “Отправить”», а «попробовать отправить форму с отрицательным доходом», «ввести 1000 символов в поле “ФИО”», «сменить язык браузера на турецкий — что покажет интерфейс?». Это не деструктивное тестирование. Это эмпатия в действии.
Ещё один кейс — EdTech-платформа добавила новый тип задания: drag-and-drop. Разработчики проверили на десктопе — всё летало. QA протестировал на планшете — и обнаружил, что при зуме 125% элементы перекрывались, и 38% студентов не могли завершить задание. Они не «нашли баг». Они выяснили: «На каких устройствах учатся наши пользователи?». Оказалось — 61% — на планшетах и телефонах. Без этого — релиз с 40% падением завершаемости.
QA не должен знать Python. Но должен понимать: где ломается логика, а не только код.
Команда веб-студии ввела простое правило: перед релизом каждый QA пишет один абзац: «Как я это сломаю?». Не технически. А как пользователь: «Я уйду в чат, вернусь через 10 минут — сохранится ли прогресс?», «Я введу email через кириллицу — что будет?». Эти тексты читает вся команда. Часто находят проблемы, которые не видны в тест-кейсах.
Один из моих коллег, бывший учитель математики, стал QA. Его сильная сторона — не знание Selenium, а умение задавать вопросы: «А что, если…?». За год он предотвратил 12 критических ситуаций — просто потому, что думал не как разработчик, а как человек, который впервые видит продукт.
Если интересно, какие 5 тестов должен проходить любой интерфейс до релиза, как начать с нуля без IT-бэкграунда и чем ручное тестирование остаётся незаменимым даже при 90% автотестов — подробнее в блоге Eduson.
Автор: Антон
Реклама. ООО «Эдюсон». ИНН 7729779476 eduson.academy. Лицензия №Л035 – 01298-77/00374370
