테스트 시트와 품질관리

안녕하세요. 연두씨입니다.

운영이든, 프로젝트든 개발 후에는 반드시 QA를 하게 되는데요.

이때 어떠한 기준으로 기능 완료를 체크할 것인지를 정리한 문서가 바로 테스트 시트입니다.

테스트 시트의 가장 큰 목적은 당연하게도 기능 개발의 완료를 체크하기 위함이고요,

또 한편으로는 테스트 당시의 품질을 체크한 기록이니 추후 운영 시에 프로덕트 품질을 관리하는 중요한 자료가 될 수 있습니다. 예를 들면 구축 당시의 테스트는 사파리 xxx버전까지 하였으나 추후 버전이 업되면서 추가적인 이슈가 발생할 경우 당시의 테스트 기록을 보며 버전업으로 인한 이슈일 수 있다고 추측할 수도 있게 되겠죠. 혹은 대응 브라우저를 정책적으로 정리할 때 참고자료가 될 수도 있고요.

이 처럼 테스트 시트는 한번 체크 함으로 그 활용이 끝이 아니라 계속 참고 또는 근거 자료로 활용될 수 있으니 최대한 상세히 또 성실히 작성해 둘 수록 큰 도움이 될 것입니다.

작성자는 기획자가 되겠지만 사용자(실제로 시트대로 테스트를 하는 사람)는 개발부서 부터 QA부서까지 많은 분들이 될 수 있겠습니다.

종합해보면, 개발된 기능의 완료 여부를 면밀히 체크할 수 있고 추후에 봤을 때 자료로 활용될 수 있음을 감안하여 작성하되, 많은 사람들이 보기에 이해가 쉽도록 작성되면 되겠지요.

테스트 시트는 꼭 반드시 이렇게 작성해야 한다는 법칙(?)은 없는 것 같아요. 어떤 방향성에서 어떻게 활용될지 고민하면서 상황에 맞게 작성되면 좋을 것 같습니다.

제가 주로 작성하는 방법을 공유해보도록 하겠습니다.

이미지가 작아서 잘 안 보인다면, 클릭해서 큰 화면으로 봐주세요.

쓰시는 상황에 따라 항목과 양식의 형태는 알아서 바꿔서 쓰시면 될 것 같아요.

저는 주로 여러 테스터들의 결과를 취합해서 정리하는 경우가 많아서 되도록 취합에 용이하도록 가로 열에 항목을 다 추가하는 편입니다.

맨 위에는 테스트 제목과 사용법을 간단히 적어두고요, 실제로 작성하는 항목은 가로에 모두 나열합니다.

1. 넘버링은 해두면 전체로 몇 건인지 한눈에 볼 수가 있고요,

2. 테스트하는 위치의 화면 경로를 정리해 둡니다.

3. 각 페이지별로 테스트할 내용과 예상 결과를 정리해 둡니다. 이 부분이 아마도 가장 중요한 부분이 될 것 같아요.

개발 기능을 정의할 때 성공했을 경우와 밸리데이션 체크, 그 이외에 안 되는 케이스에 대한 결과 등을 정리했을 텐데요, 그대로 개발이 잘 되었는지 확인을 위해서는 정상적인 케이스 이외에도 모든 케이스를 다 기입하여 테스트가 될 수 있도록 합니다.

당연한 말이지만, 테스트할 내용과 예상 결과는 이해하기 쉽도록 작성하고 테스터가 오류의 여부를 판단할 수 있도록 명확히 작성하는 게 중요합니다.

4. 테스트 결과와 오류 종류는 상황에 맞게 미리 후보군을 정해서 정해진 후보 중에 선택할 수 있도록 합니다.

취합과 정렬에 용이할 거예요.

5. 모든 페이지 url까지는 필요 없지만 특정 페이지에서 발생되는 오류를 빨리 찾으려면 저는 파라미터를 포함한 url이 많이 도움이 되어서 오류 시 url을 작성하는 란을 둡니다.

6. 정상이거나 오류 거나 선택하여도 테스터가 테스트하다 보면 추가적인 의견이나 문의가 필요한 경우가 있을 거라 생각돼요. 오류가 아니더라도 참고할 수 있도록 칸을 두면 의견을 받아 도움이 될 수 있을 거예요.

7. 테스트 일시~작성자 까지는 테스트 환경에 대한 항목입니다. 환경에 따라서 결과에 영향을 줄 수도 있으므로 전 반드시 작성할 수 있게끔 해 두고요, 테스트 항목 위에 별도로 정리하여도 되고 가로로 정리하여 보기엔 불편해도 취합에 용이하게 정리할 수도 있겠습니다.

반드시 위의 항목만 필요한 것은 아니고요, 상황에 따라 항목을 더 추가하거나 생략하셔도 되어요.

다만 테스트 내용과 예상 항목만은 상세히 기입할수록 좋은 테스트가 될 뿐 아니라 그 결과가 추후에도 좋은 자료로 남게 될 거예요.

구축 시에는 기능 정의한 내용을 토대로 작성하여 개발 완료를 체크하고요,

운영 시에는 분야 별로 작성해 두고 테스트가 필요할 때마다 시트를 열어서 테스트합니다.

예를 들면 회원가입, 결제 단계, 로그인 등 각 분야별로 어느 정도 항목을 정해서 만들어 두고요,

이번에 회원가입에 뭘 수정했다 하면 수정한 기능에 대한 테스트도 하지만, 회원가입 시트를 열어서 쭉 한번 돌려 봅니다.

혹은 회원가입 수정으로 인하여 결제 단계에도 영향이 있을 수 있는 상황이라면, 결제 단계도 열어서 돌려 볼 수 있도록 테스트 프로세스를 마련해 두면 운영 시에도 품질 관리하는데 많은 도움이 될 거예요.

제 경험으로는 항목을 상세히 정리해 두고 문서를 꾸준히 관리하는 부분이 귀찮긴 하지만 장기적으로 볼 때 품질을 관리하고 리스크를 미연에 방지하는데 큰 도움이 되었습니다.

작은 기능 개발에도 문서로 정리하여 테스트할 수 있도록 하고(문서로 정리하는 과정 자체로 큰 도움이 됩니다), 운영 시에도 어떻게 테스트하고 품질의 기준을 가져 갈지 항상 고민하는 부분들이 서비스를 계속 성장하게 할 거라 생각합니다.