10화 블랙박스 테스트,이제 아무나 할 수 없습니다
Risk Based Testing
마무리는 리스크 기반 테스트 전략 실무와는 좀 다른 얘기를 해볼 텐데요. 리스크 기반 테스트 전략에 대한 포스팅을 진행하며 문득 HBsmith 서비스 매니저 직무 경험이 떠올랐습니다. 그리고 담고 싶은 이야기가 생겼습니다.
우선 지금까지 게임 분야에 적용한 리스크 기반 테스트 전략을 알아보았습니다. 리스크 기반 테스트 전략은 꽤나 적용하기 어려운 테스트 전략입니다. 하지만 시행착오가 있는 만큼 소프트웨어 테스트에 대해서 깊게 알아보는 시간이 되리라 생각합니다. 리스크 기반 테스트 전략은 소프트웨어 테스팅에 대한 국제 표준인 ISO/IEC/IEEE 29119 파트 2: 테스트 프로세스 기준으로 테스트 관리 프로세스 계층에서의 테스트 계획에 포함됩니다.
일반적으로 QA 체계가 잡힌 조직에서는 킥오프 단계부터 테스트 계획서를 작성합니다. 보다 효과적이고 효율적인 리스크 기반 테스트 전략을 수립하여 테스트 계획에 포함시키기도 합니다. 탐색적 테스팅과 같은 방법론 또한 효율적이고 효과적인 테스트 수행을 위한 수단입니다. 테스트 계획안에 포함된 리스크 기반 테스트 전략은 테스트 모니터링과 제어 그리고 테스트 완료까지의 테스트 관리 프로세스에 활용될 수 있으며, 주로 테스트 리더 또는 QA 매니저라 불리는 포지션에서 이를 리딩 합니다.
테스트 관리 프로세스와 수행 프로세스가 다르게 구성된 만큼 품질 보증 활동은 쉽고 간단한 활동이 아닙니다. 특히 QA 컨설팅이라는 영역은 웬만큼의 실무 경력과 도메인 경험으로는 서로 다른 개발 프로세스와 인력 구성을 지닌 기업들의 니즈를 충족시키기 어렵다 생각됩니다. Testing is context dependent, 테스트는 지극히 정황에 의존적인 활동입니다. 대상에 따라 테스트 내용이 달라집니다. 단편적인 예로 게임 분야에서의 테스팅 방법론과 보안과 안전이 중요한 의료 분야의 테스팅 방법론이 같을 리 없습니다. 도메인 지식도, 사용되는 용어도, 진행하는 절차도, 테스트 설계부터 구현, 실행, 마감까지의 방법이 달라집니다. 테스트 대상이 달라지면 테스트 활동의 시각화 및 정량화에 필요한 매트릭 또한 중요시 여기는 항목이 달라집니다. QA 컨설팅을 적절한 방향으로 진행하기 위해서는 웹, 앱 등 서로 다른 도메인의 테스팅 실무를 직접 경험해본 인력이, 기술에 대한 이해도가 합쳐졌을 때 수많은 시행착오를 겪으며 진행되는 분야라 생각됩니다.
QA 업무에는 테스트 활동이 포함됩니다. 블랙박스 테스트라고도 불리는 이 활동은 요구사항 분석을 토대로 테스트 항목을 설계하고 배포 과정에 필요한 품질 보증 활동에도 포함됩니다. 인력과 테스트 일정이 충분치 않다면 공인된 테스트 설계 기법을 활용하여 테스트 커버리지를 보완하고, 수정 변경된 내역으로 인해 이전 빌드에서 잘 동작되었던 기능들에 대한 문제가 없는지 검증하는 리그레션 테스트 범위를 산정해야 합니다. 이외에도 테스트 리더 포지션이 진행해야 할 업무에는 상당수가 테스트 수행 외적인 활동에 치중되어 있습니다. 그러한 모든 것들을 통 들어 블랙박스 테스트라 칭합니다. 버튼을 클릭하고 테스트 입력 값을 키보드로 입력하는 것이 쉽고 단순한 과정인 거지, 블랙박스 테스트 자체가 전문성이 낮고 쉬운 활동인 건 아닙니다. 누구든 프로그래밍 언어를 이용해서 코드를 작성할 수 있는 것처럼요.
블랙박스 테스트는 복잡한 주제인지라 이 글에서 상세히 다루지 않고 블랙박스 테스트&QA 입문서 브런치 북을 통해 다룰 예정입니다. 이미 QA와 테스트는 다르다 라는 주제를 관통하는 이야기들은 오래전부터 지속되어 왔습니다. 저는 제가 겪은 경험을 통해 조금 다른 얘기를 해보자 합니다. 쉽게만 느껴졌고 비전문적인 업무로 인식되었던 블랙박스 테스트. 테스트 자동화 서비스의 고도화로 인해 이제 전문성을 갖추지 않으면 아무나 할 수 없는 업무가 되고 있습니다.
저는 1년 3개월간 HBsmith 테스트 자동화 서비스의 기술 변화 과정을 직접 겪으며 서비스 운영을 해왔습니다. 기술 개발 과정에 직접 참여한 것은 아닙니다. 개발 완료된 제품을 운영하며 테스트 자동화 등록을 해왔습니다. 수십 명의 테스터를 리딩 하거나 중간 관리자로서 컨택 포인트 역할을 해오며 경험했던 테스트 실무와, 1인 QA 위치에서 한정된 자원으로 매번 최고의 효율을 이끌어내야 하는 테스트 실무를 모두 경험해본 저의 생각은 아래와 같습니다.
HBsmith와 같은 테스트 자동화 서비스가 기존 매뉴얼 테스트의 한계를 극복할 수준의 기능이 탑재된다면 대규모 인력 테스팅이 필요한 분야를 제외하고는 리그레션 테스트는 사람이 수행하지 않아도 품질 유지가 가능할 것입니다. 지금도 해당 서비스를 사용하는 기업들이 이 사실을 증명하고 있습니다.
또한 사후 모니터링 개념의 업데이트 또는 패치 후 진행되는 모니터링 업무를 보다 효율적으로 상시 테스트가 가능합니다. OP 환경의 주요 기능에 대한 상시 모니터링 용도로도 활용 가능하기에 테스트 수행보단 요구사항 분석과 설계 결과 분석과 같은 역량이 더욱 필요 해질 것입니다.
매뉴얼 테스트의 가장 큰 문제점이라 생각되는 점은 테스트 결과에 대한 신뢰성과 신뢰성을 보장하기 위한 과정에서 발생하는 비용이라 생각합니다. 사람의 컨디션에 따라 테스트 속도와 퀄리티가 달라질 수 있습니다. AI(기계)가 하면 달라지냐 라고 생각할 수 있겠지만 테스트 과정과 결과를 신뢰성 있게 확인해볼 수 있는 GUI를 QA 담당자가 원하는 형태로 제공해준다면 얘기는 달라질 것 같습니다. 아무래도 사람의 기억과 엑셀에 기입된 테스트 코멘트보다 시각적으로 확인 가능한 형태의 화면이 더욱 신뢰성 있지 않을까 싶습니다.
반복된 작업에도 꼼꼼한 집중력을 유지할 수 있는 능력을 요구하는 테스터 채용 공고가 많습니다. 과거 신입 테스터 면접 당시 저 또한 이러한 부분을 중요시 여겼고 요구했던 적이 있었지만 지금 생각해보면 지원자분께 과도한 요구가 아니었을까 싶습니다. 피로한 상태에서 운전대를 잡고 절때 사고 내지 말라며 주의하는 것과 다를 바 없습니다. 쉼터에서 쉬어가거나 피로한 상태로 운전대를 잡지 않는 방법을 찾아야 합니다. 휴먼 에러는 시스템으로 보완하는 것이 바람직합니다. 실수가 발생하는 환경임을 뻔히 알면서도 이를 사람의 노력으로 해결하기에는 비효율적인 시대라 생각됩니다. 일을 대하는 집중력은 프로의 자세이고 당연한 것입니다. 하지만 반복된 작업을 통해 피로가 쌓인 상태에서 집중력을 유지하는 것은 매우 힘든 일입니다. 이건 마인드셋의 문제가 아니라 시스템을 고치거나 바꿔야 합니다.
하지만 현업에서 단순 반복 형태의 테스트에 어쩔 수 없이 집중하게 되는 경우가 많습니다. 리스크 분석을 진행해보면 최종 사용자에게 중요한 비즈니스 로직 대부분이 반복 테스트 영역에 놓인 경우가 많습니다. 그러다 보니 쉽게 번아웃이 찾아오고 더 나은 테스트 고도화 방법이 있는지 알면서도 시도조차 하지 않는 경우가 많습니다. 단순 반복 형태의 업무에서 벗어나지 못한 상황에서 일을 더 키우고 만들기가 싫은 거죠.
HBsmith 서비스는 인공지능 봇이 24시간 365일 수행하기 때문에 결과 신뢰성 문제가 발생하지 않습니다. 결과의 정확성과 신뢰성의 문제는 다른 문제입니다. 결과가 정확하지 않다는 것은 테스트 자동화 설계가 잘못되었거나, 시스템의 문제이니 그 부분은 개선 포인트로 삼으면 됩니다. QA팀이 필요한 사항들을 계속 요구하여 실무 진행에 활용도가 높은 서비스가 될 수 있도록 요청하고 사용하면 됩니다. 그에 따른 대가를 지불하고서 말이죠.
HBsmith와 같은 인공지능 테스트 자동화 서비스는 QA 담당자가 무엇을 테스트해야 하는지 명확히 알고 있다면 더욱 효율적인 서비스라 할 수 있습니다. 반대로 QA 담당자가 무엇을 QA 해야 할지 명확하지 않고 QA 업무에 대한 이해도가 낮다면 활용 가치가 떨어지는 서비스라 할 수 있겠죠. 테스트 자동화 서비스를 잘 사용하기 위해 QA 분야의 업무 이해도를 늘려야 하는 시기가 왔다고 생각합니다.
HBsmith 서비스는 테스터분들께서 눈으로 확인하는 엑셀 시트의 테스트 사전 조건과 스텝을 기계가 똑같이 24시간 반복 수행합니다. 테스트 실행 주기를 분단위로 설정할 수 있고 테스트가 실패하면 관련 내용을 안내받을 수 있습니다. 블랙박스 테스트에서 가장 많은 시간을 할애하는 부분이 테스트 수행 영역인데, 이 부분을 대신해주는 겁니다. 24시간 365일 최고의 컨디션으로 말이죠. 200개 TC 15분도 안돼서 설계 및 실행이 가능합니다.
블랙박스 테스팅 실무에서 무슨 의미냐면 단순 반복 테스트는 기계에게 맡기고 휴먼 리소스는 탐색적 테스팅과 같은 경험, 직관, 기술이 필요한 테스트 영역에 집중할 수 있다는 거죠. 과거 테스트 리더 재직 당시 1200개의 등급 상자 데이터 검증을 해야 하는 상황이 있었는데 이걸 그날 자정까지 마무리 후 결과보고를 해야 해서 모든 파트원분들께 야근 요청한 기억이 아직도 생생합니다. 저 혼자서는 다 못 까니깐요. 업무 시간에는 테스트 설계, 모니터링, 제어하기 바빴습니다.
하지만 기계는 개수 제한 없이 병렬 및 동시 테스트가 가능합니다. 테스트 수행을 대신해줄 수 있는, 그것도 24시간 상시 테스트 가능한 환경이 마련되었다는 것은 테스트 고도화 환경이 갖춰졌다는 걸 의미합니다. 테스트 수행 프로세스에서 단순 반복적인 테스트 업무에 소요되는 리소스가 최소화된다면 다른 활동을 고도화시킬 수 있습니다.
오늘 하루 진행한 TC에서 분명 반복적이고 정형화된 패턴이 보이는 테스트 대상이 있을 겁니다. 그런 테스트 케이스 또는 체크리스트는 전부 봇에게 맡기는 겁니다. 즉 테스터의 판단이 필요한 TC만 남기고 모두 봇에게 맡기는 거죠.
이러한 서비스의 가치를 파악하고 제대로 활용하기 위해서는 우선 QA 부서에서 체계적인 테스트 프로세스를 잡아가는 것이 효율적이라 느껴졌습니다. 전체 기능에 대한 테스트 케이스를 관리하고 유지 보수하는 것도 큰 도움이 됩니다. 테스트 케이스를 유지 보수하려는 시도와 의지는 테스트 원리 중 살충제 패러독스의 개념을 이해한다는 의미이고, 고객 피드백을 테스트 활동에 반영한다는 의미로 해석할 수 있습니다. 또한 한번 발생한 버그는 QA팀에 의해 Close 되었다 하더라도 언제 어떠한 경로로 재발할지 모릅니다. OP 환경에서의 사용자 피드백인 CS 유입을 처리하는 과정에서 확인된 버그들을 리그레션 범위에 포함시켜 지속 관리하겠다는 의미로도 해석 가능합니다. 그만큼 테스트 디자인은 중요합니다.
단순히 엑셀 시트에 테스트 시나리오를 적는 것과 한번 잘 작성된 테스트 케이스는 큰 차이가 있습니다. 테스트 케이스가 잘 작성된 조직은 무엇을 테스트해야 하는지, 우리 서비스에서 중요한 기능은 무엇인지, 리그레션 관점에서는 어떤 항목이 중요한지를 파악하고 있기 때문에 더욱 잘 활용할 수 있으리라 생각됩니다.
테스트 자동화 서비스는 사용자의 니즈를 충족시킨 서비스 형태로 성장할 것입니다. 이미 내부 QA팀 없이 해당 솔루션만을 활용하여 품질 유지를 해오는 고객도 존재했습니다. 테스트 자동화 서비스 도입으로 효율적 품질 관리의 사례가 늘어남과 더불어 비용적인 측면에서의 효율성이 매뉴얼 테스트보다 월등하다는 것이 확실하게 입증된다면 블랙박스 테스트는 아무나 할 수 없는 업무가 될 것이라 생각합니다. 피상적으로만 알아도 업무에 큰 문제가 없는 테스트 수행 영역을 대체할 테니깐요.
이러한 이유로 앞으로의 QA 엔지니어는 테스트 수행 업무와 더욱 멀어질 것이라 생각합니다. 테스트 설계와 구현, 환경 구축, 탐색적 테스팅 또는 애드혹 테스팅과 같은 사람의 투입이 필요한 테스트 영역과 더불어테스트 계획, 모니터링, 제어, 측정, 전략, 정책과 같은 품질 보증 활동에 더욱 집중하게 되겠죠. 이러한 지식들을 학습하고 도입하는 것 자체가 아무나 할 수 없는 일이고 복잡한 영역입니다.
HBsmith와 같은 테스트 자동화 서비스를 운영만 했다는 점이 꽤나 아쉽고 직접 사용해본 사례가 없는 점도 아쉽습니다. 그렇지만 다양한 웹 및 앱 서비스의 고객들의 제품을 분석하여 테스트 자동화 등록을 직접 한 경험을 토대로 작성한 의견이기에 쓸모없는 이야기는 아닌 것 같습니다. 제가 만약 고객이라면 품질 보증 활동에 있어서 해당 서비스를 도입했을 때의 효과적인 QA 방법이 많을 것 같습니다. 저는 테스트 자동화 서비스 운영 경험 이전에 QA, Tester 였기 때문입니다. 당장 리스크 기반 테스트 전략만 보더라도 HBsmith 서비스 도입으로 전략 수립 방향이 달라질 수 있겠다는 생각이 들기도 하네요.
다만 아직까지는 앱, 웹 서비스 UI의 큰 변화에 빠른 대응이 힘들긴 합니다. 즉, QA 환경에서의 테스트 수행은 그리 효율적이지 못할 수 있다는 거죠. 보통 QA팀의 리소스가 가장 많이 소요되는 곳은 경험상 업데이트 과정에서의 테스트 수행 기간인데 이 기간에는 앱 또는 웹 서비스가 기획과 정책 구현 방향에 따라서 UI가 계속해서 변경되기 때문입니다.
하지만 위 문제도 생각해보면 업데이트 TC와 리그레션 TC가 명확히 분리되어 있고, 모든 UI가 변화하는 것이 아니기 때문에 QA 환경에서도 서버만 24시간 열려있다면 24시간 검증할 테스트 대상은 존재한다는 것이죠. 또한 테스트 케이스를 잘 작성하고 관리하는 조직이라면 테스트 실행 순서와 의존성 문제를 고려해서 작성하게 되므로 어떤 TC를 도입하고, 하지 않을 것인지 구분이 쉬울 겁니다.
다만 버그 수정 확인과 같은 확인 테스트(Confirmation testing)는 수정 전과 후로 UI 변경 가능성이 크기 때문에 아직까지는 사람이 진행하는 것이 효율적이라 생각되고요. 리그레션 TC는 매 업데이트마다 진행해야 하므로 QA팀 입장에서는 리그레션 TC 중 단순 반복 테스트 커버리지만 인공지능 봇으로 대체해도 전체 테스트 일정에서 큰 도움이 될 것 같습니다.
신규 업데이트 내역 TC 수행은 글쎄요, 서비스 도입이 효과적일지 사람이 하는 것이 효과적일지 사용자의 입장에서 서비스를 도입하여 QA 해본 적이 없기에 애매한 부분이네요. 확실한 건 리그레션 TC를 줄여준다는 것 만으로 큰 도움이 됩니다.
OP 환경의 사후 모니터링 개념으로는 인력을 투입하여 진행하는 것보다 훨씬 효과적이지 않을까 생각합니다. 사실 기존 매뉴얼 테스트가 지닌 한계점을 극복한 것이라 볼 수 있습니다. 제가 겪어온 환경만 그런지는 모르겠지만 QA 관점에서는 버그가 OP 환경에서 발생하면 서비스 장애라 부르고, QA 환경에서 발생하면 버그라 부르는 것처럼, 버그는 OP 환경에 배포하기 전에만 고치면 된다는 인식이 강했고 그렇다 생각합니다. 결국 QA팀의 존재 가치는 서비스 장애를 최소화하여 사용자들의 안정적인 앱 사용에 중점을 둔다는 것이죠. 사용성, UX UI와 같은 품질도 중요하지만요. 따라서 24시간 365일 상시 테스트가 병렬 및 동시 수행이 가능하기 때문에 QA 담당자가 기존에 자주 발생했던 버그 유형을 파악했다면 그러한 부분을 상시 테스트하는 것도 품질 유지에 좋은 방법이라 생각됩니다.
결론
블랙박스 테스트 수행은 가까운 미래에 테스트 자동화 서비스 등으로 대체될 가능성이 매우 높으니, 테스트 수행 외적인 활동에 대한 역량을 키우는 것에 집중하고 학습해야 하는 시기가 찾아온 듯합니다. 테스트 결과 판단 기준도 사람이 하는 것과 유사한 형태로 발전한다면 이제 정말 아무나 할 수 없는 업무가 되겠네요.
인공지능 Bot을 뛰어넘을 테스트 수행 능력을 지녔거나, 블랙박스 테스트 활동을 고도화시킬 수 있는 지식(리스크 기반 테스트 전략 등)과 경험을 지녔거나, 그게 아니라면 할 수 없는 그런 업무가 되는 거죠.
긴 글 읽어주셔서 고맙습니다.
이지원 드림.
