'이거 다 됐어요?' 대신 테스트 기준을 만들기로 했다

프로젝트 관리

서비스 런칭 프로젝트의 후반부에서 가장 중요한 점은 "오류 없이 기능을 완성해서 배포하기"일 것이다.

작년에 공모전 팀빌딩 웹서비스 런칭을 앞두고 이런 문제점이 있었다.

- 오류 없이 잘 굴러가는 기능과 작은 버그가 생기는 기능을 정리하기 힘들다.
- 단면적인 이용에서 나아가 유저가 이용할 수 있는 다양한 경우의 수를 고려하지 못했다.

유저가 서비스에 진입해서 우리가 원하는 플로우대로 서비스를 이용하길 기다릴 순 없다.

같은 버튼을 10번 이상 클릭하는 유저부터 뒤로 가기를 무한대로 하는 유저가 있을 수도 있다.

그래서 이런 문제점을 해결하고자 QA 시트를 도입하기로 결정했다.

QA는 Quality Assurance의 약자로 제품이나서비스가 일정한 품질 수준을 유지하도록 관리하고 보장하는 활동을 의미한다. 쉽게 말해 문제가 생기기 전에 예방하고, 제품이 기대한 품질을 갖추도록 시스템적으로 관리하는 과정이다.

IT서비스를 운영하는 조직에 따라 QA 전문 매니저가 있을 수도 있고 없을 수도 있다.

하지만 대학생 프로젝트에서는? PM이 이 업무를 해야 한다 ㅎㅎ

QA는 조금 포괄적인 개념인데, 아래의 작업들을 주로 일컫는 것 같다.

테스트 케이스(Test Case)
→ 어떤 상황에서 어떤 결과가 나와야 하는지를 미리 정해놓은 문서

버그 리포트
→ 발견된 문제를 개발자가 수정할 수 있도록 기록

회귀 테스트(Regression Test)
→ 수정한 기능이 다른 데 영향을 주지 않았는지 확인

자동화 테스트
→ 반복되는 검증 작업을 자동화해서 효율 높이기

이 중에서 나는 출시 전 테스트 케이스 문서를 제작했다.

프로젝트에서 직접 사용했던 엑셀 QA문서 양식과 각 영역에 대한 개념은 아래 티스토리 링크에 기록해 두었다!

https://jieunforpm.tistory.com/3

직접 제작한 기본 QA시트 미리 보기

실제 우리 팀이 런칭 전 작성했던 QA 시트

QA시트 프로세스를 도입하고 나서 이런 점이 변화했다.

- 단순히 기능 개발 O, X가 아닌 유저 케이스로 작성하면서 유저 플로우 흐름에 이상이 있는 부분을 발견할 수 있었다.
- 다 됐다! 생각했는데 예상치 못한 버그가 정말 많았다. 다행히 출시 전에 이를 전부 고치고 배포할 수 있었다.

개발자 팀원들도 구두로 기능이 되었는지 안되었는지 확인하는 것보다 기록을 남길 수 있어서 훨씬 작업하기에 편리했다는 이야기를 해주었다.

다음에는 스프레드시트를 자동화해서 QA를 할 수 있는 방법에 대해서도 연구해 봐야겠다!