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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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