4. 버그를 많이 찾는 QA보다는

4. 버그를 많이 찾는 QA보다, 제품을 오래 지켜본 QA가 가진 힘

QA 업무를 오래 하면 조금 이상한 능력이 생깁니다.

기능을 보는 순간 불안한 지점이 보입니다.

“이거 로그인 만료되면 어떻게 되지?”

“장바구니에 넣은 뒤 가격이 바뀌면?”

“쿠폰 적용한 상태에서 수량을 변경하면?”

“결제 버튼 두 번 누르면?”

“배송지 바꾼 다음 뒤로 가기 하면?”

“재고가 마지막 하나일 때 두 명이 동시에 주문하면?”

누가 시키지 않아도 이런 생각이 먼저 떠오릅니다.

처음 QA를 시작했을 때는 테스트케이스에 적혀 있는 Step을 따라갔습니다.

경력이 쌓이면 테스트케이스에 적혀 있지 않은 Step을 생각하기 시작합니다.

바로 그 변화가 QA의 성장입니다.

전자책은 커리어를 단순히 몇 년 동안 어떤 업무를 했다는 사건의 목록이 아니라, 문제를 만나고 해결하면서 사람이 어떻게 달라졌는지를 보여주는 이야기로 바라보라고 말합니다.

QA의 커리어도 그렇습니다.

3년 동안 테스트케이스 5만 개를 수행했다는 숫자도 의미가 있습니다.

하지만 더 중요한 것은 그 5만 개의 테스트케이스가 당신에게 어떤 감각을 남겼는가입니다.

어떤 변경이 위험한지.

어떤 개발 방식에서 Regression이 자주 발생하는지.

어떤 요구사항이 모호하면 반드시 버그가 생기는지.

어떤 로그를 먼저 봐야 하는지.

개발자에게 어떤 정보를 줘야 빨리 문제를 해결할 수 있는지.

출시 직전에 시간이 부족하다면 어디부터 검증해야 하는지.

이것들은 테스트케이스 문서에 그대로 적혀 있지 않습니다.

일하면서 몸에 쌓입니다.

그래서 좋은 QA는 모든 케이스를 똑같이 보는 사람이 아닙니다.

중요한 케이스를 알아보는 사람입니다.

앞으로 AI와 자동화가 발전할수록 이 능력은 더 중요해질 가능성이 높습니다.

기계는 수천 개 테스트를 빠르게 실행할 수 있습니다.

하지만 수천 개 중 어떤 테스트가 이번 Release에서 가장 중요한지는 누군가 결정해야 합니다.

자동화 결과가 99% Pass였다고 합시다.

좋은 QA는 99%라는 숫자에서 안심하기 전에 묻습니다.

“실패한 1%가 어떤 기능이지?”

만약 그 1%가 회사 로고 위치 문제라면 Release 판단이 달라질 수 있습니다.

하지만 그 1%가 결제 금액 오류라면 이야기는 완전히 달라집니다.

QA의 가치는 Pass와 Fail을 세는 데 있지 않습니다.

Fail의 의미를 판단하는 데 있습니다.

그래서 지금 수많은 TC와 Jira 티켓 사이에서 지쳐 있다면 한 가지는 기억했으면 좋겠습니다.

지금 하는 일이 모두 사라지는 것은 아닙니다.

테스트케이스는 Release가 끝나면 닫힙니다.

Jira 티켓도 Done이 됩니다.

Regression 결과 파일도 언젠가는 아무도 열어보지 않습니다.

하지만 그 과정에서 생긴 판단력은 남습니다.

전자책에서는 일의 경험을 그냥 흘려보내지 않고 성장 기록으로 남겨야 자신의 변화가 보인다고 이야기합니다.

QA라면 매주 한 줄만 기록해도 좋습니다.

“이번 주에 발견한 가장 위험했던 버그.”

“이번 주에 새롭게 알게 된 시스템 구조.”

“다음 Release에서 반드시 먼저 확인할 영역.”

“자동화할 수 있을 것 같은 반복 TC.”

“다시 발생하지 않도록 테스트케이스에 추가해야 할 조건.”

몇 달 뒤 그 기록을 보면 자신이 단순히 TC를 수행한 사람이 아니라는 것을 알게 됩니다.

서비스를 이해한 사람.

실패 패턴을 배운 사람.

Risk를 판단할 수 있게 된 사람.

제품의 약한 부분을 알고 있는 사람.

그것이 QA의 경험입니다.

쇼핑몰에서 고객은 QA의 이름을 모릅니다.

오늘 자신이 결제를 무사히 끝낸 이유가 누군가 며칠 전에 새벽까지 Regression을 했기 때문이라는 것도 모릅니다.

주문 취소 버튼이 정상적으로 동작하는 이유가 누군가 Jira에 버그를 등록하고 개발자와 몇 번이나 재현했기 때문이라는 것도 모릅니다.

좋은 QA의 역설은 아무 일도 일어나지 않는 것입니다.

고객은 평범하게 상품을 찾습니다.

평범하게 장바구니에 넣습니다.

평범하게 결제합니다.

그리고 평범하게 상품을 받습니다.

그 평범함을 만들기 위해 누군가는 수천 번 평범하지 않은 상황을 확인했습니다.

바로 QA입니다.

그래서 오늘 TC를 하나 더 Pass 처리하는 일이 작아 보이더라도 괜찮습니다.

Jira 티켓 하나를 더 작성하는 일이 지겹더라도 괜찮습니다.

자동화 결과 화면을 또 한 장 확인해야 해서 눈이 피곤해도 괜찮습니다.

그 과정에서 당신은 단순히 테스트를 ‘소모’하고 있는 것이 아닙니다.

제품을 보는 눈을 쌓고 있습니다.

그리고 언젠가는 수천 개의 테스트케이스를 전부 직접 수행하는 사람이 아니라,

어떤 테스트를 해야 하는지를 결정하고, 무엇을 자동화할지 설계하며, 결과가 의미하는 위험을 판단하는 QA가 되어 있을 것입니다.

오늘의 반복은 그곳으로 가는 과정입니다.

그러니 모든 TC를 사랑할 필요는 없습니다.

모든 Regression을 즐거워할 필요도 없습니다.

다만 오늘도 하나씩 쳐내고 있는 그 테스트들이 아무 의미 없이 사라지고 있는 것은 아니라는 것만은 기억했으면 합니다.

버그는 Done으로 닫히지만, 그 버그를 찾아낸 QA의 경험은 닫히지 않습니다.

그 경험은 다음 테스트에서 더 빠른 의심이 되고,

다음 Release에서 더 정확한 판단이 되고,

결국 더 좋은 QA를 만드는 자산으로 남습니다.

 

 

#QA경력 #QA전문성 #품질관리 #리스크기반테스트 #탐색적테스트 #제품이해 #커리어개발 #시니어QA #소프트웨어품질 #문제해결능력 #테스트전략 #버그분석 #직무전문성 #IT커리어 #제품개발