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

Диана, инженер по тестированию в Naumen, делится личным опытом: как перестать бояться задавать вопросы, говорить о багах без конфликтов и выстраивать рабочие отношения на старте.

Как я справилась со страхом задавать вопросы

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

В этот период меня очень поддержал наставник. С ним можно было обсудить, как корректно сформулировать баг, что именно стоит спросить у разработчика и как не растеряться на созвоне. Он сказал мне важную мысль: «Даже самый глупый вопрос — это нормально, если ты действительно хочешь разобраться».

Как говорю о багах, чтобы меня поняли

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

Со временем я поняла: чтобы избежать недопонимания, важно говорить максимально конкретно.

Когда я сообщаю о баге, всегда прикладываю:

• шаги воспроизведения;

• скриншоты или видео;

• ожидаемое и фактическое поведение;

• логи.

Что я делаю, если разработчик говорит «у меня все работает»

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

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

Ответы коллег могут быть сухими и перегруженными техническими деталями. Если я не до конца поняла, я прямо пишу об этом и прошу объяснить проще.

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

Что помогает выстроить рабочий контакт:

• приносить максимум информации;

• избегать обвинений — мы ищем решение, а не виноватого;

• предлагать созвон, если переписка не помогает;

• не бояться переспрашивать;

• напоминать аккуратно, если задача «зависла».

Почему важно уточнять требования

Аналитики формируют требования, а тестировщики проверяют реализацию. Казалось бы, все должно быть просто: есть ТЗ — идем по нему. Но на практике почти всегда возникают нюансы.

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

У меня была задача с новым функционалом. Я разработала тест-кейс и пошла к аналитику — уточнить корректность сценария. Аналитик сказал, что сценарий невозможен.

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

Почему полезно делиться опытом

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

И сама стараюсь делать то же самое: делиться тем, что знаю, помогать, если кто‑то только погружается в проект. Команда работает лучше, когда в ней не боятся спросить и не жадничают знаниями.

Когда я только шла в тестирование, мне казалось, что главное — это внимательность, логика и документация. Со временем стало понятно: на первом месте — умение взаимодействовать с людьми.

→ Подробнее своим опытом Диана поделилась в статье.