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