만화영화 옥토넛(Octonauts)과 유사한 QA Engineer

나는 품질 관리 업무를 처음에는 Test Engineer(이하 TE)으로 시작해서 Quality Assurance(이하 QA)로 그 역량을 확장하였다. 임베디드, 게임, 플랜트, 금융, 보안 도메인을 경험하며 Knowledge Boundary를 확장하였고, ISO 12207과 CMMi, TMMi를 기반으로 한 방법론 개발로 Process 측면의 한축을 세웠다. 그리고 다수의 GS인증이나 CC인증을 통해 평가 방법이나 절차를 습득하여 Product 측면의 한축을 마련하였고 이를 기반으로 한 조직의 품질 관리를 주도하고 있다.(참고: 소프트웨어 품질의 집, ISO/IEC/IEEE 12207)

그래서 TE와 QA에 대한 차이는 어쩌면 다른 사람보다 잘 구별할 수 있다고 자부한다. (사실 어쩌면 망각하고 있는 건지 모르겠다.😁) 그렇게 여지껏 경험했던 20년을 앞으로 다시 QA를 업(業)으로 연구하면 그때는 무언가 명확한 해답을 얻을 수 있을지 모르겠다. 하지만, 늘 그랬듯 언젠가는 하면 될꺼라 믿는다.

 

오늘 하고자 하는 이야기는 옥토넛에 대한 QA 이야기이다. 아이들과 함께 TV 애니메이션을 시청하던 옥토넛(The Octonauts)에서 외치던 구호를 듣고 찌릿한 느낌을 받게 되었다. 아이들은 늘 그랬듯 노래를 따라 부른다. 😍♪♬

[아이들의 바닷속 친구 옥토넛 |출처]

옥토넛 주인공들은 바닷속 친구들은 시작과 끝에 이런 구호를 외친다.

Explore(탐험), Rescue(구조), Protect(보호)…

주요한 스토리는 옥토넛 대원들이 여러 환경들에서 바다 생물을 구조하기 위해 고군분두하는 내용이다.🤠 어쩌면, QA가 Project를 옥토넛의 각 대원들과 같은 입장에서 Product를 살펴보고 있는 것은 아닌지 싶다.

효과적인 소프트웨어 프로젝트 관리를 위해 공학 측면에서는 3가지 측면을 제시하고 있다. People, Problem, Process이다. 이를 위해서 다양한 측면으로 설명하고 개선을 요구하는 이론들이 나오기 시작했다. 😨

‘소프트웨어 공학의 사실과 오해’라는 책에서는 사람, 도구, 프로세스(방법론)로 이를 설명하려고 하였지만, 차이를 인정하고 이를 차이를 줄여 목표를 달성하는 것이 옳다라는 결론에 곧 봉착한다.(필자만 그렇게 생각할 수 있으니 한번 읽어보길 추천한다.👻)

[결국 사람, 도구, 프로세스도 아닌 무엇인가? | 출처]

QA로서 Project를 접할 때 주로 하는 행위는 앞에서 이야기한 것처럼 Explore, Rescue, Protect에 가깝다고 생각한다. 우리가 이미 다양한 지식체계에서 배워온 것처럼 우리는 제한된 상황에서 품질관리를 수행하고 있다. 그리고 그 안에서 우리는 Goal과 Practice를 찾아야 하는 사명을 있다. 그렇다면 우리는 어떻게 행동하고 있는가❔ 익숙하게 기존처럼 활동하는가, 아니면 무언가 제안할 수 있는 다른 것을 찾고 있는가⁉ 아마도 제한된 시간, 자원 등이라면 기존처럼 이전에도 그냥 그랬던 것처럼 지나가길 원하는 사람이 더 많을 것이다. 왜냐하면 프로젝트에서 품질 관리하던 그들은 늘 그랬고, 앞으로도 그럴 것이기 때문이다. 결론은 바뀌지 않을 것이며, 바뀌고자 하는 의지가 없다는 것이다.

우리는 탐색적 기법(Exploratory Testing)의 테스트를 활용합니다. 테스트 케이스 작성 및 관리가 그만큼 중요한 것도 잘 알고 있다. 그래서 우리는 우리의 노하우를 (시간이 허락한다면) 문서화하는 것을 즐긴다. 그렇게 쌓인 지식(Knowledge)은 개인에게 할당되지 않고 QA팀에게 기초지식이 될 수 있도록 리뷰하고 관리하려고 노력한다. 물론 우리가 최고라고 말할 수는 없겠지만, 그래도 그런 노력에 나는 우리에게 80점 이상은 주고 싶다. 📜

[엔지니어에게 경험을 무시할 수 없지! | 출처]

그리고 우리는 종종 위기의 Project & Product를 구해내기도 합니다. 종종 계획에 없더라도 시간을 쪼개내고 다시 만들어서 우리가 확인하지 않은 일을 최소화하려고 노력한다. 그런 노력이 있음에도 불구하고 우리 몰래 슬쩍 배포 하는 경우 담당자에게 찾아가서 불쾌감을 표시하기도 한다. 우리 손을 거쳐야 온전한 배포이며, 우리를 거치지 않는 것은 보증할 수 없다.

Project 입장에서 QA는 Protect 하는 입장에 가깝다. 사용자나 인터페이스에서 검증하지 않은 상태에서 오픈하는 것은 회사, 제품, 서비스, 시스템 전반에 악영향을 줄 것이 뻔하기 때문이다. 모두 알다시피 “테스트 활동은 버그가 있음을 보여주고, 반대로 없음을 증명할수는 없다”(관련 링크). 그러므로 우리가 하는 활동은 유의미하고 그로 인하여 발생할 위험을 막는 최종 행위(Hurdle)라고 생각한다.

지금 돌아와 이런 글을 쓰게 된 이유를 다시 고민해보니, 체계가 잘 잡히고 절차대로 작업대로 진행하는 조직이 있는 반면에 어느 조직은 빅뱅 테스팅에 익숙한 것은 아닌가 싶다. 단순히 Testing 활동만으로 product의 완성도를 순간적으로 기여할 수 있겠지만 연속적인 활동에 있어 QA가 배제된다면 그 조직의 미래는 어두울 것이다.

 

마지막으로 QA로써 IT를 이끄는 인원들이 업의 Special Point에 머물지 말고 General Point에서도 리드할 수 있도록 꾸준한 자기 계발로 발전을 주도했으면 한다. 😘 Good Luck!!!