[Udemy 강의] 소프트웨어 테스트 QA

Udemy 강의를 정리한 글입니다

 

 

🔎 Jira를 사용한 애자일 스크럼에서의 QA 역할

📌 애자일 스크럼에 대한 개념과 해당 프레임워크를 사용할 때 따라야 할 패턴

📌 Jira 도구를 이용해 스크럼 프로세스를 성공적으로 적용하는 법 : Jira 사용법

 

📋 애자일 스크럼에서 회고(Retrospective)의 중요성

스프린트에서 잘된 점과 잘못된 점을 팀원들과 회고

 

📄 QA 관점에서 회고의 중요성

회고는 테스트 과정에서 누락•불필요•비효율을 발견해 QA 사이클을 반복 개선할 수 있다

정량 데이터(버그 발생 패턴, 결함 집중 구역, TC 소요시간 등)을 기반으로 다음 스프린트 품질 목표를 수립할 수 있다

회고가 없으면 테스트는 단순 반복 작업이 된다

 

💡 칸반과 스크럼의 차이점

칸반에는 스프린트가 없다 (스크럼 - 스프린트 = 칸반)

칸반에는 릴리스 날짜만 있으며 아직 개발되지 않은 Story는 모두 To Do 상태로 남는다

칸반은 주어진 기한까지만 작업을 마무리하면 된다

 

 

 

🔎 QA의 사고 방식 / 제품 테스트 케이스 설계 전략

QA는 모든 측면을 고려해서 품질 기준에 부합하는지 아닌지 판단해야 한다

ex) 은행 잔액을 보여주는 웹 화면

1. 잔액이 표시되는지 확인 ➡︎ UI Testing

2. 잔액이 올바르게 표시되는지 확인 (DB Data와 비교) ➡︎ Functional Testing

3. 잔액이 0원이면 어떻게 표시되는지 확인 ➡︎ UI Testing

4. 잔액이 마이너스면 어떻게 표시되는지 확인 ➡︎ UI Testing

5. 잔액이 12자리 이상의 큰 금액이면 어떻게 표시되는지 확인 ➡︎ UI Testing

6. 브라우저를 축소하면 어떻게 표시되는지 확인 (브라우저 호환성) ➡︎ UI Testing

7. API Response 값 확인 ➡︎ API Testing

8. 3천명이 동시에 잔액을 확인하려고 할 때 화면이 표시되는지 확인 ➡︎ 성능 Testing

최소한 시스템들이 서로 어떻게 통합되어 있는지만 알면 기능의 작동 방식을 역추적하고 기능 테스트를 수행하는데 도움이 된다

 

 

 

🔎 테스트케이스의 설계 형식의 이해

📋 테스트 시나리오

기능 하나를 검증하기 위한 큰 흐름(Story 단위의 테스트 목적)

테스트 방향

 

📋 테스트 케이스

시나리오를 구체적인 실행 단위로 분해한 테스트 검증 목록

입력값, 테스트 절차, 예상결과까지 상세히 정의해야 한다

긍정 케이스와 부정 케이스 모두 작성

 

 

 

🔎  테스트 생명주기, 테스트 계획과 종료 활동 이해

테스트의 목적은 버그를 찾는 것에만 국한되어 있지 않다

QA는 프로젝트가 시작된 순간부터 끝까지 품질을 책임지고 흐름 전체를 관리한다

📋 소프트웨어 테스트 수명주기 (STLC)

테스터가 프로젝트 내에서 경험하는 전체 테스트 과정의 흐름이다

요구사항 분석 단계에서 시작해 테스트 종료까지 이어지며, 개발 방식(애자일/폭포수)에 따라 반복 방식이 달라진다

 

1. 요구사항 분석

고객, 비즈니스 분석가, 제품 책임자(PO) 등 다양한 관계자와 요구사항을 상세하게 이해

애매한 요구사항이 있다면 바로 질문하고 명확히 문서화

 

 

2. 테스트 계획

STLC 주기 중에 가장 중요한 단계

테스트 전략을 정의하고 테스트 계획을 준비하는 단계

모든 프로젝트는 테스트 계획 문서를 가진다

계획을 작성하기 전 제품 분석은 필수다

애자일이든 폭포수든 테스트 전략·범위·환경·리스크·기간을 명시해야 한다

 

📄 테스트 계획에 포함되어야 하는 부분

테스트 범위 (가능/불가능한 영역 모두 명시)

테스트 도구 (Jira, Selenium, Postman 등)

테스트 환경, 장비, 서버 정보

테스트 리소스(인원) 및 일정

예상 리스크와 비상 대응 프로세스 : 인프라 문제나 환경 문제를 겪는 경우, 프로젝트에 필요한 자원을 제때 지원받지 못하는 경우 등

 

🚫 테스트 계획이 없으면?

일정·범위·품질 기준이 모호해지고, Release 승인 기준도 모호해진다

 

 

💡 개발 모델별 테스트 프로세스 흐름 비교

📄 애자일 모델

요구사항 분석 ➡︎ 테스트 계획 ➡︎ [테스트 케이스 개발 ➡︎ 테스트 환경 설정 ➡︎ 테스트 실행] 스프린트마다 반복 ➡︎ 테스트 종료

스프린트마다 개발하고 테스트해야 할 스토리가 존재

 

📄 폭포수 모델

요구사항 분석 ➡︎ 테스트 계획 ➡︎ 테스트 케이스 개발 ➡︎ 테스트 환경 설정 ➡︎ 테스트 실행 ➡︎ 테스트 종료

개발팀에서 빌드를 완료할 때까지 QA팀은 테스트 케이스 개발, 테스트 환경 설정에 집중

애플리케이션 전체에 대한 테스트 케이스 개발 (애플리케이션이 완료된 후 테스트를 진행하기 때문)

 

 

3. 테스트 케이스 개발

스토리를 확인하고 이에 대한 기능을 테스트하고 인증하기 위한 모든 측면을 생각해야 한다

제품 책임자(PO)나 고객과 상호 작용하면서 테스트용 빌드를 전달받을 때까지 테스트 케이스를 준비해두는게 이상적이다

테스트 케이스 개발은 스토리마다 변경될 수 있다

테스트 데이터 (로그인 정보 등) 준비

 

📊 요구사항 추적표(RTM)

모든 요구사항 수집 ➡︎ 각 요구사항에 상응하는 테스트 케이스를 매핑한 표 생성

긍정적인 케이스와 부정적인 케이스를 나눠서 작성하기도 한다

상위 호환성은 요구사항이 매핑됐는지 확인하는 것

하휘 호환성은 테스트 케이스가 요구사항에 매핑되었는지 확인하는 것

보통 프로젝트가 끝날 때 작성하지만 애자일 모델에서는 프로젝트 진행(테스트케이스 개발 단계에서 작성 시작)과 같이 이루어짐 ➡︎ 스프린트가 끝날 무렵 해당 스프린트의 목표 요구사항에서 어떤 테스트 케이스가 반영됐는지 보여주는 추적표 작성 ➡︎ 요구사항에 매핑이 누락되었다고 생각되면 해당 요구사항에 대한 테스트 케이스를 작성한 후 다시 매핑

RTM은 테스트 범위 누락을 방지하는 가장 강력한 무기

 

 

4. 테스트 환경 설정

개발 서버 배포 ➡︎ QA 서버 배포 (Jenkins와 같은 도구로 서버 배포 가능) ➡︎ DB 연결 확인

DB 연결 확인 : 최소한 코드가 엑세스할 수 있는 데이터가 데이터베이스에 있는지 확인

➡︎ 스프린트 그루밍 단계에서 스토리를 선택하고 분석하여 어떤 개발 작업이 필요한지 논의함과 동시에 테스트 데이터에 어떻게 접근할지, QA 환경에 배포됐을 때 거기서부터 작업을 시작하면 될지 이런 사항을 개발팀에 문의하기

테스트 데이터 유효성 확인 후 테스트 실행 준비

 

 

5. 테스트 실행

빌드 완료 ➡︎ 테스트 계획과 테스트 케이스 기반 테스트 실행

개발 코드를 QA 환경에 배포하고, 해당 스토리나 릴리즈에 개발된 기능 테스트를 위해 준비한 모든 테스트 케이스를 실행하는 단계

버그 발견 ➡︎ 개발팀에 전달 ➡︎ 수정 후 재테스트 (애플리케이션에서 버그가 발생한 부분 주변으로 리그레션 테스트) ➡︎ 해당 버그 이슈 종료 처리

제품 책임자(PO)로부터 최종 승인을 받은 후 애플리케이션 릴리즈

 

 

6. 테스트 종료

릴리즈가 성공적으로 완료되면 테스트 종료 활동 수행

테스트 완료 확인 : 모든 테스트케이스가 성공적으로 실행되었는지 확인과 동시에 테스트 적용 여부 확인 (모든 요구사항 매핑 완료 확인 ➡︎ 누락된 항목 확인하고 다음 릴리즈에 추가)

테스트 산출물 인계 (주로 폭포수 모델에서 진행) : 프로젝트가 완료되면 해당 프로젝트에서 테스트한 모든 문서를 고객에게 인계하고 최종 승인을 받은 후 향후 추가 작업을 위해 유지관리팀에 전달

프로젝트 회고 : 이전 스프린트나 이전 릴리즈에서의 개선점, 실수, 성공점 피드백

테스트 작업물 보관 : 테스트 계획과 테스트 데이터를 저장, 릴리즈를 위해 작성한 테스트 계획을 저장하는 것

 

 

 

🔎  버그 감지와 결함 생성에 대한 QA의 업무

📋 트러블 슈팅 옵션

• 서버 로그 : 애플리케이션 서버 로그 파일(애플리케이션 내의 동작을 타임스탬프로 기록) 오픈 (개발팀 문의)
• 백엔드 검증 : 네트워크 탭(우클릭-검사-개발자도구)에서 Status Code 확인 ➡︎ Postman으로 Request URL을 이용해 API Test ➡︎ 정상 동작 (프론트엔드에서 서비스로 연결하는 과정에 문제가 있다는 의미) ➡︎ 개발자에게 로그인 요청에 문제 (프론트엔드에서 보낸 요청이 유효하지 않음) 발생과 네트워크 탭 하단의 view source 세부사항 전달
• 프론트엔드 검증 : Console logs(우클릭-검사-개발자도구) 확인 ➡︎ 수행한 작업에 대한 로그 추적 ➡︎ 에러 로그를 개발자에게 설명

🎙️ 페이지 오류를 발견하면 어떻게 할 것인가?

- 네트워크, 브라우저 콘솔 로그, 애플리케이션 서버 로그를 확인하여 개발팀에 찾아가기 전에 먼저 트러블슈팅 방법을 취할 것

 

 

📋 버그에 관한 모든 세부 사항과 함께 결함 생성 방법

버그(bug) : 애플리케이션이 의도대로 작동되지 않는 것 (현상)
결함(defect) : 발생한 버그를 수정하도록 티켓으로 남긴 기록 (버그 해결위해 생성하는 문서)

 

📄 결함 생성을 위해 제공할 내용

오류 재현 단계 : ex) Navigate to page

테스트 데이터 정보 : 테스트 데이터, 테스트 환경(브라우저, url 등)

기대 결과, 실제 결과

로그 타임스탬프(optional)

트러블슈팅 사고(thoughts) : Front / Back / 네트워크 중 어디에서 실패했는지 판단 근거

스크린샷

 

🎙️ QA 담당자가 확인한 오류를 개발자가 발견하지 못하는 경우

- 0월 0일 오후 0시 0분 타임스탬프가 기록된 로그 제공 ➡︎ '0월 0일 오후 0시 0분에 시도했을 땐 오류가 발생했습니다'라고 QA 담당자로써 정확하게 말한다

 

 

📋 결함의 심각도와 우선순위

📄 심각도(Severity)

애플리케이션(소프트웨어)에 미치는 정도

Critical : 치명적인 결함

Major : 매우 심각한 결함으로 시스템 붕괴를 일으키는 수준이지만, 시스템의 특정 기능에는 문제가 없는 경우

Medium : 의도하지 않은 대로 작동하지만 애플리케이션은 정상 작동, 기능에 영향이 없는 결함

Low : 다음 릴리즈에서 수정해도 되는 사소한 결함

 

📄 우선순위(Priority)

결함 수정 긴급도

High : 긴급!!!

Medium

Low

 

🎙️ 낮은 심각도의 높은 우선순위를 갖는 결함이 존재할 수 있는지 (심각도와 우선순위의 차이점)

- 예를 들어 'Amazon' 사이트의 로고가 'Amzon'으로 오타가 발생한 경우,

기능에 문제는 없으니 심각도는 Low지만 고객의 신뢰도를 잃을 수 있는 부분이기에 우선순위는 High로 측정

 

📄 결함 수정 후 재테스팅

수정한 결함과 관련된 모든 기능을 제테스팅해서 수정 과정에서 새로운 버그가 생겼는지 확인

관련 결함과 관련된 테스트 케이스를 모두 찾아서 다시 테스트

 

 

 

🔎  테스트 타입

📋 회귀 테스트 (Regression Testing)

변경 사항으로 인해 기존 기능이 망가지지 않았는지 확인하는 테스트

변경이 사소하더라도 기존 기능 전체 영향도 확인이 목적

릴리즈 직전에 반드시 수행되어야 함

 

모든 테스트를 자동화할 수는 없음 ➡︎ 비즈니스적으로 중요한 기능 + 결함 발생 빈도가 높은 영역 위주로 자동화

자동화 테스트 구축 시 “회귀 테스트의 목적에 맞는가?”를 먼저 검토해야 함

 

 

📋 스모크(Smoke)/세너티(Sanity) 테스트

빌드가 테스트할 가치가 있는지 빠르게 판단하는 얕은 테스트

회귀 테스트와 목적은 비슷하지만 범위와 깊이가 훨씬 얕음

수행 시간은 보통 5분 이내

“깨진 빌드인지 아닌지”를 빠르게 판별

 

개발자가 새 코드를 푸시(커밋)할 때마다(빌드마다) 수행

애플리케이션 실행 여부, 주요 페이지 로딩 여부만 확인

대부분 자동화되어 CI/CD 파이프라인에서 실행

 

✔ 스모크 테스트는 대부분 자동화

Jenkins에서 코드가 저장소(Repository)에 Push ➡︎ Smoke Test 자동 실행

 

 

📋 통합 테스트, 컴포넌트 테스트

📄 컴포넌트 테스트

애플리케이션의 특정 컴포넌트 단위 검증

시스템 전체가 아닌 개별 컴포넌트만 분리하여 테스트

백엔드와의 연동 없이 수행 가능

주로 프론트엔드 수준에서 UI/비즈니스 규칙 검증

 

✔ 목적

컴포넌트가 자체적으로 올바르게 동작하는지 확인

비즈니스 요구사항을 충족하는 UI/로직인지 검증

 

📄 통합 테스트

여러 컴포넌트가 연결되어 정상적으로 동작하는지 확인

두 개 이상의 모듈을 논리적으로 결합해 테스트

API ↔ 프론트엔드, 서비스 간 연동 검증

컴포넌트 테스트 이후 단계에서 수행

 

 

💡 인증(Verification)과 검증(Validation)

인증(Verification) : 컴포넌트가 설계대로 올바르게 작동하는지

검증(Validation) : 애플리케이션에서 비즈니스 요구사항을 검증하는 것

 

 

📋 부하(Load) 테스트, 스트레스(Stress) 테스트

📄 부하 테스트

정상 범위 내 트래픽에서 성능을 측정하는 테스트

수천~수백만 사용자가 동시에 접근할 경우를 가정

응답 시간, 처리량 등을 파라미터로 설정 ➡︎ 애플리케이션의 성능 개선 필요 여부 판단

 

📄 스트레스 테스트

시스템 한계를 넘는 부하를 걸어 붕괴 지점을 확인하는 테스트

최대 부하를 가해 시스템이 언제 멈추는지 확인

장애 발생 시 시스템의 반응과 복구 가능성 관찰

안정성과 내구성 평가 목적

 

 

 

🔎  테스트 범위

📋 기능적 요구사항, 비기능적 요구사항

📄 기능적 요구사항

시스템이 무엇을 해야 하는가에 대한 요구사항

사용자가 수행할 수 있는 기능 중심

시스템의 동작 방식, 비즈니스 로직 정의

주로 클라이언트가 개발자에게 전달

 

📄 비기능적 요구사항

시스템이 얼마나 잘 동작하는가에 대한 요구사항

성능, 안정성, 보안 등 시스템 품질 관점

기능이 아닌 특성을 검증

주로 개발팀이 클라이언트에게 설명·공유

 

✔ 유형

성능(Performance) : 동시에 많은 사용자가 접속했을 때 시스템이 견딜 수 있는지 ex) 로드 테스트, 부하 테스트, 스트레스 테스트

사용성(Usability) : 모바일, 태블릿 등 다양한 환경에서 접근성과 편의성 확인

신뢰도(Reliability) : 데이터가 정상적으로 DB에 저장되는지 / 데이터 유실·오염·비정상 접근 여부

복구성(Recoverability) : 서버 장애 발생 시 복구 시나리오 존재 여부 / 백업 및 이중화 구성 확인

보안(Security) : OWASP Top 10 기반 취약점 점검 / 인증, 권한, 데이터 보호 여부

 

 

📋 블랙박스 테스트, 화이트박스 테스트

📄 블랙박스 테스트

내부 구조를 알지 못한 상태에서 외부 동작만 검증

구현 방식, 코드 구조를 고려하지 않음

UI 및 사용자 관점 중심 테스트

입력 → 출력 결과만으로 판단

 

✔ 예시

시스템 테스트(System Test)

E2E 테스트

회귀 테스트(Regression Test)

 

📄 화이트박스 테스트

시스템 내부 구조와 구현을 이해한 상태에서 테스트

코드 흐름, 로직, 분기 조건 고려

개발자 또는 기술 이해도가 높은 QA가 수행

내부 결함 탐지에 강점

 

✔ 예시

단위 테스트(Unit Test)

통합 테스트(Integration Test)

컴포넌트 테스트(Component Test)