테스트 레벨 별 비정상 테스트 케이스 작성 방식 (매뉴얼 TC)

API TC 작성 방식에 이어서 매뉴얼 TC에서 비정상 테스트 케이스를 작성하는 기준에 대해 정리해 보도록 하겠습니다.

 

이전 글 참고 링크 : 테스트 레벨 별 네거티브 테스트케이스 작성 방식 (API TC)

테스트 레벨 별 네거티브 테스트케이스 작성 방식 (API TC)

 

테스트 레벨은 단위 테스트와 통합 테스트로 구분하였으며, 정상 동작은 제외하고 비정상 TC 항목을 어떤 식으로 작성할지에 대한 고민을 작성해 봤습니다.

 

 

여기서 하나 의문이 생겼습니다. 사용자 관점에서 테스트 케이스를 작성할 때 단위 테스트와 통합테스트를 정확하게 구분할 수 있을까..?

 

 

API 테스트의 경우엔 하나의 API를 테스트하고, 연계된 API를 테스트할 땐 통합테스트, 그 이상을 테스트할 땐 사용자 여정 테스트 (Journey Test)처럼 구분해서 작성할 수 있지만, 사용자 관점은..? 구분을 해야 하나???라는 의문이 생겼습니다.

 

 

단위 테스트와 통합 테스트로 나눈다면 단위 테스트는 텍스트 필드에 대한 테스트만 할 수 있는 것 아닐까..?라는 생각이 들기 시작했고, 단위 + 통합 일부를 합친 기능 테스트(완결된 기능의 품질 검증)로 정의하여 관리하고, 통합 일부 + 시나리오를 합친 사용자 시나리오 테스트(전체적인 사용자 경험기반)로 구분하게 되었습니다.  

 

 

구분한다면 기능테스트는 회원가입 기능, 로그인 기능 등 기능 안에서 테스트할 수 있는 항목을 의미하고,

사용자 시나리오 테스트는 회원가입 후 로그인 후 이후 동작까지 사용자의 동작 개념으로 정의하여 구분하게 되었습니다.

 

 

실무를 진행할 땐 이 사용자 시나리오를 E2E 테스트 자동화 스크립트로 구성하여 기능테스트까지 한 번에 수행할 수 있는 환경을 만들었습니다.

 

 

그럼 기능 테스트와 사용자 시나리오 테스트로 구분하여 비정상 테스트 케이스를 만든다면..? 한번 정리해 보겠습니다 :)

 

---

 

기능 테스트에서 비정상 테스트 케이스 

 

기능 테스트에서 비정상 테스트를 한다면..?

 

나는 아무것도 모르니까 날 알아서 막아봐. 제대로 알려주지 않으면 내 맘대로 하겠어.

라는 느낌으로 테스트 케이스를 작성하기도 하는 것 같습니다.

 

 

사용자는 어떤 방식으로 사용할지 모르고, 아무리 제품 안내서를 제공해 준다 해도, 그대로 사용하지 않는 것은 사용자의 자유니까요!

 

 

마치 사용자 설명서를 읽지 않고 일단 눌러보는 사용자처럼..? 흔하게 쓰는 스마트폰도 사용설명서를 읽어가면서 조작하는 사람은 정말 드문 편인 것처럼 아무리 안내를 해도 설명서를 제공해도, 사용자는 그렇게 쓰지 않을 권한이 있습니다.

 

 

그럼 우리는 이런 행동을 막아야 할 필요가 있습니다. 비정상 동작을 정상적인 동작으로 유도하고, 비정상 입력 시 다음 동작이 이뤄지지 않게 만드는 데이터나 동작 검사가 필요합니다.

 

 

이런 데이터 입력 동작들을 단위 테스트에서 검증해야겠죠.

 

 

기능 테스트의 비정상 TC 체크리스트

1. 대상 기능의 실패 케이스를 작성했는지? -> 입력 값 검증, 경계값 검증  2. 오류 상황에서 사용자가 정상 동작을 할 수 있는지? -> 오동작에 대한 안내가 발생하고, 정상 동작 유도 기능 검증 3. 같은 오류 동작에 대한 안내를 하고 있는지? -> 미 입력, 잘못된 입력 데이터에 대한 포커싱, 색상 변경을 통한 가시성 기능 검증 4. 화면에 데이터가 정상적으로 표시되고 있는지? -> UI가 틀어지는 현상, 레이아웃이 깨지는 현상 검증

 

 

저는 기능 테스트를 수행할 때 항상 비정상 동작을 정상 동작으로 유도할 수 있는지를 위주로 검증했습니다.

 

 

 그래서 테스트 케이스를 간단하게 작성해도, 화면에서 검증은 체크리스트처럼 사용자에게 잘 안내해주고 있는지까지 확인하는 습관을 들이게 되었습니다.

 

 

물론 이런 체크리스트 내용을 TC에 추가할 수 있으나, 모든 TC에 다 넣게 되면 너무 디테일해지는 경향이 있어서, 실제 수행하는 테스터의 역량에 의존하곤 했습니다. (QA 능력이 중요한 이유...!!)

 

 

위에서 안내한 내용 말고도, 기능 테스트는 기획 문서에 따라 보안적인 측면에 따라 범위가 달라질 수 있어서 상황에 맞게 작성할 필요가 있습니다. 

 

 

예를 들어 로그인 5회 이상 실패 시 30분 동안 로그인 잠금 기능이 있는 경우 기능 테스트에서 검증해야 하는 부분인 것처럼, 입력뿐만 아니라 상황에 대한 테스트 케이스를 작성하는 것도 중요합니다.

 

 

 

---

사용자 시나리오 테스트에서 비정상 테스트

 

그럼 기능 테스트에서 기능적인 측면은 다 검증이 되었다면, 이제 사용자 시나리오를 작성하며 제대로 연동이 되고 있는지를 확인해야 합니다.

 

 

사실 기능 테스트에서 정상적으로 확인했다고 해도, 시나리오 테스트에서 새로운 결함이 발생하는 경우도 종종 있습니다.

 

가장 많이 발생하는 것은 시간, 화면 동기화 등 기능 테스트에서 정상적으로 동작은 했으나, 시나리오로 동작할 때 캐시, 네트워크 등 다른 요소의 문제로 시나리오가 동작 안 하는 경우가 있던 적이 있으니까요.

 

그래서 기능 테스트도 중요하고, 시나리오 테스트도 꼭 해줘야 하는 이유입니다.

 

그럼 시나리오 테스트의 비정상 TC 체크리스트는 어떻게 될까요?

 

시나리오 테스트의 비정상 TC 체크리스트

1. 여러 단계를 진행해도 정상적으로 표시되는지? -> 장바구니에 넣은 상품이 장바구니 페이지에 정상 표시 검증 -> 상태 변경한 데이터가 대시보드 페이지에서 변경 검증 2. 다양한 환경(디바이스, 브라우저)에서 정상 동작하는지?   -> 어떤 환경에서도 정상적으로 데이터가 표시 검증 -> 중복 로그인 검증 등 3. 여러 단계를 수행하는 시나리오 중 중단된 경우 처음부터 해야하는지? -> 결제 실패 한 경우 사전에 입력한 데이터는 유지되는지 검증

 

사용자 시나리오 테스트는 사실 정상 동작 위주로 TC를 작성하지만, 사용자의 기능 동작 중에 환경적인 이슈로 인해 동작 실패하는 경우 기능으로 일부 대응할 수 있는 것을 알 수 있어야 합니다.

 

저는 시나리오 테스트를 하는 경우 정상 동작 과정의 시나리오는 자동화 스크립트로 구축하여 동작하도록 하고,

비정상 동작은 탐색적 테스트를 활용하여 자유도 높은 테스트를 수행해보고 있습니다.

 

탐색적 테스트 중에도 중요도가 높은 과정들은 자동화하여 관리하기도 하고, 기능 테스트 케이스로 생성하여 테스트 케이스를 유지보수하고 있습니다.

 

---

 

이번 블로그 포스팅을 작성하면서 느꼈던 부분은 매뉴얼 테스트에서 테스트 레벨에 대한 명확한 구분은 어렵다고 생각했고, 매뉴얼 테스트인 만큼 사용자의 행동 기반으로 구분하여 테스트 케이스를 관리하는 것이 좋다고 생각했습니다.

 

사실 명확한 구분이 필요한 것은 아니지만, 특정 기능 변경 시 재 검증 수행해야하는 리그레션 테스트를 수행할 때 기능 테스트와 시나리오 테스트를 구분하여 대상을 선정하기 위한 방법 중 하나라고 생각해도 될 것 같습니다 :)

 

다른 분들은 어떻게 TC를 관리하고 작성하고 있을지 궁금하네요 🤔