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