Коммуникации в жизни QA: как понимать людей и поддерживать хорошие отношения со всеми
Меня зовут Оксана Харчук, и я QA-специалист в компании DataArt. Проработав более 5 лет в качестве QA Engineer и QA Lead на разных проектах, обучив при этом несколько практикантов, я сделала вывод, что все люди разные и у каждого, как говорится, свои тараканы в голове, но найти общий язык можно абсолютно со всеми. В этой статье я расскажу о роли коммуникаций в жизни QA.
Круг общения QA
Коммуникации в жизни QA занимают очень большое место. Наверное, каждый сталкивался с ситуацией, когда ты целый день онлайн: созвоны, митинги — и к вечеру ты понимаешь, что потратил на это весь рабочий день, при этом никто не отменял твоих прямых обязанностей, связанных с тестированием программного продукта.
QA Engineer — это человек, который коммуницирует с большим количеством людей: с разработчиками, заказчиками, бизнес-аналитиками, дизайнерами, пользователями и т. д. Их круг общения огромный, и с каждым нужно уметь договориться. Поговорим вкратце об особенностях каждого типа.
Дизайнеры
Это люди творческие, они отвечают за внешний вид программного обеспечения. Тестировщик во время своей работы уточняет вопросы, связанные с макетами программного продукта. Мне всегда нравится общаться с дизайнерами. Когда ты делаешь замечание по какому-то вопросу, взамен тебе прилетает еще три разных варианта того, как сделать по-другому, чего зачастую от разработчиков не дождешься. На основании своего опыта могу сказать, что дизайнеры — легкие в общении люди. С ними очень интересно, ведь они креативные личности, и это чувствуется.
Разработчики
Разработчик и тестировщик — это люди, которые живут по соседству и не могут друг без друга. На эту тему можно начинать холивар, но, по моему мнению, это так. Давайте немного абстрагируемся и представим такую ситуацию: муж и жена живут в одном доме и не разговаривают друг с другом, только пишут сообщения в случае необходимости, если нужно купить что-то из еды или заплатить по счетам. Каждый день они просыпаются и молча идут на работу, работают, приходят домой и снова не разговаривают. Что будет спустя месяц, год? Увы, такой брак будет разрушен, это очевидно. Потому что нет общения.
Я веду к тому, что эту ситуацию можно применить и к IT-сферe. Если нет хороших отношений между разработчиком и тестировщиком, проект уже априори неуспешен.
Причины, по которым Dev и QA могут не ужиться
Черствость и равнодушие
Каждый человек может столкнуться с трудностями не только в работе, но и в личной жизни. Мы все понимаем, что домашние проблемы должны оставаться дома, но так получается не всегда, и иногда человек переносит свои тяготы в работу. Соответственно, падает работоспособность, человек не хочет проявлять инициативу, у него не получается вкладываться в сроки или он вовсе не справляется с поставленной задачей. В такой ситуации главное — поддержать коллегу, даже если вы не знаете его проблем. Проще всего махнуть рукой и подыскать замену, а вот проявить человечность — это дорогого стоит.
Неумение принимать критику
К сожалению, эта проблема актуальна в повседневной жизни каждого. Представьте, что вы решили приготовить пирог, может, даже первый раз в жизни, и позвали товарища испробовать результат проделанной работы. Угостившись, ваш друг вас не хвалит, а критикует: мол, тесто твердое и начинка солоноватая, но, вообще, есть можно. Может быть два варианта исхода этой истории: человек больше никогда не будет готовить пирог или, наоборот, приложит еще больше усилий и сделает пирог идеальным. Все зависит от человека, умеет ли он принимать критику правильно и учиться на своих ошибках. Так же происходит и между разработчиком и тестировщиком.
Находя очередной баг, тестировщики часто забывают о том, что это создано разработчиком, который тратил время и силы, и нужно постараться не ранить его своей критикой. Критику нужно уметь подавать так, чтобы сохранить хорошие взаимоотношения.
Например, вы, как тестировщик, нашли баг и теперь должны сказать об этом разработчику. Первый способ: «Твой вчерашний залитый функционал не работает. Там баг, и не один». Или второй способ: «Я посмотрел твой вчерашний залитый функционал, ты хорошо потрудился. Есть несколько нюансов, можешь глянуть, пожалуйста?» Согласитесь, что второй способ звучит гораздо приятнее: вы критикуете и при этом хвалите.
Сложные люди
Это такие, с которыми тяжело общаться. Вас игнорят, не отвечают на звонки и письма — хуже может быть, только если это человек со стороны заказчика. Такая ситуация была со мной. Придя на проект, где половина разработчиков были на стороне заказчика, я столкнулась с кейсом, когда нужно было уточнять рабочие вопросы со «сложным» разработчиком, при этом никто, кроме него, помочь мне не мог.
Когда я спросила у команды, как мне быть, ребята просто посоветовали ждать и разбираться самой. Однако такой вариант меня не устраивал, и я начала писать ему по несколько раз в день — сначала лично, затем в общие чаты, чтобы все видели, а если уж и это не помогало, то с отсылкой на вышестоящего менеджера. Таким образом я все-таки достучалась до него, и теперь у нас хорошие отношения. Мне не нужно писать вышестоящим менеджерам, чтобы он ответил на мое письмо или вопрос, ведь он знает, что я все равно достучусь.
Оказывается, нужно всего лишь быть настойчивым, хотя и с этим надо соблюдать осторожность. Слишком большой напор может закончиться для вас плачевно. И самое главное — не верить распространенному мнению, что с кем-то работать невозможно. Просто нужно найти ниточки, за которые дернуть, и получше узнать человека.
Советы для счастливой совместной жизни Dev и QA
Не судите строго за ошибки
После обнаружения критического бага не осмеивайте его перед разработчиком. Поймите: тестер работает в условиях ограниченного времени и бюджета, но то же справедливо и в отношении разработчика. Никто не может создать программное обеспечение без ошибок, иначе тестирования не существовало бы.
В то же время разработчики не должны высмеивать баги, которые вовсе не кажутся им багами. Не стоит судить строго подход к оформлению багов. Например, шаги написаны непонятно: то слишком кратко, то слишком подробно, то какой-то шаг пропущен. Если вам неудобно работать, можете красиво намекнуть, а не предъявлять претензии.
Обменивайтесь идеями
Как говорится, одна голова хорошо, а две лучше. Частое общение между разработчиком и тестировщиком помогает генерировать больше идей с каждой стороны. Разработчик может подсказать, как лучше протестировать конкретный модуль, в то же время тестировщик может показать, как исправить дефект. Откройте себя для новых предложений и обмена идеями.
Будьте реалистами
Бывает, сидишь и ловишь баг полдня, выписываешь шаги, а потом бац — и он уже со статусом «won’t fix» или «it is not a bug», и на глазах появляются слезы, потому что потрачено столько времени и сил. Будьте реалистами, постарайтесь понять причину, по которой баг был отклонен. Может, вы что-то неправильно поняли или предположили. Постарайтесь убедить разработчика или менеджера устранить баг, если вы считаете, что представленный вами сценарий был верным, и двигайтесь дальше.
Расставляйте приоритеты повсюду
Проект и командная работа важнее, чем баг и ваше мнение. Если разработчик считает, что любой дефект в разработанном им модуле, о котором сообщалось, является тривиальным, злонамеренной идеей или попыткой преследовать его, то этот дефект — скорее проблема его эго, чем ошибка.
Если тестер считает, что обнаруженный им баг был отклонен из-за того, что разработчик хотел причинить ему вред, потому что разработчик не любит исправлять ошибки, считая, что конкретный тестировщик не понимает вещи должным образом, или потому что он думает, что является разработчиком и делает все возможное, то тогда идея тестирования сходит на нет.
Показывая свое эго и действуя в соответствии с ним, мы лишаем себя возможности расти, а других — работать.
Поэтому, если возможно, изначально ведите себя не как тестировщик, а как член команды, который усердно работает, чтобы все исправить. Не нужно расстраиваться, когда баги будут отклонены, но стоит постараться узнать причину этого. Не останавливайтесь, узнав, что время, отведенное на тестирование, закончилось. Не стоит недооценивать себя, признавая, что разработка — это отличная работа. И наконец, не будьте слишком уверены в себе, полагая, что вы превосходите самого себя, потому что находите проблемы в работе других.
Если следовать вышеизложенным правилам, то можно получить следующие преимущества:
- Мотивация. Хорошо сплоченная команда всегда мотивирует на проявление инициативы, на карьерный рост, есть желание двигаться только вперед и не прекращать совершенствоваться.
- Хорошее настроение. Когда в команде отличная атмосфера, человек хочет идти на работу и вкладываться, общаться.
- Обучение на будущее. Каждый приобретает бесценный опыт, который можно использовать в будущем.
- Проект успешен по умолчанию. Когда в проекте команда разработчиков и команда тестировщиков не воюют, а, наоборот, помогают друг другу, проект гарантированно будет успешным. У меня был опыт, когда разработчики писали локаторы специально для автоматизаторов, чтобы облегчить им жизнь. Был случай сотрудничества, когда автоматизированные тесты писались еще на машине разработчика, чтобы после поставки функционала сразу протестировать его автотестами.
- Индивидуальный рост. Все растут, потому что есть здоровая конкуренция и нет скрытых боев. Обмен идеями и принятые предложения дают всем шанс для прогресса.
- Командный рост. В итоге команда становится более сильной и компетентной благодаря наличию членов команды, которые понимают друг друга и уважают работу друг друга.
Бизнес-аналитики
Не на всех проектах есть бизнес-аналитик. Очень часто его роль исполняют другие участники жизненного цикла разработки программного обеспечения. Мне довелось сравнить жизнь на проекте с бизнес-аналитиком и без него. На одном из них роль бизнес-аналитика исполнял Team Lead со стороны заказчика, и, признаюсь, это было нелегко, ведь, помимо основных задач, ему нужно было уделять время работе с требованиями, а времени катастрофически не хватало. Поэтому качество требований было низким, об удобстве работы со стороны тестировщика я вообще молчу.
На следующем проекте мне посчастливилось поработать с Senior BA, и, скажу честно, поначалу я не понимала, насколько мне повезло. Только спустя несколько месяцев я осознала, как удобно работать с бизнес-аналитиком, и выделила следующие плюсы:
- Хорошие требования. User Stories ориентированы на бизнес, нет зависимости со стороны разработки — есть задача, которую требуется выполнить. А вот как — это уже головная боль разработчиков.
- Есть на кого спихнуть. Если в функциональности заказчику что-то не понравилось, вы всегда можете сказать, что она реализована согласно заявленным требованиям, и тогда уже бизнес-аналитик объясняет, откуда он взял такие требования.
- Лучшее понимание, есть возможность обсудить, взвесить все за и против и принять необходимое решение на ранней стадии разработки.
Бизнес-аналитик выступает на проекте в роли переводчика, он анализирует нужды пользователей и доносит их до нас на понятном языке. Вы спросите, о чем это я? Просто в своей практике мне приходилось разговаривать с пользователями продукта разработки, и это очень сложно, ведь они хотят многое, нужно уметь вынести из всего сказанного самое важное и сказать нет всем остальным «хотелкам».
Хорошие отношения с бизнес-аналитиком существенно облегчают жизнь тестировщику, пусть даже иногда вам приходится выслушивать крик души о том, как ему надоели эти бизнес-пользователи, которые и сами не знают, чего хотят, и заказчик, который хочет получить максимум прибыли и минимум расходов. Но поверьте: оно того стоит.
Заказчики
О коммуникациях с заказчиком можно говорить очень долго и написать целую книгу, даже не одну, но я постараюсь обозначить самые, на мой взгляд, главные вещи.
Терпение. Заказчики бывают разные: агрессивные, деловые. Этот список можно продолжать долго, но самое важное для нас — это терпеть их прихоти и не выходить за рамки дозволенного.
Честность. Если вы опаздываете с релизом по причине того, что вы неправильно оценили время, то лучше скажите об этом честно, не стоит врать. Да, это ваша ошибка, но люди, которые признают свои ошибки, вызывают доверие и уважение.
Инициатива. Проявлять инициативу нужно, но главное — не перегнуть. Если вы будете слишком настойчивы, вас могут и попросить. Важно доказать, зачем это нужно и в чем плюс для заказчика, желательно в денежном выражении, ведь для заказчика это является одним из важнейших факторов.
Информативность. Заказчик должен видеть, что работа выполняется, поэтому старайтесь максимально визуализировать процесс. Однажды я пришла на проект, на котором не было отчетов о тестировании. Когда я предложила отсылать их заказчику, моя команда тестировщиков сказала, что это пустая трата времени и что заказчик и так нам доверяет. Я не послушала ребят, все-таки сделала отчет и отправила его. К моему удивлению, заказчик не просто был в восторге, он распечатал отчет и на всеобщем созвоне сказал, что это круто и что ему очень нравится.
Активное слушание. У меня есть такое правило: всегда нужно больше слушать, чем говорить. Пусть даже вы говорите о погоде, но интерес должны проявлять вы, а не заказчик.
Примеры. Лучше один раз показать, чем сто раз рассказать. Представим ситуацию: вам нужно внедрить какой-то инструмент, но он стоит денег. Если вы придете и покажете, как этот инструмент работает, хорошо бы еще на реальных данных заказчика, то, вероятнее всего, вам скажут да.
Не выкладывайте компромат на себя в социальных сетях. Со мной был забавный случай. Я плохо себя чувствовала и взяла больничный на день. В тот же вечер у меня было выступление на конференции. Думаю, подлечусь до вечера, чтобы выступить хорошо. Но организаторы выложили в социальные сети историю о моем выступлении, и на следующий день я получила выговор от PM, что так делать нельзя. Заказчик подумал, что я всех обманула и на самом деле не болела. Так что социальные сети — это компромат на вас. Если вы не выкладываете компрометирующие фото, то убедитесь, что этого также не делают ваши друзья и коллеги.
Все вышесказанное может принести вам и вашей команде следующие плюсы:
- доверие и уважение заказчика;
- премию и рост заработной платы;
- ответственность и независимость.
Заключение
Современный мир, по сути, сформулировал одно из ключевых своих правил: чтобы быть успешным специалистом, недостаточно одних лишь глубоких знаний и трудового опыта, нужно еще нечто, чему толком не учат в школах. Это нечто — особые, так называемые «мягкие навыки», или «гибкие навыки» — soft skills.
Надо отметить, что soft skills можно и нужно развивать, причем начиная со школьной скамьи. Мой сын недавно окончил первый класс, и одной из основных целей его обучения было не освоение математики или чтение, а научиться общаться с другими детьми, быть командой. Ведь математика — наука точная, ее можно выучить, а вот адаптировать ребенка к социуму, развить лидерские качества — это задача сложная и требующая особых усилий.
Развивайте свои soft skills, двигайтесь по карьерной лестнице вверх, цените свое время и время других.
