이득:
- 인공 지능의 지원을 받아 동등 클래스, 경계 값 분석, 결정 테이블과 같은 기술을 사용하여 요구 사항 및 허용 기준을 포괄적인 테스트 사례로 변환하는 기능
- 긍정, 부정, 엣지 케이스 시나리오를 별도로 생성하고, 인공지능이 놓친 엣지 케이스를 제품 정보로 완성하는 능력
- 테스트 사례를 승인 기준에 연결하여 추적성을 확립하고 적용 범위 격차와 불필요한 팽창을 제거하는 기능
테스터의 작업은 종종 이 백지 상태에서 시작됩니다. 그는 요구 사항("사용자는 자신의 비밀번호를 재설정할 수 있어야 합니다")을 갖고 있으며 이 단일 문장을 소프트웨어가 실제로 올바르게 작동하는지 입증하는 수십 개의 구체적인 검사로 바꿔야 합니다. 이러한 변환을 테스트 설계라고 합니다. 테스트 시나리오(예: "잘못된 비밀번호는 거부되어야 함"과 같이 테스트 대상을 설명하는 상위 수준 목표)와 테스트 사례(구체적인 단계, 입력 및 예상 결과로 해당 시나리오를 자세히 설명하는 실행 가능 단위) 간의 차이점을 아는 것이 중요합니다. 인공 지능(AI)은 이 빈 페이지의 순간을 정확히 가속화합니다. 즉, 하나의 요구 사항을 몇 초 만에 수십 개의 초안 시나리오로 전환합니다. 하지만 기억하세요. AI는 사용자가 생각할 수 있는 상황을 복제합니다. 어떤 상황이 정말 중요한지 제품 지식을 바탕으로 선택합니다.
이 단원에서는 AI 지원을 통해 요구 사항을 포괄적이면서도 복잡하지 않은 테스트 모음으로 전환하는 방법을 단계별로 학습합니다.
단계별: 요구사항에서 테스트 세트까지
1단계 - 요구사항을 명확히 합니다. AI에 원시 요구 사항을 제공하기 전에 수락 기준(작업이 "완료"로 간주되기 위해 충족해야 하는 조건)을 수집합니다. "비밀번호를 재설정할 수 있어야 합니다"만으로는 충분하지 않습니다. '리셋 링크는 30분 동안 유효하다', '같은 비밀번호는 재사용할 수 없다' 등의 규칙이 실제 테스트의 원천이다.
2단계 - 테스트 기술을 구현합니다. AI에 대해 "스크립트 작성"이라고만 말하지 마십시오. 이름으로 고전적인 테스트 설계 기술을 요청하십시오.
- 동등 클래스(동등 분할): 입력을 동일한 동작을 생성할 것으로 예상되는 그룹으로 나눕니다. 예를 들어 연령 필드의 경우 "유효 범위", "너무 작음" 및 "너무 큼"은 클래스입니다. 각 클래스에서 하나의 예제를 테스트하는 것으로 충분합니다.
- 경계값 분석: 경계에서 오류가 가장 많이 발생한다는 사실을 기반으로 임계값을 테스트합니다. 18세 제한에 대해 17세, 18세, 19세를 별도로 테스트하는 것과 같습니다.
- 의사결정 테이블: 여러 조건의 조합과 각 조합의 예상 결과를 표로 작성합니다.
- 상태 전환: 상태에서 상태로의 시스템 전환(예: 주문: 생성 → 지불 → 배송) 및 유효하지 않은 전환을 테스트합니다.
3단계 - 포지티브, 네거티브 및 에지 상태를 분리합니다. 긍정적인 테스트(올바른 입력으로 예상되는 결과), 부정적인 테스트(잘못된 입력으로 인한 올바른 오류) 및 경계선 또는 비정상적인 사례인 엣지 케이스를 요청하세요. AI는 일반적으로 긍정적인 점을 강조합니다. 부정적인 사례와 엣지 사례는 명시적으로 요청하지 않는 한 불완전합니다.
4단계 - 우선순위를 정하고 정리합니다. AI는 60가지 시나리오를 생성할 수 있습니다. 그것들은 모두 동일한 가치가 아닙니다. 위험도가 높은 항목(금전, 보안, 데이터 손실)을 우선적으로 처리하고 중복되는 항목을 결합합니다.
팁: "이 요구 사항에서 상상할 수 없는 5개의 극단적인 경우를 생성하세요"라는 별도의 요청을 AI에 보냅니다. AI의 가장 가치 있는 기여는 당신이 간과했던 특별한 상황을 종종 상기시켜준다는 것입니다.
약한 프롬프트 / 강한 프롬프트
약함: "비밀번호 재설정을 위한 테스트 사례를 작성합니다."
Strong: "다음 허용 기준을 사용하여 '비밀번호 재설정' 기능에 대한 테스트 사례를 생성합니다. 30분 동안 유효한 링크, 단일 사용, 마지막 3개의 비밀번호는 재사용할 수 없음, 5회 잘못된 시도 후 15분 동안 계정이 잠김. 등가 클래스 및 경계 값 분석을 적용합니다. 별도의 제목에 긍정, 부정 및 엣지 사례를 제공합니다. 각 사례에 대해: ID, 전제 조건, 단계, 테스트 데이터, 예상 결과, 관련 허용 기준. 보안/잠금 시나리오를 강조 표시합니다."
강력한 프롬프트; 규칙, 기술, 출력 형식 및 우선 순위를 제공합니다. 따라서 AI는 장식적인 테스트 케이스가 아닌 실행 가능하고 추적 가능한 테스트 케이스를 생성합니다.
테스트 케이스 출력 형식
팀의 테스트 관리 도구(예: TestRail, Zephyr, Xray)로 직접 가져올 수 있는 구조화된 형식을 요청하세요. 다음 표는 좋은 테스트 사례의 구성 요소를 보여줍니다.
지역
설명
예
아이디
고유 ID
TC-PWD-014
제목
간략한 목적
만료된 링크는 거부됩니다.
전제 조건
테스트 전 필요한 조건
재설정 링크가 31분 전에 생성되었습니다.
단계
순차적 작업
1. 링크 클릭 2. 새 비밀번호 입력
테스트 데이터
사용된 구체적인 값
이전 링크, 새 비밀번호 "Abc!2345"
예상되는 결과
확인해야 할 동작
"링크 만료" 오류, 비밀번호가 변경되지 않음
합격 기준
추적성 링크
AK-3: 링크는 30분 동안 유효합니다.
우선순위
위험 수준
높다
복사 가능한 템플릿 4개
1) 기술 기반 시나리오 제작:
귀하의 역할: 수석 테스트 디자이너. 기능에 대한 테스트 사례 생성: [기능 및 승인 기준]. 적용: 동등 클래스, 중단점 분석, 결정 테이블. 3개 그룹의 출력 제공: 긍정/부정/에지 사례. 각 사례: ID, 전제 조건, 단계, 테스트 데이터, 예상 결과, 관련 허용 기준, 우선순위(높음/중간/낮음).
2) 엣지 케이스 헌터:
다음 기능에 대해 일반적으로 간과되는 10가지 예외 사례를 나열하십시오: [기능]. 각각 위험한 이유를 한 문장으로 적어보세요. 비어 있음/널(null), 너무 긴 입력, 동시성, 시간 초과, 형식 오류, 유니코드/이모지, 음수/0, 네트워크 중단과 같은 축을 생각해 보세요.
3) 의사결정 테이블 생성:
다음 비즈니스 규칙에 대한 의사결정 테이블을 작성하십시오. [규칙].열: 조건 조합; 행: 각 조건 및 예상되는 동작. 달성할 수 없거나 충돌하는 조합을 표시합니다. 그런 다음 각 조합에 대한 테스트 사례를 제안합니다.
4) 추적성 관리:
다음 허용 기준 목록과 테스트 사례가 주어졌습니다:[기준] / [사례]. 테스트 케이스가 없는 경우(커버리지 격차) 승인 기준을 충족하는 기준과 어떤 기준도 충족하지 못하는 경우(중복 케이스)를 표 형식으로 표시합니다.
세 개의 미니 케이스
사례 1 - 가장자리 상태의 값. 한 핀테크 팀의 전문가가 송금 기능을 위한 18개의 스크립트를 작성했습니다. 그는 AI에 "Edge Case Hunter" 템플릿을 적용했습니다. AI는 "동시에 두 기기에서 동일한 잔액을 이체하는 것"(동시성) 상황을 상기시켰다. 이 시나리오를 테스트했을 때 이중 지출 취약점이 발견되어 실행되기 전에 해결되었습니다. 단일 주변 상황으로 인해 잠재적인 6자릿수 손실을 방지할 수 있었습니다.
사례 2 - 돌출부 다듬기. 한 팀은 AI가 회원가입 양식에 대한 스크립트를 작성하게 했고 74건이 처리됐다. 추적성 템플릿을 실행하면 74개 사례가 9개 허용 기준만 충족하는 것으로 나타났으며, 많은 경우 동일한 동등 클래스를 다시 테스트했습니다. 세트는 74개에서 23개의 중요한 사례로 줄었습니다. 실행 시간이 68% 감소했지만 적용 범위는 감소하지 않았습니다.
사례 3 - 잘못된 가정. AI는 날짜 필드에 "2월 31일"과 같은 유효하지 않은 날짜 테스트를 제안했지만 팀이 사용하고 있는 달력 구성 요소가 이미 이를 차단했다는 사실은 몰랐습니다. 전문가는 AI가 제작한 데이트 시나리오 6개 중 제품 맥락에서 불필요하다고 판단되는 4개를 삭제했다. AI가 생성한 가능성; 상품정보 선택을 하셨습니다.
일반적인 실수
- 승인 기준을 제공하지 않고 스크립트를 요청합니다. 무엇이 진실인지 알지 못한 채 AI는 종종 실제 위험을 놓치는 피상적인 시나리오를 생성합니다.
- 긍정적인 테스트에 만족하면 됩니다. 부정적이고 극단적인 경우를 명시적으로 원하지 않습니다. 여기에 오류가 자주 발생합니다.
- 생산된 것을 있는 그대로 받아들이는 것. AI가 제품의 맥락을 모른다는 사실을 망각하고 불필요하거나 불가능한 시나리오를 세트장에 남겨두는 것입니다.
- 추적성을 우회합니다. 사례를 승인 기준에 연결하지 않음 결과적으로 어떤 기준이 테스트되지 않았는지 알 수 없습니다(커버리지 격차).
- 수량 오류. "대본이 60개나 나왔다"는 게 기쁘다. 그 가치는 숫자에 있는 것이 아니라 위험을 포괄하는 범위에 있습니다.
요약하면
테스트 설계는 한 문장의 요구 사항을 소프트웨어의 정확성을 입증하는 구체적이고 실행 가능한 사례로 변환하는 것입니다. AI는 이러한 변환을 크게 가속화합니다. 수용 기준, 기존 테스트 기술(동등 클래스, 중단점, 결정 테이블, 상태 전환) 및 명확한 출력 형식을 제공하면 포괄적인 청사진을 생성합니다. 그러나 AI는 긍정적인 쪽으로 편향되어 제품의 맥락을 알지 못하며 불필요한 부풀림을 생성할 수 있습니다. 귀하의 임무는 부정적인 사례와 극단적인 사례를 명시적으로 요청하고, 추적성을 설정하고, 위험에 따라 우선순위를 정하고 정리하는 것입니다.
응용과제
자신의 프로젝트에서 기능을 선택하고 승인 기준을 적어보세요. AI가 '기술 기반 시나리오 생성' 템플릿으로 테스트 케이스를 생성하게 하세요. 그런 다음 "Edge Case Hunter" 및 "Traceability Check" 템플릿을 적용합니다. 결과적으로 (1) AI가 건너뛰는 3개 이상의 엣지 케이스를 추가하고, (2) 어떤 승인 기준에도 연결되지 않는 케이스를 잘라내고, (3) 테스트되지 않은 승인 기준이 남아 있으면 새 케이스를 작성합니다. 최종 세트를 스프레드시트에 붓습니다.
체크리스트
- [ ] 대본을 요청하기 전에 수락 기준을 명확히 했습니다.
- [ ] YZ에 이름별 등가 클래스 및 경계값 분석을 요청했습니다.
- [ ] 포지티브, 네거티브 및 에지 상태를 별도로 생성했습니다.
- [ ] 각 테스트 사례를 승인 기준(추적성)에 연결했습니다.
- [ ] 범위의 차이와 불필요한 경우를 표로 확인했습니다.
- [ ] 위험을 우선시하고 부풀어 오른 세트를 잘라냈습니다.