AI를 이용한 결합 테스트 명세서 리뷰: 기능 간, 권한, 상태 변화까지 검토 가능한가

이전 글에서는 Excel로 작성한 테스트 명세서를 AI에게 리뷰시키는 방법을 다루었습니다.

하지만 결합 테스트(結合試験)의 경우 이야기가 조금 달라집니다.

단순히,

입력
↓
처리
...

를 확인하는 것만으로는 부족합니다.

결합 테스트에서는,

기능 A
↓
기능 B
...

와 같은 기능 간의 연결을 확인합니다.

게다가,

권한(権限)

상태(ステータス)

이력(履歴)

갱신 순서(更新順序)

전처리(前処理)

후처리(後処理)

등도 얽혀 있습니다.

그래서,

AI에게 결합 테스트 명세서를 리뷰시켰을 때, 어디까지 확인할 수 있는지

정리해 보겠습니다.

예를 들어 다음 케이스가 있습니다.

① 신청 등록
② 승인
③ 등록 내용 조회

각각 단독으로는 올바른 테스트일지라도,

①의 데이터를
②로 승인하고
③에서 확인하는

이러한 흐름(흐름)이 확인되지 않으면, 결합 테스트로서 부족할 가능성이 있습니다.

즉,

케이스 단독이 아니라, 케이스 간의 관계를 볼 필요가 있습니다.

갑자기 PCL이나 테스트 명세서를 리뷰시키기보다는, 먼저 설계서로부터 기능을 정리하게 합니다.

첨부한 설계서에서
이번 테스트 대상 기능을 정리해 주세요.
다음 형식으로 해 주세요...

다음으로,

기능 간의 조합

을 만들게 합니다.

예를 들어,

등록 → 승인은 있지만, 변경 → 승인의 시나리오가 없다
와 같은 누락을 발견하기 쉬워집니다.

업무 시스템에서는,

관리자
담당자
일반 사용자

처럼 여러 권한이 있습니다.

모든 권한 × 모든 기능을 테스트하면, 케이스 수가 폭발합니다.

그래서 AI에게,

권한별 차이점을 정리해 주세요.
같은 로직을 거치는 것과,
권한 고유의 동작이 있는 것을 나눠 주세요.

라고 요청합니다.

이를 바탕으로,

모든 패턴을 테스트할 필요가 있는지

를 사람이 판단합니다.

결합 테스트 리뷰에서 어려운 것이,

횡전개 확인(横展開確認)
입니다.

예를 들어,

권한 A로 확인했으니,
권한 B에서는 대표 케이스만 확인한다

와 같은 설계가 있습니다. AI는 이것을 알지 못하면,

권한 B의 케이스가 부족합니다
라고 대량으로 지적합니다.

그래서,

이번 횡전개 방침:
- 공통 로직은 대표 권한으로 상세 확인한다
- 다른 권한에서는 이용 가능 여부와 등록 가능 여부를 확인한다...

처럼, 리뷰 방침 자체를 AI에게 전달할 필요가 있습니다.

결합 테스트에서는 상태 변화(状態遷移)도 중요합니다.

예를 들어,

미신청
↓
신청 중
...

와 같은 상태가 있다고 가정해 봅시다.

AI에게는,

설계서에서 상태의 상태 변화를 추출해 주세요.
다음을 작성해 주세요.
|현재 상태|조작|전이 후 상태|실행 가능 권한|

라고 요청합니다.

그 후에는,

각 상태 변화에 대해,
테스트 명세서에 대응하는 케이스가 존재하는지 확인해 주세요.

라고 합니다. 이는 결합 테스트 리뷰와 매우 궁합이 좋습니다.

의외로 누락하기 쉬운 것이,

처리 도중에 데이터가 변경된 경우

입니다.

예를 들어,

신청
↓
승인 대기
...

와 같은 케이스입니다. 등록 시에는 존재했던 데이터가,

승인 시에는,

무효(無効)

삭제

유효 기간 만료

다른 상태

이 되어 있을 가능성이 있습니다.

AI에게는,

시나리오의 시작 시점과 종료 시점 사이에,
참조 데이터가 변경되었을 경우 영향을 주는 부분을 추출해 주세요.

라고 요청합니다. 화면상의 처리가 성공하는 것만으로는 부족할 때가 있습니다.

예를 들어,

승인

했다는 것으로,

DB 업데이트
이력 추가
메일 전송
...

이 이루어진다고 합시다. 이 경우,

승인이 되었다

뿐만 아니라,

승인
├ DB
├ 이력
...

까지 확인해야 합니다.

당신은 업무 시스템의
결합 테스트 리뷰 담당자입니다.
첨부 자료:
...

AI 리뷰를 반복할 경우,
이전에 지적했던 내용을 매번 지적받는 문제가 있습니다. 그래서,

기 검토 결과

도 컨텍스트에 포함시킵니다.
예를 들어,

CASE-001에 대해서는 검토가 완료되었습니다.
CASE-020부터 030까지는
CASE-001과 동일한 공통 처리를 이용하고 있기 때문에,
...

이렇게 하면 검토 결과의 노이즈를 줄일 수 있습니다.

예를 들어 30개의 케이스 모두에 대해,

기대 결과에 DB 업데이트 내용을 기재해 주세요

라는 문제가 있었다면,

30건이나 나오면 곤란합니다.

그래서,

동일 원인으로 인한 지적은
「공통 지적」으로 모아주세요.

로 합니다.

결합 시험 검토에서 AI가 유용한 것은,

대량의 대응 관계를 유지하는 것입니다.

사람이,

CASE-001
CASE-002
CASE-003
...

을 검토하고 있으면,

이거, 어디선가 확인했던 거 같은데?

라는 생각이 듭니다.

AI에게,

명세서
↕
시나리오
...

의 대응표를 만들게 하는 것만으로도 검토가 상당히 수월해집니다.

결합 시험에서는,

이 시스템에서는
이 패턴은 업무상 발생하지 않는다

와 같은 암묵지가 많습니다.

AI는 설계서에 적혀 있지 않으면 알지 못합니다.

따라서,

이론상 가능

과,

업무상 필요

을 구분할 필요가 있습니다.

여기는 인간의 판단이 중요합니다.

AI
│
├ 기능 목록 작성
...

AI를 검토자 그 자체로 만들기보다는,

검토자의 보조자로 사용하는 것을

이미지입니다.

AI에게 결합 시험 명세서를 검토하게 해보면,

• 기능 간 매트릭스
• 상태 전이
• 권한 차이
• 시나리오 간 관계
• 기존 케이스와의 중복
• 명세와 케이스의 대응付け

에서 힘을 발휘합니다.

반면,

• 업무상 발생할 수 있는지
• 어디까지 시험해야 하는지
• 리스크를 허용할 수 있는지
• 가로 전개가 충분한지

와 같은 판단은 인간이 해야 합니다.

결합 시험 검토를 완전히 자동화하기보다는,

수십~수백 케이스를 머릿속으로 연결하는 작업을 AI에게 도움을 받는

방식이 현재로는 상당히 실용적이라고 느낍니다.

그리고 가장 중요한 것은,

AI에게 시험 케이스만 보여주는 것이 아니라, 설계서・검토 방침・기 검토 결과까지 컨텍스트로 전달하는 것입니다.

OpenAI「How OpenAI uses Codex」
https://openai.com/business/guides-and-resources/how-openai-uses-codex/
-OpenAI「Prompt engineering」
https://developers.openai.com/api/docs/guides/prompt-engineering
-OpenAI「File inputs」