QA for Beginners
이전에 소프트 스킬을 다뤘다면, 이번에는 하드 스킬에 대해 이야기해보고자 한다. 하드 스킬은 소프트 스킬과 달리 능력의 정도를 가시화하기가 쉽다. 그중 자격증은 능력을 가시화하기 좋은 대표적인 예이다. QA와 관련된 여러 자격증이 있지만 이번 주제에서는 ISTQB-CTFL을 기준으로 다뤄보겠다.
QA에 입문했다면 아마 ISTQB라는 자격증을 들어봤을 것이다. 회사에서 권유하거나 지원해주기도 하고, 채용 공고에서 우대 사항에 심심찮게 등장하며, 간혹 필수로 요구하는 곳도 있기에 관심이 없더라도 한 번쯤 알아보게 되는 자격증이다. ISTQB의 경우 예전에는 영어로만 시험을 볼 수 있었지만 비교적 최근에는 한국어로도 응시가 가능하여, ‘그럼 한번 볼까?’ 하고 홈페이지에 들어갔다가 금액을 보고 ‘나중에 볼까?’ 하며 생각을 고쳐먹곤 한다. 더구나 Syllabus를 보면 당장 내가 하는 일과 다소 동떨어진 이야기가 많아, 어디에 도움이 되는지 의문까지 들게 된다.
결론부터 말하자면, 자격증은 필요 없다. 정확히 말하면 자격증을 취득할 필요는 없지만, ISTQB Syllabus의 내용은 공부할 필요가 있다. 그 이유는 자격증 취득을 위한 투자 가치 대비 취득으로 얻는 효용성이 현저히 낮기 때문이다.
ISTQB의 1회 응시료는 약 20만 원으로, 학교에 재학 중이라 학생 할인을 받는다 하더라도 응시료는 대략 15 ~ 20만 원 선이다. 문제는 QA가 의사, 전기기사와 같이 지식이 있어야 실무를 할 수 있는 직군이 아니라, 실무를 하면서 직접 배워나갈 수 있는 직군이라는 데 있다. 특별한 연구직이 아닌 이상 개발자에게 자격증을 요구하는 회사가 있다는 소리는 들어보지 못했을 것이다. QA도마찬가지다. 모르는 개념들은 ISTQB에서 제공하는 Syllabus와 구글링으로 충분히 알 수 있으며, 이를 적용하는 능력은 팀과 협업하는 과정에서 충분히 기를 수 있다.
또한 ISTQB에서 다루는 테스트 방법론들은 실제 업무에 적용하기에는 다소 괴리감이 있다. FM대로 100% 모든 과정을 적용할 수 있다면 분명 공인된 적격 한 검증을 마쳤다고 자부할 수는 있으나, 현실은 그럴 정도로 리소스가 많지 않은 경우가 대부분이다. 기획 리뷰를 받지 못하는 경우도 있고, 기획 리뷰 후 TC 작성 기간 중에 hotfix가 들어오는 바람에 우선순위가 변경되어 나머지절차를 수행하지 못하는 경우도 있다. 물리적 기간은 여유 있으나 인원이 부족한 경우도 있고, 프로덕트의 특성상 배포 주기가 빠르거나 개발 모델 자체가 Agile 한 방식으로 개발하는 등의 이 유로 근본적인 프로세스부터 설계해야 하는 경우도 있다.
채용 및 추후 이직 시에 얻는 이익 또한 크지 않다. 트렌디하고 QA를 잘 아는 회사일수록 자격증의 보유 여부를 큰 플러스 요인으로 보지 않는다. 그러므로 ISTQB 자격증을 필수로 요구한다면 그렇지 않을 회사일 가능성이 높다. 왜냐하면 ISTQB 자격증 보유라는 요구사항을 넣고, 면접을 보는 사람도 결국 같은 필드에서 일하는 QA이다. 제대로 된 실무 경력을 가진 면접관이라면 ISTQB를 취득했다고 해서 실무에서 탁월한 퍼포먼스를 보여줄 수 없다는 것을 누구보다 잘 알고 있다. 우리나라의 정서 상 채용희망자도 무언가 보여줄 수 있고, 면접관도 직관적으로 ‘음, 이 정도는 아는 사람이군.’ 하며 실력을 파악하기 용이하기에 관습처럼 필요성을 강조하곤 한다. 하지만 앞서 말한 이유로, ISTQB 자격증 유무에 대해 따지는 회사일수록 QA의 사정을 잘 모르거나 배울 것이 없는 회사임을 방증한다. 유능한 QA로 성장하고 싶다면 정확히 반대인 회사에서 일하고 싶을 것이므로, 독자가 원하는 회사로 이직하는 데 불이익은 없다고 단언할 수 있다.
자격증을 취득할 때까지 1회 당 에어팟 하나 가격에 맞먹는 응시료를 투자할 바에,
그 돈으로 자기 계발에 투자하길 권한다.
하지만 자격증이 필요 없다는 말의 의미를 공부를 안 해도 된다는 의미로 받아들이면 안 된다. 이제 막 입문했거나 QA를 알아보는 사람, 또는 백그라운드 지식이 부족한 사람에게는 ISTQB 공부를 함으로써 업무 이해도를 높일 수 있다.
공부가 필요하지 않은 직업은 없다. 하지만 어리석게도 나의 경우 이 당연한 사실을 잊은 채이직을 결심하기 전까지는 '자격증 없어도 됨'과 '공부 안 해도 됨'을 동의어로 여겼다. 그때까지도 나는 TC 잘 쓰고, 결함 잘 찾고, 적절한 수행 속도, 좋은 커뮤니케이션 스킬과 여러 회사들과 일해본 경험을 갖고 있으니 괜찮은 실력을 갖춘 주니어라고 착각했기 때문이다. 그렇게 면접을 보러 가서
기능과 비기능 테스트의 차이가 뭘까요?
Agile 한 환경에서는 QA 프로세스를 어떻게 구축하셨나요?
와 같은 질문을 받았을 때, 속수무책으로 당할 수밖에 없었다. 실무에서 이런 용어들을 자주 사용한 적도, 이를 고민하며 QA를 한 적도 없었기 때문이다.
스스로에게 가장 화가 났던 경우는 면접관이 TC 작성 시 적용해 본 테스트 기법이 있는지를 물어봤을 때, 내가 평소 TC를 쓸 때 종종 하던 기법임에도 불구하고 그것이 용어로 정의된 기법 중하나인 것을 몰랐을 때였다. 예를 들어 범위가 정해진 텍스트필드의 유효성 체크를 할 때
명세 기반 기법(Specification-based technique)의 동등 분할(Equivalence Partitioning)과 경곗값분석(Boundary Value Anaylsis)을 사용합니다.
라는 설명을 못해서 '범위를 이렇게 저렇게 나눠서..'로 운을 떼고 말았다. 그리고 당연하게도 만족스럽지 못한 면접관의 표정과 마주했다.
백그라운드 지식을 위해 개발자가 CS(Computer Science) 공부를 하듯, QA도 QA 공부가 필요하다. QA 카페에서 소프트웨어공학과 테스팅 공부가 필요하다는 의견을 보았는데, 나도 여기에 동의한다. 이들을 공부하면 소프트웨어공학은 프로세스, 즉 숲을 보는 능력을, 테스팅은 결함, 즉 나무를 보는 능력을 키울 수 있을 것이다. ISTQB, 소프트웨어공학, 테스팅, 무엇이 됐든 상관없다. QA로서의 전문성 확보를 위해 본인이 가장 부족하다고 판단한 부분부터 공부해두길 권한다.
나의 사례를 예로 들었듯, 면접관이나 어느 정도 경력을 가진 QA는 몇 가지 질문으로도 앞에 앉은 이 사람이 QA 지식이 있는 사람인지, 아니면 단순 테스터인지 판단이 가능하다.
1회에 20만 원 상당의 시험비를 지불하고 자격증을 취득했지만 백그라운드 지식으로 활용하지 못하는 QA
그리고
자격증은 없지만 백그라운드 지식을 프로젝트에 적용해 보려는 QA
당신이라면 전자와 후자 중 누구와 같이 일하고 싶은가?
자격증 '취득‘이라는 수단보다 자격증을 취득하는 ‘목적’을 우선 고민해 보길 바란다.