Связь Тестер-Разработчик

9

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

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

Любые советы или исследования о том, как тестер должен общаться с разработчиками?

Обновление : Спасибо всем за ваши ответы. Все они подтвердили то, что я имел в виду. На данный момент моя команда очень восприимчива к моей роли, и мы в итоге добились реального прогресса. Я мог бы выбрать более одного в качестве ответа, но я должен был принять решение.

HH
источник
1
Когда вы находите кучу ошибок, хорошей идеей будет спросить, как их следует регистрировать, а также, должна ли ошибка быть ошибочной или порождаться как новая. Восприятие разработчика другими людьми имеет значение. Каждый раз, когда вы ошибаетесь, это может плохо отразиться на нем. В идеале вы должны сидеть в пределах 9 ярдов от этого разработчика и разговаривать, иначе вы на самом деле не делаете разборки.
Работа

Ответы:

11

Самый простой способ улучшить коммуникацию - это работать вместе с вашими разработчиками (и дизайнерами, архитекторами и т. Д.) И постепенно разрушать эти глупые роли и в конечном итоге понять, что мы все тестеры, за исключением того, что некоторые из нас имеют больше опыта, чем другие.

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

Вот что я имею в виду, когда говорю о «совместной работе». Я полностью уверен, что так должно работать общение в команде. Эта статья объясняет это очень хорошо, кстати.

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

Мартин Викман
источник
Большую часть времени им обоим трудно общаться, поскольку у них разный словарный запас. Отправка аннотированных снимков экрана (например, с помощью Usersnap ) экономит много времени и помогает разработчикам лучше понимать тестеров. Кроме того, метаданные, такие как используемый браузер, разрешение экрана и операционная система, предоставляются автоматически.
Грегор
11

Я твердо верю в ЛЮБОЙ вид общения между разработчиком и тестом.

Слишком много раз я видел драки булочек между каждой командой, мелкие взад и вперед («закрыто по замыслу», затем «вновь открыто» и т.д.).

Я всегда говорю тестировщикам, с которыми я работаю, приходить и говорить со мной, если у них есть какие-либо сомнения.

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

Ozz
источник
1
Что такое "битва с булочками"? :)
Марси
1
+1 Я очень тесно сотрудничаю с руководителем отдела контроля качества в моем текущем проекте и считаю, что это чрезвычайно полезно для моей продуктивности. Мне повезло, что он также является полностью квалифицированным разработчиком, и он часто предлагает решения обнаруженных им дефектов.
Адам Кроссленд
1
булочка в бою = борьба за булочки .... булочка = торт
ozz
2
Торт - единственное, за что стоит бороться в моем офисе.
JeffO
2
.... есть торт?
Дэн Рэй
4

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

FrustratedWithFormsDesigner
источник
2
+1 - и я хотел бы дать ему +1000. Разработчики хороши в создании программного обеспечения, но часто не являются экспертами в использовании того, что они создают. Когда вы разработчик, который находится под угрозой исправления ошибки, и в отчете об ошибке нет четких, простых для выполнения инструкций по воспроизведению, а тестер, подготовивший отчет, недоступен, жизнь - это ад - и это правда выполняете ли вы Agile или любую другую методологию. Напишите свои сообщения об ошибках, как будто ваша бабушка должна была сделать воспроизведение, и жизнь будет хорошей.
Боб Мерфи
4

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

Рейчел
источник
1
Было ли нарушение HR в конце?
Работа
Нет не было нарушения прав человека как такового.
Рэйчел
3

Поскольку вы заявили, что являетесь единственным тестировщиком в Agile-среде (с учетом Scrum), возможно, можно использовать ретроспективную встречу в качестве открытого форума для определения процесса общения.

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

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

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

Аарон Макивер
источник
2

Я предпочитаю видеть тестеров как часть одной команды. В связи с этим нет проблемы общения.

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

Однако обе стороны должны уважать друг друга и выполнять свою работу должным образом.

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

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

Профессиональный подход - это все, что нужно.


источник
«Я предпочитаю видеть тестеров в составе одной команды. В этом отношении нет проблемы общения». Нахождение в одной команде не означает, что проблемы со связью не возникнут.
Аарон Макивер
1
@ Аарон: Ты прав. Однако , если вы решите увидеть тестировщиков в качестве нижнего слоя под ваши вопросы связи ноги будут возникнуть гарантировано.
... Я беру такт ... "Ты сегодня обнял тестера?" Он творит чудеса.
Аарон Макивер
2

Я обнаружил, что инструмент номер 1, который я, как тестировщик (SDET), могу использовать для улучшения отношений между разработчиками и тестами, - это честная лесть, особенно в форме поиска наставничества у разработчиков.

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

Предоставление положительных отзывов о качестве, а также отрицательных отзывов и просьб о совете меняет отношения от спорных к командной работе и взаимному обучению и снижает обороноспособность. Разработчики знают, что они могут доверять мне всегда говорить больше хорошего, чем плохого, поэтому они чувствуют себя комфортно, слушая меня. Кроме того, задание проницательных вопросов о разработке повышает их мнение обо мне и ломает стереотип «SDET - неудачные разработчики» (где он все еще существует).

Этель Эванс
источник
2

Я твердо верю, что хорошее общение между разработчиками и тестировщиками имеет решающее значение. Что касается лучшего способа сделать, я уверен, что есть много хороших подходов, но вот то, что сработало лучше для меня.

Прямое / Личное общение! Я обнаружил, что личное, а не электронное письмо, общение всегда работает лучше всего. Это позволяет разработчику и тестеру формировать личные отношения. Как только у вас это получается, кажется, что все работает лучше и имеет тенденцию течь. У них никогда не будет проблем с проведением специального теста или прохождением дополнительной мили для вас. То же самое относится и к разработчику, и я всегда трачу дополнительное время на то, чтобы взглянуть на вещи, по которым им нужна помощь или с которыми возникают проблемы. По моему опыту, это ускоряет решение проблем, тратит меньше времени.

barrem23
источник