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

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

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

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

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

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

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

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

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

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

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

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

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

Метки
#Тестирование ПО (2)Android (1)courses (1)HR (1)iOS (2)java (1)kaizen (2)QA (11)QualityLab (1)REST API (1)selenium (1)SOAP UI (1)softwaretesting (1)SQA Days-25 (1)sql (5)TestSuites (1)usability (2)БАГИ (1)Исследовательское тестирование (2)Истории поинт (7)Команда разработки (1)Курс тестирования для начинающих (1)Мнемоники (1)Мнемоники в тестировании (1)Нина Агеева (4)ПОИНТ (30)ПРомо-вебинар (1)Роман Буданов (3)Скриншот (1)Тестирование (10)Тестирование ПО (1)Тест менеджмент (1)Тренер (11)Туры (1)автоматизация (2)алгоритмы (1)баг (1)безопасность (1)введение в тестирование (1)декомпозиция (1)домашки (1)займемсяпоинтом (1)игры (1)идеальный мир (1)интернет (1)истории выпускников (7)как надо тестировать (2)конференция (1)котик (1)курс для начинающих тестировщиков онлайн (1)мобилки (3)мобильное тестирование (3)настройка мозгов (1)начинающий тестировщик (6)негативное тестирование (2)организация тестирования (1)персонажи (1)планирование (1)постановка мозгов (2)работа над ошибками (1)рабочий процесс (1)радиоСаня (1)режим разработчика (3)резюме (1)сопроводительное письмо (1)тайм-менеджмент (1)тестировани (1)тестирование usability (2)тестирование безопасности (1)тестирование мобильных приложений (1)тестировщик (4)улучшайзинг (1)ученик (2)фреймворки (1)чит лист (1)что должен делать тестировщик (1)
С 19.08 по 14.10, ОНЛАЙН Зарегистрироваться