QA란 무엇인가

QA라는 단어는 개발 현장에서 자주 쓰이지만, 막상 “QA가 정확히 무엇인가”라고 물으면 명확하게 답하기 어렵습니다. ‘QA 강화’ 가 어떤 걸 의미하는지 알기 위해 QA가 무엇인지부터 짚어봅니다.

보통 소규모 팀에서 QA는 ‘새로 빌드된 앱이 잘 돌아간다’는 의미 정도로 사용됩니다. 잘 돌아간다는 건 무엇일까요. 새로 개발한 피쳐가 의도대로 동작하며, 앱이 크래시가 나지 않고, 유저가 UX상 불편함을 겪지 않으며, 디자이너의 의도대로 앱이 렌더링되는 상황을 말할 것입니다.

하지만 이는 너무 포괄적인 개념입니다.

‘새롭게 추가된 기능에 대한 QA를 한 번씩은 하자’ 라는 게 어디부터 어디까지 확인하는 것인지, ‘QA 잘 됐습니다.’ 는 뭐가 잘 됐다는 건지 모호하기 때문입니다.

예를 들어 ‘특정 기능 QA 완료됐습니다.‘의 의미는 QA를 진행하는 사람에 따라 천차만별입니다.

• A: ‘2번째 케이스를 넣어봤더니 잘 나오더라.’
• B: ‘4번째 케이스까지 DB에 넣어봤더니 3번까지 잘 짤려서 나오더라.’ ( Edge case 포함 )
• C: ‘외부 연동 기록, 수기 기록까지 포함한 복합적인 케이스 조합으로 테스트해봤는데 의도대로 나오더라.’ (Corner Case 포함)

이런 간극을 완화하기 위해 많은 팀들이 QA 시트를 도입하지만, 보통은 큰 효과가 없기 마련입니다. 이유는 두 가지입니다. 첫째로 QA 시나리오(Given/When/Then)를 디테일하게 적지 못합니다. 시간 여유도 없거니와, QA를 준비하고 진행하는 동시에 HotFix와 개선사항 추가가 병렬로 진행되기 때문입니다. 둘째로 배포 일정상 매 버전별/피쳐별로 Assignee를 할당해 Expected Output이 정말 다 나왔는지 일일이 확인하기도 어렵습니다.

결국 어느 정도 믿음에 기반한 QA가 반복됩니다. “특정 기능 개선 확인했다”는 말을 믿는 것으로 검증을 대체하고, Dev에서 검증된 피쳐를 Prod에 배포하기 전에는 유의미한 변수만 핀셋으로 찝어 검증합니다. 나머지 디테일한 기능 검증은 팀원의 말을 신뢰하는 것으로 갈음합니다. 빠른 배포 사이클을 유지해야 하는 소규모 팀에서는 어쩔 수 없이 선택하게 되는 방식입니다.

QA와 Test

그렇다면 개선안을 찾으려면 ‘누가, 무엇을, 어떻게’ 해야 하는지부터 정립해야 합니다. 이를 위해 다시 한 번 QA가 무엇인지 생각해봅니다. 많은 팀에서 하고 있는 것이 과연 정말 QA일까요?

요즘 업계에서는 QA(Quality Assurance)를 Test와 동의어처럼 사용합니다. 하지만 실제로 QA는 상품 관점에서 좀 더 상위 레이어의 검증을 말하고, 기능 Test는 이에 속하는 하위 개념입니다.

QA를 앱 기준으로 말하면, Data fetch 속도는 충분히 빠른지, 외부 기기 연동 로딩이 너무 길지는 않은지, 디바이스별로 디자인이 튀게 나오지는 않는지 등 앱의 종합 퍼포먼스를 측정하고 완성도를 평가하는 것입니다. 과한 퍼포먼스를 요구하지 않는 서비스에서는 정량적 측정보다 정성적 평가가 더 많이 요구됩니다. 서비스 도메인을 이해하는 기획 담당자가 하는 것이 적합합니다.

반면 많은 팀에서 QA라고 부르는 작업의 대부분은 사실 Test입니다. Test에서는 기능이 예상대로 동작하는지 검증합니다. 특정 목록이 N번까지만 잘 필터링 되는지, 파일을 업로드했을 때 정상적으로 저장되고 출력되는지 등을 검증합니다.

이는 엔지니어(FE, BE, TechLead)단에서 검증되어야 하는 것들입니다. 배포 전에 테스트 코드 레벨로 검증되는 것이 가장 좋습니다. TDD가 말은 좋지만 완성도 있게 실행하기 어렵다는 건 현장에서 일해본 사람이라면 잘 알 것입니다. 그럼에도 지향해야 할 방향이므로, 엔지니어가 무엇을 해야 할지 테스트를 좀 더 자세히 살펴봅니다. 테스트 개념은 다양하지만 실무에 적용할 수 있는 수준으로 크게 나누면 이렇습니다.

1. Sanity Test
   • 새로 개발한 피쳐를 검증합니다. 최소한 개발자의 의도대로는 구현되었는지 검증할 수 있습니다.
   • (예시) 특정 목록이 N번째를 넘어갈 때 그 이후 항목이 잘 필터링 되는지 등을 테스트케이스로 삼을 수 있습니다.
2. Smoke Test
   • 기존 기능들이 잘 동작하는지 검증합니다. 빌드된 코드가 QA 단계로 넘어가기 전 최소한의 조건을 충족하는지 확인할 수 있습니다.
   • (예시) Test 계정의 로그인, 로그아웃, 핵심 기능 검색 등이 잘 동작하는지 검증합니다. 테스트케이스 수준에 따라 다르지만 배포 사고도 이런 과정을 통해 방지할 수 있습니다.
3. Regression Test
   • 지금까지 쌓인 테스트 케이스들을 회귀 테스트합니다. 새로 개발한 피쳐가 기존 기능에 Side-Effect를 유발하진 않았는지, 버전관리 미스로 이미 개선된 버그가 다시 재발하진 않았는지를 검증할 수 있습니다.

이 테스트들은 코드 기반으로, 엔지니어 주도로 실행되어야 합니다. 그렇다면 어떤 장점이 있을까요.

• 명확한 역할 분담. 정성적 평가를 주로 하는 QA 담당자는 500 Internal Server Error 같은 이슈를 버그 리포팅하고 개발자와 소통하는 데 집중할 수 있습니다. QA를 다시 하게 되는 리소스 낭비를 줄일 수 있고, 개발자 입장에서도 매번 새 테스트 빌드를 전달해야 하는 수고를 덜 수 있습니다.
• 테스트 범위가 명확해집니다. 어떤 기능을 어디까지 검증했는지 누군가의 말을 믿는 것으로 대체하지 않아도 됩니다. 테스트 코드에 쓰여진 것이 곧 테스트 범위이며, 버그가 QA 단계에서 발견되었다면 테스트 케이스를 강화해 재발을 방지하면 됩니다.
• 문서 작업이 줄어듭니다. QA 시트에 누가 어떻게 어떤 기능을 검증했는지 구구절절 기록하는 과정이 대폭 감소합니다.

테스트 케이스를 작성하는 것은 따분하고 힘든 일입니다. 하지만 배포 과정에서 똑같은 기능을 N번 이상 동일한 시나리오로 검증하게 되고, 여러 명이 같은 플로우를 반복하는 낭비가 생깁니다. 테스트 빌드 버전이 여러 번 올라가는 배포 사이클을 생각해보면, 그 과정에서 몇 번의 앱 다운로드를 하고 몇 번의 동일한 동작을 반복하게 되는지 쉽게 상상할 수 있습니다. 테스트 횟수가 많은 것은 좋은 일이지만, 그 중 상당수는 중복된 유효하지 않은 테스트입니다.

전담 QA팀을 꾸리기 어려운 소규모 팀일수록 완벽함보다 ‘효율’을 택해야 합니다. 흔히 테스트는 고품질 프로덕트를 위한 도구라고 말하지만, 빠르게 개발해야 하는 상황에서는 오히려 무거운 족쇄처럼 여겨지기도 합니다. 하지만 개발 히스토리를 돌아보면, 테스트 강화가 오히려 더 빠르고 효율적으로 가는 길이라는 결론에 이르게 됩니다.

“QA 강화는 엔지니어의 테스트 강화로부터 시작되어야 합니다.”

클린 아키텍처 저자 엉클 밥의 명언 하나를 남기고 마칩니다.

빨리 가는 유일한 방법은 제대로 가는 것이다. - Robert C. Martin