"QA 직무를 준비하고 있는데, 자격증은 어떤 것을 따는 게 좋은가요?"
QA 직무로 전환하거나 준비중이신 분들이 가장 많이 물어보는 위 질문에 관련된 포스팅을 한번 해볼까 합니다.
QA 업무를 위한 준비
대다수의 QA 역할을 시작하려는 분들과 대화해 보면 자격증부터 준비하게 된다는 말을 많이 들었습니다.
QA의 준비는 왜 자격증 준비부터일까요..?
현실적으로 QA는 자동화 관련 엔지니어 역량을 쌓는 것을 제외한 매뉴얼 QA 역할은 혼자서 경험해 보기는 정말 어렵습니다.
매뉴얼 QA의 핵심 역량은 소통이라고 생각되는데, 이것을 혼자 학습하면서 경험할 수 있는 환경이 없으니까요.
그럼 혼자서 학습하는 방법은 무엇인가를 생각해봤을 때 자격증을 공부하며 실무에 활용될 수 있는 능력을 쌓는다라고 생각합니다
위 화면처럼, 다양한 공고에서 QA 관련 자격증을 자격요건이나 우대사항으로 목록에 적어두는 경우가 많습니다
때문에 자연스럽게 QA 관련 업무를 진행하려는 분들은 자격증을 준비하게 되고, QA 직무를 경험해보지 못한 분들은 어떤 업무를 진행하는지 확인해 보는 준비과정이 될 수 있습니다.
그리고 QA를 담당하고 계신분들은 더 좋은 업무 프로세스나, 업무에 활용할 기술을 학습하는 방식으로 기초 단계 이상의 자격증을 준비합니다.
이처럼 QA 자격증 ISTQB, CSTS를 준비하며 QA라는 역할을 미리 알아보거나 더 좋은 업무를 활용하기 위해 자격증을 준비합니다.
저도 개발자에서 QA로 전향할 때 가장 먼저 자격증을 준비하기도 했고, 경험해보지 못했던 QA 역할을 미리 학습하면서 내 적성과 맞는지 확인하고, 더 잘 맞는다고 판단되어 QA 전향을 확정했습니다.
그럼 이 포스팅은 QA 자격증을 취득해! 취득하면 좋아 일단 취득해 봐.
이런 내용을 담는 포스팅일까요...?
자격증은 왜 취득했어?
솔직한 마음으로 저도 취업에 도움 되기 위한 생각으로만 자격증을 준비하고 취득했습니다.
이거 거의 QA 업계의 운전면허증 같은 거 아니야...? 이거로 일하려면 기본 레벨은 다 있어야 하니까 따야겠다.라고 생각했죠
(나만 그랬나...?)
이렇게 생각해서 그런지 ISTQB, CSTS의 기본 레벨 자격증을 취득하고, 어떤 점이 도움이 되었는지에 대한 질문에 명확하게 대답을 하지 못했던 경우가 있었습니다.
정말 취업용 자격증이었나?를 생각해 봤을 땐 전혀 그렇지 않았습니다
정리를 해본 적이 없어서 떠오르지 않았지만, 실무에 적용한 기법들이 곳곳에 포함되어 있었거든요.
운전면허증도 운전을 하기 위해 취득하는 것처럼, QA 자격증도 업무에 잘 사용될 수 있게 취득한다는 것을 다시 한번 떠오르게 하면서 어떻게 도움이 되었는지를 한번 작성해 보겠습니다.
자격증 내용을 활용한 방법은?
자격증을 취득하고 내가 했던 업무 중 어떤 부분에 도움이 되고 있었을까?
자연스럽게 하다 보니 했던 일들을 한번 정리해 볼 겸 직접적인 도움이 되었던 부분에 대해 정리해 보겠습니다.
테스트 케이스를 작성하기 전, 자연스럽게 체크리스트를 수행
기획팀으로부터 기획 문서를 받으면 항상 확인해 보는 체크리스트가 생겼다는 것입니다.
1. 새로운 기능에 대한 내용을 확인할 때 사용자가 수행할 수 있는 정상 동작에 대한 내용 검토 후 정상 TC 작성
- Happy Path Test, 기획 문서에 작성된 기능에 맞도록 기능을 정상적인 동작으로 수행해 보는 TC
2. 글자 제한, 용량 제한, 등록 수 제한 등 기능 동작에 제한 요소가 있는 TC 작성 및 비정상 동작 시 안내 기능 여부 확인
- 경계값 테스트, 유효성 검사 등 제한 요소가 기획 의도와 맞도록 통제되는지 확인하는 TC
3. 내가 사용자라고 생각하고, 불편한 점은 없는지, 개선사항은 없는지 검토
- 오류 추정 기법, 닐슨의 사용성 테스트를 위한 10가지 휴리스틱 평가 기준처럼, 사용성을 고려한 기획 문서 검토
위 항목처럼 기획 문서를 받게 되면 자연스럽게 체크하는 항목들이 생겼다는 것이고, 사용자의 입장에서 생각해 보는 관점이 생겼다는 것입니다.
복잡도가 높은 로직을 하나씩 정리하면서 효율적인 테스트 진행
여러 조건이 합쳐져서 테스트를 수행해야 할 때 수행 방식을 정리하고 어떤 방식으로 테스트를 진행할지 전략을 구성할 수 있었습니다.
실무에 적용했던 사례를 적어본다면 테스트 대상은 아래와 같았습니다.
환경은 고객과 상담사 채팅 상담 플랫폼에서 대화 진입 방식에 따른 응답 메시지 확인하는 작업이었습니다.
자동 응답 메시지 전달 상황
- 대화 가능한 상담사 유무에 따른 응답
- 고객이 미리 대화 주제를 선택할 수 있는 토픽 유무에 따른 응답
- 센터 환경에 따른 응답
간략하게 3가지로 줄였지만, 실무를 진행할 때는 더 많은 조건들이 있었어서, 검증하기 까다로웠던 작업이었습니다.
결정 테이블 방식처럼 설정 가능한 상황을 정리해 보고, 수행이 불필요한 조합을 정리해 본 뒤 TC를 생성하는 작업으로 진행했습니다
하나씩 생각하는 것보다 전체적인 흐름을 파악하고, TC를 생성하는 방식을 활용한 것이 효율적인 테스트 구조를 만들 수 있었다고 생각됩니다
이렇게 나열하면서 체크하는 것도 좋지만, 시간이 많이 걸리기 때문에, 페어와이즈 기법과 함께 활용하면 좋습니다.
센터운영: O, X
상담사상태: O, X
토픽설정: O, X
위 조건이 이렇게 구분되고, 센터가 없는 경우 상담사의 상태는 의미 없다는 조건을 추가해서 PICT 툴을 활용해서 계산해본다면
CENTER: O, X
USER: O, X
TOPIC: O, X
IF [CENTER] = "X" THEN [USER] = "X";
이렇게 테스트 데이터를 입력할 수 있고, 그 결과는 위 엑셀과 동일하게 출력됩니다.
사용한 툴은 아래 사이트에서 확인할 수 있고, 조건을 텍스트로 정리할 수 있다면, 복잡한 로직을 테스트케이스로 만들 때 유용하게 사용할 수 있을 것 같네요 :)
https://pairwise.yuuniworks.com/
Pairwise Pict Online
pairwise.yuuniworks.com
그리고, 다른 예시로 페어와이즈 기법을 활용한 방식도 활용한 사례도 정리해보겠습니다.
위의 이미지처럼 필터 항목의 검증을 하려면 3x2x2x2 = 24개의 조합이 있으나, 조건을 조립해서 TC를 수행하는 방식입니다.
위처럼 PICT 툴로 계산할 수도 있지만, 요즘은 AI를 활용해서 바로 TC를 구성할 수 있는 방식을 활용한다면 더 빠른 결과를 얻을 수 있습니다.
Claude의 결과를 확인해 보니, 8가지 케이스로 줄여주게 되었고, 이에 해당하는 티켓을 만들어서 필터 기능에 대한 검증할 수 있었습니다. (AI 없이 못 살아...😢)
필요에 따라 프롬프트를 변경해서 중요도 높은 테스트 케이스는 필수로 추가해서 TC를 구성할 수도 있습니다.
개발 프로세스 단계에 참여하는 것이 당연하게 느껴졌고, 일부 프로세스 개선 참여
체계적인 QA 팀이 있는 경우에는 다르겠지만, 제가 업무 했던 환경은 큰 틀은 있지만, 상세한 프로세스의 개선이 필요했습니다
테스트의 시작조건, 종료 조건이 불명확했고, 개발팀에 이끌리는 QA 활동을 할 수밖에 없던 환경이었습니다.
그러다 보니 자연스럽게 설정한 테스트 기간이 개발 기간으로 변경되며, 부족한 테스트 기간에 어떻게든 검증을 해야 하는 상황이 흔하게 발생했죠. 현재도 많은 기업에서 이런 방식으로 진행되는 것 같습니다.
조금이나마 테스트 기간을 효율적으로 사용하기 위해 기획, 개발 변경사항을 모니터링하며 이슈를 확인하고, 테스트 기간 전 개발 서버에서 개발된 기능을 확인해 보며 어떻게 테스트할지 생각해 보는 과정을 진행했습니다.
그러다 보니 테스트를 수행할 수 있는 환경인지 미리 알 수 있어서 갑작스러운 기간 조율에 대응할 수 있었고, 결함의 중요도에 따라 최소 기준을 만들어서 종료 조건을 명확하게 수립하며 QA의 힘을 조금이라도 높여보려는 방향으로 진행했습니다.
자격증에 나오는 SDLC 모든 활동에 상응하는 테스트 활동을 도입하는 방식을 활용했고, 반복적인 테스트 작업을 줄이기 위해 자동화 환경도 만들어서 운영하기 시작했습니다.
프로세스의 참여하는 방식은 이전에 작성했던 포스팅을 참고해 주세요!
2025.10.20 - [QA/업무 방식] - 테스트? 그냥 하면 되는 거 아니야? STLC란? 무엇...?
테스트? 그냥 하면 되는거 아니야? STLC란? 무엇...?
테스트라는 단계를 가볍게 생각할수록 개발이 중요한 거지, 테스트? 그냥 오류 없는지 확인하면 되는 거 아닌가?라고 생각될 수 있습니다. 하지만, 테스트..? 어떤 테스트를 어떻게 할건데? 우린
qa-subi.tistory.com
테스트 케이스의 우선순위를 선정하고 상황에 맞는 대응 진행
리스크 기반 우선순위를 지정해서 TC를 관리해야 한다, 커버리지가 높은 테스트 케이스를 작성해서 우선적으로 수행한다.
위 내용은 ISTQB에 나오는 내용인데, 실무에서 정말 많이 활용했던 방식이었습니다.
배포 기간이 짧을수록 테스트 기간도 줄어들고, 기능이 정상적으로 동작하는지 우선적으로 확인해야 했으니까요.
그래서 초기 품질을 확인하는 스모크 테스트 방식이나, 필수 사용자 시나리오를 구성해서 시간이 없는 경우 이 TC라도 수행해야 한다는 것을 구성하여 프로세스를 운영하게 되었습니다.
하지만 이것도 동일한 테스트를 매번 하는 것이었기 때문에, 효율적인 공수 조율을 위한 자동화가 필요했고, 환경을 구성해서 필수 테스트를 수행하는 프로세스를 구축하게 되었습니다.
실제로 자동화를 처음 도입할 때 필수 테스트를 수행하는 것을 목표로 잡고, 이후 범위를 늘려가는 방식을 추천드립니다!
끝으로 정리해 보자면, 이번 포스팅은 자격증을 취득했지만, 분명 도움이 되었는데 언제 도움이 되었지...? 어떻게 활용했는지에 대한 정리를 한 번도 해본 적이 없어서 정리해 보게 되었습니다.
저도 당연한 업무 방식이라고 생각했던 것처럼, 현업에서 QA 업무를 진행하시는 분들이라면 당연하게 생각했던 내용일 수 있고, 더욱 체계적인 방식을 활용하는 회사도 많을 것이라 생각됩니다.
그래서 ISTQB를 취득해야 해? CSTS를 취득해야 해?라고 물어본다면, 저는 둘 다 취득하는 것을 추천드리긴 합니다.
내용적으로도 겹치는 부분이 많고, 두 자격증 다 업무에 도움이 된다고 생각하거든요.
QA라는 프로세스를 익히는 것에 도움을 주는 ISTQB와 실무에서 활용하는 용어를 많이 사용하는 CSTS라고 생각되고, Claude는 아래처럼 정리해서 알려주긴 하네요
실제로 업무를 진행할 때 실무 용어적으로 많이 사용했던 것은 CSTS에서 나왔던 용어들을 많이 사용했던 것 같습니다.
ISTQB의 FL 기준으로 확인한 내용이고, FL 이후의 고급 단계의 자격증까지 고려한다면 ISTQB가 더 좋을 수 있습니다.
뭐가 됐던, 자격증을 취득하고 내용을 실무에 잘 적용해서 사용할 수 있는지에 더 초점을 두는 것이 좋을 것 같네요!
생각보다 길어지긴 했는데, 읽어주셔서 감사합니다 :)
'QA > 업무 방식' 카테고리의 다른 글
| AI 잘 쓰시나요?가 아닌 프롬프트 잘 쓰시나요? (3) | 2025.10.26 |
|---|---|
| 테스트? 그냥 하면 되는거 아니야? STLC란? 무엇...? (4) | 2025.10.20 |
| SDLC(개발 방법론)와 활용 모델에서 QA는...? (2) | 2025.10.15 |
| QA 업무를 진행하면서 AI를 활용한 방법 (0) | 2025.09.30 |
| 테스트 레벨 별 비정상 테스트 케이스 작성 방식 (매뉴얼 TC) (3) | 2025.08.24 |
