<1> SW QA란 무엇인가?
QA for Beginners
QA란 무엇인가?
제삼자가 QA는 무슨 일을 하냐고 질문했다면, 당신은 뭐라고 답할 것인가?
혹시 테스트하는 사람, ‘테스터’를 먼저 떠올렸는가? QA 종사자에게 QA가 테스트를 하는 일이냐고 물어본다면 그 이상의 것을 한다는 걸 설명하기 위해 입이 근질근질할 것이다. 하지만 IT산업 종사자에게 물어본다면 아마 대체로 그렇다고 할 것이고, QA를 잘 모르는 사람들이라면 그렇지 않냐고 오히려 반문할 것이다.
물론 인지도의 차이도 있지만, QA가 흔히 테스터로 설명되는 이유는 3가지라고 생각한다.
첫째, 직무 이름 자체가 직관적이지 않기 때문이다. ‘개발자’는 무언가를 만들 것이며, ‘기획자’는 대충 계획 같은 것을 하겠구나라고 연상이 되지만 QA는 전혀 그렇지 않다. Q&A냐고 묻지나 않으면 다행일 것이다.
둘째, 여기에 더해 품질 보증이니, 검수니, 프로세스니 하는 설명들은 테스트라는 설명보다는 분명 추상적이다. 실무에서야 개괄적으로 설명했을 때
기획 리뷰 > 공수 산정 > TC 작성 및 문의 > TC 리뷰 > TC 수행 및 이슈 등록 > Sign Off
으로 이어지는 프로세스를 이미 몸으로 겪고 있고, 이슈를 발견하며 결함도를 줄이고 있음을 알고 있지만, 이것을 말로 설명할 때는 업무의 내용 자체가 특정한 대상을 지칭할 수 없는 용어로 설명할 수밖에 없다. 아무리 잘 설명하더라도 대부분의 사람들은 ‘그래서 무슨 일을 한다고?’ 라며 반문할 것이다.
셋째, 결국 가장 메인이 되는 업무가 테스트이기 때문이다. 적어도 우리나라에서는 그렇다. 비중의 차이는 있지만, TE, TL을 거쳐 QA 이상을 맡게 되더라도 결국 핵심이 되는 활동은 결함이 존재한다는 것을 증명하는 것이며, 이 결함 발견의 활동에서 QA가 프로세스 기반의 활동만 할 수 있게 해주는 회사는 많지 않다. 테스트 활동을 배제할 수가 없다 보니 ‘결함의 발견’이라는 표현이 ‘테스트 수행’으로 받아들여지는 경우가 많다.
QA는 무슨 일을 하는가?
그래서 QA는 무슨 일을 하는가? 우선 그전에, 두 가지를 알아야 한다. 첫째, 프로젝트를 수행할 때 QA 내에서도 역할이 나뉘며, QA는 그 역할들 중 하나다. 개괄적인 관점에서 로드맵을 표현하자면 TE < TL < QA로 표현할 수 있고, TE에서 QA로 갈수록 프로젝트를 리드하는 역할을 맡는다. 둘째, 이렇게 역할이 나뉘는 이유와 QA가 테스트 이상의 것을 한다고 하는 데에는 소프트웨어 제7원칙, 그중에서도
테스팅은 개발 초기 단계에서부터 시작해야 한다
라는 원칙을 얼마나 잘 수행할 수 있느냐가 중요하게 적용된다는 점이 있다. QA 마다 생각하는 정의나 회사마다 수행하는 업무에는 다소 차이가 있기 때문에, 각 포지션에 대해 이해하기 쉬운 방향으로 정리했다.
TE는 Test Engineer를 뜻하며, 당신이 생각하는 그 테스터가 여기에 속한다. 이미지가 잘 노출되는지, 버튼 클릭에 따라 활성화 또는 비활성화가 되는지, 소리는 잘 나오는지와 같은 테스트를 하며 결함을 찾는 활동을 수행한다.
실무에서는 보통 TC를 작성하고, TL에게 할당받은 영역을 테스트하고, 결함을 발견하여 Jira와 같은 BTS(Bug Tracking System, 이슈 관리 도구 중 하나이다)에 리포트한다.
TL은 Test Lead를 뜻한다. 무엇을 테스트하느냐는 출시하려는 프로덕트의 목적에 따라 달라지므로, 어떻게 테스트할 것인지에 대해 테스트 방법을 계획하고 테스트를 수행할 인원(TE) 및 테스트로 발생하는 산출물(e.g., QA Plan, QA Status, Sign Off와 같은 리포트)을 관리하는 활동을 수행한다.
실무에서는 보통 타깃 프로덕트의 테스트 범위를 확인하고, 필요한 인원과 QA기간을 정하고(공수산정), QA 시작 전 QA Plan을, QA 기간 동안 QA Status를, QA 완료 후 Sign Off 리포트를 작성해 유관 부서에 전달한다.
QC는 Quality Control, 즉 품질 관리를 뜻한다. 기획대로 프로덕트가 개발되었는지, 기능이 정상 동작을 하는지 검증하고 결함을 찾아 보고하는 활동을 수행한다.
QA는 Quality Assurance, 즉 품질 보증을 뜻한다. 테스트 중 어떤 결함을 발견했다면 QA는 프로세스 전반을 평가하고, 보다 효율적으로 조기에 개선할 방법을 고민하는 활동을 통해 그 결함이 두 번 다시 일어나지 않도록 예방한다.
예를 들어 기획 리뷰 단계에서 결함을 발견하고 논의한 끝에 해당 내용을 제외하기로 협의했다면, 개발팀은 해당 내용을 구현하지 않아도 되므로 개발 완료 후 결함을 발견하는 것보다 공수가 적게 들 것이다. QA Engineer 또는 QA Manager로 나누기도 하는데,
QA Engineer는 테스트 활동을 포함해 자동화, 코드 분석 등 상위 테스트를 ‘수행’하는 활동에 포커스를 두고,
QA Manager는 인원이나 일정뿐 아니라 기획, 개발을 아우르는 전체 프로세스 관점에서 효율적으로 프로덕트를 개선하기 위해 유관 부서들과 협의하는 등 프로세스 지향적으로 ‘관리’하는 활동에 포커스가 맞춰져 있다.
역할을 명확히 구분해야 하는 이유
만성적인 인력난과 일정의 압박이 원인이기도 하지만, 정의 자체도 각 역할의 영역을 명확히 구분하기 애매하다. 특히 우리나라에서는 역할들의 관계가 부분집합 관계이다. 즉, QA는 TE와 TL의 업무도 겸하며, TE가 TL 대신 리포트를 작성하게 될 때도 있고, TL이 기획 내용 중 발생할 수 있는 예상 결함에 대해 문의하기도 한다. 귀에 걸면 귀걸이, 코에 걸면 코걸이인 식이다.
또한 QC는 정의 상 TL과 TE를 통칭해서 부르는 역할이라, 엄밀히 말해 우리가 QA라고 생각하는 활동은 사실 QC 활동이다. 제조업에서 많이 사용하며 IT업계에서는 잘 사용하지 않다 보니 채용 시장에서도 이들을 혼용해서 부르곤 하는데, QA Engineer로 명시했지만 JD(Job Description, 요구 사항)에서는 TE 수준의 경력을 요하기도 하고, 또는 QA로 입사했더니 TL 수준의 업무를 하게 되는 경우가 많다.
또한 QC는 정해진 테스트 기준에 맞춰 프로덕트를 ‘검증’할 뿐, 결함에 대한 기준을 세우지 않지만 QA는 테스트 기준을 정하고, 관리하고, 결함을 예방하도록 개발 등의 유관 부서와 소통할 수 있다는 차이점이 존재한다.
역할의 정의에 대해 옳고 그름을 논하려는 것이 아니다. 뭐라고 불리든 어떤 업무를 맡게 되든, 테스트 활동은 가장 기본적인 것이며, 상위 직책으로 갈수록 인원과 일정의 관리, 프로덕트 요구 사항에 대한 높은 이해, 유관 부서와의 커뮤니케이션 능력을 요한다는 것을 이해하는 것이 중요하다. TE로 QA 경력을 시작해 본다면 이 일이 아무나 할 수 있겠다는 생각이 들 것이다. 실제로도 일부 회사에서는 지원자의 경력과는 상관없이 특별한 결격 사유가 없다면 일단 채용하는 경우도 많다. 그것도 QA라는 명칭으로 말이다.
이러한 로드맵을 염두에 두지 않는다면 TE 수준에서 버그를 잘 찾는 능력에만 몰두하며, 테스터에서 벗어나지 못하고 있다는 것도 모른 채 QA를 잘하고 있다는 착각을 하다 한 순간에 어제 입사한 신입과 별다른 차별점 없이 경력만 쌓인 자신의 모습을 발견하게 될 것이다.
당신은 QA를 하고 있는가?
다시 돌아와서 정리해 보자. 이제 QA가 무슨 일을 하는지 설명할 수 있겠는가?
QA는 코치다.
코치는 선수들을 평가하고 훈련 프로그램을 설계하며, 선수들을 옳은 방향으로 이끌어 대회에서 성과를 내도록 돕는다.
QA는 프로덕트를 평가하고, 프로세스를 평가하며, 효율적인 방식으로 개선하도록 유관 부서와의 커뮤니케이션을 통해 팀을 이끌어 완성도 높은 프로덕트를 세상에 내보일 수 있도록 돕는다.
완성도 높은 프로덕트의 비밀은 결함을 예방하는 데에 있으며, 테스트는 결함 예방을 위한 방법 중 하나에 불과하다는 것을 이해하고 앞으로의 커리어에 대한 방향을 설계하길 바란다.
당신은 QA를 하고 있는가? 혹은 QA를 하고 싶은가?
