Как вы решаете, является ли проблема с QA дефектом?

Question

Я работал в нескольких компаниях как разработчик и недавно перешел на автоматизацию QA в новой компании. Каждая компания отличается, и мне еще предстоит увидеть способ справиться с этим, что мне действительно нравится. Слишком часто QA говорит, что что-то является проблемой, и ответ «хорошо, но это слишком сложно и слишком долго исправлять», или «это не ошибка, это особенность!».
Кто-нибудь нашел разумный способ определить, должно ли быть исправлено то, что говорит QA, ошибка?

Answer 1

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

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

Answer 2

Как я обычно делал это, один человек (Менеджер продуктов) отвечал за определение приоритетов ошибок и новых функций. PM решили, был ли каждый элемент ошибка или новая функция, на основе следующих критериев:

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

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

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

Answer 3

Методика SCRUM дает ответ на этот вопрос. Владелец продукта решает, что что-то является ошибкой, которая создает элемент в списке отставаний продукта. Затем элемент назначается на итерацию в зависимости от ее приоритета.

Answer 4

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

Answer 5

существует несколько способов. некоторые из них:

1. Требования к программному обеспечению должны быть полностью описаны.Если вы видите, что некоторые требования не выполняются, это, очевидно, ошибка.

2. Вы видите, что это требование выполняется, но в некоторой неочевидной форме. Это тоже ошибка. Но это ситуация, когда разработчик может сказать «все в порядке» и попытаться закрыть ошибку. Вы можете найти свое мнение (этот дефект существует):

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

3. Вы видите, что что-то работает, но может быть улучшено. Это тоже дефект :). Это похоже на пункт 2, и все рекомендации, представленные там, также полезны для этого случая.

P.S. и обсуждать, обсуждать, обсуждать с людьми из других отделов.