Как вы решаете, является ли проблема обеспечения качества дефектом? - PullRequest
4 голосов
/ 25 сентября 2008

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

Ответы [ 5 ]

5 голосов
/ 26 сентября 2008

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

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

3 голосов
/ 25 сентября 2008

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

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

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

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

1 голос
/ 26 сентября 2008

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

0 голосов
/ 26 сентября 2008

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

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

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

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

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

0 голосов
/ 26 сентября 2008

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

...