AI Insight | 슈어소프트테크

작성 시간 5배 줄인 AI 기반 TC 생성 프로세스

블로그에서 더 자세한 내용 확인하기

 

기존 테스트 케이스(TC)의 한계

 

자동화 테스트를 적용하려면

그 전에 믿을 수 있는 TC가 준비돼 있어야 합니다.

 

하지만 기존 자연어 TC는 Step 누락, 작성자마다 다른 상세 수준,

제각각인 표현 방식 때문에 자동화 전에 다시 정비하는 작업이 반복됐습니다.

 

이 반복을 줄이기 위해 요구사항 분석부터 화면 기반 실행 검증까지

이어지는 AI 기반 TC 생성 프로세스를 적용했습니다.

 

 

요구사항을 기능 단위로 구조화

 

AI는 요구사항을 바로 TC로 바꾸지 않고, 먼저 '기능 단위'로 분해합니다.

기능 단위란 TC 1건을 만들 수 있는 수준의 검증 단위이며,

다음과 같은 흐름을 거칩니다.

 

요구사항 분석 → 기능 단위 도출 → TC 초안 생성 → 실제 화면 기반 Step 보완 → QA 최종 검토

 

이 단계의 목적은 단순히 TC 개수를 늘리는 것이 아니라,

어떤 요구사항에서 어떤 TC가 나왔는지 확인할 수 있는 추적성과,

요구사항이 TC에서 빠지지 않도록 하는 커버리지를 확보하는 데 있습니다.

 

 

TC 형식 표준화

 

기능 단위별 TC 초안은 사전조건·Step·Expected Result 구조로 표준화해 생성합니다.

 

특히 테스트 자동화에서는 Step의 구체성이 중요하기 때문에,

"설정 화면으로 이동한다"는 식의 추상적 서술 대신

실제 선택해야 하는 메뉴와 버튼까지 순서대로 명시합니다.

 

다만 이 단계에서 생성된 TC는 최종본이 아니라 QA가 검토할 수 있는 수준의 초안이며,

다음 단계에서 실제 사용 흐름을 기준으로 다시 보완됩니다.

 

 

실제 화면에서 Step 보완

요구사항 문서만으로는 사용자가 거쳐야 하는 모든 화면 조작 과정을 알기 어렵습니다.

Playwright MCP를 활용해 AI가 생성한 TC 초안을 실제 제품 화면에서 수행하며,

TC에 포함되지 않았던 중간 Step을 찾아 추가합니다.

 

다만, Expected Result는 요구사항의 품질에 좌우되므로,

화면 조작 흐름과 달리 올바른 결과가 무엇인지는

여전히 요구사항 자체에 명확한 검증 기준이 작성돼 있어야 판단할 수 있습니다.

 

QA 최종 검토 & 반복 개선

AI와 MCP가 TC 생성과 Step 보완을 수행하더라도 QA의 역할은 사라지지 않습니다.

QA는 요구사항과 생성된 TC를 비교해 누락된 검증 대상이 없는지,

Expected Result와 실제 검증 포인트가 적절한지 최종 확인하고,

확정된 TC는 TestRail에 등록해 회귀 테스트(RT)에 활용합니다.

 

AI가 요구사항 분석과 TC 초안 생성을,

MCP가 실제 화면 흐름 기준 Step 보완을 담당하는 동안

QA는 검증 기준과 예외 상황처럼 판단이 필요한 영역에 집중하고,

그 검토 결과는 다시 생성 규칙에 반영되어 품질이 반복적으로 개선되는 구조를 만듭니다. 

 

실제 프로젝트 TC 작성 시간 비교

 

VPES 3.7 프로젝트에서 기존 방식으로 132건의 TC를 작성하는 데 약 2MD가 소요됐습니다.

 

동일한 요구사항에 AI 기반 프로세스를 적용해

요구사항 14건, 기능 단위 87건을 분석하고 151건의 TC를 생성한 결과,

전체 과정이 약 3시간으로 줄어 약 5배의 시간 단축 효과를 확인했습니다.

 

속도만 빨라진 것이 아니라,

기능 단위 기반 생성을 통해 요구사항 커버리지와 작성 품질까지 함께 확보할 수 있었습니다.

6개 프로젝트 TC 생성 적용

 

한 프로젝트의 좋은 결과가 모든 업무에 동일하게 적용될지 확인하기 위해,

상반기 동안 총 6개 프로젝트에 AI 기반 TC 생성을 적용했습니다.

 

총 772건의 TC를 생성했고(프로젝트당 평균 약 129건),

공수 측면에서는 프로젝트당 평균 약 2.3MD, 전체 약 14MD의 절감 효과를 확인했습니다.

 

프로젝트별로 제품과 요구사항의 특성이 서로 달랐음에도 반복적으로 활용할 수 있었다는 점에서,

특정 프로젝트에서만 통하는 일회성 방법이 아니라

정형화된 QA 업무 전반에 지속적으로 적용 가능한 방식임을 확인했습니다.

 

 

적용 효과 4가지

 

이번 적용으로 확인한 효과는 크게 네 가지입니다.

 

TC 작성과 RT 준비에 드는 반복 작업 시간을 줄였고,

기능 단위와 고정된 작성 구조를 기준으로 생성하면서

담당자별 TC 품질 편차를 줄였으며, 요구사항–기능–TC를 연결해

어떤 요구사항이 테스트되고 있는지 쉽게 확인할 수 있게 됐습니다.

 

네 가지는 서로 분리된 성과가 아니라 하나로 이어지는 흐름이며,

결국 AI 도입의 목적은 TC를 더 빨리 만드는 것이 아니라

절감된 시간을 QA의 판단과 경험이 필요한 결함 분석, 검증 포인트 설계 같은 업무에 쓰는 데 있습니다. 

 

 

 

요구사항을 기능 단위로 구조화하고, TC 생성 후 실제 화면 기반으로 보완하고,

QA가 최종 검토하는 프로세스를 통해 TC 작성 시간을 줄이면서도

품질과 요구사항 커버리지를 함께 관리할 수 있는 가능성을 확인했습니다.

 

QA의 검토 결과와 결함 이력을 반영해

오류 추정(Error Guessing)까지 지원할 수 있고,

하나의 파이프라인 연결로 생산성 향상을 기대할 수 있습니다.

 

AI를 QA에 적용하는 목적은 판단을 대체하는 것이 아니라,

반복 작업의 시간을 QA의 경험과 판단이 필요한 검증에 쓸 수 있도록 역할을 재구성하는 데 있습니다.