10 примеров эффективного общения для тестировщиков

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

Будущих студентов курса "QA Engineer" и всех желающих приглашаем записаться на открытый урок по теме "Как правильно составлять баг репорт".

Также делимся переводом полезного материала.


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

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

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

В этой статье описаны 10 примеров ситуаций, когда хорошо развитые коммуникативные навыки тестировщиков могут стать решающим фактором.

1. Тестирование начинается с анализа и проектирования

Как в каскадной, так и в agile среде, встречи по анализу, проектированию и планированию требуют тщательного изучения формулировки задачи и предлагаемых решений. Цель состоит в том, чтобы обеспечить наилучшее возможное разрешение с учетом всех накопленных знаний и опыта. Жизненно важно, чтобы каждый член команды четко понимал видение и намеченный путь. 

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

  • Характерный опыт тестирования аналогичного продукта в прошлом, а именно — что было легко, а что было сложно, особенно если это неочевидные или неожиданные вещи;

  • Особые юзкейсы или пользовательские запросы — доступность, тестируемость, пограничные случаи, и другие относящиеся к делу элементы;

  • Юзабилити и дизайн-мышление;

  • Подходы к тестированию, особенности фреймворков автоматизации и т. д.

2. Тестировщики как представитель интересов пользователей

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

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

Тестировщик должен выступать в роли представителя интересов клиента и может делать это посредством:

  • Изучения дефектов, о которых сообщают пользователи;

  • Управления ожиданиями пользователей относительно того, когда дефект будет устранен;

  • Информирования пользователя об обходных путях решения проблемы до исправления дефекта, если он мешает пользователю что-либо делать;

  • Ссылаясь на существующую техническую документацию, когда это уместно, или сообщая авторам о необходимых изменениях;

  • Сообщая клиентам, когда для бета-тестирования будут доступны новые фичи.

Хорошие коммуникативные навыки могут сделать управление ожиданиями и планирование релизов гладким и четким.

3. Голос качества

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

  • Код ревью;

  • Обсуждение стратегии тестирования;

  • Разбор плана/кейсов тестирования;

  • Обзор/оптимизация процессов тестирования;

  • Планирование релиза;

  • Работа с разработчиками технической документации;

  • Обеспечение адекватного кода и покрытия тестами;

  • Борьба с запоздалой отправкой на тесты;

  • Обсуждение проблем;

  • Обзор процесса разработки и его улучшений;

4. Обмен знаниями

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

5. Фидбэк 

Очень важна обратная связь о любых рисках, обнаруженных намного позже в SDLC (жизненном цикле разработки ПО), или любых тревожных сигналах, которые могут поставить под угрозу план релиза. Тестировщики должны эффективно и своевременно сообщать об этом другим членам команды — разработчикам и товарищам по тестированию; а также доносить их до своего руководителя и других заинтересованных сторон. Этот канал обратной связи очень важен, поскольку такая информация может привести к принятию важных и трудных, но своевременных решений.

6. Связь с пользователями

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

7. Документация

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

8. Задавать правильные вопросы

Один из самых важных навыков для быстрого получения правильных ответов и нужной информации — это умение задавать правильные вопросы. Технику работы с вопросами можно улучшить — этому навыку можно научиться. Как совершенно верно отмечено в этой статье:

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

9. Коучинг и руководство командой тестирования

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

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

10. Когда нужно выразить несогласие

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

Для agile команд решение о релизе становится командным решением, что по-прежнему означает, что если есть риски и требуется отложить релиз, инженерам-тестировщикам необходимо будет подкрепить ответ данными, хорошо изложенными причинами и важной информацией. Это требует четкого понимания проблемы, риска, а также анализа и обобщения основных причин.

Рекомендации по улучшению коммуникации

Вот некоторые способы улучшить ваше общение:

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

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

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

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

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

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

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

  • Знайте свое дело/Делайте свою домашнюю работу — когда то, чем вы делитесь, подкреплено данными, фактами и наблюдениями, на которые вы можете сослаться, ваша способность разъяснять и извлекать информацию становится более мощной. Используйте эту способность в своих интересах.

  • Постоянно развивайтесь — стремитесь работать над собой, если вы один из тех, кто от природы не наделен хорошими коммуникативными навыками, с практикой приходит совершенство… или, по крайней мере, становится чуточку ближе!

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


Узнать подробнее о курсе "QA Engineer".

Записаться на открытый урок по теме "Как правильно составлять баг репорт".

ЗАБРАТЬ СКИДКУ

Источник: https://habr.com/ru/company/otus/blog/533400/


Интересные статьи

Интересные статьи

Многие компании в определенный момент приходят к тому, что ряд процессов в бизнесе нужно автоматизировать, чтобы не потерять свое место под солнцем и своих заказчиков. Поэтому все...
Команда Rust рада сообщить о выпуске новой версии, 1.42.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение. Если вы установили пред...
OTP расшифровывается как Open Telecom Platform; так исторически сложилось, потому что платформа создавалась для нужд и на деньги Ericsson. Но, в принципе, это название имеет примерно столько же к...
Эта публикация написана после неоднократных обращений как клиентов, так и (к горести моей) партнеров. Темы обращений были разные, но причиной в итоге оказывался один и тот же сценарий, реализу...
Согласно определению в Википедии, тайник (dead drop) — это инструмент конспирации, который служит для обмена информацией или какими-то предметами между людьми, использующими секретное местоположе...