Коммуникации в тестировании

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

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

Стоит поставить перед собой две задачи:

  1. прокачать навыки деловых коммуникаций, как устных, так и письменных,
  2. научиться грамотно формулировать  свои вопросы.

Давайте остановимся подробнее на этих задачах.

Деловые коммуникации

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

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

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

Многие тестировщики зачастую допускают ошибку, которую я называю «как слышим, так и пишем». Увидел ошибку, побежал фиксировать, записал все сплошным текстом: «вот эта синяя кнопка не работает» и отправил, пока тепленькая. Разработчик открывает ваш репорт и не может понять, что произошло, где это произошло и при каких условиях.

Проблема в данном случае в том, что тестировщик особо не вникал в свой отчет и писал, как на духу ­­– ему-то все понятно, кнопка не работает. А разработчик – другой человек, он вполне может мыслить несколько иначе и в вашем отчете увидеть свою головную боль. Он будет задавать вам множество уточняющих вопросов, просить приложить файлы и описать все пошагово. Вы будете думать, что разработчик вообще живет на другой планете и не понимает очевидных вещей. Вы потратите много времени на выяснение всех деталей, а поскольку время = деньги, потери будут значительными.

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


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

В нашей команде тестирования ребята говорили, что хороший баг-репорт – это, когда даже твоя бабушка может понять его суть и воспроизвести ошибку. Немножко смешно, ведь пишутся репорты не для бабушек, но становится не так весело, когда ты видишь чужой репорт, перечитываешь его примерно пять раз и под конец можешь сказать только одно: «И что я должен с этим делать?».

Но всему можно научиться: писать баг-репорты, сценарии, отчеты. Можно научиться и правильным устным коммуникациям. Совет достаточно прост: «Практикуй и все придет!». Нет более действенного способа в освоении навыка, чем его изучение и практика. Читайте тест-кейсы, написанные другими тестировщиками, анализируйте, пишите свои и не бойтесь задавать вопросы, просить советов у коллег, обсуждать навыки и способы решения возникающих задач.

Умение задавать вопросы

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

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

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

Как правильно задавать вопросы?

Перед тем, как задать вопрос, проанализируйте его. В чем именно у вас затруднение на данный момент? Как только вы это сделали, постарайтесь кратко, но емко ввести собеседника в курс дела, объясните суть вашего вопроса или просьбы. Не стоит начинать издалека и рассказывать, как вы пришли в тестирование или же, наоборот, с наскока заключать: «Я, короче, попробовал и ничего не получилось!».


Не стоит начинать издалека и рассказывать, как вы пришли в тестирование или же, наоборот, с наскока заключать: «Я, короче, попробовал и ничего не получилось!».

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

Не знаете, что за слова «мёржить», «невалидный», «тест-сьют» и «фича»? Задавайте вопросы. Можно гуглу, можно коллеге.
Не можете понять, баг в документации или так должно быть? Задавайте вопросы аналитику.
Не понимаете, что понаписал разработчик в ответ на ваш баг-репорт? Задавайте вопросы разработчику.
Так вы поубиваете сразу кучу зайцев: наладите коммуникации с коллективом, восполните свои пробелы в знаниях, сможете быстрее схватывать поступающую информацию, научитесь четко и красиво излагать свои мысли.

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

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

Метки
ISTQB FL (5)IT (1)Java для тестировщиков (1)Jedi Point (12)JSON (1)kaizen (2)Pairwise Testing (1)QA (25)QualityLab (1)REST API (1)selenium (1)SOAP UI (1)softskills тестировщика (7)SQA Days-25 (1)Sql в тестировании (6)TestSuites (1)XML (1)xpath (1)Анна Палей (1)Исследовательское тестирование (3)История успеха (18)Курс тестирования для начинающих (15)Мнемоники в тестировании (1)Наталья Руколь (1)Нина Агеева (4)Обучение тестированию (13)ПОИНТ (51)Роман Буданов (3)Сессионное тестирование (1)ТЗ (1)Таблица решений (1)Тест-анализ (2)Тест-дизайн (6)Тест-кейс (1)Тест-стратегия (1)Тест-туры (1)Тестирование usability (6)Тестирование ПО (7)Тестирование игр (4)Тестирование мобильных приложений (4)Тест менеджмент (4)Чек-лист в тестировании по (4)Чит-лист в тестировании (2)автоматизация тестирования (2)автотесты (1)английский для тестировщиков (3)аудит проекта (3)баг (1)багнапродакшене (1)введение в тестирование (1)виды тестировния (2)граничные значения (1)декомпозиция (1)инструменты тестирования по (4)как надо тестировать (2)как стать тестировщиком (2)комбинаторика в тестировании (1)метрики тестирования (1)начать карьеру в IT (8)начинающий тестировщик (11)негативное тестирование (2)ограничения (1)оптимизация QA-процессов (1)организация тестирования (1)персонажи (1)планирование тестирования (1)профессия тестировщик (3)резюме (1)сертификация ISTQB FL (4)скринкаст (1)смена работы (2)сопроводительное письмо (1)тест-кейс (1)тест-менеджмент (3)тестирование безопасности (1)тестирование веб (3)тестовая стратегия (1)удаленная работа (1)управление требованиями (6)фреймворк тестирования (1)школа тест-менеджера (3)
С 19.10 по 31.12, ОНЛАЙН Зарегистрироваться