테스트 종료활동에 대해 기재해봅니다.
QA / Test Process의 마지막 단계입니다.
이전 단계들이 궁금하시면 상단 시리즈의 목록보기를 통해 확인해주세요!
7. Test Closure - 테스트 종료작업
종료작업은, 테스트 종료판정을 한 후에, 모든 작업들의 최후 확인 및 자료 정리, 이후 다음 테스트를 위한 feedback을 중심으로 진행합니다.
계획대로 작업성과물이 작성되어있는지, 대응하지 않은/놓친 issue가 있진 않은지 등도 확인합니다. 테스트를 진행하면서 추후대응하기로 협의된 issue가 있다면, 이 단계에서 정리합니다. 실제 Real환경으로의 배포 작업 및 일정기간 모니터링도 이 단계에 포함되기도 합니다.
이 단계에서 중점적으로 진행하면 좋을 것들에 대해 아래에서 소개해봅니다.
1. Real환경으로의 배포 및 모니터링
위에서 설명드린대로, 이 작업을 종료작업에 포함하여 정의하기도 합니다. real환경으로의 배포 후 간단한 확인작업, 제대로 동작하는지의 모니터링작업이 포함될 것 입니다.
2. Issue의 경향 분석
issue가 발생한 기능, 환경, 시간대등을 조합하여 분석합니다. 분석된 데이터를 이해관계자들에게 공유를 하기도 하며, 다음 버전 시에 issue가 많을 것으로 예상되는 부분에 대해 미리 TestPlan을 수립하기도 합니다.
3. 테스트 데이터 정리
테스트를 진행하면서 생성된 많은 테스트용 문서 및 데이터들을 정리합니다. 추후에도 다시 사용할 수 있는지 검토하고, 정리합니다.
4. 작업성과물들의 확인
여기서 말하는 작업성과물이란, 대체적으로 테스트케이스와 해당 케이스를 진행한 결과가 기재되어있는 문서를 포함하여, 전반적인 테스트활동으로 인해 생성된 문서들을 말합니다. 이 작업성과물들을 정리하여 고객에게 제시하고, 납품할 수 있습니다. 추후 Real환경에서의 issue가 발생한다면, 해당 성과물을 가지고 문제를 유추해볼 수 있을 것 입니다.
Water-fall에서만 어떠한 Document화된 작업 성과물이 있다고 생각하시는 분들이 있을 수 있습니다만, Agile에서도 많은 것들을 문서화합니다. Agile은 방법론일뿐, Business level에서의 요구하는 성과물들은 어떠한 형태로든 있을 것 입니다. 문서화의 여부는 이해관계자들과 협의 후 진행하는 것이 바람직합니다.
5. 이해관계자들과의 feedback, Retrospective.
QA종료 후에 이해관계자들과의 feedback, 회고를 실시합니다. 보통은 기획자와 개발자들과의 feedback을 실시하나, 진행하는 프로젝트에 따라서는 많은 부서에서 같이 협업하여 진행하는 경우가 있기 때문에, 필요에 따라 적절히 이해관계자들을 선정, 회의 소집하여 회고를 진행합니다.
Retrospective in Software development
The term is also used in software engineering, where a retrospective is a meeting held by a project team at the end of a project or process (often after an iteration) to discuss what was successful about the project or time period covered by that retrospective, what could be improved, and how to incorporate the successes and improvements in future iterations or projects. Retrospective can be done in many different ways.https://en.wikipedia.org/wiki/Retrospective#Software_development
retrospective는, 프로젝트 혹은 테스트를 종료한 후에 성공적이었던 점, 개선해야할 점등에 대해 말합니다. 조직마다 사용하는 언어가 조금씩 다르고, 진행하는 방법이 다르긴 합니다.
회고를 진행할 때는 여러 방법이 있겠으나, 여기서는 3가지 방법을 소개하고자 합니다.
1. KPT, Keep-Problem-Try
Keep-Problem-Try는 다음과 같습니다.
- Keep : 이번 테스트 및 버전에서 잘한 점. 잘했다고 느낀 점.
- Problem : 이번 테스트 및 버전에서 부족했던 점, 잘 안된 점, issue가 생긴 점.
- Try : 다음 테스트, 다음 버전에서 개선해야할 점, 개선하면 좋을 점, 문제가 있다면 해결하기 위한 방법
팀원 혹은 이해관계자들끼리 각자 작성 혹은 하나의 보드에 다같이 작성하고, 발표를 진행합니다.
발표는 K-P-T 순으로 진행합니다. 이 활동에서의 포인트가 몇가지 있는데요,
- 작성할 때는 말하지 않고 작성합니다. 즉 작성하는 활동과 발표하는 활동을 나눕니다. 어떤 사람이 발언을 함으로 인해서 다른 사람에게의 영향이 발생할 수도 있습니다.
- Keep에서는 다른 사람이 한 행동에 대해서도 작성합니다. 자신의 관점에서 당연하다고 생각하는 것은 잘 생각이 들지 않아 작성을하지 않는 사람이 있을 수 있습니다. 때문에 다른 사람의 잘한 점을 작성해줌으로 인하여 찾아낼 수 있는 또다른 의견을 도출해내도록 유도합니다.
- Problem에서는 가능한 부정형으로는 작성하지 않습니다. ~~을 하지 않았다 라는 의견은, ~~을 하면 된다 라는 의견으로 밖에 연결되지 않을 수 있습니다.
- Try에서는 쓸모없다고 생각되어도 일단 작성합니다. 일단 양을 많이 작성하고, 그 중에서 좀 더 좋은 개선안 등을 도출해내는 것이 쉬울 수 있습니다.
2. Postmortem (사후 부검)
단어 뜻만 봐서는 사후검시, 부검, 뭐 이런 뜻입니다.
Postmortem
A project post-mortem is a process used to identify the causes of a project failure (or significant business-impairing downtime), and how to prevent them in the future. This is different from a Retrospective, in which both positive and negative things are reviewed for a project.
위 내용들과 다르게, postmortem 은 어떠한 issue가 발생하였을 때, 이것이 발생한 원인을 확인하고, 다음 버전에서는 어떻게하면 동일한 문제가 발생하지 않을지에 대해 논의합니다. 단순한 issue에 대해 논의하기 보다는, 그 issue가 왜 발생하였는지에 대한 근본적인 원인을 다같이 생각해보는 자리입니다.
3. Poka-yoke
포카 요케(ポカヨケ, poka-yoke)는 품질 관리의 측면에서 실수를 방지하도록 행동을 제한하거나 정확한 동작을 수행하게끔 하도록 강제하는 여러 가지 제한점을 만들어 실패를 방지하는 방법을 말하는 용어이다. 토요타의 시게오 신고에 의해 처음으로 고안됐으며, ‘실수(ぽか)를 피하다(除ける)’는 뜻의 일본어에서 왔다.
https://ko.wikipedia.org/wiki/%ED%8F%AC%EC%B9%B4_%EC%9A%94%EC%BC%80
제조업에서 유래한 이 포카요케는, 어떠한 실수를 방지하기 위해 프로세스를 만들고, 그 프로세스를 강제하도록 하는 방법입니다. 이슈가 발생했다면, 관계자들과 함께 논의를 진행하고, 재발방지를 위해 어떠한 프로세스를 만들고 반드시 이 프로세스를 준수하도록 하는 것입니다.
Feedback 활동들의 공통점
위의 활동들의 공통점들은, 절대 잘못된 일, 발생한 issue에 대해 문책하는 자리가 아니라는 것입니다. 실수한 사람이나 문제의 책임자를 비난하기만 한다면, 해당 조직은 점점 책임을 회피하기 위해 어떠한 팀 혹은 개인의 입장에서만 생각하게 될 것 입니다. (특히 실제 Real환경에서 issue가 발생하면 제일 먼저 연락오는 것이 QA/Test조직이긴 하죠... ㅠㅠ)
Product / Service는 어떠한 개인 혹은 하나의 팀만 만들어나가는 것이 아닌, 조직원 전체가 협업해나가며 만들어나갑니다. 개인단위에서는 알아차리기 힘든 원인, 해결하기 어려운 원인들이 있을 수 있으며 그러한 문제들을 다같이 해결해나가야만 합니다.
이렇게 QA / Test process에 대해 정리해보았습니다.
Ref
