<2> QA 프로세스가 왜 필요할까?
QA for Beginners
프로세스가 무엇인가?
앞서 QA가 하는 일에 대해 설명하면서 프로세스라는 것을 자주 언급했다. 그럼 QA의 프로세스는 무엇일까? 그리고,
도대체 프로세스가 뭘까?
프로세스는 컴퓨터에서 연속적으로 실행되고 있는 컴퓨터 프로그램이라는, 컴퓨터 용어로써의 사전적 의미를 갖고 있다. 하지만 재미있게도 QA는 IT 직무임에도 프로세스라는 용어를 컴퓨터 용어가 아닌 비즈니스 용어로써 사용한다. 즉, QA 프로세스란 QA Workflow(업무 흐름)와 같다고 이해해도 무방하다. 용어의 정의가 어찌 됐든 프로세스의 뜻에는 눈에 보이는 대상 또는 그에 준하는 명확한 대상에 대해 설명하는 것이 아니라는 공통점이 있다. 이 말은, 프로세스에는 기준도 없고, 정답도 없다는 것을 의미한다. 단지 효율적인 프로세스가 최선의 프로세스일 뿐이다. 따라서 액체가 담는 그릇에 따라 모양이 변하듯, 프로세스 또한 회사마다, 조직마다, QA마다 달라질 수 있음을 염두에 두길 바란다. 오늘 정리할 내용들은 그중 가장 기본적이고 공통적인 부분들을 추려 이야기해 보겠다.
두 가지 관점에서 프로세스를 이해할 수 있다. 첫 번째는 QA 업무 흐름에서의 관점이고, 두 번째는 조직 업무 흐름에서의 관점이다. 혹시 아래의 순서로 QA 프로세스에 대해 언급했던 것을 기억하는가?
기획 리뷰 > QA 준비 > QA 시작 > QA 진행 > QA 종료(Sign Off) > 모니터링(Monitoring)
어느 회사에서든 위의 업무 흐름을 가지는 것처럼 이야기했지만, 사실은 그렇지 않다. 대체로 이런 순서로 진행된다는 것을 설명하기 위한 것이었을 뿐, 체계적인 QA를 위해서는
Test Strategy(테스트 전략), Test Design(테스트 설계), Entry/Exit Criteria(시작/종료 조건) 판단
등 더 다양한 활동이 수반되어야 한다. 그렇지만 이들에 대해서는 추후 다루기로 하고, 이번 글에서는 위의 프로세스를 기준으로 하나씩 뜯어보겠다.
우선, 우리가 리얼 환경이라고 부르는 대중들(엔드 유저)이 이용하는 환경에 하나의 버전이 릴리즈를 하는 데는
기획 > 개발 > QA > 배포 (릴리즈)
의 프로세스를 거친다(사실은 디자인, 마크업, 보안 등의 많은 세부 작업들이 포함되지만, 개괄적인 설명을 위해 4단계로 나누었다).
1. 기획 리뷰
제일 먼저 기획에서 이번 버전에서 출시할 태스크(Task)를 정하고 스펙(Spec, Specification)을 명세하여 어느 정도 기획서로 가시화되면, 유관 부서들을 모아 리뷰를 진행한다. 리뷰의 목적은 유관 부서들에게 기획 의도와 스펙을 설명하고, 팀 전체의 컨센서스(Consensus, 합의)를 맞추기 위함이다.
리뷰에 들어가기 전 기획서를 한번 검토하고 들어가는 것이 좋다. 모두 모인 자리에서 질문이나 제안을 하면 조기에 결함을 발견할 확률이 높아지고, 그만큼 효율적으로 리소스를 사용할 수 있기 때문이다.
2. QA 준비
리뷰 이후에는 공수 산정을 하게 된다. ‘얼마나 걸려요?’를 있어 보이게 표현한 것이라고 이해하면 된다. 이 기간을 근거 있게 산정하기 위해 테스트 범위를 정하고, 투입될 인원을 정하고, 소요될 기간을 예상한다.
테스트 범위 파악 > 투입 인원 대비 QA 소요 기간 산정 > 유관 부서에 공유 > 최종 공수 결정
테스트 범위는 상수가 아니다. 우선 QA의 타깃이 F/E만 될 수도 있고, B/E만 될 수도 있다. F/E가 타깃이라고 해보자. 예를 들어 우리의 서비스가 모든 OS 환경을 타깃으로 하는 웹 서비스이고, v1.0, v2.0과 같이 첫자리 단위의 메이저 업데이트가 예정되어 있다면 테스트 환경은 Windows, macOS, Android, iOS가 될 것이고, 이 중에서 타깃 브라우저를 선별해야 한다. 그다음으로 이 서비스 지역, 국내 한정인지 혹은 글로벌인지를 따져보고 최소 지원 OS 버전을 검토하며 이후 더 세분화하여 검토를 진행해야 한다.
하지만 아주 작은 업데이트만 필요하다면 어떨까? 이를테면 iOS 16에서 사진 업로드가 되지 않아 hotfix를 한다고 하자. v1.0.1과 같이 소수점 단위의 업데이트로 예정되었다면, 앞서 고려한 환경 검토는 필요하지 않을 것이다. iOS 16을 대상으로 어떤 아이폰 또는 아이패드에서 검증할 것인지 적절한 디바이스 선정만 하면 되므로 범위는 상당히 축소된다.
이렇게 테스트 환경을 정의하기 위해 선행되어야 할 것은 기획서의 내용을 정확히 이해하는 것이다. QA는 말 안 듣는 어린아이와 같은 사고방식을 지녀야 한다. 기획서를 검토할 때 ‘아 그렇구나’ 수준에서 그치지 않길 바란다. 사진 업로드 기능이 추가된다면 업로드의 대상이 프로필 이미지 또는 배경 이미지인지, 동시에 몇 개까지 업로드 가능한지, 용량은 어느 정도까지 허용하는지, 영상도 업로드가 가능한지, 어떤 확장자를 지원하는지 등 젠가를 하듯 기획서를 조금씩 분해하면서 어느 수준까지 커버리지가 고려되었는지 확인하라.
이러한 방식으로 기획서를 검토해야 현실적으로 커버 가능한 테스트 범위를 산정할 수 있고 이후의 리소스를 계획할 수 있기 때문에, 기획서를 이해하는 것은 무엇보다 중요하다.
테스트 범위를 정의했다면 투입 인원과 기간을 고려해야 한다. 공수 산정을 하는 방법에 대해서는 추후 다뤄보겠지만, 분명한 것은 기간을 무조건 길게 확보한다고 해서 100% 결함이 없음을 증명할 수 있는 테스트 활동이 될 수 없으며, 인원이 무조건 많이 투입된다고 해서 인원수에 따라 일정한 비율로 테스트 진행률이 빨라지는 것은 아니라는 것이다. 테스트 제7원칙
테스트는 결함이 없음을 증명하는 것이 아니라, 결함이 존재함을 밝히는 활동이다.
를 기억하길 바란다. 테스트활동으로 결함이 없다는 것을 증명할 수 있었다면 구글, 애플과 같은 공룡 기업들마저도 핫픽스 버전을 릴리즈 하는 일은 단 한 번도 없었을 것이다.
수면 저 아래에 아무도 몰랐던 결함이 존재할 수 있다. 그러니 우리의 목표는 최적의 인원으로 최적의 기간을 산정하여 최대한 중요 하고많은 결함들을 제거하는 것이다. 효율적으로 인원과 기간을 산정하라.
공수 산정까지 완료했다면 이를 유관 부서에 공유하여, 최종 QA 기간을 결정한다. QA 입장에서는 reasonable 한 일정일지라도 기획, 개발 등 다른 유관 부서에서는 동의하지 않을 수 있으며, 이미 프로젝트의 최종 릴리즈 일정이 픽스되었거나 개발 일정이 밀리는 등 QA기간 자체를 수용할 수 없는 상황으로 인해 협의가 필요할 수 있기 때문이다.
공수 산정이 끝나면 테스트 케이스(TC, Test Case)를 작성하고, 케이스들을 기능 별로 묶어 테스트 슈트(Test Suites)로 구성하여 리뷰를 진행한다. 테스트 케이스는 누구나 수행할 수 있도록 동작을 명확하게, 세분화하여 작성해야 하며, 이를 위해 Excel, Google Sheets, TestRail, Jira 등 테스트 케이스를 작성하기 위한 다양한 툴이 사용된다. 이러한 목적을 달성했다면 형식은 중요하지 않다. 단, 테스트 케이스를 작성할 때는 최소한 확인 과정(Steps), 기대 결과(Expected Results), 테스트 상태(Status)를 포함해야 한다. 확인 과정은 기대 결과를 확인하기 위해 수행해야 할 과정을, 기대 결과는 기획서에 정의된 내용을 명시한다. 테스트 상태에는 확인 과정대로 수행했을 때 기대 결과대로 확인이 되었는지를 체크하며, Pass/Failed 등으로 이를 구분한다.
리뷰는 이해관계자들을 대상으로 진행하는데, 좁게는 팀원에서부터 넓게는 기획, 외부의 협력업체까지가 이해관계자에 포함되게 된다. 붕어빵을 먹을 때 머리부터 먹는 사람이 있고, 꼬리부터 먹는 사람이 있다. 똑같은 붕어빵을 먹을 때도 먹는 순서가 다르듯, 테스트 케이스 또한 그렇다. 동료가 보는 관점이 다르고, 기획에서 보는 관점이 다르다. 리소스의 한계로 리뷰를 생략하는 경우도 있지만, 가급적이면 먼저 동료나 유관 부서에게 리뷰를 요청하라. 빙산의 일각만 보던 독자의 시야를 넓혀줄 것이다.
3. QA 시작
테스트 케이스 작성까지 완료되었다면, Entry Criteria를 따져보고, 이를 통과했다면 유관 부서에 QA 시작을 알리는 것으로 테스트가 진행된다. 정해진 형식은 없으므로 Slack 등의 커뮤니케이션 툴에서 간단히 공지할 수도 있고, 메일로 특정 양식으로 작성된 QA Plan을 전달할 수도 있다. 어찌 됐든 QA 기간 중 기획이나 빌드의 스펙이 지속해서 수정된다면 테스트 환경도 바뀌게 되고, 테스트 범위가 변경되어, 테스트 슈트를 다시 써야 하는 도미노 현상이 일어나게 된다. 그럴 경우 테스트의 신뢰성을 보장할 수 없기 때문에, ’QA 기간 중에는 테스트 변경되지 않는다는 것을 보장해 주세요 ‘를 공지하는 것이 QA 시작을 알리는 목적이다. 물론 실제로는 이를 지키지 않는 경우가 더 많다. 테스트 환경에는 크게 다음과 같이 4 종류가 있는데,
Alpha
개발 환경. 개발에서 변경한 코드가 바로바로 적용되는 환경이며, 유관 부서에 배포되기 전 팀 단위의 규모로 테스트하는 환경.
Beta
테스트 환경. Alpha 환경과 분리되어 있어 비교적 안정된 상태에서 유관 부서들의 테스트가 가능한 환경.
RC
Real 환경과 동일한 내부 환경. 이용자들은 접근할 수 없지만 Real과 동일한 빌드이기 때문에, 이 환경에서 이슈가 발생한다면 Real에서도 발생할 확률이 매우 높다.
Real
이용자들이 접근 가능한 환경. App Store, Google Play 등 우리가 사용하는 일반적인 환경.
명칭은 다를 수 있지만 QA 시에는 내부 망을 이용하는 환경에서 테스트를 수행하게 된다.
4. QA 진행
QA 기간에는 우리가 일반적으로 부르는 버그 또는 이슈를 찾아내고, 이를 유관 부서에 바로바로 공유하는 활동에 집중한다. 테스트 케이스의 확인 과정대로 수행했을 때, 기대 결과와 ‘공유하는 활동’을 어떻게 할 것인가는 지금까지 글을 읽었다면 이제 느낌이 올 것이다. 맞다. 마찬가지로 정해진 형식이 없으므로, Slack 등의 커뮤니케이션 툴을 이용해도 되고, Jira와 같은 BTS(Bug Tracking System)에 등록해도 된다. 하루의 QA가 끝나면 그날의 진행률과 특이사항, 협의 내용 등을 정리해 QA Status Report로 작성해서 전달하는 것도 좋다. 다양한 방법들 중 어떤 것이 공유와 관리에 효율적인지 선택하는 것은 QA의 몫이다.
QA라면 앞으로 '정상'이라는 단어 사용을 지양하라. 대신 '기대 결과'라는 용어 사용을 지향하라. 테스트 중 기대 결과와 다른, 어떤 비정상적으로 보이는 현상을 발견했을 때 이것이 이슈인지 아닌지를 판단하는 기준은 기획서가 된다. 단순히 자신의 예상대로 동작하지 않는다고 해서 이슈로 인지해서는 안된다.
예를 들어 뒤로 가기 버튼을 클릭했을 때, 나는 이전 페이지로 이동하는 것을 기대 결과로 예상했지만 홈 화면으로 이동한다고 하자. 이때 홈 화면으로 이동하는 것이 기획 의도였다면, 다른 서비스에서는 대부분 이전 페이지로 이동하거나 본인의 경험 상 동작이 어색하게 느껴져도 이것은 이슈가 아니다. QA의 목적 중에는 요구 사항을 충족하는지 검증하는 것도 포함되어 있기 때문이다.
하지만 이 동작이 프로덕트 전체의 통일성을 해친다면 어떨까? 서비스의 로그인, 결제 등 중요한 프로세스와 관련되지 않으면서, 전반적인 서비스 이용에서 거의 유일하게 홈 화면으로 이동한다면 말이다.
방법은 두 가지가 있다. 이전 페이지로 이동해야 하는 이유에 대해 기획과 개발을 설득하여 수정하거나, 정상 동작으로 판단하고 넘어가거나. 쇼핑몰 서비스 이용 중 특정 페이지에서 뒤로 가기를 했을 때 홈 화면이 나왔다고 사이트 이용을 못하는 것은 아니기에, 기능적인 관점에서는 굉장히 사소한 이슈이다.
그러나 UX(User Experience, 이용자 경험) 관점에서는 이야기가 조금 달라질 수 있다. 과연 문제의 페이지를 자주 이용하는 이용자도 사소하게 생각할까? 혹은 브랜드 가치가 높은 프리미엄 쇼핑몰이라면? 어떤 이용자는 이전에 봤던 상품을 보지 못하고 자꾸 홈 화면으로 돌아가서 스트레스가 시나브로 쌓일 수 있고, 해당 브랜드의 팬보이들에게는 브랜드의 가치를 떨어뜨리는 요소가 될 수도 있다.
서비스의 완성도를 어디까지 끌어올릴 것인가는 전적으로 QA의 판단과 커뮤니케이션에 달려있다.
5. QA Sign off
이렇게 QA 기간의 마지막 날이 되었을 때, QA 기간 마지막 날이 무조건 QA를 종료하는 날이라고 생각하면 안 된다. QA 종료 여부 결정을 Sign off라고 하는데, Sign off를 하기 위해서는 기간이 아닌 Exit Criteria를 만족하는지를 판단해야 한다. Exit Criteria는 모든 테스트 케이스를 수행했는지, 그 밖의 테스트 활동으로 추가 결함이 발견되지 않았는지, 공유된 이슈가 모두 해결되어 Pass rate가 100%에 근사한지 등의 객관적인 지표를 기반으로 정의하는데, 이 조건들을 모두 만족한다면 유관 부서에 Sign off를 공유할 수 있다.
QA 마지막 날이라 하더라도 Status 상 Exit Criteria로 정의한 지표들을 만족하지 못하거나, 지표들은 만족하지만 아직 해결하지 못한 중대한 결함이 있는 경우에는 Sign off를 유보하고 협의를 통해 결함을 당일 내 모두 해결하도록 하거나, QA 기간을 연장하는 등의 방법으로 Exit Criteria를 만족할 수 있도록 해야 한다. 검증할 테스트 케이스가 남아있거나, 해결되지 않은 결함이 존재하는데도 Sign off를 진행한다면 발견한 결함들을 비롯해 잠재된 결함들까지 모두 이용자가 떠안게 될 것이기 때문이다.
6. 모니터링
Sign off 이후 마침내 하나의 빌드가 Real에 릴리즈 된다. 이때 RC에서는 확인되지 않았던 결함이 발생할 수도 있고, 아예 RC 환경을 구축하지 않은 프로덕트도 있기 때문에 이용자의 어뷰징이나 추가 결함 등이 발생할 수 있다. 이를 방지하고 기대한 대로 프로덕트가 동작하는지를 검증하기 위해 모니터링을 진행하는데, 프로덕트의 성격에 따라 모니터링은 생략하기도 한다. 여기까지 완료되면 드디어 하나의 빌드에 대한 QA 프로세스 수행이 종료된다.
많은 QA들이 최적의 리소스로 최대의 결함을 제거하기 위해 다양한 테스트 방법들을 고안하고, 이를 적용할 프로세스 상의 순서와 횟수를 고려하고, 개발 프로세스와 효율적으로 결합할 수 있는 테스트 설계를 고민하고 있다. 빠지지 않고 거론되는 Automation(자동화)에서부터 ISTQB에서 설명하는 Agile, Waterfall, V-model 등의 소프트웨어 개발 프로세스나 Sanity, Smoke, Regression, Experience-based, Pairwise 등의 테스트 방법들은 이러한 고민의 결과로 제안된 것들이다.
지금 독자가 수행하는 프로세스는 프로덕트의 품질을 꽤 보장할 수 있다고 보는가?
그렇지 않다면 어느 부분이 효율적이지 않은가?
어떤 점을 보완하여 개선하면 더 나은 품질을 보장할 수 있겠는가?
여러 기업들의 QA 프로세스를 찾아보며 최적의 프로세스에 대해 고민해 보길 바란다.
