qa-note

자동화 테스트가 필요한 상황QA 업무를 하다 보면 반복적으로 같은 테스트를 수행해야 하는 경우가 많습니다.그럴 때 자동화 테스트를 적용하면 효율이 훨씬 높아집니다.자동화 테스트가 필요한 상황을 정리하면 크게 4가지로 나눌 수 있습니다.1️⃣ 반복적으로 수행되는 테스트로그인/회원가입 기능상품 검색 테스트결제 프로세스 테스트주요 기능 회귀 테스트이런 테스트는 매번 배포될 때마다 반복해서 수행해야 합니다.사람이 반복해서 하면 실수도 생기고 시간이 오래 걸립니다.그래서 자동화 테스트로 반복을 대신하게 만들면 시간을 절약할 수 있습니다. ⏱️2️⃣ 테스트 데이터가 많은 경우예를 들어수천 개 회원 계정 로그인 테스트수백 건 주문/결제 처리 테스트다양한 결제 방식 테스트이런 경우 사람이 일일이 테스트하기 어렵습니다...

QA 자동화 테스트란 무엇인가?소프트웨어 테스트를 하다 보면 반복적으로 수행해야 하는 테스트가 많습니다.예를 들어 로그인 테스트, 회원가입 테스트, 결제 테스트 같은 것들입니다.이러한 테스트를 사람이 직접 수행하지 않고 프로그램이 자동으로 실행하도록 만드는 것이 바로 자동화 테스트(Automation Test) 입니다.즉,👉 사람이 반복해서 하던 테스트를👉 코드나 도구를 이용해 자동으로 수행하게 만드는 것이것이 QA 자동화 테스트의 핵심 개념입니다.자동화 테스트가 필요한 이유QA 업무를 하다 보면 같은 테스트를 여러 번 반복하게 되는 경우가 많습니다.예를 들어로그인 기능 테스트회원가입 테스트상품 검색 테스트결제 프로세스 테스트이런 기능들은 새로운 버전이 배포될 때마다 다시 확인해야 합니다.하지만 사람..

서비스가 한 번 정상적으로 동작했다고 해서앞으로도 계속 문제없이 동작한다고 보장할 수는 없습니다.기능 수정, 신규 기능 추가, 버그 수정 이후에기존 기능이 다시 깨지는 현상은QA 실무에서 매우 흔하게 발생합니다.이러한 문제를 방지하기 위한 테스트가바로 회귀 테스트(Regression Testing)입니다.1️⃣ 회귀 테스트란?✔ 회귀 테스트 (Regression Testing)기능 수정이나 코드 변경 이후,기존에 정상 동작하던 기능이여전히 문제없이 동작하는지 확인하는 테스트즉,👉 “수정으로 인해 다른 기능에 문제가 생기지 않았는가?”를 검증하는 테스트입니다.2️⃣ 왜 회귀 테스트가 필요한가?소프트웨어는 기능 간에 서로 영향을 주고받습니다.하나의 버그를 수정했을 뿐인데전혀 다른 화면에서 오류가 발생하는 ..

QA 실무에서는 항상 충분한 시간과 인력이 주어지지 않습니다.모든 기능을 동일한 깊이로 테스트하기 어려운 상황에서,QA가 반드시 갖춰야 할 사고 방식이 바로 리스크 기반 테스트(Risk-based Testing)입니다.리스크 기반 테스트는👉 “무엇을 먼저 테스트해야 하는가”에 대한 명확한 기준을 제공합니다.1️⃣ 리스크 기반 테스트란?✔ 리스크 기반 테스트 (Risk-based Testing)서비스에 미치는 영향도와오류 발생 가능성을 기준으로테스트 우선순위를 결정하는 테스트 기법즉, 모든 기능을 동일하게 테스트하는 것이 아니라문제가 발생했을 때 가장 큰 영향을 미치는 영역부터 테스트하는 방식입니다.2️⃣ 왜 리스크 기반 테스트가 필요한가?현실적인 QA 환경에서는 다음과 같은 제약이 존재합니다.제한된 테..

QA 업무를 하다 보면이런 말을 종종 듣게 돼요.“이건 테스트 전에 리뷰부터 해야죠”“직접 실행해서 확인해봐야죠”이 두 말의 차이가 바로👉 정적 테스트와 동적 테스트의 차이예요.이번 글에서는👉 두 테스트의 개념 차이,👉 언제, 왜 사용하는지,👉 QA 실무에서의 역할을한 번에 정리해볼게요.1️⃣ 정적 테스트와 동적 테스트를 나누는 기준가장 쉬운 기준은 이 질문이에요.“실행을 하느냐, 하지 않느냐?”실행 ❌ → 정적 테스트실행 ⭕ → 동적 테스트이 기준만 기억해도두 개념이 헷갈리지 않아요.2️⃣ 정적 테스트란 무엇인가?✔ 정적 테스트 (Static Testing)소프트웨어를 실행하지 않고문서나 코드를 검토하는 테스트QA가 아주 초반 단계부터 참여할 수 있는 테스트예요.✔ 주요 대상기획서 / 요구사항 ..

QA를 하다 보면이런 기능을 자주 만나게 돼요.로그인 전 / 로그인 후주문 전 / 결제 중 / 결제 완료 / 취소활성 / 비활성 / 정지 상태이런 기능들은 공통점이 있어요.👉 “상태에 따라 가능한 행동이 달라진다”이럴 때 사용하는 테스트 기법이바로 상태 전이 테스트(State Transition Testing)예요.1️⃣ 상태 전이 테스트란 무엇인가?✔ 상태 전이 테스트 (State Transition Testing)시스템이 가질 수 있는 상태(State)와상태 간 이동(Transition)을 기준으로정상/비정상 흐름을 검증하는 테스트 기법핵심은 이거예요.👉 “이 상태에서, 이 행동이 가능한가?”2️⃣ 왜 상태 전이 테스트가 필요할까?상태 개념이 있는 기능에서이런 버그가 자주 발생해요.이미 완료된 주..

QA 실무에서 이런 기능 많이 만나게되요.조건이 여러 개인 할인 정책회원 등급 + 결제 수단 + 이벤트 여부권한에 따라 버튼 노출이 달라지는 화면이럴 때 테스트 케이스를 그냥 감으로 만들면👉 누락되기 딱 좋아요.이럴 때 가장 강력한 테스트 기법이바로 결정 테이블 테스트예요.1️⃣ 결정 테이블 테스트란 무엇인가?✔ 결정 테이블 테스트 (Decision Table Testing)여러 조건의 조합에 따라결과가 달라지는 로직을표(Table)로 정리해서 테스트하는 기법핵심은 이거예요.👉 “조건이 많을수록, 표로 정리하자”2️⃣ 왜 결정 테이블 테스트가 필요할까?조건이 많아질수록 이런 문제가 생겨요.테스트 케이스 누락특정 조합만 빠짐“이 케이스 테스트했나요?”에 답 못함결정 테이블 테스트는👉 모든 조건 조합을..

QA로 일하면서 힘든 순간은 생각보다 자주 찾아왔어요. 😮‍💨그중에서도 가장 힘들었던 건, "나는 분명 최선을 다했는데 결과가 좋지 않았을 때"였어요.책임은 QA에게 먼저 오는 순간테스트를 다 끝내고, 문제 없다고 공유한 뒤 출시했는데 장애가 발생했을 때가 있었어요.그 순간 가장 먼저 떠오르는 직무는 대부분 QA였어요."테스트는 다 한 거 맞아요?""이건 왜 못 잡았죠?"그 질문을 들을 때마다 머릿속이 하얘졌어요.내가 놓친 걸까, 아니면 구조적으로 막기 어려운 문제였을까 스스로를 계속 의심하게 됐거든요.모든 걸 통제할 수는 없다는 걸 받아들이기까지처음에는 모든 문제를 QA가 막아야 한다고 생각했어요.그래서 장애가 나면 괜히 더 위축됐고, 제 탓인 것 같아 말을 아끼게 됐어요.하지만 경험이 쌓이면서 조..