[준비] 프로젝트 종료까지 관리되는 테스트 계획서 작성하는 방법 공유!!

오프닝: 프로젝트를 준비하는 QA의 자세는?

테스트 계획서는 SI에서는 필수 산출물로 꼭 작성되어야 하는 문서입니다. 그리고 또 포함되는 문서가 품질 관리 계획서입니다. 이번 섹션에서는 품질 관리 계획서가 아닌 테스트 계획서에 대해서 말씀드리겠습니다.

 

간단하게 설명하면 품질 관리 계획서에는 기획/개발/테스트/배포/운영 유지보수에 대해서 품질을 어떻게 관리할지에 대한 내용이 있어야 하며, 테스트 계획서는 품질 관리의 일부 '테스트' 목적과 목표. 그리고 어떻게 테스트하고 테스트 관련 정보를 담은 문서라고 생각해 주시면 쉽게 이해 되실 거로 생각합니다.

테스트를 바라보는 QA의 자세

 

프로젝트의 시작은 '킥오프'라는 활동으로 시작됩니다. 킥오프는 아시다시피 축구에서 공을 차는 것으로 경기를 시작한다는 의미로 새로운 프로젝트를 시작할 때 킥오프 회의 혹은 미팅함으로써 프로젝트를 시작하게 됩니다. 물론 킥오프의 주최는 PM(Project Manager)이 합니다. 참석자는 유관부서 장들과 고객이나 현업, 외주 개발을 하는 경우 외주 개발사 담당자가 참여합니다.

 

이때, QA나 테스트 엔지니어는 무엇을 해야 할까요? 저는 킥오프 미팅에 참석하면 이후 풀이에서 술 마셨던 기억밖에 없습니다. 회의 때는 아무런 말 하지 않고 있다가 "수고하셨습니다." 한마디 했던 것 같습니다.

 

이유 있는 '수고하셨습니다.'이긴 한데요. 왜냐하면 과업의 범위나 어떤 프로젝트인지 감도 없는 상황이기 때문에 품질이나 테스트에 관련된 정보를 말할 수 없는 상황이기 때문입니다. 결국 '의쌰의쌰'의 시간에 나도 힘내보고자 참여하는 회의라 생각하시면 될 것 같습니다.

킥오프는 한 잔하기 위한 명분인가?

 

물론, PM의 성향에 따라 품질에 대해서 의견을 물어보는 경우도 있을 테지만, '아직 특별한 계획은 세우지 못했고, 프로젝트 관련 문서를 보고 말씀드리겠다' 정도로 정리하더라도 특별히 문제가 되지 않습니다.

 

그렇다면, 프로젝트 관련 RFP(Request For Proposal) 문서가 작성되고, WBS(Work Breakdown Structure)라는 업무 분류 체계 문서가 작성될 때쯤, 그리고 요구사항이 명확해질 때 우리는 움직여야 합니다. RFP 문서를 보고 프로젝트(과업)의 범위를 확인하고, WBS 문서에서는 일정과 리소스를 확인해야 합니다. 가장 중요한 요구사항 문서를 보고 우리는 품질 관리 계획과 테스트 계획을 수립해야 합니다.

 

우린 RFP? WBS? 이런 거 없는데? 요구사항 문서 이것도 그냥 피그마 문서가 다인데? 하시겠죠? 위에 문서들은 SI 사업에서나 모두 볼 수 있는 문서이고, 애자일하게 개발하는 회사(스크럼, 칸반, 사일로, 스쿼드 방식 등)는 요구사항이 정리된 문서와 피그마 문서가 어느 정도 작성이 완료되었을 시점이라 말씀드릴 수 있습니다.

 

제가 말씀드리려는 부분은 SI에서 작성하는 테스트 계획서가 아니고, 빠르게 대응해야 하는 조직에서 테스트 계획서 꼭 작성해야 하는가에 의문을 풀고, 프로젝트가 종료될 때 테스트 계획서가 어떻게 활용되는지 말씀드리겠습니다.

 

오해가 풀리고 진실을 알게 되었을 때 테스트 계획서를 작성하는 방법

오해라고 할 것까지도 없었고, 진실이라고 하기에도 모호한? 그런 내용이었지만 테스트 분석과 설계에 대해 이해하셨다면 그것으로 되었다고 생각합니다. 😉 혹시나 이전 글을 읽어보시지 않았다면 제가 무슨 얘기를 했는지 모르실 것이기 때문에 아랫글을 참고해 주세요.

[오해와 진실] 테스트 분석과 설계, 나는 잘 하고 있을까? 혹은 이렇게 하는 게 맞나?

 

테스트 계획서의 작성 목적은 계획해서 계획한 대로 업무를 수행하기 위한 단순한 의미가 아닙니다. 프로젝트 수행에 있어서 계획서는... 테스트 계획서뿐만 아니라 '계획서'라는 명명의 문서들은 모두 같은 목적을 가집니다. 계획 대비 얼마나 성과를 내었는지를 확인하기 위함입니다. 이것은 프로젝트 종료 시 회고의 참고 자료가 되기도 하고, 일부 회사에서는 평가의 기준 지표가 되기도 하고 협력사나 외주사와 함께 일하는 경우 SLA(Service Level Agreement) 기준이 되기도 합니다.

 

정리하면 테스트 계획 대비 얼마나 테스트를 했나? 만 확인하면 안 되죠. 테스트는 그렇습니다. 성과? 잘해야 본전인 것이 테스트 활동이라 성과로 표현하기는 매우 어려운 영역이라 생각합니다. 😁

 

그렇다면 테스트에 있어서 계획서의 목적은 무엇일까요? 제가 생각하는 테스트 계획서를 작성하는 목적은 '요구 추적을 한 눈에 확인 할 수 있는 문서'라고 생각합니다. 그래서 계획서에 포함되어야 하는 내용은 일정, 리소스, 요구사항(기준), 테스트 분석/설계 내용, 이슈 관리 목록, 테스트 범위, 테스트 환경 정보, 테스트 결과, 그리고 결과에 따른 배포 현황 등이 포함되어야 합니다.

 

이렇게 많은 내용을 담으려면 문서 작성 시간만 하더라도 많은 시간이 소비되고, 이렇게까지 작성해야 하나? 싶을 정도의 내용이 많다고 생각하실 수 있겠지만 사실 문서를 작성하는 데 필요한 시간은 30분도 안 걸리는 것 같습니다. 

개인적으로 테스팅 전략이라 쓰지만 결론은 테스트 계획서이다

 

제가 하는 방식을 그대로 공유해 드리겠습니다. 따라만 하셔도 테스트를 관리하는 데 매우 큰 도움이 되실 거라 자신합니다.

 

첫 번째, 테스트 요청을 받습니다. 슬랙(메신저)를 통해 일정 조율을 하고, 필요시 테스트 범위를 확인하기 위해 기획 리뷰? 설명을 듣고 테스트를 분석합니다. 물론 저는 머리로 합니다. 노하우가 쌓이면 충분히 하실 수 있습니다. 분석된 내용을 바탕으로 일정을 산정합니다. 어느 시점에 어느 정도 공수가 필요하고, 어떤 환경에서 어떻게 테스트하는 것이 좋겠다는 결론을 바로 결정합니다.

요청 받은 내용 및 조율된 내용 작성

 

두 번째, 요청받은 내용을 컨플루언스에 정리합니다. 현재 재직 중인 회사는 컨플루언스/지라 세트로 업무를 수행하고 있습니다. 대부분의 문서는 컨플루언스 문서로 작성하고 있으며, 저는 '테스팅 전략'이라는 제목으로 템플릿을 하나 만들어 두고 바로 작성을 합니다. 작성할 수 있는 내용은 별로 없습니다. 조율된 일정, 요구사항이 있는 피그마 문서 링크, 개발 담당자 정도입니다.

테스트 환경 및 개발 정보 정리

 

세 번째, 테스트케이스를 작성합니다. 계획서 내용에 요구사항 기준으로 작성된 테스트케이스를 첨부합니다. 저는 지라 애드온인 Xray라는 도구를 사용 중이어서 Xray의 링크를 첨부합니다. Xray라는 도구가 좀 재미있기는 한데요. 혹시나 기회가 된다면 활용해 보시길 추천해 드립니다. 가장 많이 활용하고 있는 기능은 Xray에서 제공하는 Test Plan이라는 이슈 유형(커버리지 측정)이 있고, Test Execution이라는 유형(테스트 케이스에 이슈 추적)으로 테스트 수행 관리가 가능합니다. 나중에 Xray 활용에 대해서도 한번 상세히 다뤄보도록 할께요. 😎

테스트 분석/설계 후 작성된 테스트 케이스 정보

 

네 번째, 테스트 수행 결과를 작성합니다. 여기에는 테스트를 수행하는 동안 발견한 이슈 목록이 포함됩니다. 이슈 목록은 지라의 에픽으로 관리하고 있습니다. 예를 들면 에픽 제목은 '[이슈 목록 - {플랫폼}] {프로젝트명}'으로 일관화하여 프로젝트를 진행할 때마다 에픽을 생성해서 이슈를 관리하고 있습니다. 또한, 이 시점에 꼭 확인해야 할 것은 이슈로 생성된 개발 아이템이 모두 해결되었는지와 이슈 목록에 링크된 이슈들은 모두 해결되었는지. 그리고 테스트하지 못한 항목들에 대해서는 어떻게 협의했는지에 대한 정보를 작성합니다.

 

테스트 수행 결과 정리

 

다 섯째, 배포 여부에 대해서 작성하게 되면 테스트 계획을 포함하는 테스팅 전략 문서가 완료됩니다.

 

정리하면,

1. 테스트 기간 및 범위
   • 일정: 테스팅 전략 수립, 테스트 케이스 설계 및 작성, 테스트 수행 기간, 배포 예정일, 테스트 대상 플랫
   • 요구사항 기준 문서: 기획서, 피그마, 화면설계서, 스토리보드 등
2. 테스트 케이스 목록
3. 테스트 수행 여부
   • 테스트 환경 정보
   • 개발 담당자 정보
4. 이슈 관리 목록
5. 테스트 결과
   • 배포 여부 및 배포일
   • 잔여 이슈
   • 수행하지 못한 테스트케이스 목록

 

위의 모든 내용이 하나의 문서에 작성되어 있습니다. 테스트 계획서(필자는 테스팅 전략 문서라 쓰고 있음)에는 어떤 요구사항으로부터 어떤 변경 점을 테스트하였는지와 테스트 수행에서 발견된 이슈는 무엇이 있는지? 해결하지 못한 이슈나 확인하지 못한 케이스는 무엇인지를 확인할 수 있습니다.

 

요구사항 = 테스트 케이스 = 이슈

 

이것을 보통 요구 추적이라 이야기합니다. 예전에 엑셀을 많이 활용하던 시절에는 ID로 요구 추적을 하였고, 지라나 혹은 다른 도구를 통해 관리하는 경우에는 링크라는 기능을 이용해 요구 추적이 가능하게 되었습니다. SI에서는 요구 추적 문서를 별도로 사이트맵처럼 작성하기도 합니다. 일반적인 테스트 계획서에는 요구 추적에 관련된 내용을 포함하지 않습니다.

 

요구 추적이 중요한 것은 누구의 잘잘못을 추적하려는 게 아닙니다 88년도에는 그랬을지 몰라도 😭 현재의 요구 추적은 배포 후 이슈가 발생했을 때 빠르게 대처하기 위함임을 알아야 합니다. 이슈를 해결하기 위해서 히스토리 정보가 필요하거나 어디 영향 범위에 내의 테스트가 부족해서 미처 발견하지 못한 이슈가 있었다던가 등등의 정보를 통해 운영/유지 보수를 원활히 하기 위함입니다.

 

테스트 계획서(전략 문서)를 위와 같이 작성한다면 테스트에 국한된 일부의 문서가 아닌 프로젝트 전체적으로 현황을 확인할 수 있는 문서로 활용될 수 있다고 확신합니다. 😎

 

도움이 되셨길 바라고, 긴 글 읽어 주셔서 감사합니다. 😍

 

---

관련 참고 자료 및 서비스

JIRA를 활용하여 업무 프로세스 구축해 드립니다. - 크몽

테스트케이스 작성 및 요구 검증 수행해 드립니다. - 크몽

요약 : 투잡, n잡, N잡, 크몽부업, 부업, 부수익, kmong부업, 전자책, vod, 유튜브