우리만의 지식과 전문성
테스트 자동화 에세이
인공지능 테스트 자동화 서비스 매니저 직무 경험을 회고하며 2021. 04 포스팅했던 Risk Based Testing 주제의 마지막 포스팅인 "블랙박스 테스트, 이제 아무나 할 수 없습니다."의 당시 결론은 이랬었다.
https://brunch.co.kr/@jiwonleeqa/203
"다만 아직까지는 앱, 웹 서비스 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을 뛰어넘을 테스트 수행 능력을 지녔거나, 블랙박스 테스트 활동을 고도화시킬 수 있는 지식(리스크 기반 테스트 전략 등)과 경험을 지녔거나, 그게 아니라면 할 수 없는 그런 업무가 되는 거죠."
최근까지 클래스 기반의 페이지 개체 패턴을 줄곧 활용해 오다 BDD 프레임워크인 Cucumber의 Feature와 Step의 단계 매핑 원리를 활용한다면 자연어만으로 테스트 시나리오를 생성할 수 있다는 점을 깨닫게 되었다.
이러한 방식이 동작하려면 몇 가지 프레임워크 설계 측면에서 전제 조건 있는데, 첫 번째로 Step에 해당하는 Given, When, Then 로직을 수정하지 않고도 Feature 파일에서 재사용 가능토록 Cucumber 정규표현식과 동작 및 체크 함수로 구현하는 과정이 필요하다. 두 번째는 클래스 기반의 개체 패턴에서 함수로 분리된 동작과 체크 함수에 대해 Jest와 Mock Functions을 활용한 단위 테스트가 필요하다. 동작과 체크를 함수로 분리했기 때문에 E2E 코드 실행 전 해당 함수가 정상 동작하는지 체크해 보면 좋다. 테스트 코드를 위한 단위 테스트에서 문제가 없다면 E2E 테스트 코드에서 발생하는 문제는 로케이터와 실제 서비스 장애로 문제 원인이 좁혀지기 때문에 디버깅도 용이하다.
이러한 접근 방식은 React와 프론트엔드 생태계에 대한 이해가 없다면 전통적인 페이지 개체 패턴 개발 방식에 비해 어렵고 복잡하게 느껴질 수 있지만 만약 프론트엔드 개발에 관심이 많다면 유용한 접근 방식 중 하나이다. E2E에서 유용한 이유는 E2E 테스트는 정형화된 패턴으로 동작하는 코드이기 때문이다. 상호작용과 검증에 해당하는 클릭 스크롤 입력 확인의 모든 로직은 사실상 어떠한 서비스든 활용될 수 있고 재사용 가능하다. 서비스만의 특정 상호작용과 검증이 필요하다면 그 부분에 대해서만 별도의 단계를 구현하여 단위 테스트를 추가하면 된다.
JavaScript 라이브러리인 pixelmatch로 진행하는 E2E 테스트 결과 검증의 고도화와 위와 같은 접근 방식을 활용하면 E2E에서도 대규모 스위트를 굉장히 쉬운 방법으로 구축할 수 있겠다는 생각(JM Player는 매일 밤 약 25,000개의 UI 인수 테스트를 실행)이 들자 문득 과거 포스팅했던 "블랙박스 테스트, 이제 아무나 할 수 없습니다."의 결론이 떠오르는 건 왜일까, 앞으로 SW QA 분야에서는 탐색적 테스팅과 같은 우리만의 지식과 경험이 보다 필요하고 더욱 인정받는 순간이 찾아올지도 모르겠다. 테스트 자동화는 테스트 방법 중 하나 일뿐 SW QA 분야의 고유한 지식과 전문성은 기술로 해결하기 힘든 사람이 필요한 영역이기 때문이다. 하지만 그렇기에 누군가는 외롭고 아무도 알아주지 않는 과정을 통해 테스트 자동화로 좋은 선례와 결과를 만들어야 한다.
SW QA 분야에서 이루고 싶었던 목표와 직업인으로서 찾고 싶었던 가치에 대해 어떠한 커리어를 쌓아가는 게 좋을진 모르겠지만 커리어에 대한 고민은 2가지 분야에 대한 균형을 이룰 만큼의 역량과 경험이 쌓인 뒤 새롭게 나타난 길을 선택해 보는 것도 의미 있는 순간이 아닐까. 오늘도 내일도 Vanilla JS, React, 프론트엔드 생태계 그리고 Node.js 기반의 웹 모바일 테스트 자동화 프레임워크인 WebdriverIO DeepDive를 통해 현재 해야 할 것들에 집중하고, 고민을 즐기지 않으려 한다.
