Overview

QA담당으로 입사하자마자 12월 21일, 22차 업데이트를 위한 앱 QA를 진행했습니다. QA는 이전 직장에서도 꾸준히 했는데도 아직까지 적응하기 어렵습니다. 그렇게 확인을 많이 하는데 오류는 왜 배포 후에 보이는 걸까요.

22차 QA 한줄 요약: 뫼비우스의 QA

QA담당자의 카운트다운은 기획이 완료된 SB를 참고하여 TC를 수정하는 것부터 시작됩니다. 물론 이전의 다른 과정들도 중요합니다만 이때부터는 마음속에 폭풍전야의 전운이 돌기 시작합니다. TC를 수정하는 순간 시트를 통째로 머릿속에 외워야 합니다. Depth 구성이나 QA해야할 내용을 담당자가 미리 파악하지 못한다면 테스트 도중 쏟아지는 문의사항들을 감당하지 못하기 때문이지요.

어떤 문의사항이냐고요? 이것을 설명하려면 브랜디의 QA과정을 먼저 설명드려야 할 것 같습니다. 브랜디의 QA는 내부 테스트와 외부 테스트로 구분되어 있습니다. 내부 테스트는 R&D본부의 서비스팀에서 1차 개발이 완료된 Android, iOS 버전의 앱을 검증합니다. 반면 외부 테스트는 브랜디 전체 직원들이 모여 앱을 검증합니다. 개발자가 아닌 사용자 입장에서 QA가 진행되다 보니 수많은 질문들을 마주합니다.

“이건 왜 이럴까요?”
“꼭 이래야만 할까요?”
“이상한 것 같은데요.”

그러나, QA담당의 책무를 다하기 위해 이를 꽉 무는 일이 있더라도 친절하게 답변합니다. 좋은 앱을 위해 모두가 노력하는 거니까요. 게다가 QA전문 회사에 다니면서 여러 프로젝트를 경험해봤지만, 회사 직원 전체가 배포 전에 테스트하는 게 굉장히 좋은 과정이라고 느껴졌습니다. 개발자가 아닌 고객의 관점에서 품질을 높이겠다는 회사의 방향을 엿볼 수 있었기 때문입니다.

사실 이렇게 꼼꼼한 과정을 거쳐도 완벽한 테스트는 없습니다. QA담당은 지속적으로 테스트를 해야 합니다. 그렇기 때문에 입사 후 처음으로 경험했던 브랜디의 QA테스트는 무사히 마쳤지만 아직도 현재진행형이기도 합니다. 내부, 외부 테스트 때 나온 결함을 Android와 iOS개발자에게 직접 전하고, 다시 테스트를 진행하고 있습니다.

Conclusion

QA 담당자로서 첫 번째로 중요한 업무는 QA프로세스의 정립입니다. 브랜디는 스타트업 회사이기 때문에 QA프로세스의 완성도가 아직 부족합니다. (제가 입사한 이유이기도 합니다.) 두 번째로는 JIRA(BTS) 도입으로 이슈관리의 개념부터 만드는 것도 목표 중에 하나로 생각하고 있습니다. JIRA가 있으면 소스코드 관리, 이슈 관리, 빌드, 프로젝트 관리 등의 효과를 얻을 수 있는데 특히 이슈관리(버그추적) 시스템이 도입되면 신세계가 열립니다.

JIRA이슈관리 시스템은 이슈를 쉽게 조회할 수 있고, 저장된 속성을 이용해 통계자료까지 얻을 수 있습니다. 이슈 형태를 이용한 검색도 가능하기 때문에 이전에 발생했던 이슈를 쉽게 찾아볼 수 있습니다. (브랜디를 포함해 이슈관리 시스템을 이용하지 않는 회사가 많습니다만… 여기에 글을 쓴 이상 제가 해야겠지요.) 또한 다른 개발자들과 함께 피, 땀, 눈물을 쏟아내다 보면 selenuim, appium을 이용한 자동화 테스트 도입도 할 수 있을 거라 생각합니다.

QA와 관련된 자세한 이야기는 앞으로도 꾸준히 공유하겠습니다. 기대해주세요.

글
김치영 팀장 | QA팀
kimcy@brandi.co.kr

브랜디, 오직 예쁜 옷만