소프트웨어 테스팅(Software Testing)
Test Engineer(TE)가 제품 또는 서비스가 특정 요구사항을 충족하는지 개발 후반부에 Product의 기능적 측면에서 테스트를 수행하고 결함을 찾는 역할을 한다면,
❆ Quality Assurance(QA)는 문제를 해결하는 것이 아니라 문제를 예방하고 방지하는 일을 하는 사람입니다. 파이프라인을 통해 이슈가 유입되는 경로를 확인하여서 원인을 제거하고, 제품이 필요한 수준 이상의 품질을 달성했는지 평가하고, 품질에 영향을 미칠 수 있는 요소를 정의하거나 개선하고, 품질 목표를 달성하기위해 프로젝트를 전반적으로 컨트롤 하는 역할을 합니다. ❆
때로는 이론적 개념으로서의 QA정의보다 저자가 생각하는 개인적 관점에서의 업무 철학에 대한 질문을 받곤합니다. “당신이 정의하는 QA란 무엇인가요?”
이 질문에 대해 남들과 다른, 유니크하고 특별한 대답을 들려주고 싶은 욕심에 질문을 곱씹어보고 새로운 정의들을 내려보고 실무에서의 다양한 사례와 회사마다 차별화된 품질 관리 활동을 겪으면서 저또한 성장을 거듭하는 과정속에서 질문에 대한 답변도 점점 발전해가는 것을 느꼈습니다. 그렇게 최종적으로 정리된 저의 업무 철학과 그 속에 녹아든 QA에 대한 정의를 소개해드립니다.
- 루트비히 비트겐슈타인(Ludwig Josef Johann Wittgenstein)
독일의 철학자 루트비히가 했던 말을 인용하여 저의 업무 철학에 적용하고 있습니다. 제품의 품질은 다양한 상황, 환경, 도구, 인간, 시간 등 영향을 미치는 모든 요소로부터 위협을 받을 수 있습니다. 품질을 검증하고 관리하는 QA라면 생각의 틀을 벗어나 편파적이지 않고 관행을 따르지 않는 남들과 다른 시선에서 문제를 볼 수 있어야 합니다. 정상적인 환경에서의 제품의 동작만 보는 것이아니라 반대되는 환경에서 발생될 수 있는 문제까지 폭넓은 이슈 유입경로와 이슈 요소, 해결법을 찾아내는 감각을 가져야 합니다.
일을 하다보면 항상 시간에 쫓기거나 부족한 상황들을 만납니다. 빠르게 처리하고자 편법을 쓰기도 하고 ‘결과가 완벽할 필요는 없다고, 결함을 100% 찾는 것은 원래 불가능한 일이라고, 그러니 이정도만 테스트해도 괜찮다’고 자신과 타협하기도 합니다. 또는 빠르게 변화하는 시장과 고객의 요구사항에 응하기위해 테스트 단계만이라도 빨리 처리할 수 있는 방법을 찾으라는 요청을 받기도 합니다.
이렇듯 업무 중에는 항상 다양한 사건과 사고가 발생됩니다. 지금 맞닥뜨린 사건을 피하기위해 일을 빨리 처리해버리는 대신 품질을 포기할 것인가, 아니면 QA로써 마땅히 해야할 일을 충실히 수행할 것 인가 결정해야 합니다. 품질을 포기하고 일을 빨리 처리한다면 결과물을 빨리 얻을 수는 있습니다. 하지만 그렇게 얻은 결과물에서 파생되고 재생산된 결함은 손을 댈수 없는 수준이 될 수 있고, 제품을 포기하게 만드는 원인이 될수 있습니다. QA로써 마땅히 해야할 일을 충실히 수행한다는 것은, 주어진 조건내에서 최대한의 품질을 확보하기 위한 전략이 포함되어있다는 것을 의미합니다. QA가 제품을 이해하고 있다면 가장 심각한 리스크를 판별할 수 있고, 무엇을 테스트 해야하는지 알며, 일의 우선순위를 결정할 수 있습니다. 빨리 가는 것보다 우리의 목표가 어디인지알고 목표를 향해 가는것이 더 중요합니다. 품질에 대한 바른 태도를 가지는 것이 일을 제대로 처리할 수 있는 가장 빠른 길입니다.
1973년 10월 5일 이스라엘 안전보장 회의는 만에 하나 있을지도 모를 이집트의 침공 가능성을 논의 했지만 참석한 위원(9명) 모두 ‘절대 그런 일은 일어나지 않는다'고 결론을 내리고 침공에 대한 대비를 하지 않았고, 다음날인 10월 6일 이집트의 전면 공격을 받는 사건이 발생됩니다. 그 이후 도입한 규칙이 바로 10번째 사람 규칙입니다.
회의에서 합의된 다수의 결론에 무조건 반대하는 소수의 의견을 내고 결론의 맹점을 공격하고 막는 역할을 하는 사람을 의미합니다. 9명이 찬성하더라도 10번째 사람은 무조건 반대되는 상황을 생각하고 고려하여 불가능한 일이 발생될 상황을 가능성있는 시각으로 보고 이를 대처하는 역할을 하는 사람입니다.
QA가 이와 같은 역할을 해야합니다.
실제 현장에서도 ‘절대 일어나지 않을 일'은 우리의 예상을 엎고 매번 발생됩니다. 유저의 데이터 정보를 사람의 실수로 DB를 다 날려버리거나, 단말기 성능 조작으로 일부 애플리케이션의 성능을 저하시킴으로 인해 출시된 제품 자체를 벤치마크에서 제외하는 일(S사의 GOS성능 조작 사건) 등이 발생됩니다.
제품을 만들때 대부분은 일어나지 않을 일은 제외하고 해야할 일만 결정합니다. 하지만 제품의 결함이 어디서 발생될 지는 예측하기 어렵습니다. 다양한 제품의 결함을 경험하고 출시 노하우가 많은 QA가 발생될 수 있는 가능성을 가진 모든 경우의 수를 생각하고 문제상황을 예측하여 의견을 내고 대응 할 수 있는 전략을 마련하여 문제를 예방할 수 있도록 10th man의 역할을 해야합니다.
QA의 본질은 ‘서비스를 이용함에 불편함이 없도록 최고의 경험을 제공하는 것’, ‘문제를 거시적 관점에서 통찰하여 접근방식과 해결법을 찾는 태도', ‘사용자의 관점에서 의견을 제시하는 역할', ‘개발자의 생산성을 보장하여 재작업을 회피할 수 있도록 하는 것', ‘올바른 정보를 알고 항상 질문하는 자세', ‘협력의 리더십:다양한 상황/관점/의견을 듣기위한 소통과 오픈 커뮤니케이션’ 으로 정리할 수 있습니다.
어떤 역할을 수행하던 본연의 일과 부차적인 일, 본질적인 면과 지엽적인 면이 존재합니다. 의사의 본질은 진료와 치료를 잘하는 것, 변호사의 본질은 승소하는 것, 교사의 본질은 잘 가르치는 것입니다. 의사가 치료보다 마음씨 좋고 친절하다는 평가를 받는 것에 더 집중한다면, 변호사가 승소보다 수임을 따내는 것에 더 집중한다면, 교사가 학생을 가르치는 것보다 교내봉사 활동에 더 집중한다면 결국 본질을 잊은 그 의사와 변호사와 교사는 사회 구성원에게 나쁜사람, 책임없는 사람이라는 평가를 받을 것입니다.
내가 맡은 역할의 본질을 제대로 이해하고 불필요한 것은 제거함으로써 가장 중요하고 핵심이 되는 일에 집중하고 충실해야 하는 이유가 여기에 있습니다. 좋은 QA가 되는 것은 QA 본연의 역할과 본질에 충실한 것입니다. 그래야 생산성을 높일 수 있고 목표에 도달할 수 있으며 원하는 가치와 성과를 얻을 수 있습니다.
저년차부터 고년차까지 성장과 변화의 과정 속에서 내린 QA의 정의를 보며 이 글을 읽는 여러분의 개인적 업무 철학도 생각해보는 시간을 가져보기 바랍니다.
자신만의 업무 철학을 가진다는 것은 일을 진정성있게 대하면서 일을 즐기며 일을 지속적으로 할 수 있는 방법을 고민하게 만듭니다. 이것은 개인을 성장하게 하거나 변화하도록 만드는 원인과 계기가 될 수 있고, 자신이 보유한 핵심 역량을 증명하는 경험 스토리가 될 수 있습니다. 평범한 회사 생활과 당연히 해야할 업무들 속에 주어지는 다양한 상황들을 특별한 경험으로 만들수 있고 놀라운 혁신으로 바꿀 수 있으며 성취를 통한 성장을 이룰수 있게 할 것입니다.