Как я могу сделать свои отношения с QA менее состязательными?

Question

На протяжении всей моей карьеры у меня были разные успехи, связанные с QA. Я признаю, что могу принимать отчеты об ошибках лично, но обычно, когда они обрабатываются в стиле произвольной формы, который сформулирован больше как жалоба: «Этот процесс все еще не работает!», Без достаточного количества информации для воспроизведения дефекта.

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

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

Answer 1

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

2. Никогда не принимай это на свой счет. Я постоянно получаю сообщения об ошибках, как через нашу систему отслеживания ошибок, так и через личные контакты. Независимо от их тона, я всегда отвечаю: «Спасибо, что поймали это, я посмотрю на это». У них может быть плохой день, у вас может быть плохой день, кто знает? Если они не предоставляют достаточно информации для воспроизведения и не предоставляют эту информацию на достаточно последовательной основе, см. # 1 (получите реальный рабочий процесс и придерживайтесь его).

Answer 2

Забудьте инструменты. Речь идет об общении. Вам нужны люди, у которых есть дисциплина, чтобы точно сказать вам, что не так, как они туда попали, и любые конкретные условия, которые привели к этому событию. Вы также должны быть в состоянии дать обратную связь, когда люди пишут что-то вроде «Это сломано». Управление развитием и QA должно говорить о том, что нужно с обеих сторон.

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

Answer 3

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

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

Я видел, что разработчики часто испытывают проблемы с принятием ошибок лично, что приводит к тому, что они отбрасываются как «неважные», «крайние случаи», «по назначению» и т. Д., Когда проблема действительно является проблемой. , Даже если проблема на самом деле не важна, просто поделитесь своей оценкой риска / вознаграждения при исправлении ошибки, чтобы улучшить взаимодействие.

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

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

Answer 4

Я оставлю рекомендации по инструменту кому-то еще, поскольку то, что мы используем, не "бесплатно, как в пиве".

Ваша первоочередная задача должна заключаться в том, чтобы развивать способность отрываться от процесса. Это не может быть личной проблемой. При этом, попробуйте связаться с QA (лично или через CoC), что редактирование в отчетах об ошибках контрпродуктивно («Этот процесс все еще не работает!», Как вы написали, не помогает). Цель процесса - повысить качество конечного продукта. Такие восклицания не способствуют достижению этой цели.

Answer 5

Как и разработчики, QA имеет (или должно иметь) минимальные стандарты, которых необходимо придерживаться. При постановке вопроса им необходимо предоставить:

• повторяемый контрольный пример;
• скриншот; или
• описание проблемы и любой картины, если она противоречива или не воспроизводима.

Если мне нужно пойти в QA и спросить, в чем проблема или как они ее вызвали, меня раздражает. «Это не работает» просто недостаточно хорошо.

В одной из разработанных мной систем (система веб-отчетности) я генерировал все входные данные для каждого сгенерированного отчета. Когда QA запустило отчет и обнаружило проблему, они могли перейти на скрытый URL-адрес и скачать ZIP-файл, содержащий:

• определение отчета;
• используемый шаблон; и
• любой ввод базы данных.

Со стороны разработчика я написал инструмент, который мог бы перезапустить отчет, основываясь только на этом ZIP-файле. Это имело несколько эффектов:

• Если QA поднимает проблему, я могу сказать: "Где ZIP-файл?";
• Как только они вошли в привычку, стало намного легче поднимать вопрос; и
• Проблемы были тривиальны для воспроизведения и повторного тестирования разработчиками.

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

Итак, мой совет для гармоничной работы с QA сводится к:

• использовать систему отслеживания проблем. Это абсолютный приоритет №1. Все нуждается в контрольном журнале;
• есть кто-то, кто отвечает за обеспечение качества и отвечает за команду. Они могут решать проблемы с недостаточной детализацией, представленной в вопросах, связанных с QA. Вместо того, чтобы идти к каждому тестеру, идите к этому человеку и дайте ему разобраться с этим так, как он считает нужным. Во-первых, это должно привести к согласованию стандартов;
• предоставляет QA как можно больше инструментов и средств диагностики, чтобы облегчить им жизнь. Это тоже облегчит вашу жизнь;
• не судите разработчиков и QA по проходным баллам. Даже не производите такую ​​статистику. Они ведут к конфликтной, а не совместной среде. Вы (или должны быть) все в одной команде;
• проводят еженедельные встречи по дефектам между QA, разработкой и руководством проекта, чтобы обсудить последние, решенные и нерешенные проблемы на более макроуровне. Это может быть полезно как для точки зрения отслеживания проекта, так и для понимания основных проблем или проблемных областей, которые могут у вас возникнуть.

Answer 6

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

• не принимайте вещи на свой счет
• будь благодарен, что они нашли проблему до того, как твой босс или клиент ее нашли
• прийти к отношениям с уважением к тестерам; подумайте о том, что они добавляют в этот процесс разработки
• выразите свое разочарование способами, которые могут быть приняты лучше:

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

Я в замешательстве о том, как его воспроизвести. У тебя есть есть идеи? или больше информации? "

• Помните, что вы в одной команде:

Ух ты, тот отчет об ошибке, который ты написал, был действительно великолепен. Это сэкономило мне кучу времени на локализацию ошибки. Спасибо!

Хотите пойти на пиво? Пиво, как в бесплатном?

и т.д.

Answer 7

Читать "Работа с тобой убивает меня!" Поймите, что люди просто хотят пережить день, заработать доллар и пойти домой. «Не парься по мелочам».

Answer 8

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

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

Я полностью не согласен с сообщением, которое отправляет AnthonyWJones. Я понимаю, что у каждой компании есть своя собственная культура, но то, как он сформулировал свой ответ, говорит о том, что «брось это на стенку, QA отвечает за качество, а не я». В этом нет ничего плохого, но это не поможет, если вы хотите создать благоприятную и дружескую атмосферу. Более здоровая культура - это та, в которой вся команда разработчиков (включая QA) несет равную ответственность за качество.

Answer 9

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

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

Сообщение об ошибке, отправленное по почте или поданное в каком-либо багтрекере, может быть оскорбительным в том виде, в каком оно сформулировано, и, несомненно, так и будет, поскольку оно указывает пальцем на «вашего ребенка», ваше творение. Поговорите с человеком, регистрирующим ошибку, и вы можете заметить общую цель: сделать мир / программное обеспечение немного лучше.

Мое отношение к QA окупилось тем, что оно стало отношением взаимного уважения (хотя никто из нас не признал бы это: P), вместо того, чтобы кричать «не ошибка», я сначала подошел бы к ним. Вместо того, чтобы сразу утверждать, что что-то было ошибкой, они сначала шли ко мне. В конце концов, мы все делаем свою работу. Программисты пишут программное обеспечение, а инженеры QA - пробивают дыры в этом программном обеспечении. И я очень благодарен за то, что работал с очень яркими людьми, которые рассказывали мне, что я сделал не так.

О, и никогда никогда не используйте фразу "Это не ошибка, это особенность".

Answer 10

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