Всем привет! Меня зовут Марина, я QA в компании Банки.ру и сейчас занимаюсь продуктами личного кабинета, но успела поработать и в других командах. 

В IT все по-разному представляют работу тестировщика:

• Кто-то видит человека, который по 8 часов кликает на кнопки (я, честно говоря, так же представляла разработку, что уж скрывать…).

• Кто-то – душного охотника на баги, который только и делает, что пытается что-нибудь сломать.

• Кто-то вообще считает, что это просто начальная ступень в IT, чтобы потом пойти в разработку.

И в каждом из этих представлений есть крупица правды – но только одна сотая. На самом деле тестирование – это куда более сложный и интересный мир, чем просто цепочка «нашёл баг → завёл баг → проверил → закрыл». Это постоянный анализ, предугадывание проблем, переключение между разными типами задач и умение задавать возможно глупые, но нужные вопросы. 

QA – это смесь паранойи, здравого смысла, скепсиса и заботы о пользователе, внимания к деталям и одновременного удержания всей картины в голове. 

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

Кому будет интересно?

• Разработке – чтобы наладить коммуникацию и лучше понимать, зачем QA просит что-то исправить.

• PM'ам – чтобы осознать, какую ценность приносит качественное тестирование, и чего от QA можно ожидать.

• Новичкам – чтобы увидеть, как на самом деле устроена работа в этой профессии.

Добро пожаловать в голову QA! Но будь осторожен, тут много «а что, если?..»

1. Мышление QA

Использовать теорию про граничные значения, негативные/позитивные проверки и т.д., конечно, здорово. Но истинный QA этим не ограничивается – для работы ему нужно развивать особое мышление. 

На первом месте, конечно, понимание продукта – без этого бесполезно будет придумывать какие-то сценарии и тесты. И к тому же, так весь интерес пропадет, и начнется выгорание.

Также важно умение смотреть на свою работу глазами пользователя. В основном это приходит с опытом – как раз когда ты уже «пощупал» продукт и узнал его получше. Тогда ты уже можешь представить себя на месте юзера, понять, как бы он мог поступить и какую нелогичную комбинацию действий совершить, которая в итоге приведет к ошибкам.

И еще одно важное качество – это упорство, чтобы донести до разработчика, зачем нужны все твои вопросы и правки. Это может быть непросто, даже когда ты принес ему все доказательства, чтобы он сам воспроизвел ошибку, а он все равно противится. 

Кроме того, есть много навыков, которые вроде бы необязательны, но если у тебя они есть, то это будет очень круто – например, разобрать кусочек кода продукта. Но в этой статье я расскажу все-таки про ключевые скиллы.

2. Радар QA

Это умение не просто тестировать отдельные фичи, а смотреть на весь продукт в целом, как на живой организм, в котором сломаться может что угодно – и в самом очевидном месте, и в самом глупом и неожиданном. А для этого надо перед началом тестирования задать себе много вопросов: 

• Что именно должно работать в этой задаче? (Какая цель/польза продукта/фичи?)

• Что поменялось, а что осталось, как было? (Что могли сломать?)

• Какая документация понадобится? (Есть ли макеты и описание на wiki?)

• Как будет выглядеть поведение при нестандартных действиях пользователя?(А если пользователь прервёт процесс? А если вернётся назад и снова вперёд?)

• Как всё это будет работать в сложных условиях?

  • с медленным интернетом,

  • с просроченным jwt-токеном авторизации,

  • с выключенным JavaScript, 

  • с устаревшим браузером и т. д.

3. Подход «Что может пойти не так?» – мышление в худших сценариях

Есть правило тестирования – сначала проверяем, что задуманное работает: кнопка жмётся, форма отправляется, пользователь получает ожидаемый результат. Если все ок, то можно включать режим «тревожника» и моделировать провалы:

• Что будет, если пользователь отправит пустую форму?

• А если нажмёт кнопку 3 раза подряд и наделает дублей?

• А если клиент начнет проходить флоу с десктопа, продолжит на мобилке, и история действий не перенесется?

Да, в идеале «такого быть не должно». Но мы здесь именно для того, чтобы проверить, что произойдет, если «такое» вдруг будет.

Пример из жизни:

Пришла в тест простая задача – проверить, что отзыв успешно создаётся после пары мелких правок. Заполнила все поля тестовыми данными, нажала «Отправить». Ничего не происходит.

Жму ещё раз – отзыв наконец создаётся. Ну, отлично, тест прошёл, можно закрывать задачу. Но чуть позже замечаю в общем списке отзывов… два одинаковых. Те же тестовые данные, то же время создания. Совпадение? Не думаю. :)

Решила проверить теорию. Заполнила новый отзыв и кликнула по кнопке «Отправить» столько раз, сколько успею, пока меня не средиректит на страницу созданного отзыва. И вуаля – семь дублей одного и того же отзыва. Красота.

Вывод: доверяй, но проверяй (а потом иди проверяй все остальные сервисы на наличие того же бага ?).

Вы вряд ли встретите подобные сценарии в документации, но они почти всегда всплывают у пользователей, если их не предусмотреть заранее. Они же не обязаны использовать продукт правильно – они использует его, как умеют, и во время тестов нужно стараться думать, как они.

4. Скепсис как профессиональная черта

Скепсис у QA – это не занудство, а рабочий инструмент.

Когда разработчик говорит: «Там минимальные правки, проверь, что просто страница открывается или можно даже не проверять». QA думает: «Ага. Проведем-ка смоук-тестирование или автотесты прогоним на всякий случай».

Он проверяет всегда, даже когда никто не просил: незначительные изменения могут повлиять на другие части сервиса, о которых не подумали. Поэтому не доверять на слово и сомневаться – это нормально и профессионально. 

Пример из жизни:

Когда я только пришла в компанию, в мой первый месяц работы, в тестирование попала задача с высоким приоритетом на исправление бага в админке. В описании было указано, что правки минимальные, и нужно проверить конкретные разделы, в которых дефект был найден изначально.

На тот момент я была мало знакома с этим сервисом и не до конца понимала, как именно устроена админка, и какие части логики связаны между собой. Формально можно было ограничиться только указанными в задаче разделами, но я решила провести небольшое исследовательское тестирование, так как правка была срочной и без неё коллеги не могли полноценно продолжить работу.

В результате выяснилось: тот же самый баг воспроизводится и в других разделах админки. Позже стало понятно, что проблема находилась во фронтовом компоненте, который переиспользуется в нескольких местах. Исправление было внесено только для части сценариев, поэтому во всех остальных разделах, где использовался этот компонент, дефект продолжал проявляться.

Задача была возвращена в доработку, а область влияния фикса расширена. Баг был оперативно исправлен. В итоге мы друг друга поблагодарили: разработчик меня – за внимательность, а я его – за то, что все быстро пофиксил. 

Как сами тестировщики часто говорят, нельзя протестировать продукт на 100% – не получится учесть абсолютно все, что может накликать пользователь, особенно если продукт обновляется. Даже в учебниках пишут, что исчерпывающее тестирование невозможно. Всегда есть шанс, что где-то спряталась ошибка. 

Да, из-за этого скепсиса многие разработчики называют тестировщиков душнилами. А может быть даже считают, что мы подвергаем сомнению их компетентность, но мы просто делаем свою работу. QA – это не про «поймать», а про «подстраховать». 

Бывает, что логика продукта становится сложной или неочевидной. В такие моменты всегда можно прийти к разработчику, задать вопросы и разобраться вместе. Очень часто именно в таких разговорах находятся самые правильные решения. Как бы ни было важно смотреть со стороны пользователя, не менее важно понимать продукт изнутри. Поэтому я вижу взаимодействие QA и разработки как возможность дополнить знания друг друга в своих областях и полноценное партнерство.

Именно при таком слаженном взаимодействии «рождается» не просто написанная и протестированная фича, а продукт, в котором команда может быть уверена.

5. Алгоритм принятия решений

Задача тестировщика – это не просто проверить все подряд, а подобрать правильный порядок действий: на что смотреть в первую очередь, а что оставить на «сладкое».

Мой процесс, если это новая фича:

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

2. Приоритизация сценариев. Определяю, что проверить в первую очередь, а что потом:

• критичные сценарии – на старт, потому что это «скелет» фичи;

• сценарии с регистрацией, авторизацией – всегда в приоритете;

• пограничные случаи и нестандартное поведение – после основного функционала;

• дизайн-детали – когда логика уже проверена.

Это экономит время и силы, особенно если дедлайн рядом.

3. Когда я сформулировала алгоритм проверки, выбираю подход к тестированию:

• Что пройдёт автотестами, а что руками?

• Нужны ли моки, postman или подключение к БД?

• Проверю ли это только в Chrome или посмотрю ещё в Safari?

• На каких устройствах протестировать?

Я выбираю подход не по шаблону, а под конкретную задачу, чтобы получить максимум результата. Иногда приходится комбинировать несколько разных видов тестов и перепроверять результаты, чтобы разобраться в проблеме. 

Еще один рабочий пример:

Запустили новый сервис – что-то вроде соцсети, но для обсуждения финансовых тем.
Начала покрывать его e2e-автотестами. Запускала тесты параллельно с задачами и ждала, когда хоть один баг попадёт в мой капкан.

И вот наконец это случилось: во время очередного прогона вижу красный тест, который проверял флоу подписки на профиль. Как и в любой соцсети, там есть кнопки «Подписаться» и «Отписаться». Ну что ж, идём смотреть и видим в логах несоответствие текста: должно быть «Отписаться», а на скрине вижу «Подписаться».

Проверяю вручную – с кнопкой всё в порядке. Ничего не понятно.

Думаю: «Наверное, страница просто не успела прогрузиться. Добавлю ожидание, и проблема решится».

Запускаю тест снова – та же ошибка.

Решаю запустить локально, с просмотром действий в браузере. И вижу то, чего не ожидала: при клике на «Подписаться» страница перезагружается, и на долю секунды снова появляется старая надпись, прежде чем смениться на «Отписаться».

Проверила с медленным интернетом – та же история. Радовалась, как будто котёнка с улицы домой принесла. Несмотря на то что, баг был бы незаметен пользователю с хорошим соединением.

Вывод: хороший тест видит чуть больше, чем пользователь.

И это одна из причин, почему у нас в компании есть тестировщики фулл-стеки, которые и руками тестят, и пишут автотесты. А еще это экономит всем время.

В итоге

В работе QA важно уметь задавать вопросы и иногда побыть «детективом» – видеть связи между изменениями и понимать, к чему они могут привести для продукта в целом. Многие решения принимаются не по шаблону, а с учетом контекста задачи, анализа требований и реального поведения пользователей. Такой баланс структуры и исследовательского подхода помогает находить проблемы раньше, снижать риски и делать релизы более предсказуемыми для всей команды.