많은 사람들이 내가 일하는 곳에서 비난 게임을하는 것처럼 보입니다. 흥미로운 질문이 제기됩니다.테스트 케이스 테스터, 개발자, 고객의 디자인과 책임
한 과학적 :
요구 사항 팀은 제품에 대한 요구 사항을 기록합니다. 개발자는 요구 사항에 따라 자체 단위 테스트를 만듭니다. 테스팅 팀은 요구 사항에 따라 테스트 조건, 테스트 디자인 및 테스트 사례를 생성합니다.
테스트 팀의 테스트 사례 중 X %가 통과 한 경우에만 출시됩니다.
배달 고객은 수용 테스트를 수행합니다. - 고객 대응 팀이 현장에서 버그를 가져오고 테스트 팀에 이러한 문제를 알릴 수 있습니다.
질문 :
고객이 비난하는 결함을 많이 신청 끝나는 경우? 테스트 팀이이를 다루지 않았습니까? 아니면 더 나은 요구 사항을 작성하지 않은 요구 사항 팀입니까? 그리고 시스템을 개선하는 방법은 무엇입니까?
"테스트 팀 패스의 테스트 케이스 중 X %가 출시 된 경우에만 출시되는 제품"이라는 문장은 실제로 저를 괴롭게합니다. 팀은 단순히 시험 합격률 이상을 기준으로하는 더 나은 릴리스 기준을 고려할 수 있습니다. 예를 들어, 시나리오가 알려지고, 이해되고, 설명되고 (테스트 된) 있습니까? 물론 모든 버그가 수정되는 것은 아니지만, 연기되거나 수정되지 않은 버그가 올바르게 선별 된 것입니까? 스트레스 테스트 및 성과 목표에 도달 했습니까? 잠재적 인 위협에 대한 완화를 모델로 삼아 위협을 감수하고 있습니까? x 개의 고객 (내부/외부)이 빌드를 배포하고 출시 전에 의견 (예 : "dogfood")을 제공 했습니까? 개발자는 현장에서 오는 버그와 테스터가 회귀 단위 테스트를 만드는 것을 이해합니까? 시나리오가 왜 설명되지 않았는지 확인하기 위해 요구 사항 팀이 이러한 버그를 이해하고 있습니까? 스펙, 개발 또는 테스트에서 설명되지 않은 기능간에 핵심 통합 지점이 있습니까?
팀에 대한 몇 가지 제안은 발견 된 문제에 대한 사후 검토를 수행하고 파산 된 위치를 이해하고 가능한 한 품질을 업스트림에 올려 놓는 것입니다. 요구 사항 팀, 개발자 및 테스터가 계획, 개발 및 테스트 사이클 전반에 걸쳐 자주 의사 소통을 통해 모든 사람이 같은 페이지에 있는지 확인하고 누가 무엇을하고 있는지 알도록하십시오. 개발하는 동안 사람들이 실제로 서로 이야기 할 때 얼마나 많은 제품 품질을 얻을 수 있는지 놀라실 것입니다.
+1 - 통신 문제는 거의 모든 주요 결점의 근원에 있습니다. 첫 번째 문장은 –
+1입니다. 그것은 정말로 나를 괴롭혔다. –
버그는 요구 사항과 개발 단계 모두에서 시스템에 입력 할 수 있습니다. 요구 사항 팀은 요구 사항을 만들 때 실수를하거나 과도하게 단순화 할 수 있으며, 개발자는 요구 사항을 잘못 해석하거나 자신의 가정을 할 수 있습니다.
개선하기 위해 고객은 개발이 진행되기 전에 요구 사항을 승인해야하며, 상황을 올바른 방향으로 진행하기 위해 개발 모니터링에 어느 정도 관련되어 있어야합니다.
내 생각에 첫 번째 질문은 "결함이 요구 사항에 어떻게 겹 칩니까?"입니다.
"OK 버튼이 파란색이어야하고 결함이"OK 버튼이 녹색 "인 경우, 개발 및 테스트 비난을하고 요구 사항을 읽지 마십시오. 반면, 불만 사항이 "OK 버튼이 노란색이 아님"이라면 명확하게 요구 사항 수집 또는 변경 제어 프로세스에 문제가 있습니다.
이 질문에 대한 쉬운 대답은 없습니다. 시스템은 프로세스에 관련된 모든 사람들간에 책임이 분산되어있는 많은 결함을 가질 수 있습니다. 결국 "결함"은 "충족되지 않은 고객 기대"를 말하는 또 다른 방법 일뿐입니다. 기대는 그 자체로 항상 올바른 것은 아닙니다.
"테스트 팀 패스 중 테스트 사례의 X % 만 허용되는 경우에만 출시되는 제품"- 출시 기준 중 하나입니다. 이 경우 서면 기술위원회의 "테스트 커버리지"는 매우 중요합니다. 어떤 기능이나 시나리오가 누락되었거나되지 않았는지 TC의 좋은 검토가 필요합니다. 최우수 사용자 (TC)에 누락 된 것이 있으면 테스트 케이스에서 요구 사항 중 일부가 다루어지지 않아서 버그를 발견 할 수 있습니다.
또한 TC의 버그를 찾아내는 데 필요한 예비 테스트뿐만 아니라 예비 테스트가 필요합니다. 또한 테스트를 위해 "종료 기준"을 정의해야합니다.
고객/클라이언트가 버그/결함을 발견하면 다음과 같이 조사해야합니다. i) 발견 된 버그 유형은 무엇입니까? ii) 그와 관련하여 작성된 테스트 케이스가 있습니까? iii) 제대로 실행 된 것과 관련된 테스트 케이스가 있다면? iv) TC가 결석 한 이유는 무엇입니까? 등등
누가 비난 받아야하는지 조사한 후 결정을 내릴 수 있습니다. 그것이 매우 간단하고 눈을 감은 버그/결함이라면 확실히 테스터들이 비난 받아야합니다.
또는 제품을 출시 한 후 원하는 내용에 대해 마음을 바꾸는 것이 고객입니까? –
고객의 결함의 심각성은 무엇입니까? 이들이 몇 가지 사소한 문제라면, 언급 한 바와 같이 고객이 마음을 바꿀 수 있습니다. 그러나 이들이보고되지 않는 주요 버그 인 경우 테스트 케이스가 충분한 범위를 제공하지 못한다고 생각하게됩니다. P. "X % of testcases"를 읽는 것이 유일하게 사용 된 측정 항목 인 경우 걱정할 것입니다. 바라건대, 실패한 테스트의 심각성도 고려됩니다. –
@Michael, 좋은 통화 커버 - 아래에 나와있는 출시 기준 기준의 일부로보고 싶었습니다. 단위 테스트 레벨 및 테스트 케이스 레벨의 적용 범위를 살펴보면 테스트되지 않은 항목, 올바른 경로가 테스트되는 경우 및 발견 된 고객 버그가 위의 두 가지 범주에 속하는 경우를 이해하는 것이 좋습니다. – nithins