AI에게 테스트를 맡길 때, 그 '판단 기준'을 어떻게 확인할 것인가 ── QA 하네스 발표를 듣고

connpass에서 신청한 이벤트에서, 니시다 야스아키 씨(주식회사 TOKIUM의 첫 번째 QA)의 「QA에 의한 하네스 엔지니어링과 QA 조직의 미래상」이라는 발표를 들었습니다.

저는 현재 신입으로 QA 엔지니어를 목표로 하고 있습니다. 이번 글에서는 발표 내용 중에서도 'QA를 자동화하는 시스템을 어떻게 신뢰할 수 있는 상태로 만들 것인가'에 초점을 맞춰 생각한 것을 정리합니다.

특히 신경 쓰였던 부분은 AI로 테스트 케이스를 생성했다는 사실보다, 그 이후의 운영 과정에서 발생한 문제였습니다.

테스트 자산이 늘어나고 사용자도 증가하는 한편, 지식의 중복이나 충돌이 발생하여 시스템을 재구축해야 한다는 판단에 이르렀다고 합니다.

이를 듣고 'AI에게 올바른 지시를 내리면 된다'는 이야기로 끝나지 않는구나라고 생각했습니다. 지시를 따르게 하는 것 외에도, 그 지시가 지금도 정확한지, 그리고 이번 대상에 적용해도 괜찮은지까지 확인할 필요가 있습니다.

발표에서는 하네스를 '지식(ナレッジ)', '검증', '실행 환경'의 3가지로 설명했습니다. 1

① 지식 (판단 기준)
QA가 가진 테스트 관점이나 기술 규칙, 도메인 지식을 AI가 매번 동일하게 읽을 수 있는 형태로 만든 것.

↓ AI(Claude Code)에 의한 테스트 설계·실행

② 검증 (Hook 그룹)
규칙을 '알고 있다'에서 '어길 수 없게'로 만드는 것.
생성된 결과물이 규칙을 따르고 있는지 기계적으로 검증하고, 위반이 있으면 되돌리는(差し戻す) 것입니다.

③ 실행 환경 (기반)
그 지식과 검증이 매번 작동하는 실행 환경을 준비한다는 구성입니다.

인상 깊었던 표현은 다음과 같았습니다.

규칙을 '알고 있다'에서 '어길 수 없게'로 만드는 것.

'반드시 이 관점을 확인해 주세요'라고 지시할 뿐만 아니라, 조건을 충족하지 못하면 다음 공정으로 진행할 수 없도록 하는 것입니다. AI의 주의력에 기대는 것이 아니라, 주변 시스템으로 제약하는 사고방식이라고 이해했습니다.

또한, 모든 처리를 매번 AI에게 맡기는 설계가 아니었다는 점도 흥미로웠습니다. 생성한 테스트 케이스와 실행 코드를 자산으로 남기고, 다음에는 AI를 사용하지 않고 재실행한다는 방침이 제시되었습니다. 1

AI가 필요한 경우에 사용하고, 반복적으로 확인하는 부분은 코드에 남기는 것입니다. '어디까지 AI에게 맡길 수 있는가'뿐만 아니라, '어디부터는 AI에게 매번 판단하게 하지 않을 것인가'도 설계한다는 느낌을 받았습니다.

발표에서는 5개월간의 운영으로 6,482건의 테스트 케이스를 생성했고, 그중 60

이 경우, '테스트가 통과했다'는 구현(implementation)과 기대 결과가 일치했음을 보여줄 수는 있지만, 최신 요구사항을 충족했음까지는 보여주지 못합니다.

따라서 AI가 생성한 테스트를 확인할 때에는 절차나 기대 결과의 문장뿐만 아니라, '그 기대 결과를 어떤 사양(specification)에서 도출했는지'까지 추적할 수 있도록 하고 싶습니다.

필요 항목이 채워져 있는지 여부, 정해진 형식에 따르고 있는지 여부, 기대 결과가 현재 요구사항과 일치하는지 여부는 각각 별도의 확인 사항입니다.

'검증을 통과했으니 괜찮다'라고 뭉뚱그리지 않고, 그 검증이 무엇을 확인했고, 무엇을 확인하지 못했는지 설명할 수 있는 상태가 필요하다고 생각했습니다.

발표 자료의 부록에는 구(舊) 도구에서 인계하는 방침으로, 판별할 수 없는 경우에는 사람에게 확인을 요청하거나, 검색 결과가 0건인 경우에는 실패로 처리한다는 내용이 적혀 있었습니다. 4

저는 이러한 '진행할 수 없는 조건'에서도 QA의 판단이 드러난다고 생각합니다.

예를 들어 사양이 모순되는 경우에 AI가 어느 한쪽을 선택하여 끝까지 처리를 완료하면, 겉보기에는 자동화가 완료된 것처럼 보입니다. 하지만 그 선택에 근거가 없다면, 나중에 전체 결과를 다시 확인해야 할 수도 있습니다.

그렇다면 '여기는 판단할 수 없습니다'라고 멈추고, 확인해야 할 지점을 명시하는 편이 신뢰해서 사용할 수 있는 상황도 있을 것 같습니다.

다만, 사람에게 되돌리는 횟수가 많다고 좋은 것은 아닙니다. 매번 거의 모든 판단을 사람에게 맡긴다면, 기대했던 부담 경감으로 이어지지 않습니다.

그래서 단순히 사람에게 돌린 건수뿐만 아니라, 돌려주는 방식도 보고 싶습니다.

'사양이 불명확합니다'라고만 하는 것과 달리, '이 두 자료에서 유효 기간이 달라 어느 것이 현재 기준인지 확인할 수 없습니다'라고 제시된다면, 확인해야 할 부분을 좁힐 수 있습니다.

자동화를 평가할 때는 끝까지 처리된 비율뿐만 아니라, 멈춰야 할 상황에서 멈췄는지, 멈춘 후에 사람이 판단하기 쉬운지도 확인하고 싶다고 생각했습니다.

이번 발표를 계기로 작은 테스트 케이스 생성 메커니즘부터 시도해 보고자 합니다.

발표 자료의 부록에서는 신구 메커니즘을 비교하는 조건으로, 사전에 고정된 필수 관점/기존 결함에 대한 검출률이나, 사람의 확인 시간을 포함한 소요 시간이 언급되어 있었습니다. 5

이러한 사고방식을 참고하여, 저는 우선 생성 건수보다는 '참조해야 할...

우선은 작은 기능으로, 올바른 사양만 전달하는 경우와 오래되거나 모순된 정보를 섞는 경우를 비교해 보겠습니다. 자동화할 수 있었던 범위뿐만 아니라, 맡길 수 없었던 조건과 그 이유까지 다음 결과물에 남기고 싶습니다.