QA 그리고 오해의 시선
오해의 시선? 어찌보면 살짝 논란의 여지가 있을만한 이 제목과 내용은 일전에 Software QA가 하는 일? 이라는 발로 쓴 듯한 짧고 간단한 QA 소개글을 올리고 나서 벌써 1년 하고도 수개월이 훌쩍 지나고 있어 아쉽던 차에 평소 존경하던 분으로 부터 글 요청을 받아 공유하게 되었습니다.
사실 타인의 시선 보다는 자기 자신의 시선도 오해가 있는 것을 알고 있고 자아성찰을 먼저 해야겠지만 이번에는 우선 제가 QA로 느껴왔던 타인의 시선에 대한 주관적인 경험을 토대로 시작해 볼까 합니다. 편의상 경어체를 사용하지 않는 것에 양해 부탁 드립니다.
어떤 시선을 느꼈나?
필자가 현재까지 경험한 혹은 여러 지인들로 부터 들은 바로는 아직까지는 QA팀이 존재하는 많은 소프트웨어 개발 회사들 중 상당수(당연히 모두가 아닌 일부이다 하지만 꽤 많이)의 경영진 및 QA팀과 협업하는 stakeholder들은 QA에 대한 오해의 시선을 가지고 있는 것 같다.
그 중 대부분은 QA팀을 한정된 시선으로 바라보고 극히 한정된 업무만을 기대하는 것으로 그 이상의 어떤 활동을 시도할 경우 버그나 잘 잡아내면 되지 그걸 꼭 해야 하냐는 질문 아닌 질문을 접하곤 한다. 또한 제품을 함께 만들어간다라기 보다는 만들어진 제품에 대해 그저 최종확인에 도움을 주는 팀으로 그냥 마냥 도와줘서 고맙습니다하는 시선이다.
어찌보면 뭐 대단한 QA 라고 그 이상의 기대감을 바라나 할 수 도 있겠지만 본질은 개발된 (그렇담 이게 정말 개발된 혹은 완료된 상태이기는 할까?) 제품에 대해 버그를 찾는 것 이상의 품질에 대한 기대감의 부재로 인해 좋은 품질을 위한 기초 토대마저 확보 하기가 어려워지게 되는 악순환의 연속이 개탄 스럽다.
그럼 이제 각 시선을 세부적으로 살짝 나누어 더 들어가 보자.
경영진의 시선
경영진은 업무 프로세스가 이미 잘 갖추어져 있다는 전제하에 QA 에게는 큰 관심이 없거나 가끔씩은 팀장회의를 소집해 유저에게 발생한 이슈에 대해 왜 이런 이슈를 못 잡아 냈는지 뒤 늦게 궁금해 하는 듯 하다. 경영진의 시선에서는 높은 품질에 대한 기준이 개발 완료 후에 놓여져 있다보니 프로젝트의 성과가 있을 경우에도 QA팀으로 그 공이 돌아오는 경우는 극히 드물다.
협업하는 Stakeholder(Product/ SE/ Art/ Project Management) 들의 시선
먼저 기획서가 완성이 되어야 QA팀에 공유 할수 있고 그 완벽한 기획서로 좋은 테스트 케이스를 만들어서 버그를 잘 걸러내 주기를 바라는 것 같다. 그 기획서가 초안이 마련되고 함께 리뷰를 통해 SE팀으로 부터 기술관련 피드백을 받아 많은 부분 수정을 하기도 하지만 QA팀의 피드백에 있어서는 특별한 오류가 예상되지 않는 한 오류 이외의 피드백에 대해선 크게 받아 들여진 경우는 드물다.
어느 정도 완성된 기획서와 UI/UX 어셋을 가지고 어느 정도 제품을 완성시키고 나서야 QA팀이 눈에 들어오는 듯 하다. 대개 그 어느 정도에 못 미치는 제품을 보자고 하는 것에 대해 큰 부담을 가지고 있어 다시 말하지만 모두 그런 것이 아니지만 몇몇은 마치 치부가 들어 날까봐 두려워서 떨고 있는 듯한 인상도 느껴 질 때가 상당하다.
이렇다 보니 개발 프로세스가 잘 돌아서 출시 일정에 맞추어 내보내는 것에 중점을 두고 많은 부분은 개발이 어느 정도 완성되는 것에 너무 많은 신경을 쓴 나머지 QA 프로세스를 놓치는 경우가 많은 것 같다. 사실 QA 프로세스는 개발 프로세스 안에 포함되어 있다는 것 보다 개발 프로세스가 끝나야 QA 프로세스가 있다는 생각을 가지고 있는 것 같아서 이 부분을 개선 시키고자 하는 계획을 세우기가 싶지가 않다.
정말 오해의 시선 일까?
오해의 시선이라고 생각하는 가장 큰 이유는 아주 간단하다. 바로 QA는 개발 후 Test, 바로 뭘 해도 기승전Test로 이어지는 것이 QA가 나아가고자 하는 방향이 아니라는 것이다. 다르게 표현하자면 선 개발 후 QA라는 공식이라면 위 시선이 정말 오해가 아닐 수도 있다는 것이다. 그 공식이 성립하는 QA도 많겠지만 일단 그 자리에 머물러 있기 보다는 한 걸음 더 나아가고자 하는 QA에게는 참으로 답답한 공식인 것 같다.
그럼 정작 QA 는 무슨일을 어떻게하는 팀 이어야 할까?
QA 프로세스는 개발 프로세스의 일부로 전체 개발 기간 중 후반의 일부에 포함되는 것이 아니라 개발 프로세스 시작부터 끝까지 모두 포함되는 프로세스로 기획의 아이디어 초안 회의부터 제품 출시 후의 동향을 살피는 것까지 모두를 아우른다고 말할 수 있겠다. 여기서 오지랖 이라는 단어가 생각이 나지 않는 다면 이 글을 쓰는 목적의 반은 성공한 셈이다.
가장 기본적 이자 가장 중요한 다양한 유저들의 시각
일반적인 QA의 가장 큰 장점은 바로 누구보다도 더 많은 시간을 넓은의미에서의 다양한 부류(일반적인 유저: happy scenario, 특별한 유저: edge scenario)의 유저로서 직접 사용하는 것과 같은 제품 테스트에 쏟아 붙는 관계로 많은 유저 전문가들이 팀안에 존재한다는 것이다. 이 다양한 유저들의 시각을 아이디어 초기 회의 부터 적극적으로 기획/ 명세서에 반영하면 어떨까?
또한 좀 더 완벽한 테스트를 위해 좀 더 다양한 테스트 케이스를 미리 준비하는 과정에서의 많은 질문 세례는 개발 후 이슈가 발생할 확률을 줄이는 역할도 할 수 있다 하겠다.
Technical 지식 그리고 자동화
Technical 지식이 반드시 자동화를 하기위한 지식만을 뜻하는 것은 아니다. 위 가장 기본적이지만 가장 중요한 다양한 유저들의 시각에서 한 단계 더 깊이 들어가기 위해서 필요한 스킬을 활용해 SE 개발 문서/Architecture를 토대로 개발된 각 기능들에 대한 로직을 개발 소스의 대략적인 flow를 훑어 가며 대략 아래와 같은 순서로 흐름을 파악해 좀 더 깊고 다양한 이슈 (기능, 보안 및 퍼포먼스 등등) 들을 테스트하고 개발 단계에서 잡아 낼 수 가 있다. 물론 이부분은 개념을 얼마나 잘 숙지하나가 중요하지 도구 (프로그래밍 실력)가 꼭 SE와 같은 수준일 필요는 없다.
Front End (UI/View) --> Back End(Server/API) --> Model (DB)
뿐만 아니라 다양한 유저의 시각을 무기로 Unit test의 테스트 시나리오에 대한 조언을 하거나 혹은 직접 Unit test 작성하고 Coding Standard/ Convention을 기반으로 정적 분석을 하기도 한다. 또한 잘 짜여진 테스트 시나리오를 이용하여 Front End, Back End, Model에 대해 각각의 테스트들을 통합 후 자동화를 통하여 효율성을 극대화 한다. 테스트 자동화에 있어 가장 중요한 것은 좋은 자동화 도구와 스킬도 있겠지만 그 무엇 보다도 좋은 시나리오가 필요하다는 것이다.
데이터 분석
QA 활동과 연관된 모든 데이터를 분석하여 우리가 가고자 하는 방향성 아래 현재 어느 부분에 집중을 하고 있고 앞으로는 어떻게 추가로 개선해 나가야 하는 지에 대한 계획을 세운다. 아래의 예시와 같은 각종 QA 연관된 데이터들의 상호 연관관계를 분석하고 리스크를 도출해 개발단계에서 부터 관리해 나갈수 있다.
- 예상되는 버그 수
- 발견된 버그 수
- 테스트 시간
- 기능별 의존관계
- 소스 코드의 크기 및 복잡도
- 각 팀 별 중요도 및 리스크
- 유저 데이터
그래서 결국 가고자 하는 방향은?
QA도 결국은 모든팀과 마찬가지고 더욱 효과/효율적으로 품질을 확보하고자 노력하는 팀이라 할 수 있겠다. 알고리즘의 효율관계처럼 품질 확보에 대한 효율성을 높이고자 하는 것이다.
O(n²) >>> O(n) >>> O(c)
물론 절대값 효율에만 매달리는 것이 아니라 해당 상황에 맞는 최적화된 상수를 대입해 가면서 뒤 늦게 튀어나온 이슈를 처리 하느라 많은 인력과 비용을 투입하는 일이 없도록 방지하는 역할을 하고자 하는 것이다. 아래의 그림과 같이 대부분의 Risk/Issue 해결 비용은 시간이 갈 수록 증가하며 거의 무료에 가까운 비용으로 Risk를 줄일 수 있는 방법은 모두 Pre-integration 단계에 있다.
