После многих лет работы в должности QA Engineer я решил поделиться некоторыми советами по общению с разработчиками. Далее описаны мои наблюдения по этому поводу.
❌ Нельзя
Не отвлекайте программиста по мелочам. Сначала задайте свой вопрос в мессенджере, либо договоритесь о встрече, если уж очень жаждете личного общения. Я понял это, как только начал программировать сам. Когда вы творите, и кто-то отвлекает вас, требуется много времени и сил, чтобы снова погрузиться в состояние сосредоточения. Такие перерывы нарушают продуктивность.
Не бойтесь просить о помощи. Вы не можете знать все. Спрашивать — это нормально! Просто убедитесь, что вы поняли ответ, – не задавайте один и тот же вопрос дважды. Главный принцип командной работы при реализации проекта “Мы в одной лодке и всем будет хорошо, если у каждого будет весло.”. Он позволяет двигаться дальше в одном направлении.
Главное правило QA – никогда не верить словам разработчиков! «Все должно быть хорошо!» или «Я изменил одну строку в коде, это ничего не сломает» – фразы, после которых стоит насторожиться и перепроверить проект.
Не вините разработчика в ошибке. Не зацикливайтесь на негативе, попытайтесь решить проблему. Позже всей командой обсудим, как избежать того или иного случая в будущем. Никто не идеален. Ошибки неизбежны. Основная цель – иметь возможность быстро отреагировать на проблему и качественно выполнить свою работу.
Не назначайте конкретного разработчика на дефект. В этом есть аналогия с тем как разработчик закрывает тикет без одобрения QA. Подобное поведение может разозлить
Не занимайтесь микро менеджментом над разработчиком. «Ты посмотрел багу?», «Как насчет сейчас?», «Когда ты исправишь багу?». Это раздражает, не уменьшая сроки решения проблемы. Поставьте себя на место работника, выполняющего задачи в строгой последовательности. Подобные “пинки” нецелесообразны.
Не принимайте все близко к сердцу, с “толстой кожей” живется проще. Чрезмерная эмоциональность (негативная) — кратчайший путь к выгоранию. Не позволяйте своим чувствам преобладать над здравым смыслом. В любой момент времени на вашем пути могут попасться высокомерные люди, которых придется терпеть, выполняя при этом поставленные цели и задачи. Правило применимо относительно любого специалиста. “Толстая кожа” столь же необходима, как и тактичность.
✅ Правильно
Обмен знаниями с разработчиками. Сообщите им о своих подходах к тестированию, найдите «access_key» для каждого разработчика, с которым вам приходится работать. Расскажите о том, как вы собираетесь тестировать продукт. Это поможет избежать некоторых ошибок в коде. Однако такое взаимодействие не всегда возможно по нескольким причинам:
нехватка времени;
организация процессов внутри компании, не позволяющая этого сделать;
банальное нежелание разработчика сотрудничать с тестером.
Если вы все же сможете найти тот самый «access_key», который упоминался мною выше, – будет гораздо легче поддерживать здоровые отношения и хорошее качество продукта в долгосрочной перспективе.
Будьте честны. В противном случае это разрушит вашу репутацию.
Будьте готовы защищать дефекты, о которых сообщаете. Иногда приходится отстаивать критичность дефектов, которые необходимо исправить. Со временем это становится проще, когда вы способны озвучить четкую аргументацию с обоснованием того, почему дефект должен быть исправлен. Корректное формирование фактов и умение видеть на несколько шагов вперед помогает сэкономить деньги компании.
Сохраняйте хладнокровие под давлением. Я знаю, это тяжело. Когда все торопят тебя или твою команду сложно противостоять авторитетам. Однако говорить «нет» — часть нашей работы, даже если это устраивает далеко не всех.
Обсудите тестовые кейсы с разработчиком. По моему опыту, это очень сложно сделать. Данный процесс требует много времени и силы воли. Со своей стороны QA в таких “переговорах” должен быть харизматичен и крайне убедителен. Я занимался подобным некоторое время, но так и не смог научиться правильно внедрять данный подход в собственную работу. Однако от таких переговоров с разработчиком есть очевидная польза. Они расширяют спектр мнений и позволяют учитывать кейсы, которые изначально даже не рассматривались, как потенциально перспективные.
Описывайте дефекты понятно. Говорите на языке разработчика, если можете. В ином случае, старайтесь писать как можно проще. Хорошо описанный баг со всей его информативностью и полнотой погружения в проблему со стороны разработчика будет максимально быстро исправлен. Соответственно, команда QA оперативно приступит к повторному тестированию проблемного участка.
Поощряйте заинтересованность членов команды в глубоком изучении продукта. Максимальная осведомленность специалиста позволяет минимизировать число глупых дефектов. По моему опыту, такие несущественные ошибки забирают у команды слишком много времени и сил. Лучше предугадать возможные нецелесообразные действия и сосредоточиться на более важных вещах, чем тратить время на описание несущественных дефектов, которых, возможно, вовсе и нет.
Терпение, только терпение. Научитесь справляться с трудными и самовлюбленными людьми. Это общее правило, применимое к любой сфере, как и в случае с хладнокровием.
Первоначально перевод опубликован в телеграм канале QA team