Bloodrabbid/qa-software-testing

소프트웨어 테스팅: UI, API, 수동 및 자동화

기반 — '품질이 모든 것을 결정한다: 소프트웨어 테스팅 완벽 가이드' (Roman Surkov). **[책 외부]**로 표시된 모든 내용은 다른 출처(목록은 마지막에 있음) 또는 일반적으로 허용되는 관행에서 가져왔습니다. 이를 저자의 의견이 아닌 보충 자료로 제시하십시오.

적용 시기

• '기능/화면/애플리케이션/API를 테스트하세요', '체크리스트/테스트 케이스를 작성하세요', '버그를 등록하세요'.
• 개발 전 요구사항, Figma 디자인, Swagger 검증(shift-left).
• 자동화할 항목과 방법 선택, 부하 테스트 시나리오, 릴리스 준비 보고서.
• 비디오 게임의 경우 qa-game-testing 스킬을 사용하고, 여기서는 일반적인 기반(테스트 설계, 산출물)을 가져오세요.

0단계. 작업 모드 결정

요청	제공할 내용
요구사항 명세/디자인 있음, 아직 코드 없음	요구사항 검토(1단계) + 사전 작성된 체크리스트
세부 사항 없이 '테스트하세요'	'BLUGID s PK'(2단계)로 분해 → 체크리스트 → 복잡한 부분에 대한 테스트 케이스
라이브 사이트/애플리케이션 사용 가능	검증 수행, 버그 리포트, 최종 TRR
API / Swagger / cURL	BINMEN + POISED(6단계), 요청 컬렉션
'무엇을 자동화할까요?', 플래키 테스트, Playwright	피라미드 기반 계획 및 자동화 테스트 규칙(8단계)
API 보안 확인	OWASP API Top 10 매트릭스(6단계)
LLM 기능(챗봇, 생성)	검증 계층 및 기준 세트(9단계)
새 기능 자유 테스트	SBTM 세션 헌장 + SFDIPOT(2단계)

먼저 긍정적 검증(happy path), 그 다음 부정적 검증. 긍정적 검증에서는 검증을 결합할 수 있지만, 부정적 검증에서는 하나의 검증에 하나의 유효하지 않은 매개변수만 사용합니다.

1단계. 요구사항 테스팅(shift-left)

오류는 1-10-100 규칙에 따라 비용이 증가합니다. 요구사항 명세서 수정 비용은 1, 코드 수정은 3-8배 더 비싸고, QA가 발견하면 20-80배, 프로덕션에서는 100배 이상 비쌉니다. 따라서 문서부터 시작하십시오.

좋은 요구사항의 기준(각 위반 사항에 대해 문서에 주석 추가): 완전성(극단적인 경우와 오류 설명), 일관성(텍스트가 디자인과 충돌하지 않음), 명확성, 정확성, 테스트 가능성('이걸 어떻게 확인하지?'), 원자성(하나의 아이디어).

의미 없는 단어 — '빠른', '편리한', '직관적인', '유연한', '적절한', '필요한 경우'. 측정 가능한 형태로 다시 작성하세요: '검색이 빠름' → '1000개의 동시 요청 시 결과 ≤ 1.5초'.

요구사항 명세서가 없는 경우, 예상 결과는 다음에서 가져옵니다: 디자인 및 프로토타입 → 경쟁사 → 법률 및 규제 기관 (GDPR, PSD2) → 모범 사례 및 상식(이메일 검증, 속도 제한, 전화 마스크) → 개발자 또는 분석가와의 대화.

요구사항을 철저히 검토하는 방법: 경계에 대한 질문(최대 길이, 금지된 문자, 연결 끊김, 두 사용자가 동시에 클릭), 경로의 블록 다이어그램 또는 마인드 맵(빈 공간으로 가는 화살표는 설명되지 않은 시나리오), 읽는 동안 바로 테스트 케이스 작성(케이스를 작성할 수 없으면 요구사항 명세서에 버그가 있는 것입니다).

오라클 FEW HICCUPPS [책 외부, M. Bolton과 J. Bach] — 사양이 없거나 불완전할 때 동작이 문제가 있음을 증명하는 다른 방법. 제품은 다음과 일치해야 합니다: Familiar problems(알려진 버그 유형을 반복하지 않음), Explainability(동작 설명 가능), World(현실과 모순되지 않음), History(이전 버전), Image(회사 이미지), Comparable products(유사 제품), Claims(요구사항 명세서, 광고, 도움말), User desires(사용자의 합리적인 욕구), Product(자체적으로: 하나의 동작은 모든 곳에서 동일하게), Purpose(목적), Statutes and standards(법률 및 표준). 버그 보고서에서 오라클 이름을 지정하세요: '이전 버전과 모순됨', '도움말과 모순됨' — 이렇게 하면 '이건 버그가 아닙니다'라는 논쟁을 쉽게 처리할 수 있습니다.

누락된 기능: 기능이 없고 요구사항 명세서에도 없으면 버그가 아니라 개선/기능 요청입니다. 기능 매트릭스로 논란을 해결하세요: 웹 — 있음, iOS — 있음, Android — 없음.

2단계. '테스트하세요' 작업 분해

기능 테스트는 '무엇을' 하는지에 대한 질문에 답하고, 비기능 테스트는 '어떻게' 하는지에 답합니다. 비기능적 측면은 니모닉 'BLUGID s PK' 를 사용하여 확인하세요:

• B — 보안 (XSS, SQL 인젝션, 접근 권한)
• L — 지역화
• U — 사용성 (usability)
• G — 그래픽 인터페이스 (GUI)
• I — 설치 (설치 가능한 항목: 데스크톱, 모바일, 콘솔)
• D — 접근성 (a11y)
• P — 성능 (클라이언트 및 서버)
• K — 구성 및 호환성

자유로운 탐색을 위해 Whittaker의 탐색 투어를 추가하세요: 가이드 투어(주요 기능), 뒷골목 투어(드문 설정), 택배 투어(모든 상태를 거치는 하나의 객체), 돈 투어(장바구니 및 결제), 자정 투어(백그라운드 작업), 청소부 투어('취소', '재설정'), 집요한 투어(동일한 작업 100회 반복), 나쁜 동네 투어(역사적으로 문제가 있는 모듈), 박물관 투어(오래되고 오랫동안 건드리지 않은 코드).

제품에 무엇이 있는가 — SFDIPOT [책 외부, J. Bach의 HTSM]: Structure(구성 요소: 파일, 모듈, 빌드), Function(하는 일), Data(입력, 저장, 출력하는 데이터; 빈 데이터, 거대한 데이터, 손상된 데이터), Interfaces(UI, API, 가져오기/내보내기, 통합), Platform(OS, 브라우저, 하드웨어, 외부 서비스), Operations(실제 사용 방식: 빈번한 시나리오, 경험이 없는 사용자 및 악의적인 사용자), Time(시간 초과, 병렬성, 이벤트 순서, 시간대, 장시간 작업). 일곱 단어를 살펴보면 BLUGID가 제공하지 않는 적용 범위 맵을 얻을 수 있습니다.

세션 기반 탐색 테스팅(SBTM) [책 외부, J.와 J. Bach]. 방해 없이 60-90분 세션, 헌장이 있습니다: '<도구, 기술, 데이터> 를 사용하여 <영역> 을 탐색하여 <알고자 하는 것> 을 발견하십시오.' 세션 종료 시: 적용된 내용, 발견된 버그, 질문, 위험, 테스트/버그 보고/환경 설정에 소요된 시간 비율, 그리고 리드와의 간단한 검토. 이렇게 하면 자유로운 테스트도 보고 가능해집니다: 무엇이 확인되었고 무엇이 남았는지 알 수 있습니다.

3단계. 테스트 설계 기법

순서: 먼저 EP + BVA + 결정 테이블로 프레임워크를 만든 다음, Error Guessing으로 강화합니다.

1. 동등 분할(EP): 각 유효 및 무효 클래스에서 하나의 값을 가져옵니다.
2. 경계 값 — 3BVA만 사용: 각 경계에서 min-1, min, min+1(max도 동일)을 가져옵니다. 2BVA는 연산자 오타 X == 10 대신 X >= 10를 놓칠 수 있습니다: 포인트 9와 10은 통과하지만 11은 실패합니다. 예: 18-100세 액세스 → -1, 0, 1, 16, 17, 18, 99, 100, 101. 금액의 경우 단계는 최소 단위(0.01₽)입니다.
3. 조합 테스팅: 1-wise(≈50% 버그, 빠른 확인), pairwise — 표준(70-90%), 핀테크의 경우 3-wise(≈95%), 중요 시스템에만 전체 조합. 머리로 pairwise 매트릭스를 절대 구성하지 마세요: 도구로 생성하세요(PICT, 설치된 경우, 그렇지 않으면 pip install allpairspy --break-system-packages) 그리고 스크립트로 모든 쌍이 포함되었는지 확인하세요. 적용 위치: 카탈로그 필터, 계산기, 결제 × 배송, 내보내기(형식 × 인코딩 × 구분 기호). 교차 브라우저 테스트에는 pairwise를 사용하지 마세요(5단계 참조).
4. 결정 테이블: 요구사항 명세서에 'if / and / or / except'가 많고, 2-5개의 이진 조건이 있을 때. 불가능한 조합은 제거하고, 동일한 결과를 가진 규칙은 하나의 케이스로 결합하세요. 일반적인 위치: 할인 및 프로모션 코드, 역할 매트릭스, 종속 양식 필드(법인 → INN 및 KPP 필수), 주문 상태.
5. 상태 전이 테스트: 수명 주기와 시간 초과가 있는 모든 것. 허용되지 않는 전환, 시간 초과 만료 (결제 없는 예약은 '사용 가능'으로 돌아감), 토큰 일회성(이전 링크로 비밀번호 재설정 반복), 각 단계에서 연결 끊김을 확인하세요.
6. Error Guessing — 함정 카탈로그:
   • 더티 입력: 공백만, 이메일 가장자리 공백, U+200B, 이모지, 따옴표, 한자, 버퍼의 10,000자;
   • 반복 및 경쟁 조건: '결제' 세 번 클릭, 트랜잭션 후 '뒤로', 마지막 상품을 두 명이 구매;
   • 중단: 99%에서 네트워크 끊김, 인수 중 탭 닫기;
   • 날짜 및 숫자: 윤년이 아닌 해의 29.02, 미래의 생년월일, 00.00.0000, 수량 -1, 0, 999,999;
   • 환경: 3시간 유휴 상태 후 세션 만료, .jpg 확장자의 .exe, 500MB 파일.

4단계. 산출물

체크리스트(ID, 확인 사항, 상태) — 기본값. 테스트 케이스 — 복잡한 로직, 온보딩 및 자동화 전달용.

테스트 케이스 필드: ID, 이름, 우선순위, 전제 조건(항상 작성), 단계, 테스트 데이터, 예상 결과; 실행 후 — 실제 결과 및 상태(Passed / Failed / Blocked / Skipped).

규칙: 단계에는 테스터의 작업만 포함하고 시스템 반응은 예상 결과에 포함합니다. 단계는 원자적입니다 ('이메일 입력', '비밀번호 입력', '로그인 버튼 클릭' — 세 단계). 하나의 케이스 = 하나의 확인. 케이스는 서로 의존하지 않습니다 (준비는 전제 조건으로 이동하거나 API를 통해 수행). 세부 수준은 합리적이어야 하며 '마우스 이동'과 같은 것은 없습니다. 우선순위 High는 금전 및 인증, Low는 미용상의 문제, 나머지(≈80%)는 Medium입니다.

테스트 스위트 — 모듈별 폴더, 기능별 중첩 스위트 포함. 모듈의 공통 확인 사항은 스위트 루트에 있습니다. 테스트 런 — 특정 빌드 및 환경에서 상태가 포함된 세트 실행. 테스트 계획(요청 시): 범위(in / out), 전략 및 환경, 진입, 일시 중지 및 종료 기준, 리소스 및 일정, 대비 계획이 포함된 위험.

버그 리포트

제목:       [위치] 어떤 조건에서 어떤 일이 발생하는지
             예시: [프로모션 코드 창] 만료된 쿠폰 입력 시 오류 500
환경:       Prod/Stage, 브라우저 및 버전, OS; 모바일의 경우 모델 및 정확한 OS 버전; URL
전제 조건:  사용자 역할, 페이지, 준비된 데이터
단계:       1. … 2. … (작업만, 최소 체인)
예상 결과:  구체적으로, 요구사항 명세서 또는 디자인 참조와 함께
실제 결과:  발생한 상황
심각도:     Blocker / Critical / Major (우회 있음) / Minor / Trivial — 기술 평가, QA 설정
우선순위:   High / Medium / Low — 비즈니스 긴급성(PO/PM 결정)
재현성:     Always (10/10) 또는 Intermittent (예: 1/10)
우회 방법:  가능한 경우 대체 경로
첨부 파일:  정적 화면의 스크린샷, 동적 화면의 비디오, 백엔드의 콘솔 로그 또는 HAR

규칙: 1 버그 = 1 티켓. 등록 전에 중복을 검색하세요. 즉시 등록하세요. 중립적인 어조. 티켓에서 수정 방법을 추측하지 마세요. 한 달 후에도 설명을 보고 수정 사항을 확인할 수 있도록 작성하세요. 심각도와 우선순위는 독립적입니다 (로고 오타: Trivial / Immediate).

테스트 결과 보고서(TRR)

최소한의 군더더기, 최대한의 숫자, 명확한 Go / No-Go 권장 사항:

빌드 vX.Y 테스트 결과 보고서
계획된 N 케이스: Passed a (a%) · Failed b (b%) · Blocked c (c%)
결함: BUG-… — 요약(우선순위) [링크] …
차단됨: 어떤 블록과 어떤 버그로 인해
QA 권장 사항: 출시 권장되지 않음 / 조건부로 권장됨 …

5단계. UI: 양식, GUI, 사용성, 접근성, 호환성, 지역화

양식 및 입력 필드

• 텍스트: 유효한 값. 빈 필수 필드. 정확히 max. max+1. 특수 문자 ' " < > / ; : @ # $ % ^ & * ( ) _ +. 이모지(utf8mb4 오류). 공백만, 앞, 뒤 및 내부 공백(trim 예상). 키릴 문자, 라틴 문자, 한자 및 RTL 혼합. F5는 입력을 유지합니다(비밀번호 및 캡차 제외). '보내기' 두 번 클릭은 두 개의 요청을 보내지 않습니다. U+200B.
• 비밀번호: 마스킹. 재로드 및 오류 시 지워짐. 약한 비밀번호 및 로그인 또는 이메일과의 일치 여부 확인. 클립보드 및 비밀번호 관리자에서 붙여넣기. '눈' 아이콘은 password ↔ text를 전환합니다.
• 선택 및 업로드: 합리적인 기본값(GDPR에 따라 동의가 미리 선택되어 있지 않음). 레이블 클릭은 체크박스를 전환합니다. '모두 선택 / 모두 선택 해제'. 필수 라디오 버튼 그룹. 금지된 확장자(.exe, .php), 0바이트 및 100MB+ 파일, 진행률 표시줄.
• UX 검증: blur 시 인라인 검증, 오류 시 입력이 재설정되지 않음, 필드 강조 표시 및 CTA와 함께 이유 표시. 형식이 미리 제시됨('DD.MM.YYYY'). 하나의 필드 = 하나의 값. 번호, 상태 및 다음 단계가 포함된 성공 화면. 다단계 양식의 '뒤로'는 데이터를 저장하거나 명시적으로 금지됩니다.
• 추가 BLUGID: Tab / Shift+Tab / Enter, Safari 및 모바일, 오류 번역, XSS, SQL, CSRF, 속도 제한.

GUI: 디자인과 비교(Figma + DevTools)

공통 구성 요소부터 시작하세요. 공통 구성 요소의 수정은 수십 개의 화면을 수정합니다. 크기 — Pixel Measurement(DevTools가 열린 상태에서 너비가 '디자인보다 작음'은 적응형이며 버그가 아닙니다). 글꼴 및 색상 — Elements → Computed(font-size, background-color → HEX). 여백 — Figma의 Option/Alt 대 Box Model. 애니메이션 — Command Palette → Show Animations, 10-25%로 느리게. 오버레이 — PerfectPixel 50% 불투명도. 1px 차이는 버그가 아닙니다(서브픽셀 반올림), 레이아웃이 깨지지 않는 한.

사용성(Usability)

Nielsen의 10가지 휴리스틱으로 확인하세요: 시스템 상태 가시성, 사용자 언어 사용, 사용자 제어 및 자유, 플랫폼 표준(HIG / Material), 오류 방지, 인식보다 회상, 유연성 및 효율성, 미니멀리즘, 오류 인식 및 복구, 도움말 및 문서. 성인 사용자의 경우: 12pt 미만 글꼴 금지, 대비, 큰 터치 대상. 기본 패턴을 깨지 마세요: 더블 탭, 화면 가장자리의 시스템 제스처. 'Undo'가 있는 5초 취소는 '확실합니까?' 대화 상자보다 낫습니다.

접근성(WCAG, POUR)

빠른 확인: Lighthouse(접근성만) → axe DevTools → IBM Equal Access → ANDI(Tab 순서 및 요소 이름) → 대비(AA ≥ 4.5:1, AAA ≥ 7:1). 이미지 또는 그라데이션 위의 텍스트는 DevTools 스포이드로 재확인하세요: 스캐너는 인접한 태그의 색상을 가져옵니다. 수동 확인: 마우스 없이 전체 작업, 보이는 포커스 및 가려지지 않은 포커스, 정보 제공 이미지의 alt 속성, 초당 3회 이상 깜빡임 없음, prefers-reduced-motion 준수, 스크린 리더(NVDA / VoiceOver). 시뮬레이션 — Web Disability Simulator.

호환성

데이터를 기반으로 매트릭스 구축: 자체 분석 → 지역 통계 → StatCounter(적용 범위 부족 위험 보고). 트래픽뿐만 아니라 플랫폼별 매출을 확인하세요. 꼬리 부분 < 0.5%는 제거하세요. 엔진별로 그룹화: Windows의 Chrome과 Edge는 하나의 Chromium. iOS의 모든 브라우저는 WebKit, 하지만 iOS의 Safari는 별도로 테스트하세요(자체적인 레이아웃 버그 있음). 회귀 테스트를 비율에 따라 분산하세요(200 케이스 × 그룹 비율). '브라우저 × 케이스' pairwise가 아닙니다(1400번 실행). 장치 부족은 …

[나머지 내용은 원본의 길이 제한으로 인해 잘렸습니다. 원본의 완전한 번역이 필요합니다.]