Стили мышления, стили работы



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

Кроме того, есть еще одно важное отличие – в стиле работы. Работа тестировщика обычно связана с частыми переключениями внимания, за день тестировщик порой может выполнить не один десяток разных, не слишком связанных между собой задач. У программистов всё иначе – им свойственно работать «в потоке». Эту особенность работы программистов описали Том Демарко и Тимоти Листер в замечательной книге «Человеческий фактор: успешные проекты и команды»: «Поток – это состояние глубокого, почти медитативного погружения в работу. В этом состоянии человек испытывает легкое чувство эйфории и не замечает течения времени: «Я начал работать. Когда оторвался, прошло уже три часа». Человек не прикладывает сознательных усилий, потому что работа, кажется, идет потоком.» Именно такое состояние необходимо для написания качественного кода.

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

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

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


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


Конструктивная критика

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

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

О важности конструктивной критики сказано немало, но далеко не всё из множества советов подходит к нашей работе. Нет, я не собираюсь предлагать вам писать баг-репорты, используя знаменитый «метод бутерброда» (похвала в начале и в конце критического замечания), тем более, что даже 5-летнего ребенка не получится провести таким образом более чем один-два раза В целом, сама форма баг-репорта в значительной степени защищает нас от неконструктивной критики, так что применительно к описаниям дефектов можно вспомнить только об одном принципе: конструктивная критика должна быть аргументированной. Объясните, почему вы считаете, что это дефект. Идеально – ссылка на требования или стандарты, которым должна соответствовать программа. Если вам сложно объяснить, почему вы считаете это дефектом – что-то здесь не так. Если вам просто кажется, что «лучше было бы по-другому», может быть, правильнее занести ваше замечание как улучшение или feature request.

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

Итак, какие принципы хорошей критики применимы в нашем контексте:

Выбирайте место и время. Не стоит нападать на программистов с вопросом: «Когда пофиксишь баг AB-123?!» в коридоре или когда они пьют кофе на кухне. Люди более адекватно воспринимают критику там и тогда, где и когда они ожидают ее услышать. Запланированные регулярные митинги с участием команд тестирования и разработки – хорошая идея.

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

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

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

Всегда давайте собеседнику возможность ответить. Выслушайте возражения и объяснения. Даже если вы не согласны – дайте другой стороне шанс высказаться.

Покажите, что вы тоже открыты для критики. Это важный психологический момент – показать, что это не односторонний процесс, что и вы готовы принимать и учитывать критику вашей работы. Вы можете предложить разработчикам поучаствовать в peer review вашей тестовой документации (тест-кейсов, тест-плана и т.д.). Если они согласятся и найдут для этого время, это будет действительно полезно, даже и не только с психологической точки зрения, у них могут быть действительно хорошие идеи, как улучшить тестирование. Если не согласятся – по крайней мере, вы предложили.

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

И еще один момент, важный, если вы делите с программистами общее пространство. Когда вы находите классный баг, ваша радость вполне понятна (другим тестировщикам), но постарайтесь все же не слишком бурно ее демонстрировать – вас могут неправильно понять, это может быть воспринято как злорадство.

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




«Это не баг, это фича»
Наверно, каждый тестировщик сталкивался с такой ситуацией. Вы считаете, что это баг, а разработчик так не считает. Что делать? Согласиться или спорить?


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

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



«Не воспроизводится»

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

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




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

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

Плохое описание дефекта

Распространенная причина, по которой вокруг бага возникает конфликт – плохое описание. Особенно часто пропускают пункт «expected results» - ожидаемые результаты. Разработчик смотрит и не понимает – почему это баг? А как вообще правильно? А чего вы ждали? Старайтесь всегда добавлять этот пункт, даже если вам кажется, что это тривиально и «и так понятно». Много времени это не займет, но поможет избежать лишних споров.

Неправильный приоритет

Очень много недовольства у разработчиков вызывает завышение приоритета или severity дефектов. Естественно, если приходит баг с «severity: critical», программист часто бросает все и начинает разбираться. Если в итоге оказывается, что дефект не тянет и на «major» - раздражение и возмущение вполне объяснимо, так как человека отвлекли из-за пустяка. Честность очень важна в работе тестировщика. Не завышайте приоритеты! Но и занижать, конечно, не стоит, иначе важная проблема может остаться без внимания.


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

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

«Reproducibility» как стандартное поле в описании дефекта существует не во всех баг-трекинговых системах. Она есть, например, в Mantis. Там можно указать один из следующих вариантов:

• Always – Всегда;
• Sometimes - Иногда;
• Random - Произвольно;
• Have not tried - Не проверялась;
• Unable to duplicate — Не удалось воспроизвести.
  

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

Также один из вариантов – временно назначить дефект на себя и продолжить разбираться, пока не получится выявить закономерности и/или накопить достаточно информации об условиях проявления проблемы.

Курсы по тестированию ПО.