Размышления тестировщика SaveLink о том, как мы понимаем друг друга с разработчиками.
Если вы хоть раз работали в команде с разработчиками, вы знаете этот диалог наизусть:
— «Кнопка не работает».
— «Так и должно быть».
— «Нет, не должно».
— «Так в задаче написано».
— «А пользователь так не поймет».
И все. Добро пожаловать в QA-реальность, где грань между багом и фичей тоньше, чем граница между фронтом и бэком.
Где рождаются наши разногласия
Баги не всегда про фронт. Иногда тестировщик видит, что ничего не грузится, а на деле это просто не ответил сервер. Данные не пришли, но ведь пользователю от этого не легче. Для него все равно сломалось.
Разработчик смотрит в логи, разводит руками: «У меня все чисто».
И оба правы. Просто каждый видит проблему со своей стороны экрана.
Бывает и наоборот, что поведение системы кажется странным, но не потому, что кто-то ошибся. Просто сценарий не был описан аналитиком, и разработчик сделал по-своему. QA ожидал одно, Dev реализовал другое и вот уже баг. А на деле это просто белое пятно в требованиях.
Иногда же ошибкой называют предложения вроде улучшить UX, добавить подсказку, сделать переход понятнее. Все это важно, но не стоит в один ряд с настоящими дефектами. Когда такие замечания записывают как баги, со стороны может показаться, будто фронт завален проблемами. А реально это просто список улучшений, и обидно, когда он превращается в статистику ошибок.
Почему это происходит
Причина проста, мы по-разному видим мир. Разработчик отвечает за реализацию, за сроки, за то, чтобы все работало. Тестировщик отвечает за качество и пользовательский опыт. И каждый делает свою работу правильно, но просто цели чуть расходятся. Добавим сюда человеческий фактор. Не все описано, не все сценарии проговорены, кто-то проверил на старой версии, кто-то забыл обновить кэш и обычная задача превращается в поле недопонимания.
Как мы выходим из этих ситуаций
В SaveLink мы давно поняли, что лучше поговорить до, чем спорить после.
Поэтому тестировщики участвуют в обсуждении новых функций с самого начала. Когда QA понимает контекст, половина будущих «багов» просто не рождается. Мы также договорились, что «баг» это то, что не совпадает с описанным поведением, а все остальное уточнения и доработки. Это звучит просто, но экономит часы споров.
Если поведение системы непонятно, то мы не устраиваем словесный бой, а зовем аналитика. Обычно одной встречи хватает, чтобы все стало на свои места. И, наконец, мы фиксируем договоренности прямо в задаче. Не для отчета, а для памяти: чтобы потом не гадать, кто что имел в виду.
Что в итоге
Для тестировщика «баг» это не приговор разработчику. Это приглашение посмотреть на продукт свежим взглядом. Мы не ищем ошибки ради ошибок. Мы ищем понимание.
Иногда нам кажется, что мы с разработчиками говорим на разных языках. Но, если прислушаться, смысл у нас один: сделать продукт лучше.
И, пожалуй, именно в этих спорах рождается настоящая точка роста любой команды.