문성준의 단단해지기

오늘은 QA 산출물 중에 하나인 프로젝트 중간 보고서에 대해 이야기해보려고 합니다.

프로젝트의 결과도 중요하지만

결과만큼이나 과정도 중요합니다.

늘 과정에서 배우고 결과로 증명하기 때문입니다.

프로젝트 중간 보고서는 말 그대로 프로젝트 중간에 보고서를 쓰지만

주간 보고서, 현황보고 등

프로젝트가 어떻게 진행되는지 공유가 필요한 시점에 작성합니다.

예를 들어보겠습니다.

11월 1일~ 11월 30일 1달간 진행되는 프로젝트가 있습니다.

언제 중간보고서를 작성해서 공유해줘야 할까요?

1. 매주 금요일 주간 보고서

11월 4일 / 11월 11일 / 11월 18일 / 11월 25일 

총 4번 작성되어집니다.

2. 프로젝트 중간 보고서

11월 18일 

프로젝트 중간에 1번 작성되어집니다.

4번 작성하느냐 1번 작성하느냐 차이지만 각자 회사의 환경 또는 프로세스에 따라 작성하는 것을 권장드립니다.

( 저는 주로 주간 보고서 형태로 작성합니다.)

중간 보고서 작성하기 #01 : 이 보고서를 꼭 봐주세요.

1. 수신, 참조자 파악하기 

저는 주로 [수신 : 실무 진행자], [참조 : 관리자, 내가 소속되어 있는 팀]으로 작성합니다. 

실무 진행자는 꼭 프로젝트의 현황을 알아야 하고, 숙지해야 합니다.

그래서 남은 일정 동안 프로젝트를 완성할 수 있을지에 대해 늘 생각해야 합니다.

만약, 본인이 맡은 업무 중 어떠한 요인으로 인해 수행하기 어렵다면 QA에게 공유가 되어야 합니다.

관리자 ( 각 팀 팀장), 내가 소속되어 있는 팀으로 참조를 포함시킨 이유는 각 팀의 팀장들 또한 현재 프로젝트 업무

상황을 확인하여 팀 운용에 참고를 할 것입니다. 또한 프로젝트에 참여하지 않더라도 중간보고를 받음으로써 프로

젝트 진행상황이 와전되는 것을 방지하기 위함입니다.

그리고, 팀원들에게 공유하는 이유는 제가 부재중이더라도 다른 인원이 대응할 수 있도록 공유를 해주고 있습니다.

중간 보고서 작성하기 #02 : QA팀은 이러한 환경에서 검증하고 있습니다.

1. QA가 어떤 환경에서 진행되고 있는지 공유합니다.

예를 들면 Test Device, Test App ver, OS ver 등 이 있겠죠?

2. QA 범위에 대해서 공유합니다.

신규 프로젝트일 경우 Front, Admin 둘 다 진행하겠지만 기존에 운영되고 있던 제품을 리뉴얼할 때는 일부 기능에 대해서는 검증 범위가 제외될 수 있으므로 범위에 대해 명확하게 적어줍니다.

3. 기획서 Histroy에 대해 공유합니다.

저는 주로 명세 기반 작성법으로 Testcase를 작성합니다. 

업무 프로세스상 [사업부 & 연구소 → 기획팀]으로 요구사항을 반영하여 기획서를 작성하기 때문에 기획서가 어떻게 변화했는지 중요합니다.

어떤 사람은 1.0ver 초기기획서를 보고 업무를 진행하고, 어떤사람은 1.5 ver의 최신 기획서를 보고 업무를 진행하는 불상사가 일어나는 것을 방지하기 위함입니다.
 

중간 보고서 작성하기 #03 : 본론입니다. 현재 상황을 숙지해주세요.

1. 한눈에 알아볼 수 있도록 진척률을 도식화하여 작성합니다.

기획서에 명시된 I.A ( Information Architecture )  기준으로 각 기능별 %에 대한 Progress bar를 작성합니다.

2. Test scope에 대한 CheckList를 작성합니다.

기능별 분류 값을 Depth 별로 구분을 합니다.

그리고 [확인] 칸에는 해당 기능(Depth)에 어떤 주요 기능이 확인되어야 하는지 기입합니다.

그리고 진행 여부에 [ 완료 / 진행 중 / 진행 예정 / X ] 항목을 만들어서 프로젝트 진행 현황을 공유합니다.

중간 보고서 작성하기 #04 : 결함 분석을 진행하겠습니다.

1. 진행된 Issue tracking or Bug tracking을 표와 차트를 이용하여 제공합니다.

현재 검출된 결함이 어느 정도이고, 수정률은 어느 정도인지 한눈에 파악할 수 있어야 합니다.

중간 보고를 통해 앞으로의 결함 도출 및 수정률을 예상하여 

예정된 일정을 앞 당길지, 아니면 연장할지 생각할 수 있습니다.

2. Critical 한 결함은 따로 기입을 진행합니다.

Critical 한 결함은 교과서라고 생각하시면 됩니다.

개발자는 추후 프로젝트 진행 시, Critical 결함이 왜 나왔는지에 대해 Feedback을 통해 재발을 막을 수 있습니다.

3. 기획 관련 이슈도 공유되어야 합니다.

이는 기획서 관리에도 도움이 될 뿐만 아니라 관련 정책을 재확인할 수 있는 기회입니다.

중간 보고서 작성하기 #05 : 특이사항입니다. 

1. 마지막으로 프로젝트 기간 도중 발생된 특이사항에 대해 모두 기록합니다.

저번에도 말씀드렸듯이 모든 업무는 투명하게 진행되어야 합니다.

숨기지 않아야 대처가 가능합니다. 

본인이 실수를 했다거나, 타인이 실수를 해서 지연되는 사항이 있더라고 하더라도 목표를 위해 다 기록되어야 합니다.

그것이 제가 말씀드렸던 " 늘 과정에서 배우고 결과로 증명한다 " 의 철칙입니다.



▼참고▼

2022.10.25 - [QA로 단단해지기/내가 업무 할 때 소통하는 이야기] - [내소기] Episode_#07 : 모든 업무는 투명하게 기록한다.

오늘은 QA 담당자로써 프로젝트 중간보고서는 어떻게 쓸까?

감이 안 오시는 분들에게 조금이나마 도움이 되고자

제가 작성하는 방법을 공유해봤습니다.

물론 각자 회사에서 사용하고 있는 보고서 양식이 있으시다면 사용하셔도 무방합니다.

저 같은 경우에는 QA 프로세스가 확립되어있지 않은 회사에서 

프로세스 구축을 진행하며 여러 양식으로 중간보고서를 작성해 보고 난 후

제일 깔끔하고, 전달력이 좋았던 방법이 위의 방법처럼 작성하는 것이었습니다.

그럼 Episode 01 마무리하도록 하겠습니다.

다음에도 QA 산출물에 대해 작성해보도록 하겠습니다.

그럼 이만!