Claude code로 TC 초안 작성하기

 

이전 포스팅에서 Claude code를 사용하여 QA와 업무 분담에 대해 알아봤었는데, 이번엔 TC 초안 작성하는 것에 어떤 식으로 활용했는지 후기를 작성해 보겠습니다.

 

 

예전에는 기획서를 GPT나 Claude에 전달하고 TC 초안을 작성해달라고 하면 자유롭게 전달받아서 초안으로 사용했는데, 이것이 체계적인 과정일까를 생각해 보게 되었고, 기획서와 생성된 TC를 하나씩 확인해 가며 검토하는 것이 비효율적이라고 생각했습니다.

 

 

그래서 자연스럽게 입력된 기획서를 기반으로 어느 정도 TC가 생성되었는지 커버리지를 확인하며 TC를 생성하게끔 프롬프트를 작성하게 되었습니다.

 

 

이 과정에서 토큰을 수없이 날려가며 경험했던 과정들과 시각적으로나 검토용으로나 실용성이 높다고 생각된 기능 분류 트리 방식을 활용한 방법으로 포스팅을 작성해 보겠습니다.

---

 

자동으로 생성된 TC... 다 만든 것 맞아?

 

평소와 같이 간단한 프롬프트에서 정상, 네거티브, 경계값, 시나리오 등 유형을 분리해 가며 TC 생성을 해달라고 요청하던 중 문득 의문이 들기 시작했습니다.

 

 

"자동으로 생성한 TC들은 기획서에 포함된 자료들을 다 써서 생성한 결과가 맞을까?"

 

 

이를 검증하기 위해 생성된 TC를 확인하고 기획서와 비교한다면 검증 시간도 오래 걸리고, 실제 업무 시 빠른 처리를 해야 하는 상황이 온다면 그냥 생성된 TC를 믿고 이것만 수행하지 않을까라는 고민이 들었습니다.

 

 

그래서 생성된 TC가 어떤 부분과 매핑되는지 누락된 기획 내용은 없는지 확인할 수 있는 방법을 찾다가 이전에 개발자 시절에 사용했던 Code Coverage가 떠올랐습니다.

 

 

 

 

코드 커버리지 측정 도구는 위 이미지처럼 코드 로직에서 테스트 코드가 있는지 확인해 주는 툴인데, 이를 매뉴얼 TC 생성에 응용할 수 있지 않을까라는 생각이 떠올랐고, 코드 구조처럼 기능을 트리 구조로 분류하여 확인하기 위해 기능 분류 트리 기능을 활용한 TC 생성을 진행하게 되었습니다.

 

 

---

 

기능 분류 트리란?

 

기능 분류 트리는 아래 내용처럼 기능의 크기를 나눠서 말단 노드까지 구분하는 방식이며, 이 기능을 활용한다면 어느 정도의 TC를 생성했는지 알 수 있지 않을까 생각하게 되었습니다.

 

 

 

 

기획서를 Claude에 전달하면 기능 분류 트리를 만들고, 이 내용을 바탕으로 TC 초안을 생성한다면 어떤 부분이 실제 제품과 차이가 있을지, 누락된 부분은 어디일지 판단이 가능할 것이라 생각되어 작업을 진행하였습니다.

 

 

 

 

위 단계처럼 프로세스를 잡고 진행했고, 실무에 사용되는 기획서를 블로그에 공유할 순 없어서, 예시로 사용할 기획서도 Claude를 활용해서 만들어서 자료를 만들었습니다.

 

---

 

상품 리뷰 기능 기획서를 활용한 TC 생성 예시

 

 

 

Claude에 2주 단위로 수행할만한 기획서를 요청했고, 위 이미지처럼 꽤나 상세한 기획서를 전달받을 수 있었습니다.

 

 

기획서를 기반으로 기능 분류 트리 구조와 TC 생성을 요청했고, 아래 이미지처럼 전달받을 수 있었습니다.

 

 

 

 

생성된 트리구조를 확인해 보니, 어떤 테스트를 진행해야 할지를 파악하기 편리했으며, 개발팀에서도 기획서를 기반으로 이슈 분리하고 담당자 할당할 때 유용할 것이라 생각되었습니다.

 

 

(혹시나 해서 현업 실무자에게 물어보니 요즘엔 이런 방식으로 Task를 분리했고 개발자가 기능 목록을 보고 할당받아서 처리하는 방식을 사용하고 있다고 하더라고요)

 

 

그리고 이어서 생성된 TC 내용도 검토해 봤습니다.

 

 

 

 

초안이지만 사전조건부터 단계, 결과, 위험도 구성까지 시각적으로 잘 표현되었으며, 26가지의 말단노드를 생성하고, 30가지의 TC를 생성할 수 있었습니다. 특정 노드는 2개 이상의 TC를 사용해서 검증하는 방식도 디테일하게 체크했다는 것을 확인할 수 있었습니다.

 

 

 

추가로 만들어진 TC만 수행했을 때의 리스크가 발생할 수 있는 내용과 탐색적 테스트를 진행할 때 어떤 방식으로 진행하면 좋을지 가이드까지 추가하도록 요청하였고, 어떤 식으로 테스트를 수행하면 좋을지 업무 진행 순서도 전달받을 수 있었습니다.

 

 

요청했던 프롬프트 내용은 Skill로 만들 수 있었고, 필요할 때 기획서를 첨부한 뒤 스킬 명령어를 호출하면 트리 생성과 TC 생성, 업무 진행 방식까지 전달받을 수 있는 환경을 구성할 수 있었습니다. 

 

 

---

복잡한 기획이나 기획서에 없는 기능과 연결되어 있다면...

 

위에서 들었던 예시는 Claude가 생성한 기획서로 Claude가 TC를 자동 생성했기에 좋은 결과를 얻을 수 있었다고 생각합니다.

 

 

하지만 현업에서 업무를 진행하는 방식을 생각해 보면, 제품이 있는 상태에서 새로운 기능을 추가하거나 변경하는 기획서를 마주하게 됩니다. 

 

 

그렇다면 신규 기획서에는 기존 기능에 대한 기능 설명이 간략하게 되어있을 테고, 어떤 테스트로 진행해야 할지는 기능 전체를 이해하고 있는 QA의 검토 역할이 더욱 중요해질 것 같습니다.

 

 

하나의 다른 예시로 금융권의 대출 기능에 대한 TC를 생성해 달라는 요청을 했고, 요청한 대로 기획서에 있는 자료를 기반으로 TC는 잘 구성했지만, 기획서 범위 밖의 내용은 알지 못하기에 QA가 직접 확인해야 하는 경우가 있었습니다.

 

 

 

 

위 내용처럼 비즈니스 규칙이나 법적 규정, 연결된 외부 시스템의 연계, 사용자 관점의 UI/UX 검토 등 기획서에 명시되지 않은 내용들의 TC 생성은 명확한 기준이 없기에 어렵다는 것을 알 수 있었고, 명확하지 않은 기준으로 만들어진 TC 또한 재검토를 해서 제품에 맞게 수정해야 한다는 것을 알게 되었습니다.

 

 

 

위 내용처럼 기획서로 TC 생성 후 QA가 수행해야 할 체크리스트까지 전달받아서 업무를 진행한다면 제품을 예상하며 생성된 TC 초안을 업무에 사용할 수 있는 TC로 변경해서 활용할 수 있을 것 같습니다.

 

---

 

Claude Code를 실무에 어떤 식으로 활용할 수 있을지를 생각하며 써보고 있는데, 이렇게도 써볼 수 있다는 것을 공유하기 위해 글을 작성했습니다.

 

 

모든 과정을 기획서를 하나하나 확인하면서 작업하는 것보다 기획서 하나로 TC 초안과 기능 분류 트리를 구성해서 어떤 TC를 만들지 생각하고 이후 어떤 방식으로 작업할지 가이드도 받는다면 업무 시간을 단축할 수 있다는 부분에서 실무의 생산성이 높아지는 방법이지 않을까 생각됩니다.

 

 

위에서 설명한 내용 외에도 백엔드에서 활용 될 API 자동화 테스트를 구성할 때 클로드 코드는 실제 테스트 코드까지 생성해주기 때문에 더 활용도가 높을 수 있을 것 같습니다.

 

 

QA가 아니더라도 기능 분류 트리를 활용한다면 Task 분리 및 업무 할당하는 관리 영역에서도 활용될 수 있을 것 같아 보입니다.

(이미 현업에서는 활용하고 있겠지만..)

 

 

그리고 마침 오늘 X를 통해 공유된 내용으로 pro에서 Claude code를 제공하지 않을 수 있다는 소식이 돌고 있고, 실제로 소규모 테스트를 진행하고 있다고 합니다.

(참고 URL : https://x.com/TheAmolAvasare/status/2046724659039932830?s=20 )

 

 

이전에 포스팅했던 " 원숭이 꽃신" 내용처럼 되어버리지 않을까라는 걱정도 있지만... 따라가지 않을 수 없기에 더 효율적으로 쓰는 방법도 연구해 봐야겠네요.

 

 

긴 글 읽어주셔서 감사합니다. 🫡