AI를 사용하여 테스트 설계를 해보기 ~ Part1

AI를 사용하여 테스트 설계를 해보기. 그 모습을 기록한다

하지만, 두서없이 이야기하며 진행한다.

두서없이 이야기하며 작업을 하고 있었기에, 기사를 한 번 쓰고 끝낼 생각이었으나 시간 내에 다 쓰지 못해서 Part를 나누어 게시하기로 했다.

갑작스러운 수다

AI를 사용하여 테스트 설계를 하는 방법은 여러 가지가 있다.

대략 분류하면 다음과 같다고 생각한다.

• 인풋 (Input)으로 사용
• 아웃풋 (Output)으로 사용

아웃풋으로 사용하는 것에 관해서는, 사용하는 것은 간단하지만, 사용한 결과로 무언가 기쁜 일로 연결하려고 하면 어렵다. 아웃풋으로 사용한다는 것은, 다음 공정으로 넘기기 위한 책무를 다하고 있는 상태일 필요가 있다. 다음 공정과 공통 인식이 되어 있는 책무나, 그것을 달성하기 위해 필요한 모든 것을 달성하고 있을 필요가 있다. 책무를 정의하는 것은 인간의 활동이며 모호한 경우도 많다.

한편, 인풋으로 사용하는 경우, 그것을 어떻게 할지는 받는 측에 맡겨져 있으므로, 아웃풋으로 사용하는 것보다 가볍게 활용할 수 있다.

이러한 점을 고려하면, 테스트 설계에서도 주로 인풋 활동에서 AI를 사용하는 것을 생각하는 것이 편할 것 같다.

이번에는 주로 인풋에서 AI를 사용할 예정이다.

...테스트 설계에 착수하고 싶지만, 아직 조금 더 이야기하고 싶은 것이 있다.

여기서 소프트웨어 테스트의 7원칙을 게재한다.

1. 테스트는 결함이 있다는 것은 보여줄 수 있지만, 결함이 없다는 것은 보여줄 수 없다
2. 전수 테스트는 불가능하다
3. 조기 테스트로 시간과 비용을 절약한다
...

이 중에서,

테스트는 컨텍스트 (Context)에 따라 다르다

에 주목하고 싶은데, "테스트뿐만 아니라 무엇이든 컨텍스트에 따라 다르지 않나"라는 지적은 제쳐두고, 일단 컨텍스트에 따라 결정되는 것이다. 테스트 설계를 함에 있어서 컨텍스트를 이해할 필요가 있다.

테스트 설계에 있어 내가 생각하는 최소한으로 이해해 두어야 할 컨텍스트는 다음과 같다고 생각한다.

• 테스트의 목적
• 테스트 대상은 무엇인가
• 테스트의 범위 (테스트 레벨 · 테스트 타입)
• 테스트 대상의 이용자
• 제약 사항
• 조직의 제약
• 프로젝트의 제약
• 규제나 법적인 제약

테스트 대상을 모르면 테스트를 할 수 없고, 테스트의 범위를 모르면 충분하다고 말할 수 있는 테스트를 준비하기 어려워지며, 테스트 대상의 이용자를 모르면 고려해야 할 사항이 누락될 것 같고, 제약을 모르면 테스트 내용이나 볼륨을 현실에 맞춰 최적화하기 어려워진다.

...테스트 대상의 사양이나 프로덕트 리스크 (Product Risk) 등은 컨텍스트라기보다는 테스트 설계에서 다루는 대상 그 자체라고 생각하므로, 컨텍스트로는 다루지 않는다 (다룬다고 해서 틀렸다는 뜻이 아니라, 나는 그렇게 생각하는 편이 사고하기 쉽다는 것뿐이다).

그렇다면 테스트 설계에서 다루는 것은 무엇이라고 생각하느냐 하면, 다음과 같다.

• 테스트 대상의 사양
• 프로덕트 리스크 (Product Risk)
• 사양에는 적혀 있지 않은, 테스트 대상이 충족해야 할 요구사항

...이것들에 대해 사양 기반 (Specification-based), 경험 기반 (Experience-based) 테스트 기법을 적용하여 테스트를 설계한다 (이번에 구조 기반 (Structure-based) 테스트 기법은 다루지 않는다).

다음 절차로 AI를 사용한 테스트 설계를 진행한다.

• (테스트 설계를 위한 전처리) 위에서 언급한 컨텍스트와 테스트 설계에서 다루는 것을 준비한다
• 테스트 기법을 적용하여 테스트를 설계한다

1과 2 사이에는 분석 활동이나 정리 작업이 발생한다. 공정으로서 표현하지 않은 이유는, 분석은 어떤 활동의 종속적인 것이며, 주된 것으로 파악하면 늪에 빠진다는 경험 때문에 넌지시 이번과 같은 표현으로 하고 있다. 기분의 문제다.

여기서 미리 말해두자면, 이번에 테스트 설계라는 활동의 책무를 그렇게까지 명확하게 하지 않았다. 그래서 사람에 따라서는 "그건 테스트 계획 같아"라거나 "그건 테스트 분석 같아"라거나 "그건 테스트 구현 같아"라며 여러 가지 생각을 할 것이다.

실제 현장에서는 공정으로 정의되어 있는 것을 준수하는 것보다 목적을 달성하는 것이 우선시되는 경우도 많다고 생각하며, 또한 나는 그쪽 스타일이 더 익숙하기 때문에, 교과서적인 정의로는 작업하기 어려움을 느끼고, 애초에 교과서적인 정의를 들먹일 거라면 직접 교과서를 보러 가면 된다고 생각했기에 이번에는 명확화를 생략했다.

그렇긴 해도, 이쯤 되면 '이 사람은 테스트 활동 전체 중 어느 부분을 하고 있는 거지?'라는 궁금증이 생길 것이므로, 내가 생각하는 바를 쓰자면, 우선 테스트 활동 전체에 대해 나는 다음과 같은 이미지를 가지고 있다. 이것은 ISO/IEC/IEEE 29119 소프트웨어 테스트 표준 교과서에서 설명되는 프로세스를 연결하여 miro로 표현한 것이다.

이 부분의 「테스트 설계 및 구현 프로세스 (Test Design and Implementation Process)」 정도를 수행하고 있는 이미지.

뭐, 하지만 이번 활동에 임함에 있어 어떤 전제하에 어느 부분을 수행하고 있는지는 솔직히 말해 그리 깊게 생각하지 않았다 (소프트웨어 테스트를 캐주얼하게 다루는 것이 쉽지 않다).

본론으로 돌아가자.

먼저, 1을 진행한다.

1은 일반적인 정보가 아니라 프로젝트 고유의 정보이므로, AI는 정답을 알지 못한다. 따라서 AI에게 묻지 않고 스테이크홀더 (Stakeholder)와 대화한다.

AI는 정답을 모른다

라고 썼지만, 프로젝트 고유의 정보를 관리하는 RAG (Retrieval-Augmented Generation)가 있고 이를 참조하는 AI라면, 질문했을 때 "과거 실적을 바탕으로 하면 이러한 스케줄이 바람직합니다"라거나 "이분 정도가 스테이크홀더인 것 같습니다", "이러한 테스트가 필요할 것 같습니다"와 같은 답변을 해줄 것이다.

그렇다고는 해도, 이것들에 '정답'이라는 속성을 부여할 수 있는 것은 현실적으로 프로젝트 책임자인 인간뿐이다. 현재로서는.

인간만이 책임을 질 수 있는가?는 궁금한 테마이지만, 이번 취지에서 벗어나므로 보류한다.

실제 고객은 없으므로, 우선 1에 대해서는 다음과 같이 셀프 정의했다.

항목	내용
테스트 목적	사양서에 규정된 요구사항을 충족하는지 확인하고, 릴리스 판단에 도움이 되는 품질 정보를 얻는다
...

본론에서 조금 벗어나지만, 테스트 설계에는 유일한 정답이 없다.

그렇기 때문에 위와 같이 테스트 설계에서 타겟이나 제약 사항으로 작용하는 것(제약에는 부정적인 이미지가 붙기 쉽지만 의사결정을 지원하는 측면이 있다)이 없으면, 테스트 설계의 타당성을 설명하기 어려워진다.

이러한 제약은 테스트 계획서 등에 명문화하여 스테이크홀더와 합의를 형성해 두면, 테스트 설계의 타당성도 설명하기 쉬워질 것이다. 스테이크홀더도 바쁘기 때문에 확인해주지 않거나 다뤄주지 않고 통째로 맡겨버리는 경우도 있겠지만, 시도해보는 것이 좋다고 생각한다.

또한, 다른 테스트 레벨 (Test Level)에서 어떤 테스트가 이루어지고 있는지 파악하지 못하면, 불필요한 테스트를 하게 되거나 필요한 테스트를 누락하게 된다. 이번에는 거기까지 정의하려고 하면 기획이 힘들어지므로, 다른 테스트 레벨에서 어떤 테스트가 이루어지고 있는지는 적당히 취급한다.

참고로, 나는 해본 적은 없지만, 애초에 테스트 레벨을 고려하지 않고 테스트가 이루어지는 현장에서는 우선 아래에서 소개되는 V 모델 (V-Model)을 사용한 책무나 범위 정리를 한 후에, 자신들이 수행할 테스트의 책무와 범위를 결정할 수 있으면 좋을 것 같다.

...2로 넘어가고 싶지만, 다음과 같은 문제가 있다.

• 프로덕트 리스크 (Product Risk)를 알 수 없음
• 사양서에 적혀 있지 않은 테스트 대상이 충족해야 할 요구사항을 알 수 없음
• 테스트 대상의 특성을 알 수 없음

이것들을 모르는 채로 테스트를 만들어도 대략적인 테스트밖에 할 수 없고, 타당성을 평가하기 어려운 테스트밖에 할 수 없으므로 이를 밝혀낸다.

이러한 모르는 것들 중에서도 구체적인 것부터 착수하는 것이 좋다고 생각한다.

앞서 언급한 것 중에서는,

테스트 대상의 특성을 알 수 없음

이 비교적 구체적이다.

이를 밝혀내어 테스트 대상에 대한 이해가 진행되면, 사용자가 어떤 경험을 하는지도 이미지화할 수 있게 되므로, 그 상태가 된 후에,

프로덕트 리스크를 알 수 없음

사양서에 적혀 있지 않은 테스트 대상이 충족해야 할 요구사항을 알 수 없음

에 착수하는 것이 좋아 보인다.

뭐, 이것들은 테스트 대상으로부터 생각하기보다 상류의 요구사항 정의서 (Requirements Definition Document)를 확인하러 가거나 스테이크홀더와 이야기하며 생각하는 편이 검토하기 쉽거나 정확할 것이라고 생각하므로, 병행하여 진행하는 것이 좋다고 생각한다.

AI를 사용하여 테스트 대상의 특성을 이해하는 방법인데, 나는 다음과 같은 흐름으로 작업하는 경우가 많다. 이 흐름은 테스트 베이스 (Test Base)의 볼륨이나 상태에 따라 달라진다.

• 테스트 베이스의 어디에 무엇이 적혀 있는지 정리한다 (가능하면 후속 공정에서 사용할 수 있는 정보의 메모도 남겨둔다)
• 테스트 대상의 대략적인 특징을 이해한다 (누가, 무엇을 위해, 어떻게 사용하는지, 어떤 기능이 있는지)
• 테스트 대상의 특성과 그에 대한 테스트 조건 (Test Condition)을 목록화한다
• 테스트 조건에 영향을 주는 인자 (Factor)를 특정한다

이것들을 진행하는 과정에서 스테이크홀더에게 묻고 싶은 것이 생기면 질문지에 기재한다.

AI를 사용하는 경우, 1은 AI에게 시킨다.

이곳은 어디까지나 테스트 대상(Test Object)을 학습하기 위한 사전 준비 단계이므로, 제가 직접 하지 않아도 괜찮습니다. 또한 모든 테스트 베이스(Test Base)에 대해 정리가 이루어졌는지 확인하는 것은 그리 많은 수고가 들지 않기 때문입니다 (정리 방식이 올바른지 확인하는 것과는 별개의 문제입니다).

이번 테스트 베이스(정확히는 사양서)는 규모가 작고, 장(Chapter) 구성 등도 일관성이 없기 때문에 페이지 단위로 분석합니다. 다음은 출력 결과입니다.

우선, 모든 페이지에 대한 분석 결과가 출력되었는지는 확인합니다.

내용의 정확성을 세밀하게 평가하려고 하면 AI를 사용하여 편해지려 했던 의미가 퇴색되며, 후술할 2와 3에서 직접 수행해야 하는 작업이 발생하므로 부적절한 내용이 있다면 그 과정에서 인지할 수 있을 것입니다. 따라서 세밀하게 평가는 하지 않습니다.

페이지 수로 출력은 했지만, 개요 내용이 보기 불편하여 작업 효율이 떨어지므로 정보를 조금 더 가공하도록 합니다. 또한, 식별자(Identifier)를 할당해 두는 편이 나중에 추적성(Traceability)을 조사하기 쉬우므로 ID도 부여해 둡니다.

...이후부터는 결과물을 시간 내에 준비하지 못했으므로 예정 사항만 기재합니다.

2는 직접 수행합니다.

직접 한다고는 해도, 최종적으로 자신의 언어로 책임감을 가지고 설명할 수 있으면 되므로, 그 상태에 이르기 전까지는 AI를 사용합니다. AI에게 질문하거나 자신의 가설을 리뷰받습니다. 다만, 원전(실제 테스트 베이스)을 참조하는 비율과 AI가 처리한 정보를 참조하는 비율 중 후자가 늘어날수록 불안감도 커지므로 주의해야 합니다.

3은 AI가 적절한 결과물을 내놓는 경우가 적으므로 직접 수행합니다.

AI가 적절한 결과물을 내놓는 경우가 적다

이것은 AI가 틀린 것을 내놓는다는 의미라기보다, 저와는 다른 '이해 방식'으로 내놓기 때문에 받아들이기 어렵다는 의미입니다. 예를 들어, 사과에 대해 '빨갛다', '둥글다'라는 이해의 습관이 저에게 있다면, AI가 내놓은 '채소', '좋은 향기'라는 이해 방식을 받아들이는 데 시간이 걸리는 느낌입니다. 뭐, 이해 방식을 사전에 프롬프트(Prompt)에 포함해 두면 될 문제입니다.

4는 AI를 사용합니다. 적절한 출력이 나오지 않으면 직접 수행합니다.

테스트 조건에 영향을 미치는 인자(Factor)를 특정하려면 사양서를 잘 읽어야 하는데, 그 부분은 AI가 강점을 가진 영역입니다. 또한 테스트 조건을 결정할 때와 달리, 영향을 미치는 인자는 테스트 조건과 사양서의 내용으로부터 논리적으로 도출할 수 있으므로 그 점에서도 AI가 유용하기 때문입니다.

사양서의 정보가 부족하면 반대로 엉뚱한 내용이 될 수 있으므로, 그럴 때는 직접 수행합니다.

다음 작업은 Part2에서 다루겠습니다.

AI 활용 방법이나 더 좋은 방법이 있다면 알려주세요!