3 worst defect reporting habits
결함은 심각한 비즈니스이며 작은 실수는 비용이 많이들 수 있습니다.
결함을 발견하면 어떻게해야하는지 알고 있습니다. 당신은 그것을보고합니다. 어느 쪽이든 결함 추적기 / 결함 관리 도구 또는 Excel 시트. 기본 원칙은 두 방법 모두 동일합니다.
결함 관리 도구는 더 나은보고를 보장하지 않습니다. 하루를 구하는 것은 좋은 습관입니다.
좋은 점을 인식하려면 그렇지 않은 점을 인식해야합니다.
학습 내용 :
3 가지 최악의 결함보고 습관과이를 깨는 방법
여기에 간다 :
# 1) 게으름
최선을 다하기 위해 시간을 할애하지 않습니다.
이것이 결함 추적 프로세스 대부분의 팀에서 따랐습니다.
(노트– 확대 된 이미지를 클릭)
보시다시피 테스트 리드는 결함을 QA 팀에서 보내기 전에 검토합니다.
이 검토에는 다음 사항이 포함됩니다.
- 유효성-버그입니까?
- 완전성-제목, 단계, 데이터, 스크린 샷 등
- 중복
- 재현 가능 여부 ... 등.
QA 리드가 100 % 철저한 것은 불가능하다는 것을 직접 알고 있습니다.
그래서“내가 원하는 방식으로 문제를보고하겠습니다. QA 리드는 다시 확인할 수 있습니다. 결함이 유효한지 / 완전한지 결정할 수 있습니다.”는 QA 팀의 끝과 신뢰도입니다.
일부 클라이언트에는 허용 가능한 유효하지 않은 결함 수에 대한 SLA가 있다는 것을 알고 있습니까? 숫자가 초과되면보고 된 모든 잘못된 결함에 대해 계약자에게 벌금을 부과하기 시작합니까?
치료제: 실사를 수행하고 결과물에 대한 책임을집니다. 정보가 충분하지 않거나 버그가 아닌 결함이 다시 발생 했습니까? 항상 개발팀의 잘못이 아닐 수도 있습니다. 그들이 응용 프로그램의 문제를 소유하고 싶어하지 않는 것은 아닙니다. 진정한 QA 팀 엉망 일 수 있습니다. 그렇게하지 마십시오.
# 2) 러싱
이 작업을예.
아래는 스크린 샷입니다. OpenEMR 환자 생성 화면. 오픈 소스 병원 관리 시스템입니다.
이 화면에서 사용자는 달력 기능을 통해 환자의 생년월일을 입력 할 수 있습니다. 하지 않는 것은 항목을 달력에서 선택하도록 제한하는 것입니다. 내 말은 달력에서“1983 년 3 월 31 일”이라고 말하면서 생년월일을 선택할 수 있다는 것입니다. 나중에 '1983 년 2 월 31 일'로 변경합니다.
왜 2 월 31 일인가? 구현 추측 오류 현장에서 부정적인 데이터를 시도합니다. 테스트의 요점은 무엇입니까?
완료되면“Create Patient”를 클릭합니다. 날짜가 유효하지 않기 때문에 시스템에 오류가 표시되고 환자가 생성되지 않을 것으로 예상됩니다. 그러나 그것은 일어나지 않습니다. 아래와 같이 환자를 생성합니다.
아래 화면에서 연령 및 생년월일 필드를 확인합니다.
테스트 할 때이를 몇 번 시도하고 다음을 결정할 수 있습니다.
- 버그입니다.
- 재현 가능합니다.
- 중복이 아닙니다 (팀에 확인하여 확인)
- 문제에 대한 정확한 설명을 알고 있습니다.
- 또한이를 발생시키는 정확한 단계를 알고 있습니다.
이제 원자재가 준비되었으므로 갈 수 있습니다.
신고를 시작합니다. 결함 심각도를 지정하는 것은 필수 단계이며 팀은 다음과 유사한 것을 사용할 수 있습니다. 참고를위한 뒤에 오는 표 :
| 심각성 | 타격 |
|---|---|
| 1 (중요) | •이 버그는 시스템을 손상 시키거나 파일 손상을 일으키거나 잠재적 인 데이터 손실을 유발할만큼 매우 중요합니다. • 운영 체제로 비정상적으로 복귀합니다 (충돌 또는 시스템 오류 메시지가 나타남). • 이로 인해 응용 프로그램이 중단되고 시스템을 다시 부팅해야합니다. |
| 2 (높음) | • 해결 방법으로 중요한 프로그램 기능이 부족합니다. |
| 3 (중간) | •이 버그는 시스템의 품질을 저하시킵니다. 그러나 원하는 기능을 달성하기위한 지능적인 해결 방법이 있습니다 (예 : 다른 화면을 통해). •이 버그로 인해 제품의 다른 영역이 테스트되지 않습니다. 그러나 다른 영역은 독립적으로 테스트 할 수 있습니다. |
| 4 (낮음) | • 제품 사용에 미치는 영향을 최소화하는 불충분하거나 불분명 한 오류 메시지가 있습니다. |
| 5 (화장품) | • 제품 사용에 영향을주지 않는 불충분하거나 불분명 한 오류 메시지가 있습니다. |
이 결함은 시스템을 손상 시키거나 중요한 기능을 차단하거나 응용 프로그램의 다른 영역을 테스트하지 못하게하는 것이 아니므로 '낮음'으로 이동할 수 있습니다.
맞죠?
잘못된. 환자의 데이터에서 모든 예방 접종 및 기타 알림이 기한이 지났습니다. 이것은 옳을 수도 있고 아닐 수도 있습니다. 또한 환자의 경우 나이가 소아과 의사 또는 일반 의사 등을 만나는 지 여부를 결정합니다.
그것은 우리가 알지도 못하는 약의 복용량과 다른 많은 치료 영역에 영향을 미칩니다.
그래서 저는“High”로 갈 것입니다. 병원 직원이 환자의 DOB를 잘못 입력 할 가능성은 거의 없다는 데 동의합니다. 그러나 이것이 문제 해결시기의 우선 순위에 영향을 미치는 요인이되도록하십시오.
테스터로서의 나의 임무는 가능한 한 문제의 심각성을 최대한 전달하도록하는 것입니다.
치료제: 서둘러 신고하지 마세요. 다양한 각도에서 문제의 영향을 100 % 확실히 이해해야합니다. 테스터가 제공 할 수있는 최고의 부가가치입니다. 우리는 단지“뭔가 작동하지 않는다”고 말하는 것이 아닙니다. 우리는 또한 '이것이 계속 작동하지 않으면 일어날 일이 있습니다.'라고 말합니다. 엄청나게 다르죠?
# 3) 창의력 부족
테스터는 소프트웨어 개선을위한 제안을 할 수있는 멋진 기회를 가지고 있습니다.
당신의 결함 관리 도구 또한 '향상 제안'유형의 결함을 제출할 수 있습니다. 창의력을 발휘할 수있는 곳입니다.
치료제: 상자 밖에서 생각하십시오. 특정 기능에 '와우'요소가 누락되었다고 생각하고이를 적용하는 방법을 알고 있다면 아이디어를 제시하십시오. 최악의 경우 거부 될 수 있으며 괜찮습니다. 중요한 부분은 노력입니다.
또한이 슈퍼 파워를주의해서 사용하십시오. '배너 색상이 싫습니다. 변경해주세요.'와 같은 코멘트를하지 마십시오.
여기에 좋은예내가 발견 한 개선 제안 : 자동차 대리점 사이트에서 '대리점에게 이메일 보내기'를 '대리점과 채팅'옵션으로 대체합니다. 더 많은 트래픽을 매출로 전환 할 것으로 예상됩니다.
내가 그렇게 창의적 이었으면 좋겠다! 그러나 아마도 우리 모두는 그것을 위해 노력할 수 있습니다.
여기에 보너스가 있습니다. 이러한 나쁜 습관을 없애기위한 체크리스트 :
1. 내 제목이 문제를 명확하고 간결하게 전달합니까?
예를 들면 :“Create Patient is not working”은 좋은 제목이 아닙니다. '모든 입력 필드에 올바른 값이 포함되어 있어도 환자 생성이 실패합니다'입니다.
두. 재현성 비율은 얼마입니까?
즉, 항상 발생합니까? 문제를 반복 할 정확한 단계 순서를 알고 있습니까?
삼. 이 문제가 플랫폼, 브라우저 또는 사용자 특정입니까?
네. 단계가 완료되어 문제가 발생합니까?
5 . 스크린 샷이 포함되어 있습니까?
6. 특정 영역을 강조하기 위해 스크린 샷에 주석을 달아야합니까?
7. 첨부 된 이미지 파일의 이름이 설명 적입니까?
'Untitled.jpg'와 같은 것을 사용하지 마세요. 설명이 포함 된 이름을 지정하십시오.
8. 테스트 데이터를 포함 했습니까?
예를 들면 :인증 자격 증명이 필요한 관리 모듈의 결함에 대해서는이를 포함합니다. 개발 팀은 QA 환경에 대한 액세스 권한이있을 수도 있고 없을 수도 있습니다. 당신은 그것만큼 기본적인 것에 지연과 후속 조치를 원하지 않습니다.
9. 결함을 강화하기 위해 다른 세부 정보를 제공 할 수 있습니까?
(예:FRD에 대한 참조 또는 클라이언트와의 대화 등)
10. 다른 관점에서 문제가 얼마나 심각한 지 이해하고 있습니까?
열한. 문제의 근본 원인을 알고 있습니까? 그렇다면 증거 (로그 파일 일 수 있음)가 있고이를 포함 할 수 있습니까? 항상 이것을 알고 있거나 알아야하는 것은 아닙니다. 하지만 그렇게한다면 그것을 포함해도 나쁘지 않습니다.
12. 결함 보고서에 문법, 형식, 철자 및 구두점 문제가 없습니까?
소프트웨어 테스트의 테스트 케이스 형식
13. 제품을 개선 할 수있는 방법을 알고 있습니까?
시간이 많이 걸린다고 생각하십니까? 음, 일단 습관이되면 더 이상되지 않을 것입니다.
더 나은 응원 결함보고 루틴!
저자 정보 : 이 기사는 STH 팀원 Swati가 작성했습니다.
아래에 질문 / 의견을 게시하십시오.