모든 IT 조직엔 '일명 QA' 업무가 있지만, 그것이 말뜻대로의 QA는 아니다. 테스터의 경험과 직관에 기반한 무작위 테스트에 의존하는 경우도 상당하고, 조직 구성상 PM/기획자가 겸업하기도 한다.
이런 상황에 놓인 '일명 QA'가 자신의 정체성을 지키는 가장 중요한 도구는 기술적 커뮤니케이션이다.
코딩을 하지 않더라도, API 문서를 읽고 이해하는 것만으로도 전문 테스터 나아가 QA는 겸업 테스터와 구별될 수 있다.
-
버그의 속성과 담당자를 알 수 있다.
'아 그건 백에서 해줘야 해요.'
라는 말을 듣지 않게 된다. 정말 단순하게 이 메시지를 어디서 띄우는지만 매번 정확히 알고 있어도 개발자는 테스터를 소통 가능한 존재로 느끼게 될 것이고, 버그 리포트는 신뢰성을 가지게 된다. (QA는 양치기 소년이 되어선 안 된다.) -
코드 리뷰는 하지 않아도 'API 명세 리뷰'는 할 수 있다.
QA라면 기획안을 리뷰해야 한다. 여기까지는 기획자의 테스트와 유사하다.
또 할 수 있는 것이 API 문서 리뷰이다. 사람이 하는 일이기 때문에 '누락 결함'이 있다.
예를 들면 스웨거를 보고 필수값 여부를 알 수 있다. 기획안에서는 조회 필수값이었는데 조회하는 API에서는 필수 파라미터가 아니라면 누락 결함이다. UI가 모두 개발된 뒤에 하나씩 경우를 달리해 눌러보며 필수값 적용 여부를 아는 것보다 API 문서를 읽고 판단하는 것이 빠르고 정확하다. '프론트엔드 테스트를 위한 준비 과정'이기도 하다. 이 과정을 거치고 나면 이후는 대개 프론트엔드 문제이므로.API 호출과 작성된 오류 메시지 확인도 가능하다. 특히 GET의 경우는 API 테스트 도구 안에서 과정이 끝나기 때문에(프론트엔드 개발 전일 경우) 간략하다. 오류 메시지는 QA의 중요한 대상 중 하나이다. 개발자는 오류 메시지가 고객에게 직접 노출된다는 점을 간과할 수 있다. 어떤 메시지든 고객이 볼 수 있다고 전제하고 '지금 무슨 상황이며, 나는 무엇을 해야 하는지' 알려주는 메시지여야 한다. 오류를 만들어서 직접 불러오지 않고도 작성된 것을 읽고 리뷰할 수 있다니 얼마나 좋은가?
