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



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

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

Это состояние нельзя включать по желанию, требуется не менее 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/всегда».

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

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

Последние статьи в блоге

Учебный центр IBS подписал партнерское соглашение с АО «НПО РусБИТех», разработчиком российской операционной системы Astra Linux.

Теперь мы можем проводить авторизованное обучение по работе с Astra Linux для специалистов в области информационной безопасности.

17 февраля 2025

Двойная выгода: покупай один курс — получай второй за 50% стоимости!

Воспользуйтесь возможностью изучить более глубокие аспекты одной области — например, при покупке курса по Java, архитектуре ПО, управлению проектами, системному и бизнес-анализу, тестированию ПО и Big Data вы можете получить второй курс этой же тематики за полцены! Не упустите шанс развить свои навыки и поднять свою карьеру на новый уровень. 

29 января 2025

Сертификация преподавателя Java-разработки для крупного провайдера ИТ-обучения

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

Новости
21 января 2025

Системный аналитик 100 lvl — дорожная карта развития

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

23 декабря 2024

Платформа сертификации IBS признана лучшим digital-решением для корпоративного обучения

Центр сертификации IBS стал обладателем Гран-при премии «Смарт пирамида» — одной из самых престижных российских премий за достижения в области обучения и развития человеческого капитала.

20 декабря 2024

Учебный центр IBS получил сертификат ГОСТ Р ИСО 9001-2015

В октябре 2024 года Учебный центр IBS получил сертификат соответствия ГОСТ Р ИСО 9001-2015. Это важное достижение подтверждает, что мы придерживаемся высоких стандартов качества и результативно управляем образовательными процессами организации.

19 декабря 2024

9 курсов со скидкой до 50%

Друзья, в январе стартует 9 курсов, обучение на которых можно купить со скидкой до 50%*! 

15 декабря 2024

8 заблуждений про тестирование

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

15 декабря 2024

Путь к Fullstack-тестировщику: что нужно знать о ручном и автоматизированном тестировании?

Тестирование программного обеспечения — одна из самых востребованных областей в IT. И часто новички и даже опытные специалисты, желающие строить свою карьеру в этом направлении, часто сталкиваются с вопросом: какое тестирование выбрать — ручное, автоматизированное или Fullstack? У каждого из этих направлений свои особенности, преимущества и требования к знаниям. В этой статье рассмотрим каждое из направлений, их плюсы и минусы, области применения и навыки, необходимые для успеха.

15 декабря 2024

Совет по развитию сертификации ИТ-специалистов при АПКИТ аккредитовал «Платформу сертификации IBS»

Директор департамента обучения и развития IBS Владимир Гернер участвовал в заседании Совета по сертификации ИТ-специалистов при АПКИТ.

Новости Жизнь компании
08 октября 2024

Java-сертификация: IBS в сравнении с Oracle

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

Новости
04 октября 2024

Исследование IBS: число новых ИТ-решений в реестре ПО выросло в 2023 году более чем на треть

Анализируем ситуацию на рынке российского ПО.

Жизнь компании
01 октября 2024

6 суперспособностей Fullstack-тестировщиков, которые напоминают навыки животных

Читайте о скиллах, которые делают тестировщиков востребованными на рынке труда.

27 сентября 2024

5 мифов о системных аналитиках

Вместе с Екатериной Тихомировой, специалистом по системному и бизнес-анализу, разбираемся, чем занимаются системные аналитики.

20 сентября 2024

Методология 12 факторов: как успешно разрабатывать облачные приложения

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

12 сентября 2024

Баги, которые стали фичами

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

09 сентября 2024

Шаблоны облачного проектирования

Читайте про наиболее популярные шаблоны облачного проектирования: шаблон Bulkhead и шаблон Sidecar.

06 сентября 2024

Бесплатные мини-курсы ко Дню знаний

Друзья, поздравляем с Днём знаний! Желаем любопытства, открытий и новых побед!

02 сентября 2024

5 курсов со скидкой 30%

Друзья, в сентябре стартует 5 курсов со скидкой 30%*

29 августа 2024

Исследование IBS: на одну вакансию в Java-разработке приходится 4 резюме

По данным исследования рекрутингового центра IBS, наибольшая конкуренция среди соискателей наблюдается среди Python-разработчиков: на одну вакансию приходится 10 резюме. В менее конкурентной среде находятся Java-разработчики (4 резюме на одну вакансию). Самыми дефицитными являются специалисты по языку Go: менее 2 резюме на одну вакансию.

28 августа 2024

Не нашли, что искали? — Просто напишите, и мы поможем

Продолжая, я подтверждаю, что ознакомлен с Условиями использования и Порядком обработки персональных данных
Корпоративное обучение Оценка персонала Сертификация О нас Стань тренером Блог
Пользователь только что записался на курс ""
Спасибо!
Форма отправлена успешно.