SI Project에서의 QA process

아이스크림이 떙기는 3월이 왔당 ㅋ

경험에 비추어 QA Process 를 적어 본다. 

순서는 일반적인 Process 가 맞지만 추가로 적는 내용들은 본인의 경험이 많이 들어가 있음을 밝힌다. 

Process는 충분히 변할 수 있고 혹은 개선 될수 있다는 사실을 기억해 두자.

---

1. Project 수행 계획서 작성 및 개발 방법론 정립

- 고객과의 Project를 체결 하기 위해서 해당 사업에 대한 Proposal (제안서) 및 계획서를 만들어야 한다. 보통은 Documentation을 주로하는 PL 급 이상의 사람들이나 PM이 하는 경우가 많다. 혹은 사업부와 개발팀에서 협업하기도 하는거 같기도 하다. (난 안해본 업무라... Pass)

- 개발 방법론은 사실 Proposal에 포함되긴 하는데 어떤 개발 방법론으로 제품을 구현할지 정하는 것이다. 여러 방법론들은 구글신이 찾아줄 문제라 여기에서는 생략. 

 Project 를 따내고 난뒤 고객 요구사항

A. 새롭게 개발을 하거나 CR (Client Requirement)을 받을때 고객으로 부터 요구사항을 받게 된다.

B. 요구사항 정리

제일 깔끔한건 고객님이 정리해서 보내주면 좋겠지만... 보통은 "을"인 우리가 요구사항을 바탕으로 요구사항을 정리해서 고객에게 confirm 받는 경우가 많다. (일 늘어나는 소리가 어디선가 들린다 ㅠㅠ)

2. Project 관리 및 요구사항 분석 (개발 일정 및 각종 자원관리)

- 요구사항을 바탕으로 개발파트, 검증파트 등등에서 전체업무에 대한 일정 및 자원 관리를 작성한다. 아쉽지만 내가 거친 회사들은 따로 검증 일정의 비중을 높게 잡지 않았다. 개발 >>> QA 의 종속관계이다 보니 QA 입장에서는 늘 난감한 일정에 부딪힌다.

3. 시스템 설계 (프로세스 설계, 데이터모델 설계)

A. 기본설계서 작성

- 요구사항를 바탕으로 기본설계를 작성한다. 개발 쪽에서는 보통 Usecase (sequence diagram), ERD (DB와 관련된...), Wireframe (화면 UI 구성), 기타 API 정의나 기능 설계, server architecture 들을 작성 하는데 개인적으로 넘넘 귀찮은 일이지만 필요한 문서작업이라고 생각된다. 솔직히 이게 안되어 있으면 나중에 인력이 들어오고 나갈때 아무런 History를 알수 없게 된다. (심지어 경력분들 중에 이런걸 안해본 사람들이 되게 많았다...;;;)

4. 설계의 구체화 및 코딩

- 보통 설계를 구체화 하는 작업은 안한다. 그냥 위에 시스템 설계에 있는 문서들 현행화 정도만 해줘도 Thank you 하지 않을까? 사실 3번까지도 엄청난 시간을 소모하기 때문에 대부분 이제 부터는 개발파트에서 열심히 코딩을 하기 시작한다.

- 열심히 개발팀에서 개발을 할때 QA는 뭘해야 하나? 가 난 난감 했는데, 보통 Test sheet 들을 만들고 Test 환경을 구축해 놓는다. 그외에 이슈 관리를 위해 Tracking tool 세팅, build 환경 구축등을 진행 한다. 약간 여유가 남는다면 PMO 역할이나 부족한 Documents들도 현행화 하는 작업도 나쁘지 않았다.

5. 내부 QA 및 Testing (제반 품질보증 활동)

- 품질 보증, 감리, QA 등등등 여러 단어들이 있지만 QA 활동으로 퉁 치겠다. 여기에서 부터 살짝은 애매한 부분인것 같다. 내가 engineer 능력이 되는 QA 인지 혹은 짜여진 일정에 맞춰 검증이 가능한 QA 인지에 따라서 검증의 영역이 많이 달라지는 것 같다.

A. Unit Test

모듈 단위의 테스트라고 하는데 보통 이건 개발파트에서 각자 맡은 개발자들이 한다고 나는 믿는다. 내가 이들이 짜놓은 코드를 모듈단위로 테스트를 한다? 개인적으로는 못한다에 한표를 던진다. 내가 개발능력이 없는 것도 없는 것이지만 일일히 다 볼 시간이 없다.

모듈이 모아진 기능만 보기에도 시간이 부족하다고 생각한다.

물론 Unit Test에서 너무 많은 버그나 나온다면 코딩의 문제라고 난 보통 생각하고 이건 따로 Task 등록이나 이슈등록을 해서 관리 정도만 하면 된다고 본다.

B. Combination Test

- 통합 테스트로 불리긴 하는데 각 Project 별, 상황별로 Test 할수 있는 범위가 다르기 떄문에 내 기준으로 설명 하려고 한다. 사실상 여기에서 부터 개발파트에서 넘어온 산출물을 QA 한다고 생각하면 된다. Client 와 Server 간의 Integration check, Client의 각 기능 별 check, Server와 3rd party app 간의 기능 check, 그밖에 UI 구현, 문구등을 확인한다. QA 인력에 따라 위의 검증들은 tight 하게도 혹은 reasonable 하게도 할 수 있다고 생각한다. 보통 QA나 Test 인력이 없는 소규모 팀들은 개발자들이 진행 하기도 하는데 음... 개인적으로는 내 설자리가 없어지는 것이므로 좋아하는 편이 아니다. 가끔은 개발자와 협업을 하는 것이 효율적인것도 있지만 이 또한 양날의 검이라 절차를 따르면서 QA를 하는게 좋지 않나 싶다.

7. 이슈(issue) 관리

- 이슈 관리의 목적에 따라서 이슈를 관리할 수도 안할 수도 있다. 하지만 Process 관점에서는 하는것이 좋고, 내 기억력도 좋지 않기 때문에 개인적으로는 issue 관리는 매우 중요하다고 생각한다. 이슈는 다들 알다시피 다양한 issue tracking tool을 통해 이슈를 등록 추척, 관리 한다. 이때 issue의 life cycle을 관리 하는게 나는 이슈 관리의 point 라고 생각한다. 등록만 해놓고 나중에 나몰라라 하면... 음... 안하니만 못하지 않을까?

- 이슈 관리 만큼 Risk 관리도 중요하다고 생각된다. Project 전반의 Risk 보다는 QA 관점의 Risk를 나는 많이 생각하는 편인데, 이미 정의된 요구사항에 부합하지 않는, 혹은 구현할 수 없는 부분들에 대한 Action risk item 관리도 중요하다. 이 부분은 나중에 고객과의 comm 에서 우리의 의견을 정확히 전달하고 내부적으로도 서로 잘잘못을 따지는 쓸데없는 시간낭비를 줄이기 위해서도 필요한 부분인것 같다. 개발팀에 Risk 관리를 넘기는 것보다는 QA 파트에서 관리하면서 서로 Daily든 Weekly든 조금이라도 시간을 할애 해서 공유 해야 된다고 생각한다.

8. 품질 개선 및 향상

- 사실 큰 회사에서나 이런 Category를 쓰지 않을까 싶다. (따로 QA팀이 있는 조직들...) 여기에서 부터 개발팀은 공식 Release가 생기게 되고 QA팀이나 Delivery팀도 이 release version의 검증을 통해서 고객에게 산출물을 전달 하기 때문이다. 만일 큰 회사가 아니거나 작은 조직일 경우에는 7번의 이슈관리와 8번을 잘 섞어서 사용하지 않을까 싶다.

9. Staging, UAT

A. Staging Test

- 우리의 개발 환경 (Local)이 아닌 고객님?의 테스트 환경 인 (실제 상용과 매우 비슷한?) Staging 환경에서의 QA 가 있다. 우리가 하는 경우도 혹은 고객사 내에 QA파트 나 팀이 있는 경우는 그쪽에서 주도적으로 테스트 한다. Staging 환경에서 나오는 문제점들은 항상 이슈 관리를 해주어야 하며 고객과의 협의 하에 새로운 배포 일정을 잡고 release를 해주는것이 일반적이다.

B. UAT (User Acceptance Test)

- 고객에게 대금을 수령하기 위해서 매우 중요한? 테스트 이지 않나 싶다. 더불어 해당 환경에서의 결과로 상용배포가 (Commercial Launch) 되느냐 마느냐 하는 기로이기 때문에 별표 5개이다. 보통 UAT 환경은 Commercial 환경이 Production에서 하지만 간혹 Staging과 Production의 중간쯤 환경을 만들기도 한다. (좀더 detail 할 경우 각각의 환경을 다 따로 나누고 Production 환경을 BAT (Business Acceptance Test)를 하는 경우도 있는것 같다.)

10. Commercial open 및 support

- 이건 뭐 따로 말할 필요가 없을듯 싶다. 말 그래도 상용 오픈과 유지보수다. 당연히 완벽한 어플리케이션은 없기 때문에 지속적으로 발견되지 못했던 이슈가 발생 할 것이고, 이에 대한 오류 분석, 수정, 검증, 배포의 과정을 거치게 된다. 

---

그런데... 정말 중요한건 위의 프로세스가 정말 제대로 안돌아가거나 아예 안되는 경우가 있다 ;ㅁ;

그때 해결방법은...?

난 그냥 퇴사했다. -_-