Как я могу сделать свои отношения с QA менее состязательными?
На протяжении всей моей карьеры у меня были разные успехи, связанные с QA. Я признаю, что могу принимать отчеты об ошибках лично, но обычно, когда они обрабатываются в стиле произвольной формы, который сформулирован скорее как жалоба: "Этот процесс все еще не работает!", Без достаточного количества информации для воспроизведения дефекта.
Я готов работать над своей чувствительностью к критике, но мне также будут интересны инструменты и методы, которые обезличивают процесс обеспечения качества и поощряют информативные сообщения об ошибках. В настоящее время об ошибках сообщается по электронной почте или иногда путем их подбора и вербализации.
Любые инструменты должны быть: бесплатными, как в пиве, и простыми в установке / минимальными в администрировании. Я также открыт для сообщений в блогах, книгах или статьях о том, как уменьшить чувствительность к сообщениям об ошибках.
14 ответов
Получить реальную систему отслеживания ошибок. FogBugz, Bugzilla, что угодно (я не сторонник Spolsky, но я скажу, что FB - самая простая в использовании система для наших тестеров, и простая в использовании действительно важна для них). Это значительно упрощает определение процессов QA и рабочих процессов отчетов об ошибках. Это должно помочь сделать менее личным взаимодействие между вами и вашими тестерами.
Никогда не принимайте это на свой счет. Я постоянно получаю сообщения об ошибках, как через нашу систему отслеживания ошибок, так и через личные контакты. Независимо от их тона, я всегда отвечаю: "Спасибо, что поймали это, я посмотрю на это". У них может быть плохой день, у вас может быть плохой день, кто знает? Если они не предоставляют достаточно информации для воспроизведения и не предоставляют эту информацию на достаточно последовательной основе, см. #1 (получите реальный рабочий процесс и придерживайтесь его).
Забудьте инструменты. Это насчет общения. Вам нужны люди, у которых есть дисциплина, чтобы точно сказать вам, что не так, как они туда попали, и какие-либо конкретные условия, которые привели к этому событию. Вы также должны быть в состоянии дать обратную связь, когда люди пишут что-то вроде "Это сломано". Управление развитием и QA должно говорить о том, что нужно с обеих сторон.
Что касается чувствительности, я обнаружил, что такое отношение превосходит все. Каждый раз, когда вы видите сообщение об ошибке, вы должны начинать с позиции: "Это не личная атака; это возможность решить проблему и узнать что-то". После того, как вы настроитесь, ваши ответы будут следовать.
Как специалист по обеспечению качества, который в основном является разработчиком (автоматизированное регрессионное тестирование), я думаю, что смог увидеть обе стороны этой проблемы.
Как заявили несколько других, это проблема коммуникации, и никакой инструмент не решит ее. Такие инструменты, как bugzilla, повышают эффективность общения, но они все еще требуют, чтобы обе стороны работали над тем, чтобы поддерживать линии связи открытыми.
Я видел, что разработчики часто испытывают проблемы с принятием ошибок лично, что приводит к тому, что они отбрасываются как "неважные", "крайние случаи", "по назначению" и т. Д., Когда проблема действительно является проблемой. Даже если проблема на самом деле не важна, просто поделиться своей оценкой риска / вознаграждения в исправлении ошибки поможет улучшить взаимодействие.
Наоборот, ребята из QA часто пропускают детали ошибки и шаги по ее воспроизведению (включая меня). Когда вы, как разработчик, сталкиваетесь с отсутствующими деталями, ваша задача - попросить нас предоставить более подробную информацию (и, пожалуйста, спрашивайте нас любезно и быстро). Хуже всего, когда вы пишете ошибку и отправляете ее разработчику, а затем ничего не слышите в течение нескольких дней, и она закрывается как "Невозможно воспроизвести".
В итоге ключом является оперативный и добрый отзыв с обеих сторон. Если я (в QA) работаю с разработчиком, который всегда отвечает, когда я отправляю ему сообщение об ошибке, и, кажется, рад помочь в решении этой проблемы, я гораздо охотнее найду время, чтобы рассказать ему все возможные детали.
Я оставлю рекомендации по инструменту кому-то еще, поскольку то, что мы используем, не "бесплатно, как в пиве".
Ваша первоочередная задача должна заключаться в том, чтобы развивать способность отрываться от процесса. Это не может быть личной проблемой. При этом, попробуйте связаться с QA (лично или через CoC), что редактирование в отчетах об ошибках контрпродуктивно ("Этот процесс все еще не работает!", Как вы написали, не помогает). Цель процесса - повысить качество конечного продукта. Такие возгласы не способствуют достижению этой цели.
Как и разработчики, QA имеет (или должно иметь) минимальные стандарты, которых необходимо придерживаться. При постановке вопроса им необходимо предоставить:
- повторяемый контрольный пример;
- скриншот; или же
- описание проблемы и любой модели, если она противоречива или не воспроизводима.
Если мне нужно пойти в QA и спросить, в чем проблема или как они ее создали, я раздражен. "Это не работает" просто недостаточно хорошо.
В одной из разработанных мной систем (система веб-отчетности) я генерировал все входные данные для каждого сгенерированного отчета. Когда QA запустило отчет и обнаружило проблему, они могли перейти на скрытый URL и скачать ZIP-файл, который содержал:
- определение отчета;
- используемый шаблон; а также
- любой вход в базу данных.
Со стороны разработчика я написал инструмент, который мог бы перезапустить отчет, основываясь только на этом ZIP-файле. Это имело несколько эффектов:
- Если бы QA подняло проблему, я мог бы сказать "где ZIP файл?";
- Как только они вошли в привычку, стало намного легче поднимать проблему; а также
- Проблемы были тривиальны для воспроизведения и тестирования разработчиками.
Эффект был глубоким, и я думаю, что это подчеркивает одну ключевую проблему: разработчикам не нравится, когда что-то трудно тестировать, сложно воспроизвести и так далее. Точно так же людям, отвечающим за обеспечение качества, не нравится то, что усложняет их работу, и им нравится то, что облегчает их работу.
Поэтому мой совет для гармоничной работы с QA сводится к:
- использовать систему отслеживания проблем. Это абсолютный приоритет №1. Все нуждается в контрольном следе;
- есть кто-то, кто отвечает за обеспечение качества и отвечает за команду. Они могут решать проблемы с недостаточной детализацией, представленной в вопросах, связанных с QA. Вместо того, чтобы идти к каждому тестеру, идите к этому человеку и дайте ему разобраться с этим так, как он считает нужным. С одной стороны, это должно привести к последовательным стандартам;
- предоставить как можно больше инструментов и средств диагностики для обеспечения их жизни. Это сделает вашу жизнь проще;
- не судите разработчиков или QA по оценкам проходов. Даже не производите такую статистику. Они приводят к конфликтной, а не совместной среде. Вы (или должны быть) все в одной команде;
- проводить еженедельные встречи по дефектам между QA, разработкой и управлением проектом, чтобы обсудить последние, решенные и нерешенные вопросы на более макроуровне. Это может быть полезно как для точки зрения отслеживания проекта, так и для общего понимания любых серьезных проблем или проблемных областей, которые могут у вас возникнуть.
Я согласен с Полом Уильямсом. Похоже, процесс, который использует QA для отправки вопросов, должен быть улучшен. Электронная почта и устная коммуникация о статусе вопроса предполагают возможности для улучшения. Я также согласен с его советами разработчиков и QA, работающих вместе для улучшения процесса и общения. Я инженер по контролю качества и занимаюсь этим уже более 10 лет.
Вы звучите очень зрелым и большим опором для вас, чтобы никого не взорвать. Можно написать слова с эффектом "Он все еще сломан", но, очевидно, специалист по контролю качества должен выучить больше такта.
Я полностью не согласен с сообщением, которое отправляет AnthonyWJones. Я понимаю, что у каждой компании есть своя собственная культура, но то, как он сформулировал свой ответ, говорит о том, что "брось это на стенку, QA отвечает за качество, а не я". В этом нет ничего плохого, но это не поможет, если вы хотите создать благоприятную и дружескую атмосферу. Более здоровая культура - это та, в которой вся команда разработчиков (включая QA) несет равную ответственность за качество.
Инструменты для обезличивания кажутся мне неправильным направлением.
- не принимай вещи лично
- быть благодарным, что они нашли проблему, прежде чем ваш начальник или клиент нашел ее
- прийти к отношениям с уважением к тестерам; думать о том, что они добавляют в процесс разработки этого
- выразите свое разочарование способами, которые могут быть приняты лучше:
"Черт возьми, это действительно важный баг, который нам нужно исправить. Спасибо, что нашел его, чувак.
Я запутался в том, как воспроизвести это. Есть ли у вас какие-либо идеи? или больше информации?
- Помните, что вы в одной команде:
Вау, тот отчет об ошибке, который ты написал, был действительно великолепен. Это сэкономило мне кучу времени на устранение ошибки. Спасибо!
Хотите выйти на пиво? Пиво, как в бесплатном?
и т.п.
У меня был абсолютно лучший опыт работы с QA при совместной работе над устранением ошибок и / или их анализом. Ни программисты, ни QA-инженеры не являются самыми легкими людьми, и между этими группами существует некоторая фундаментальная напряженность.
Когда у меня возникают проблемы с сообщениями об ошибках, поданными в мой код, переходите к ним и спрашивайте, что именно они имеют в виду, и / или проводите меня по шагам, чтобы воспроизвести их. В большинстве случаев проблемы находились в несоответствии между тем, как я читал какое-то требование, и они предполагали, что это сработает. Вы говорите, как люди, не в соответствии с какой-то формулой, и вы выясняете это вместе (согласие не согласиться и позволить кому-то другому сделать звонок - вариант здесь).
Сообщение об ошибке, отправленное по почте или поданное в каком-либо багтрекере, может быть оскорбительным в том виде, в каком оно сформулировано, и, безусловно, будет так, поскольку оно указывает пальцем на "вашего ребенка", ваше творение. Поговорите с человеком, регистрирующим ошибку, и вы можете заметить общую цель: сделать мир / программное обеспечение немного лучше.
Мое отношение к QA окупилось тем, что оно стало отношением взаимного уважения (хотя никто из нас не признал бы это:P), вместо того, чтобы кричать "не ошибка", я сначала подошел бы к ним. Вместо того, чтобы сразу утверждать, что что-то было ошибкой, они сначала шли ко мне. В конце концов, мы все делаем свою работу. Программисты пишут программное обеспечение, а инженеры QA - пробивают дыры в этом программном обеспечении. И я очень благодарен за то, что работал с очень яркими людьми, которые рассказывали мне, что я сделал не так.
О, и никогда не используйте фразу "Это не ошибка, это особенность".
Читать "Работа с тобой убивает меня!" Поймите, что люди просто хотят пережить день, заработать доллар и пойти домой. "Не парься по мелочам".
Постарайтесь больше вовлекать их в процессы проекта. У нас есть регулярные ретроспективы, где QA люди получают равный голос с разработчиками. Они часто предлагают способы, которыми мы можем улучшить процессы, которые облегчают их работу и облегчают им обеспечение качества. И что более важно, эти предложения обсуждаются и (если согласованы) принимаются. Это делает QA и dev частью одного процесса, а не в противостоянии.
Для разработчиков также важно нести ответственность за свой код. Если QA обнаруживает много ошибок в области, то это потому, что разработчик сделал некрасивую работу по ее написанию. Это не потому, что QA сложно. Команда разработчиков должна все это признать.
Лучший способ, которым я нашел, чтобы обрабатывать такие утверждения, как "это не работает", - использовать подобный краткий вопрос в ответе. "Спасибо, хотя вы могли бы помочь мне, рассказав больше о том, что вы нашли?". Затем оставьте мяч на своей площадке.
Если есть жалоба, которую вы не ответили, вы можете указать свой запрос для получения дополнительной информации. Не выполняйте работу кого-то другого, задача QA - определить, что конкретно не соответствует качеству, за которое они несут ответственность.
Для меня, как для удаленного члена команды, инструменты отслеживания ошибок неизбежны. И по моему опыту они действительно помогают "обезличить" процесс.
У вас есть sharepoint (или вики и т. Д.), Где вы работаете? Было бы довольно легко настроить журнал проблем там, чтобы все могли его увидеть бесплатно. Я не собираюсь вдаваться в выбор инструментов отслеживания, их там много. Проверьте SourceForge или Codeplex, если вы хотите бесплатно.
Самая важная вещь, чтобы помочь, это определенно НЕ принимать это лично - они делают свою работу так же, как вы. Установка формата для "приемлемых" отчетов об ошибках поможет, даже с электронной почтой, которую вы используете в настоящее время.
Как минимум они должны включать:
- Природа дефекта
- Серьезность (обычно 1 - 5, где 1 "невозможно продолжить", а 5 - ошибки орфографии)
- Действия по воспроизведению.
- Скриншотов, если есть.
Любой приличный специалист по обеспечению качества должен уже делать это и тестировать сценарий.
Я не думаю, что инструменты могут вам сильно помочь.
Попросите QA написать шаги для воспроизведения проблемы, желательно начиная с
- Запустить приложение
- Нажмите...
- и т.п.
Это структурирует их мысли и поможет вам понять, что хочет сказать QA.