엔드투엔드 워크플로, CI/CD 통합, 윤리 및 보안: 책임감 있는 AI 사용

이득:

• CI/CD의 맥락에서 아이디어부터 출시까지 엔드 투 엔드 QA 흐름에서 인공 지능 및 인간 승인 지점의 역할을 설계하는 능력
• CI/CD에서는 AI가 테스트를 자동으로 '통과'하도록 승인하는 것이 아니라 기밀 데이터와 키를 보호하기 위해 제한을 적용합니다.
• 권한 내에서 방어 목적으로 보안 테스트를 수행하고 책임 있는 공개 및 윤리적 투명성 원칙을 채택하는 능력.

이전 10개 단원에서는 시나리오 생성, 자동화 코드, 버그 보고, 적용 범위 분석, 돌연변이 테스트 등 개별 작업에 AI를 사용했습니다. 이 최종 단위는 모든 것을 하나의 책임 있는 작업 흐름으로 결합합니다. 현대의 QA는 한 사람의 책상에서 끝나는 작업이 아닙니다. 이는 CI/CD(지속적 통합/지속적 전달 - 코드가 지속적으로 결합되고 자동으로 테스트되며 자주 안전하게 게시할 준비가 되는 파이프라인) 내에 존재하는 프로세스입니다. AI는 이 프로세스의 모든 단계를 다룰 수 있습니다. 그러나 AI의 힘이 커짐에 따라 개인 정보 보호, 보안 테스트 권한, 윤리, 그리고 가장 중요한 품질 결정을 인간에게 맡기는 등 AI를 책임감 있게 사용하는 것의 중요성도 커집니다. 이번 단원에서는 엔드투엔드 흐름과 경계를 학습합니다.

엔드투엔드 AI 기반 QA 흐름

아이디어에서 출시까지 기능의 여정에서 AI의 역할:

1. 요구사항 분석. AI는 요구 사항의 모호성과 허용 기준 누락을 표시합니다("이 규칙은 비밀번호의 최소 문자 수를 명시하지 않습니다").

2. 테스트 설계. 시나리오 및 사례 초안(단원 2), 엣지 사례(단원 3)가 승인 기준에 속합니다.

3. 자동화. 유닛(6), API(5) 및 UI(4) 테스트 코드 초안 각각은 돌연변이에 의해 확인됩니다(10).

4. CI/CD 통합. 테스트는 코드를 병합할 때마다 자동으로 실행됩니다. AI 초안 파이프라인 구성(YAML)은 실패한 테스트 로그를 요약하고 가능한 근본 원인을 제안합니다.

5. 출시 결정. 위험 분석(8) 및 회귀(9) 결과가 수집되지만 성공 여부는 전문가가 결정합니다.

6. 생산 모니터링 및 피드백. 실시간 오류는 향후 테스트가 됩니다. AI는 제조 결함에 대한 회귀 사례를 제안합니다.

팁: AI를 "테스트를 작성하고 결정을 내리는" 대신 "사람이 검토한 초안을 가속화"하는 CI/CD의 레이어로 설정하세요. 자동으로 생성된 테스트는 사람의 검토 및 승인 없이 파이프라인에 입력되어서는 안 됩니다.

CI/CD의 AI: 예인 경우, 아니오인 경우

무대

AI핏

인간은 필수적이다

테스트 코드 초안

예

개정 + 돌연변이

파이프라인 YAML 초안

예

인증 + 비밀키 확인

실패한 로그 요약

예

근본 원인 확인

취약한 테스트 진단

예

영구적인 솔루션 결정

"버전이 있을 수 있나요?"

아니

전문가의 판단과 책임

테스트를 자동으로 "통과"합니다.

결코

—

주의: CI/CD에서 "실패한 테스트를 통과하도록 수정"과 같은 명령을 AI에 부여하지 마십시오. 이는 테스트 목적에 어긋나고 자동으로 오류를 덮어줍니다. AI는 오류를 설명하고 수정을 제안할 수 있습니다. 그러나 "테스트를 녹색으로 칠하는 것"은 개인의 의식적이고 합리적인 결정이어야 합니다.

개인 정보 보호, 데이터 및 보안: 불변의 경계

개인 정보 보호. 테스트 환경에서는 실제 고객 데이터, 프로덕션 데이터베이스 복사본, API 키 및 내부 시스템 정보가 중요합니다. 공용 AI 도구에 이러한 정보를 제공하지 마십시오. 개인 데이터에는 KVKK 및 유사한 규정이 적용됩니다. 로그 및 스크린샷을 마스크합니다. 가능하면 합성(가상) 테스트 데이터를 사용하십시오.

보안 테스트 - 방어적이고 승인되었습니다. 이 모듈에서 학습한 보안 테스트(인증/IDOR 테스트, 파일 업로드 제한, 입력 유효성 검사)는 서면 승인 및 정의된 범위 내에서 자체 제품을 테스트하기 위한 것입니다. AI를 사용하여 허가 없이 다른 사람의 시스템에 액세스하거나, 실제 취약점을 무기화하거나, 범위를 벗어난 테스트를 수행하는 것은 비윤리적이고 불법입니다. 보안 취약점을 발견하면 책임 공개 원칙을 준수하십시오. 즉, 취약점을 기밀로 유지하고 문제가 해결될 수 있도록 관련 당사자에게 보고하십시오.

윤리와 투명성. AI가 작성한 테스트를 자신의 작업으로 제시하지 마십시오. 팀 내에서 AI를 사용하고 있다고 말하는 것은 투명성입니다. AI가 생성한 출력의 부정확성에 대한 책임은 귀하에게 있습니다. "AI가 작성했습니다"는 변명이 될 수 없습니다.

약한 프롬프트 / 강한 프롬프트

약함: "CI용 테스트 파이프라인을 설정합니다."

Strong: "GitHub Actions를 위한 CI 워크플로 YAML 초안을 작성합니다. 각 PR에서 단위 + API 테스트를 실행하고, 적용 범위 보고서를 생성하고, 돌연변이 테스트(Stryker)를 매주 실행합니다. 코드에 비밀을 포함하지 마세요. 비밀 참조만 사용하세요. 테스트가 빨간색이면 병합을 차단하세요. 이것은 초안입니다. 비밀 키 관리 및 유효성 검사 단계를 검토하고 편집하겠습니다. 자동화된 테스트 '수정' 또는 '마이그레이션' 단계를 추가하지 마세요."

강력한 프롬프트; 기밀성, 인적 검토 및 "자동 테스트 없음"에 제한을 둡니다.

복사 가능한 템플릿 4개

1) 엔드투엔드 테스트 계획:

귀하의 역할: 수석 QA 리더. 다음 기능에 대한 아이디어부터 릴리스까지 엔드투엔드 테스트 계획 초안을 작성합니다: [기능 + 수용 기준]. 단계: 요구 사항 분석(불확실성), 테스트 설계, 자동화 계층(단위/API/UI), CI/CD 통합, 릴리스 결정 기준, 생산 추적. 각 단계에서 AI와 HUMAN 승인 포인트의 역할을 별도로 지정합니다.

2) CI/CD 파이프라인 개요:

[GitHub Actions/GitLab CI/Azure Pipelines]에 대한 CI YAML 초안:- PR의 단위 + API 테스트 + 범위- 빨간색 테스트에서 병합 방지- 비밀 값만 비밀과 함께; 코드에 포함이것은 초안입니다. 주요 관리 및 승인 단계를 검토하겠습니다. 자동 수정/통과 테스트 단계를 추가합니다.

3) 실패한 테스트 로그 분석:

해당 CI 인쇄물에서 테스트는 빨간색으로 표시됩니다. 로그를 조사하십시오. 오류를 그룹화하고 가능한 근본 원인을 구별하며 실제 오류일 수 있고 취약한 테스트/환경 문제일 수 있습니다. 개인정보가 있으면 마스킹하세요. 결정과 수정은 나의 몫입니다. 로그: [붙여넣기]

4) 보안/개인정보 사전 점검:

이 테스트 데이터/로그를 AI 도구로 전송하기 전에 개인 데이터, API 키, 내부 시스템 주소, 생산 데이터가 포함되어 있는지 확인하십시오. 어떤 영역을 마스킹/제거해야 하는지 나열하세요. 그대로 처리합니다. 내용: [붙여넣기]

세 개의 미니 케이스

사례 1 — 엔드투엔드 흐름 속도. 한 팀은 AI 기반 엔드투엔드 흐름을 통해 새로운 "구독 갱신" 기능을 다루었습니다. 요구사항 불확실성이 미리 표시되고 3계층 테스트 초안 작성 및 변형 검증이 이루어지며 CI와 연결됩니다. 이 기능은 기존 프로세스에서 5일이 걸리던 테스트 주기를 2일로 단축했습니다. 그러나 모든 단계에서 사람의 승인이 유지되었으며 요구 사항의 불확실성(새로 고침이 실패하면 어떻게 되는지)이 라이브 전에 종료되었습니다.

사례 2 - 키 유출로 인한 복귀. 개발자는 AI가 CI YAML을 생성하도록 했고, AI는 예시로 실제처럼 보이는 API 키를 YAML에 삽입했습니다. "보안/개인정보 사전 확인" 단계에서 이를 포착했습니다. 키가 비밀 참조로 변환되었습니다. 감사 단계가 없으면 키가 버전 제어(git 기록)로 유출됩니다.

사례 3 - 권한의 한계. 한 팀원이 "궁금하다"는 마음에 자신이 배운 IDOR 테스트를 비즈니스 파트너의 라이브 시스템에 적용하고 싶어했습니다. QA 리더가 중단했습니다. 서면 승인 및 정의된 범위 없이 다른 시스템에서 보안 테스트를 수행하는 것은 불법입니다. 테스트는 권한을 가지고 자사 제품의 테스트 환경에서만 이루어졌습니다. 공개된 책임 당사자는 해당 팀에 통보되었습니다.

일반적인 실수

• AI가 출시 결정을 내리게 만듭니다. "공개할 수 있나요?"라는 질문을 던집니다. AI에게 서명 대신 답변을 넣는 것입니다.
• 자동화된 테스트를 "통과"합니다. CI에서는 AI가 테스트 녹색을 칠하게 하는 것; 실수를 은폐하는 것.
• 기밀 데이터/키를 차량에 제공합니다. 감독 없이 생산 데이터, 개인 데이터 또는 API 키를 공유합니다.
• 무단 보안 테스트. 공격자는 범위와 허가 없이 다른 시스템에서 테스트합니다.
• 검토 없이 파이프라인에 테스트를 도입합니다. 사람의 승인 없이 AI 스케치를 자동으로 실행합니다.
• AI에게 책임을 전가합니다. "AI가 작성했습니다"라고 말하여 잘못된 출력을 방어합니다.

요약하면

엔드투엔드 QA는 요구 사항부터 생산 추적까지 확장되고 CI/CD 내에서 실행되는 프로세스입니다. 모든 단계에서 AI는 초안을 작성하고 로그를 요약하며 근본 원인을 제안합니다. 그러나 경계는 불변입니다. 인간이 테스트 결정을 내리고 릴리스 승인을 내립니다. AI에는 테스트를 자동으로 "통과"할 권한이 부여되지 않습니다. 기밀 데이터와 열쇠는 차량에 들어가지 않습니다. 보안 테스트는 서면 승인 및 정의된 범위 내에서 방어 목적으로 귀하의 제품에 대해서만 수행되며 결과는 책임 있는 공개와 함께 보고됩니다. AI를 사용할 때는 투명성을 유지하세요. 출력의 정확성에 대한 책임은 귀하에게 있습니다. AI가 가속화됩니다. 귀하는 품질과 윤리를 보증합니다.

응용과제

자신의 프로젝트 기능에 대한 "엔드 투 엔드 테스트 계획" 템플릿을 사용하여 아이디어부터 출시까지의 계획 초안을 작성하세요. 각 단계마다 AI와 인간의 승인 지점의 역할을 별도로 표시합니다. 그런 다음 "CI/CD 파이프라인 개요"를 사용하여 YAML을 생성하고 이 YAML에 "보안/개인정보 사전 확인"을 적용하여 내장된 키/비밀 데이터를 확인합니다. 마지막으로, 계획의 모든 "인간 결정" 항목을 나열하고 이러한 결정을 AI에 위임할 수 없는 이유를 한 문장으로 설명하세요.

체크리스트

• [ ] 나는 릴리스 및 테스트 결정을 사람의 승인에 따라 결정합니다. 나는 그것을 AI에게 넘겨주지 않았습니다.
• [ ] CI/CD에서는 테스트를 자동으로 "통과/수정"할 수 있는 권한을 AI에 부여하지 않았습니다.
• [ ] 기밀자료, 개인정보, 열쇠 등을 차량으로 보내기 전에 확인하고 마스킹했습니다.
• [ ] 나는 서면 승인 및 범위 내에서 내 제품에 대한 보안 테스트만 고려했습니다.
• [ ] 책임공개 원칙을 바탕으로 발견된 취약점을 해결하였습니다.
• [ ] AI를 사용했으며, 결과의 정확성에 대한 책임은 본인에게 있음을 투명하게 밝혔습니다.

모듈 시험

1. QA 맥락에서 'false pass'는 어떻게 가장 정확하게 정의됩니까?

• A) 테스트가 녹색으로 바뀌더라도 실제로 어떤 동작도 확인하지는 않습니다. ✔ 코드가 손상되어도 빨간색으로 변하지 않습니다
• B) 테스트가 매우 느리게 실행되고 시간이 초과됩니다.
• C) 테스트에서 실제 오류가 감지되고 빨간색으로 변합니다.
• D) 테스트는 프로덕션 환경에서만 실행됩니다.

설명: 의사 통과는 테스트에서 '통과'라고 표시되지만 실제로는 의미 있는 어떤 것도 확인하지 않는 경우입니다. 테스트는 녹색인데 소프트웨어에 결함이 있어도 잡아내지 못합니다. AI는 깔끔해 보이지만 공허한 테스트를 생성하는 경향이 있기 때문에 이는 QA에서 AI의 가장 큰 위험입니다.

2. 테스트 및 QA 프로세스에서 인공지능을 가장 정확하게 포지셔닝하는 방법은 무엇입니까?

• A) 인공지능은 사람의 승인 없이 버전을 출시할 수 있는지 여부를 결정할 수 있습니다.
• B) 인공 지능은 초안과 아이디어를 생성하는 보조자입니다. '게재 준비가 됐는가'에 대한 결정과 책임은 전문가에게 있습니다 ✔
• 다) 인공지능은 텍스트만 쓰고 테스트 코드는 전혀 처리하지 못한다.
• 라) 인공지능은 인간보다 항상 정확한 테스트를 작성하므로 리뷰가 불필요하다.

설명: 인공 지능은 테스트 보조자, 초안 생성기 및 아이디어 승수입니다. 테스트 시나리오, 자동화 코드 및 보고서 초안을 생성합니다. 그러나 '이 소프트웨어가 출판될 준비가 되었는지', '이 테스트를 통과했는지'와 같은 품질 결정에 대한 책임과 최종 승인은 유능한 전문가에게 있습니다.

3. 오류는 대부분 임계값에서 발생한다는 점에서 18세 제한에 대해 17세, 18세, 19세를 별도로 테스트하는 테스트 설계 기법은 무엇입니까?

• 가) 상태 전이 테스트
• 나) 결정표
• 다) 경계값 분석 ✔
• D) 탐색적 테스트

설명: 경계값 분석은 경계에서 오류가 가장 자주 발생한다는 관찰을 기반으로 하며 임계값(한계 바로 아래, 바로 위, 바로 위)을 별도로 테스트합니다. 이는 동등 클래스를 보완하는 강력한 기술입니다.

4. 인공 지능으로 생성된 UI 테스트 자동화 코드의 취약성을 줄이기 위해 요소 선택에서 어떤 접근 방식을 선호해야 합니까?

• A) 가능한 가장 긴 XPath 경로 사용
• B) 화면의 픽셀 위치에 따라 요소 선택
• C) CSS 클래스 이름을 기반으로 선택기 사용
• D) 테스트를 위해 추가된 안정적인 속성(data-testid) 사용 ✔

설명: 긴 XPath 경로와 CSS 클래스 이름은 페이지 구조와 디자인에 따라 크게 달라집니다. 인터페이스가 조금만 바뀌어도 작동이 중단됩니다. 테스트를 위해 특별히 추가된 안정적인 속성(예: data-testid)은 디자인 변경의 영향을 받지 않으며 테스트를 강력하게 만듭니다.

5. API 테스트가 HTTP 상태 코드(예: 200)만 확인하는 것만으로는 왜 충분하지 않습니까?

• A) 올바른 상태 코드가 포함된 본문 데이터가 손상될 수 있으며 상태 확인만으로는 이를 포착할 수 없기 때문입니다(의사 신뢰) ✔
• B) API 테스트에서는 상태 코드가 전혀 신뢰할 수 없기 때문에
• C) 상태 코드 검사로 인해 테스트 속도가 많이 느려지기 때문입니다.
• D) API 테스트에서는 상태 코드가 반환되지 않기 때문입니다.

설명: 서버가 올바른 상태 코드를 반환하는 동안 본문에 손상된 데이터(잘못된 유형, 누락된 필드, 잘못 계산된 값)를 반환할 수 있습니다. 상황만 보는 테스트는 이를 보지 못하고 잘못된 자신감을 갖게 된다. 따라서 스키마/계약 및 비즈니스 규칙 유효성 검사도 추가해야 합니다.

6. 단위 테스트를 인쇄할 때 AI에게 '수용 규칙에 따라 기대값을 수동으로 계산하고 함수의 현재 출력을 참조하지 마세요'라고 지시하는 것이 중요한 이유는 무엇입니까?

• A) 수동 계산이 테스트를 더 빠르게 실행하기 때문입니다.
• B) 그렇지 않으면 테스트에서 코드의 현재(아마도 버그가 있는) 동작을 '올바른' 것으로 받아들이고 버그를 확인하기 때문입니다. ✔
• 다) 인공지능은 십진수 계산을 전혀 할 수 없기 때문에
• D) 테스트에는 승인 규칙이 사용되지 않기 때문입니다.

설명: AI가 테스트 중인 함수의 출력에서 ​​예상 값을 도출하면 함수에 결함이 있어도 테스트를 '통과'하게 만듭니다. 즉, 코드가 무엇을 생성하든 테스트는 참으로 간주됩니다. 승인 규칙과 독립적으로 기대값을 계산하면 테스트가 코드를 반영하는 것이 아니라 규칙에 대한 문지기 역할을 하게 됩니다.

7. 다음 중 좋은 버그 보고서의 가장 두드러진 특징은 무엇입니까?

• A) 최대한 길고 기술적이어야 합니다.
• 나) 인공지능이 쓴 글
• C) 개발자가 독립적으로 따르고 오류를 생성할 수 있는 결정론적 재현 단계가 포함되어 있습니다.
• D) 단지 스크린샷일 뿐입니다

설명: 버그 보고서의 실제 가치는 개발자가 사용자의 도움 없이 버그를 재현할 수 있다는 것입니다. 처음부터 결정적이고 추적 가능한 재생산 단계를 통해 이를 보장합니다. 이러한 단계가 누락된 경우 보고서는 '생성할 수 없음'으로 종료되는 경우가 많습니다.

8. 홈페이지 회사명 표기 오류의 심각도와 우선순위의 관계를 가장 정확하게 표현한 것은 무엇입니까?

• A) Intensity와 Priority는 항상 같은 값을 가져야 합니다.
• B) 이 오류의 심각도와 우선순위는 모두 낮습니다.
• C) 심각도와 우선순위는 동일한 개념이므로 하나의 라벨이면 충분합니다.
• D) 기술적 강도는 낮지만 사업 우선순위(평판)는 높을 수 있다. 둘은 다르게 평가받음 ✔

설명: 심각도는 오류의 기술적 영향(기술적으로 오타가 낮음)이고, 우선순위는 오류를 얼마나 긴급하게 수정해야 하는지를 나타냅니다(모든 방문자가 보는 평판 요소이므로 높음). 두 가지가 항상 같은 방향으로 진행되는 것은 아닙니다. 이 예는 심각도가 낮고 우선순위가 높은 상황입니다.

9. 라인 커버리지가 90%인 테스트 스위트를 가장 정확하게 해석하는 것은 무엇입니까?

• A) 해당 라인이 실행되었음을 보여주지만 올바르게 동작한다는 것을 증명하지는 않습니다. ✔ 커버력이 높아 잘못된 자신감을 줄 수 있음
• B) 소프트웨어의 90%에 버그가 없음을 결론적으로 증명합니다.
• 다) 우수한 시험 품질을 나타내는 확실한 척도이다.
• D) 더 이상 추가 테스트를 작성할 필요가 없음을 나타냅니다.

설명: 행 적용 범위는 행만 실행되었음을 나타냅니다. 그것이 올바른 결과를 낳는다는 것을 증명하는 것은 아닙니다. 어설션 없는 테스트를 통해서도 90% 커버리지를 달성할 수 있습니다. 범위는 '모든 것이 테스트되었습니다'라는 보증이 아니라 '어디를 본 적이 없는' 지도입니다. 실제 보호는 돌연변이 테스트를 통해 측정됩니다.

10. 위험 기반 테스트에서 제한된 테스트 노력을 지시하기 위해 기능의 위험을 어떻게 계산합니까?

• A) 코드 줄 수로만
• B) 실패 확률과 고장이 났을 때 발생하는 효과를 곱하여 ✔
• C) 기능이 개발된 순서대로만
• D) 테스트 작성이 가장 쉬운 기능에만 우선순위를 둡니다.

설명: 위험 기반 테스트에서 위험은 확률 = 확률(고장 가능성) × 영향(깨진 경우 손상)으로 평가됩니다. 확률이 높고 영향이 큰 도메인(결제, 인증)은 가장 집중적인 테스트를 받아야 하며, lowxlow 도메인은 가벼운 테스트를 받아야 합니다.

11. 코드가 변경되지 않았음에도 때때로 통과하고 때로는 실패하는(깨지기 쉬운/불안정한) 테스트에 재시도를 추가할 때 발생할 수 있는 주요 위험은 무엇입니까?

• 가) 시험 진행 시간 단축
• B) 보장 비율을 줄입니다.
• C) 실제 동시성 오류 또는 근본 원인을 은폐하고 증상을 억제함 ✔
• 다) 시험명 변경

설명: 재시도는 치료가 아닌 진단 도구입니다. 우유부단함은 종종 실제 경쟁 상황이나 중독에서 비롯됩니다. 재시도를 통해 테스트를 '통과'하면 이러한 실제 오류가 가려지고 실제로 심각한 문제가 발생할 수 있습니다. 근본 원인을 먼저 찾아야합니다.

12. 테스트 스위트가 실제로 보호하는지 여부를 측정하는 가장 정직한 방법인 돌연변이 테스트는 어떻게 작동합니까?

• A) 테스트 진행 속도를 측정하여
• 나) 몇 줄의 코드가 작성되었는지 세어봄
• C) 다른 순서로 테스트를 실행하여
• D) 의도적으로 코드에 작은 틈을 만들어 테스트에서 이를 포착하는지 측정합니다. ✔

설명: 돌연변이 테스트는 소스 코드에서 작은 의도적 왜곡(돌연변이)을 생성합니다. 좋은 테스트 스위트는 이러한 왜곡을 포착하고 빨간색으로 변해야 합니다. 포착되지 않은(생존한) 돌연변이는 테스트가 해당 동작을 보존하지 않음을 나타냅니다. 돌연변이 점수는 적용 범위보다 품질을 훨씬 더 정직하게 측정합니다.

13. 보안 테스트(예: 인증/IDOR 테스트)를 수행할 때 따라야 할 주요 제한 사항은 무엇입니까?

• A) 방어 목적으로 서면 승인 및 정의된 범위 내에서 자체 제품에 대해서만 수행해야 합니다. ✔
• 나) 관심 있는 모든 시스템에 자유롭게 적용 가능
• 다) 허가 없이 비즈니스 파트너의 라이브 시스템에서 시도될 수 있습니다.
• D) 발견된 취약점은 즉시 공개적으로 게시되어야 합니다.

설명: 이 모듈에서 배운 보안 테스트는 서면 승인 및 정의된 범위 내에서 방어 목적으로만 제품을 테스트하기 위한 것입니다. 허가 없이 다른 사람의 시스템에 액세스하거나 범위를 벗어난 테스트를 수행하는 것은 비윤리적이며 불법입니다. 발견된 모든 취약점은 책임 있는 공개를 통해 보고됩니다.

14. CI/CD 파이프라인에서 AI에 어떤 권한을 부여해서는 안 됩니까?

• 가) 실패한 테스트 로그 요약
• B) 실패한(빨간색) 테스트를 자동으로 '통과'하거나 녹색으로 칠하는 권한 ✔
• 다) 테스트 코드 초안 제안
• D) 파이프라인 YAML 파일 초안 작성

설명: AI는 테스트 코드 개요, 파이프라인 YAML 및 CI/CD의 로그 요약을 생성할 수 있습니다. 그러나 실패한 테스트를 자동으로 '통과/수정'하는 기능은 제공되어서는 안 됩니다. 이는 테스트 목적에 어긋나고 자동으로 오류를 덮어줍니다. 테스트를 녹색으로 칠하는 것은 개인의 의식적이고 합리적인 결정이어야 합니다.