Pass? Fail?
의식의 흐름대로 만들어보는 테스트 케이스의 결과 분류
체크 리스트 결과1. Fail
결론적으로 우리는 테스트 케이스에 Pass를 만듭니다.
소프트웨어 테스트에서 QA의 주 역할은 테스트 대상 소프트웨어가 제공받은 명세서 및 기획서의 기대 결과 대로의 작동 여부 확인입니다.
개발 과정에서 의도적으로 기대 결과와 다르게 제품을 만들지 않습니다.
심지어 장치 또는 OS에 심각한 결함을 일으키는 바이러스나 멀웨어 또한 해당 소프트웨어의 기대 결과대로 작동하는 것입니다.
하지만 현실적으로 소프트웨어는 언제나 기대 결과대로만 작동하는 것은 아닙니다.
회로에 들어간 나방으로 인하여 보고된 최초의 컴퓨터 버그처럼 예상하지 못한 원인 때문에 결함이 발생할 수도 있습니다.
또한 소프트웨어의 규모는 점점 더 커지고 복잡해지고 있으며, 스마트폰의 보급으로 기존 PC환경보다 제약이 줄어든 상태로 사용자가 점점 더 많아지고 다양해지고 있습니다.
이에 따라 예기치 못한 많은 예외사항이 발생할 수 있으며, 소프트웨어 또한 사람이 만들기 때문에 실수가 있을 수 있습니다.
이로 인하여 테스트 진행 시 기대 결과와 다른 현상을 보이는 케이스를 분류하기 위해서 Fail이 필요합니다.
명세서가 없는 경우를 포함하여 일반적이고 보편적인 수준에서 사용자가 이해 가능한 기대 결과와 다르게 작동하는 경우 Fail을 사용하여 이를 구분할 수 있습니다.
2. Block
이제 테스트 케이스에 Fail을 사용해 보겠습니다.
Case_0001번 케이스에 이슈가 발생하여 하위 케이스 모두 확인 불가능으로 Fail 처리누군가 위와 같은 결과를 수령한다면
'모든 케이스가 Fail인데 이슈는 왜 하나만 등록되었는가? 나머지 Fail 케이스는 무엇을 의미하는가?'
라고 생각할 수 있습니다.
Case_0001번 케이스에 이슈가 발생하여 하위 케이스 모두 확인 불가능으로 Fail 처리또한, 위와 같은 결과는
'이 모든 Fail 케이스가 단 하나의 이슈에 등록이 진행된 건가?'
라고 생각할 수 있습니다.
여기에서 잠시 주제를 벗어나서 이슈 등록에 대해서 이야기해 보겠습니다.
다수의 버그를 하나의 이슈에 등록하여 관리하는 경우에 일부의 버그만 수정된 경우 해당 이슈의 추적 및 관리가 어렵고 모든 이슈가 수정될 때까지 장기간 이슈 종료가 불가능합니다.
또한 일부 수정 확인 후 나머지 수정을 위해 이슈 할당이 반복됩니다.
다시 본래의 주제로 돌아오겠습니다.
개인이 아닌 팀 단위로 업무를 진행하는 경우 일반적으로 테스트 케이스를 취합하고 정리하는 사람(일반적으로 TL로 명칭)과 테스트를 수행하는 사람으로 역할을 구분하여 업무를 진행하게 됩니다.
따라서 위와 같은 경우에는 Fail 이슈에 대해서 팀원 간 추가적인 커뮤니케이션 진행이 필요합니다.
이러한 상황을 위해서 Block을 사용합니다.
진행 불가능 케이스를 Block으로 표시위의 예시처럼 Block을 사용하여 Fail 케이스에 의해 테스트가 막힌(Blocking) 케이스를 구분합니다.
그렇다면 이제 Pass와 Fail로 모든 케이스의 분류가 가능할까요?
3. Not Available(N/A)
Fail을 사용하는 또 다른 경우가 있습니다.
테스트를 시작하였으나 개발이 일부 지연되어 빌드에 포함되지 않는 경우 또는, 기획 및 정책의 변경으로 해당 빌드에 특정 항목이 미 포함된 경우와 같은 상황입니다.
사전 협의 및 공유가 진행되는 경우 테스트 케이스에서 해당 항목들을 제외하면 되지만 긴급한 의사 결정 또는 커뮤니케이션 이슈로 인하여 의도치 않게 협의 또는 공유가 되지 못하는 경우가 있습니다.
이러한 경우 테스트 시작을 기점으로 기획서 및 명세서를 기준 삼아 테스트 수행 시 해당 케이스는 Fail입니다.
빌드 내 미 반영된 항목을 Fail로 처리함하지만 이 경우에도 유사하게 누군가 위와 같은 결과를 수령한다면
'Fail 케이스인데 왜 이슈는 등록이 안되었을까?'
라는 의문이 생기게 됩니다.
(물론 예시의 비고 영역을 통하여 테스트를 진행한 사람이 메시지를 전달할 수 있습니다.)
또한 TL의 입장에서는 소프트웨어 자체의 기능 이슈와 프로덕트의 프로세스 과정에서 발생한 이슈의 분리가 필요하기도 합니다.
그래서 위와 같은 상황을 구분하기 위하여 N/A를 추가하여 사용합니다.
N/A의 경우 빌드 미 포함, 스펙 아웃, 정책 논의와 같이 해당 테스트 케이스 자체를 수행할 수 없는 경우 또는 테스트 수행을 보류해야 하는 경우에 사용할 수 있습니다.
또한, 이 외에 테스트 대상 소프트웨어 자체의 결함은 아니지만 외부 환경의 일시적인 장애(서드 파티의 결함이나 서비스 장애와 같은)와 같은 항목을 구분하는 데에도 도움이 됩니다.
4. 기타
그 외에도 QA가 테스트를 진행하면서 사용하는 다양한 결과 분류가 있습니다.
N/T(Not Tested)
S/O (Spec Out)
N/B (Next Build)
5. 마치며
끝으로 테스트 케이스에 사용하는 각 결과에 대한 분류와 함께 QA의 역할에 대해 생각해 보고자 합니다.
단순히 소프트웨어를 테스트하여 버그를 찾아내고 등록하는 게 QA 업무의 끝은 아닙니다.
또한 Fail과 Block, N/A와 같은 결과 분류는 이를 분류하여 패스율과 진행률을 계산으로 테스트 진행 상황 파악만을 위함도 아닙니다.
분류의 목적은 소프트웨어의 결함(Fail)과 프로젝트의 진행 현황(N/A)을 파악하고 이를 공유하여 결함은 수정을, 미 개발 항목은 개발 완료를 요청하여 소프트웨어의 퀄리티 상승을 견인하고 프로젝트를 완성시키기 위해서입니다.
QA 개인마다 각 분류에 대한 정의와 해석은 매우 다릅니다.
이 부분은 지금 이 시간에도 어쩌면 앞으로도 끊이지 않는 논쟁거리가 될 것입니다.
하지만 이러한 정의와 해석에 대한 논쟁보다 중요한 것은 함께 협업을 하는 프로덕트의 동료와 규칙을 정의하고 이 규칙을 기준으로 만들어 낸 프로덕트의 퀄리티 상승입니다.
이렇게 테스트 케이스에 Pass를 만들어 가며 퀄리티를 상승시켜 나갑니다.
