by
Aug 14. 2023
사이드 프로젝트로 레벨업 하기 - 7장
비사이드 참여기 7. QA
디자이너, 개발자와의 티키타카를 마친 뒤 반드시 거쳐야 할 작업이 있다. QA(Quality Assusurance)라는 단계.. 하기 싫지만 해야 할 수밖에 없는 악명 자자한 그 QA... 이번 글에선 하루냥 구축 프로젝트 QA 후기와 몇 가지 팁을 공유하겠다.
SI 프로젝트의 QA
이야... 드디어 본게임 시작이네요!
재직 중인 회사에서 외국계 대기업 보험사로 파견되어 프로젝트를 진행할 때, 개발이 끝나고 UAT(User Acceptance Testing) 단계 도입 전 공통 UI 시스템 담당 기획자분께서 하신 말씀이다. 그 말과 함께 그 자리에 있던 20년 경력의 베테랑 기획자분들의 얼굴엔 수심이 깊어졌다. 어떤 분은 한숨까지 내쉬면서 이제부터 야근은 불가피하다는 말을 되뇌었다. 나는 본게임이 시작되었다는 말의 의미를 파악하지 못했지만 테스트를 진행하면서 그 의미를 깨닫게 됐다.
테스트를 수행하기 위해선 무엇을 테스트할지 명확히 규명하는 것이 중요하다. 내가 경험한 SI 프로젝트에선 Test Scenario, Test Case에 테스트할 내용을 명확히 작성한 뒤 이해관계자들에게 전달했다. 그다음 JIRA 툴을 이용해 이슈 생성(오류 제보) → 담당 개발자 확인 → 오류 수정 → 확인 → 이슈 닫기 과정을 더 이상 웬만한 이슈가 나오지 않을 때까지 반복하면서 프로그램 퀄리티를 높여갔다.
사람들이 JIRA 때문에 많이 예민해졌다. JIRA에는 Test Scenario, Test Case에 작성된 테스트 항목에 대한 오류가 등록되는데, 앱 규모가 너무 큰 탓에 등록되는 이슈의 개수가 말이 안 나올 정도로 많았다. 사람들의 얼굴엔 주름이 늘어나고 담배를 태우러 가는 횟수는 JIRA 이슈에 비례해서 늘어났다.
JIRA에 등록된 이슈. 이러한 이슈들이 많게는 수백, 수천개까지 생성된다.사이드 프로젝트의 QA - 기능
UAT에서 배운 것들을 하루냥 QA에 적극 활용했다. JIRA가 마치 문제의 근원처럼 묘사됐지만 모든 이슈와 진행 상태를 전부 파악 가능하다는 장점 때문에 JIRA는 사실상 대체불가능한 툴이다. JIRA를 하루냥 QA에 도입하고 싶은 맘이 굴뚝같았지만 짧은 시간 내에 빠르게 QA를 진행해야 했어서 JIRA 세팅 방법과 체계 생성 방법을 익히기에 시간적으로 부담이 되었다. 따라서 상대적으로 익숙한 스프레드시트를 도입한 뒤 JIRA의 공백을 메꿀 만큼 Test Scenario와 Test Case를 촘촘하고 꼼꼼하게 작성하기로 했다.
기능 QA 시트우리 팀은 스프레드시트로 QA 시트를 만들었다. Test Scenario는 1-Depth 기능을 기준으로, Test Case는 시나리오를 구성하는 2-Depth 기능을 기준으로 기획했다.
Test Case 작성 시 여러 변수를 고려했는데, 그중 더블클릭 이슈와 백 버튼 이슈(안드로이드)를 특히 신경 썼다. 이벤트가 심어진 UI에 더블클릭이 일어난 경우, 제대로 살피지 않으면 이벤트가 두 배로 생성되는 대참사가 일어날 수 있기 때문에 운영 측면에서 반드시 체크해야 한다. 안드로이드는 OS 자체 백버튼을 많이 사용하기 때문에 이 역시 체크리스트에서 빼놓을 수 없다.
이렇게 테스트할 내용을 꼼꼼히 작성한 뒤, [테스트 우선순위], [테스트 내용], [input 값], [예상 결과], [1차 ~ 3차 테스트 결과], [오류 타입], [오류 수정 우선순위], [날짜], [개발 담당자], [1차~3차 결과], [해결유무] column을 생성하고 모든 이슈를 꼼꼼하게 트래킹 했다. 기능 QA 같은 경우엔 프론트엔드, 백엔드 개발자 모두 인볼브 되는 중요한 단계다. 서버에서 데이터를 클라이언트로 못 보내는 경우, 클라이언트에 저장되는 데이터 및 서버에 저장되는 데이터가 꼬인 경우처럼 개발자들조차 몰랐던 문제를 발견할 수 있었고, 앱 전반적인 품질을 향상할 수 있었다.
사이드 프로젝트의 QA - 디자인
디자인 QA 시트디자인 QA는 기능이 아닌 화면 단위로 진행했다. 주로 검토한 항목은 UI 모양, 크기 및 위치, 화면 전환 애니메이션, 인터랙션이었다. 우리 팀은 Figma로 디자인했기 때문에 Figma 화면에 이슈 내용을 코멘트로 남기면서 프론트엔드 개발자 <-> 디자이너 간 협업이 진행되었다.
이슈 내용을 보면 폰트명과 컬러명을 명확하게 명명한 것을 볼 수 있다. Figma의 컬러/폰트 시스템 활용도가 높은 팀원분들께서 명확한 컬러명, 폰트명을 디자인 초기 단계에서 확정 지은 덕분에 커뮤니케이션 코스트가 줄어들었다고 생각한다. 만약 그러지 않았으면... 디자인 QA 이슈 개수는 3배 정도 늘어났을 테고 스프레드시트가 폰트 크기, #컬러값으로 도배가 됐을 것이다.
꼼꼼한 디자이너 팀원분들께서 쥐 잡듯이 발견한 이슈를 수정 요청 주시고, 프론트 개발자분이 이를 거의 다 반영해 주신 덕분에 디자인 QA는 무사히 끝날 수 있었다.
QA 진행 상황 공유하기
우리 팀은 QA 단계에서 약 3주를 소모했다. 프로젝트 마지막 단계인 만큼 팀원 모두가 예민해져 있는 시기였다. 나는 PM으로써 진행 상황을 공유할 의무가 있고 팀원들 멘탈 또한 신경 써야 하므로 QA가 얼마나 진행됐으며 이만큼 남았다는 지표를 주간 미팅 때마다 공유했다. 지표를 보며 진척도가 높은 시나리오엔 힘을 빼고, 진척도가 낮은 시나리오엔 인력을 추가 투입해서 QA 속도 조절에도 신경을 썼다.
군대 행정병, 카카오에서 데이터 전략파트 인턴으로 지내면서 익힌 엑셀 능력은 어딜 가든 도움이 되는 것 같다.ㅎㅎ
QA를 겪으면서 느낀 점
QA 단계는 이름 그대로 프로그램의 품질을 끌어올리는 단계다. 동일한 기획서를 보더라도 디자이너가 생각한 것과 개발자가 생각한 것은 디자인 요소, 핵심 기능 로직 등 여러 측면에서 다를 수 있다. 이러한 '다름'을 '하나'로 통일해 나가는 과정이 QA라고 느꼈다. 그래서 어렵다. 정말 힘들다. 자칫하다 감정이 상할 수 있다. 솔직히 하기 싫다.
그러나 어차피 맞아야 할 매는 최대한 효율적으로 맞아야 한다고 생각한다. 총대 멘 사람(대체로 PM)이 팀원들에게 명확한 가이드를 제공해서 서로 업무가 겹치거나 누락되는 일이 없도록 해야 한다. 그만큼 부담스럽지만 내가 짠 시스템 안에 팀원들이 유기적으로 활동하며 업무 진행도가 올라가는 것을 보는 것만큼 뿌듯하고 보람찬 게 없다.
일에는 크게 두 종류, 해야 할 일(하기 싫음)과 하고 싶은 일이 있다. QA는 나에게 있어서 해야 할 일이다. 해야 할 일을 미리 다 해 놓으면 나중엔 여유를 갖고 하고 싶은 일을 할 수 있다. 서비스 런칭 전, 우리가 QA에서 고통을 많이 받을수록 사용자 편의성과 UX 퀄리티는 비례해서 상승한다고 생각한다. 이러한 사명감 덕분에 팀원 모두가 힘을 모아 프로젝트에 매진할 수 있었으며 결론적으로 QA를 성공적으로 마칠 수 있었다.
이 명언이 앱 개발에도 통할 줄이야...