😇
На testengineer.ru мы не размещаем рекламу, но над сайтом регулярно работают несколько человек. Поддержите нас, подписавшись на телеграм-канал "Тестировщик от бога"!
ДомойОбучениеSoft skillsКак QA общаться с разработчиками? Что делать ✅ и чего не делать...

Как QA общаться с разработчиками? Что делать ✅ и чего не делать ❌

Автор

Дата

Категория

Я работаю как QA уже больше трех лет и каждый день на протяжении этого времени общаюсь с программистами. Решила поделиться своими советами по общению с этими умнейшими людьми 😀

Начнем с того, что делать нельзя:

❌ Чего не делать

Никогда не отвлекайте разработчика, если вопрос не очень срочный. Не нужно постоянно дергать разработчиков лично. Лучше напишите в мессенджере или запланируйте митинг. Я поняла всю важность этого пункта, когда сама занялась автоматизацией и начала писать автотесты. Когда находишься в состоянии потока и кто-то отвлекает — очень сложно вернуться обратно и восстановить все, что было в голове. Такие вещи точно не добавляют продуктивности.

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

Не верьте тому, что говорят разработчики. Проверяйте все и всегда! Если программист говорит вам что-то вроде «Я поменял одну строчку кода — это ничего не сломает» или «Не переживай, все будет норм», проверяйте особенно тщательно 😀

Не обвиняйте. Это дорога в никуда. Никогда не сводите все к негативу, пытайтесь решить проблему. Позже можно будет с холодной головой проанализировать ситуацию и решить, как избежать ее в будущем. Помните — идеальных людей не бывает. Все совершают ошибки. Главная цель — иметь возможность быстро реагировать исправлять их.

Не ассайните баг на конкретного разработчика. Это может раздражать. Есть менеджеры, которые решат, кто чем будет заниматься.

Не занимайтесь микро-менеджментом разработчиков. Чем больше вы будете надоедать вопросами типа «Ты посмотрел баг?», «Когда ты пофиксишь?», «А сейчас уже пофикшено?», тем медленнее будут исправляться баги. Просто попробуйте поставить себя на место программиста и вы поймете, как это может раздражать.

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

✅ Что делать

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

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

Будьте честными. Одни из самых главных качеств тестировщика — честность и открытость. Никогда не врите и ничего не скрывайте — иначе ваша репутация разрушится моментально. Или постепенно.

Будьте готовы защищать баги, которые вы завели. Бывают ситуации, когда вам придется доказывать важность багов, которые нужно исправить. Будьте готовы подробно объяснять суть и последствия, к которым баг может привести. Умение доносить важность багов сыграет на пользу всей команде.

Научитесь работать под давлением. Я знаю, что это тяжело. Когда на команду давят перед релизом, бывает трудно сопротивляться менеджменту. Однако, умение говорить «Нет» — это часть работы, даже если это будет сложно. Это правило не работает, если вам приставили к голове пистолет 😀

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

Будьте точными и подробными, когда описываете баги. Пишите так, чтобы было понятно программистам. Подробно описывайте шаги для воспроизведения. Чем лучше вы напишете, тем меньше вопросов будет у разработчиков (да и вам будет проще тестировать баг после исправления — вы быстрее вспомните, о чем он)

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

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

11 КОММЕНТАРИИ

  1. Не ассайните баг на конкретного разработчика. Это может раздражать. Есть менеджеры, которые решат, кто чем будет заниматься.

    не поняла, если разработчик делает конкретную функциональность, отправляет мне ее на тестирование, я нахожу баг и знаю, что это его баг — я должна через менеджера его ассайнить? Бредово как-то.

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

      В Вашем конкретном случае, понятное дело, можно назначить на дева напрямую.

  2. Полезные советы, видно, что автор работает в реальном коллективе. От себя (как от разработчика) добавил бы — не пытайтесь противопоставлять себя разработчикам — мы все в одной лодке, поэтому помогайте нам)

    Про «Не верьте тому что говорят разработчики» — чистая правда)))

    • Видно, что автор работает или работал в тосичном коллективе) отсюда многие пункты которые в нормальной команде (где нормальные отношения) не нужны. Никто не обижался когда я спрашиваю, как там баг или подхожу и что-то спрашиваю (а не назначаю митинг каждый раз, как советует автор).

      Но негативный опыт — тоже опыт, поэтому некоторым эти советы реально могут помочь.

  3. Как-то раз тестировал фичу, завел баг на разработчика — он фиксит, потом отправляет на меня, я снова смотрю — опять воспроизводится. Переоткрыл на него, опять типо пофиксил — присылает — то же самое. Снова переоткрыл — подходит ко мне и говорит «еще раз переоткроешь — пальцы тебе переломаю») Реальный случай.

      • На полном серьёзе) человек просто бесился жестко, когда ему баги прилетали. Это при том, что в компании метрики по багам не считались никак.

  4. Хотя и неадекватов среди коллег тоже хаватает. Замечаю такую закономерность — чем умнее человек в какой-то сфере и чем увлеченнее, тем более странным образом он может себя вести.

  5. Слишком сильно защищают программеров в этой статье)) Хотя на практике бывает так, что программеры не хотят ничего делать — пинаешь их, спрашиваешь постоянно, а в ответ вот-вот будет готово. У них вечно все вот-вот будет готово)

ОСТАВЬТЕ ОТВЕТ

Пожалуйста, введите ваш комментарий!
пожалуйста, введите ваше имя здесь

$1100*
медианная зарплата в QA в ноябре

*по результатам опроса QA-инженеров в нашем телеграм-канале

Последние публикации

Последние комментарии