저는 여러 회사에서 개발자로 일했으며 최근에는 새로운 회사의 품질 보증 자동화로 옮겼습니다. 각 회사는 다르고 나는 이것을 정말로 내가 좋아하는 것으로 취급하는 방법을보아야한다. 너무 자주 QA가 문제가되고 응답이 "잘되었지만 너무 어려워 고칠 시간이 오래 걸릴 것"또는 "버그가 아니라 특징입니다!"라고 QA가 말합니다.
누군가 QA에서 버그를 수정해야하는지 여부를 결정하는 합리적인 방법을 찾았습니까?품질 보증 문제가 결함인지 어떻게 결정합니까?
개발자가되면 QA에서 맹세를하게하는 버그가 있다는 것을 알고 있습니다.하지만 개발자가 수정 프로그램을 수정해야한다고 생각하지 않습니다. 당신이 언급하는 변명에 의해 입증! 프로그래머 중 가장 겸손한 사람은 자신의 코드에 버그가 있다는 점을 불만스럽게 느껴서 어려움을 겪을 수 있습니다. 테스터와 개발자 간의 약간의 마찰이 필요한 악이라고 생각합니다. (하루가 끝날 때 맥주를 사주세요!) '그것은 기능이라는 버그가 아닙니다.'는 일반적인 말다툼이지만 때로는 유효합니다. 아마도 중요한 사람이 참여하는 것이 아마도 당신이하는 일에 의미가있는 경우 비즈니스 측면의 누군가 일 것입니다.
내 경험에 비추어 볼 때, 지금 당장은 고칠 수는 없지만 기록할만한 가치가 있습니다. 슬라이딩 우선 순위 배율을 지정하고 특정 수준까지만 수정하면됩니다. 테스터/dev과 함께 정기적으로 버그를 검토하면 도움이 될 것입니다.
내가 사용했던 방식은 한 사람 (제품 관리자)이 버그와 새로운 기능의 우선 순위를 결정하는 것이 었습니다. 오후 각 항목은 버그의 새로운 기능은 다음과 같은 기준에 따라 여부 결정 : 소프트웨어 단지 분명히 잘못 무언가를
PM은 고객의 대표자뿐만 아니라 엔지니어링 담당자와 함께 각 버그 또는 기능 요청을 논의하고 그 기준 (상식 및 경험은 물론)이 각 항목에 우선 순위를 부여합니다. 또한 엔지니어링 팀은 각 항목에 대략적인 시간 척도를 표시하도록 요청할 것이며 PM은이를 사용하여 다음 반복을 계획합니다.
간단히 말해서, 소프트웨어가 의도 한 작업을 소프트웨어가 수행하지 못하고 기능 요청이있는 경우 소프트웨어가 계획되지 않은 작업을 수행하기를 바라는 경우입니다.
SCRUM 방법론은이 질문에 대한 대답을 제공합니다. 제품 소유자는 제품 백 로그 목록에 항목을 만드는 버그가 있는지 결정합니다. 그런 다음 항목의 우선 순위에 따라 반복되도록 예약됩니다.
기능 버그와 UI 버그를 쉽게 찾고 논쟁의 여지가 없습니다. 디자인 버그는 의견을 얻기 위해 학사 및 개발 팀을 통과해야하는 버그입니다. 또한 환경 관련 문제는 별도로 추적해야하며 버그 범주에 속하지 않을 수도 있습니다.
다양한 방법이 있습니다. 일부 :
소프트웨어 요구 사항을 완전히 설명해야합니다.어떤 요구 사항이 충족되지 않는다는 것을 알게되면 분명히 버그입니다.
해당 요구 사항이 충족되었지만 일부 명백하지 않은 형식으로 표시됩니다. 그것은 역시 버그입니다. 그러나 이것은 개발자가 "모두 괜찮습니다"라고 말하면서 버그를 닫으려고 할 때의 상황입니다. 다음과 같은 방법으로 귀하의 의견 (결함이 있음)을 발견 할 수 있습니다.
효과가 있지만 개선 될 수 있습니다. 그것은 너무 결함 :)입니다. 그것은 포인트 2와 유사하며 모든 권장 사항은이 경우에도 유용합니다.
P. 다른 부서의 사람들과 토론하고 토론하고 토론하십시오.
제니퍼가 옳다면, 항상 이런 종류의 결정을 내릴 수있는 역할을 맡을 수있는 사람이 있어야합니다. 테스터가 아니라 개발자. 그것은 분석가, 팀 리더가 될 수 있습니다. 가능성은 거의 없습니다. 기껏해야 코드에 연결되지 않았거나 테스트하지 않은 사람, 고객과 이야기 할 수있는 사람. – yoosiba