04화 Test Process 분석-디자인-실행-완료
소프트웨어 테스팅
테스트 프로세스에서 각 단계별 해야 할 것들에 대해 알아보겠습니다. 테스트 프로세스는 소프트웨어 테스트를 진행하기 위해 거쳐야 하는 단계입니다. 크게 4가지로 구성됩니다. 분석하고 디자인하고 실행하고 완료합니다. 소프트웨어 테스트를 위한 단 1가지 보편적인 테스트 프로세스는 없습니다. 회사 및 구성원 보유 역량에 따라 달라집니다. 따라서 일반적으로 진행되는 활동을(경험에 의한) 알아보겠습니다.
단, 시스템 및 인수 테스트 레벨에만 관여하는(주로 인수 테스트) 아웃소싱 형태의 테스트 활동은 다루지 않습니다. 이번 브런치 북 내용은 아웃소싱도 해당되는 부분이 있을 수 있겠지만 경험상 상황에 따른 맥락이 개발사와 아웃소싱은 다릅니다. 독립적인 형태로 진행하는 인력 중심의 3자 테스팅 조직에서는 QA가 전체 테스트 레벨에서 로우 레벨로 이동하여 Early Testing 하기엔 적합하지 않은 팀 역량과 환경이 갖춰진 경우가 많습니다.
이번 브런치 북에서는 아웃소싱 테스트 활동이 아닌, 개발사에 속하여 유관부서와 다이렉트로 컨택하는 테스트 활동을 설명합니다.
Test Analyzing(분석)
대부분 회사에서 QA, Tester가 투입되는 첫 단계입니다. 요구사항이 완성되고 이를 토대로 리뷰하는 시기입니다. 예를 들어, 다음 달 신규 기능을 운영 환경(OP)에 배포할 예정입니다. 배포를 위해선 요구사항 정리, 디자인, 개발, 테스트가 진행되어야 합니다. 어떠한 기능을 출시할 것인지에 대한 프로덕트 레벨에서의 리뷰를 진행하는 단계가 Test Analyzing 단계입니다. 이 기간에는 프로덕트 레벨에서 리뷰가 진행되어야 하기 때문에 QA, Tester뿐 아니라 관련된 유관부서들이 참여하여 협업하는 시기입니다. 신규 기능 요구사항에 부적절한 항목이 있거나, 다소 모호하고 추상적인 요구사항이 있다면 그것들을 리뷰하는 정적 테스팅 활동을 통해 발견하게 됩니다.
또한 요구사항을 토대로 QA, Test 관점에서 이번 스프린트의 테스트 전략이 담긴 테스트 계획도, 분석 작업과 함께 이뤄지는 경우가 많습니다. '추가 예정인 신규 기능이 리그레션 테스트에 어떠한 영향을 미칠지', '각 테스트 레벨별로 서버 또는 클라이언트 팀에 테스트 조건이나 환경을 세팅해야 할 필요성은 없을지?' 등을 정적 테스팅 중 하나인 리뷰 활동을 통해 테스트 계획과 분석을 진행합니다.
테스트 분석 단계에서 중요한 점은 프로덕트 전체 레벨에서 유관부서들과 리뷰를 진행하기 때문에 단순히 기능 및 기술적인(API, UI 자동화 등) 테스트뿐 아니라 사용성과 편의성, 비기능 적인 관점도 포함되어야 합니다. 다른 직군에서 신규 기능이 공개되었을 때 끼칠 수 있는 영향을 사전에 분석한 결과를 토대로 Black-box Test로 정량 또는 정성적 검증이 가능한 부분이 있을지 사전 체크가 필요한 시기입니다.
신규 기능이 복잡하고 테스트 복잡성이 높다고 판단될 경우 전체 프로세스를 추적 관리하는 Lead QA 주도하에 투입 인력, 리그레션 테스트 범위, 명세 기반 테스트 활동을 보완하는 형태인 경험 기반 기법(애드혹, 탐색적 테스팅) 활용 유무, 확인 테스트(Confirmation Test) 및 전체 테스트 종료 기준(리그레션+신규 기능+확인 테스트)을 QA 팀원분들과 협의하고, 적절한 테스트 디자인 진행이 가능토록 최종 릴리즈까지의 요구사항을 꼼꼼히 검토하고 관련 담당자 간의 세부 논의가 진행됩니다.
Test Design(디자인)
Analyzing 단계에서 도출된 테스트 요구사항을 기반으로 테스트 목적, 환경, 대상을 설계하는 시기입니다. 1부터 100까지 기능이 있다고 가정합니다. 팀 보유 역량에 따라서 A 팀은 1부터 100까지 모든 경우의 수를 어떻게든 생각하여 테스트 케이스 또는 체크리스트를 설계합니다. 서로 다른 기능 간의 기술적 흐름은 고려하지 않고 오로지 내부 구조를 모르는 상태에서 최대한 많은 조건과 입력값에 따른 출력 값을 확인하고자 테스트를 디자인합니다.
또 다른 B 팀은 소프트웨어 내부 구조를 모르는 상태에서 진행하는 블랙박스 테스트를 보다 효율적이고 효과적인 진행을 위해 테스트 기법을 활용합니다. 등가 분할(EP), 경곗값 분석(BVA), 의사결정 테이블, 상태 전이와 같은 기법을 적극 활용하여 테스트 커버리지의 신뢰성을 확보했습니다.
테스트 디자인뿐 아니라 테스트 활동 전체 레벨에서 단 한 가지 보편적으로 활용해야 하는 정답과 같은 기준은 없습니다. QA, Tester의 노력이 사용자의 만족으로 이어진다면 어떠한 형태든 괜찮다고 생각합니다. 하지만 경험상 B팀처럼 소프트웨어 테스팅을 이루는 근본 지식들을 탐구하여 적극 도입하려는 노력들이 전체 테스트 비용을 오히려 줄일 수 있었습니다.
테스트 설계 기법 활용의 의미는 테스트를 효율적으로 진행하겠다는 의지가 포함됩니다. 이는 자연스레 테스트 유지보수 활동까지 영향을 끼칩니다. '어떻게 하면 적은 노력으로 지속 가능한 QA, Test 관리를 할 수 있을까'를 고민하게 됩니다. 언제든지 재사용 가능한 테스트 케이스 공통 템플릿을 통해 끊임없이 테스트 활동을 고도화하려는 시도가 나타납니다.
테스트 막바지에(일반적으로 탐색적 테스팅은 테스트 초기 단계에서 활용하면 좋습니다만, 간혹 준비한 테스트 케이스를 모두 수행했음에도 불구하고 일정이 여유로운 업데이트가 있습니다.) 탐색적 테스팅 또는 애드훅 테스팅을 보다 효과적으로 진행하기 위해 결함 생명 주기(Defect Lifecycle)에서 Close 상태 이슈들 중, 심각도와 우선순위가 높았던 이슈들만 BTS(버그 트래킹 시스템)를 통해 분석하여 해당 부분을 경험 기반으로 사이드 이펙트를 체크하는 시도가 나타날 것입니다.
BTS 분석과 같은 활동이 가능하려면 심각도와 우선순위에 대한 내부 기준을 산정해야 하고, BTS에 의미 있는 버그 지표가 나타날 수 있도록 결함 생명 주기(Defect Lifecycle)를 관리해야 합니다. 또한 매 스프린트가 끝나고 회고 활동을 통해 심각도가 높고 우선수위가 높은 이슈들을 지속적으로 관리해야 합니다. 한번 발생한 버그는 어떠한 경로로 재발할지 모르기 때문입니다.
하지만 테스트는 아무나 진행할 수 있는 활동이라는 발전적이지 않고 수동적인 태도와 더불어 회고를 통한 배움과 성장이 없는 환경에서는 테스트 디자인 단계는 그저 귀찮고 하기 싫은 일 중 하나로 다가올 테고, 이는 서비스에 문제가 생길 때만 테스트 활동을 보완하려는 움직임이 나타날 것입니다.
Test Execution(실행)
Analyzing을 기반으로 Design 된 테스트 케이스를 수행하는 단계입니다. 배포된 빌드가 테스트 가능한 빌드인지 검증하는 스모크 테스트(Smoke Test === BAT)부터 리그레션 및 신규 기능에 대한 테스트가 진행됩니다. 발생한 버그는 담당자(개발자 또는 관련 담당자)에게 할당하고 최종 릴리즈까지 추적 관리합니다. 이 과정에서 지라 또는 맨티스와 같은 BTS(Bug Traking System) 도구가 활용됩니다.
Test Completion(완료)
Analyzing을 기반으로 Design 된 테스트 케이스를 Analyzing 간에 협의한 테스트 종료 기준에 적합한 형태로 끝마치는 시기입니다. 계획한 테스트가 모두 진행될 수도, 예상치 못한 내부 이슈로 인해(수정 연기, 보류 등) QA팀에서 목표로 한 테스트 종료 기준에 도달하지 못할 수도 있습니다.
QA팀에서는 디자인 및 실행된 테스트 케이스 및 최종 릴리즈 시점에서의 품질 상태에 대한 결과 리포팅을 진행합니다.(경우에 따라 간소화하거나 생략합니다.) 현재 품질 수준 상태를 테스트 커버리지를 통해 전체 팀으로 공유합니다. 버그에 대해서는 주관적 느낌이 아닌, 사실(Fact)에 대해서만 설명하고 전달합니다. 어떠한 버그가 발생했었고, 어떻게 처리되었으며, 해결하지 못한 버그는 무엇인지, 다음 스프린트를 준비하며 QA팀에서 보완할 점은 무엇인지에 대해 팀 공유하면 좋습니다.
결과 공유는 다음 차수에 우리 팀이 어떠한 방향으로 품질을 높여야 하는지에 대한 의미도 포함됩니다. 따라서 사실과 결과를 명확히 다루면 좋습니다. 주관적 느낌 또는 QA팀이 발견하지 못한 버그를 감추려는 듯한 수동적 태도는 적절하지 못합니다. 프로덕트 품질로 인해 고객이 돌아오지 않는다면 QA팀뿐 아니라 모든 구성원의 책임입니다. 기획, 개발, 디자인, 테스트, QA 모두가 각자 맡은 위치와 역할에서 품질을 신경 썼을 때 사용자가 사용하기 쉽고 편리한 서비스가 탄생할 것이라 믿습니다.
