애플리케이션 QA 침투기

페이스북 친구인 안영회님이 얼마전에 함께 했던 프로젝트의 어플리케이션 QA를 회고해 주셨습니다. 아래 내용은 페이스북에 올려 준 전문입니다.

나에겐 두 번의 훌륭한 QA 팀과 협업 경험이 있다. 첫번째는 한국에서 우리 팀에 QA 리더가 최문석 님일 때 모바일 애플리케이션에 대한 QA를 진행했던 경험인데... 이 글을 보니 남 얘기 같지가 않다. 구조 변경에 대한 두려움이 개발자들을 움츠러들게 하는 상황에서 신뢰를 형성하고 나니 과하게(?) 의지하는 형상이 문제가 되었던 경험도 있고, 오래 함께 일하니 기획회의 초반에 함께 참여해서 시너지를 냈던 경험이 있죠. 최문석 님이 읽으면 더 할말이 많을텐데. 이 참에 popit에 글 하나 쓰세요! (QA 관련 한글 컨텐츠는 생소할 정도로 드무니까요.) 두번째는 중국에서 현재 겪는 경험인데, 백화점 PoS 등과 같이 무선 네트워크와 물리적 장비 등의 특수성 때문에 QA들이 꼭 필요한 서비스 환경이죠. 그런데, 여기서 흥미로운 점은 QA들이 직무를 바꾸는 도전을 한다는 점입니다. 어떤 친구들은 gitlab이나 jenkins를 돌리고, slack과 연결하는 작업을 하는 수준도 있지만, 일부는 Product Owner 역할로 전환하는 모습도 보여줍니다. 심지어는 (개발을 전혀 모르던 친구가) python 을 배워 누군가 먼저 만든 tensorflow 기반 프로그램을 직접 고치고 있구요. https://www.facebook.com/permalink.php?story_fbid=189735928301409&id=100017950085523

두번째 케이스가 멋져서 관련된 내용을 정리해 보고 싶지만 이번에는 수행했던 첫번째 케이스를 가지고 짧게 내용을 정리해 봤습니다.

QA팀의 시작

이 프로젝트를 진행하기 직전에는 담당 서비스의 문제나 품질 수준을 가늠할 수 있는 정보와 QA 절차 그리고 개발한 경험이 있었지만, 이 프로젝트에서는 애플리케이션의 상태나 현황이나 운영 정보가 없었던 상태였습니다. 더군다나 자사 서비스가 아닌 상황이라서 우선 테스팅을 수행할 수 있는 QA팀을 꾸리고, 수행했던 절차에 따라 애플리케이션 개발에 참여한다는 전략(?)으로 결정하게 됩니다.

QA팀의 과제

그런데 프로젝트 현장의 이해관계자들이 애플리케이션 테스팅을 수행하는 QA팀과의 협업을 익숙해하지 않는다는 것을 인지하게 되었는데, 이러한 선입견을 극복해야 하는 과제가 QA팀에게 주어졌어요.

QA팀의 역량

개발 현장의 개발 성숙도가 높고 서비스 품질의 책임 의식이 높은 조직에서는 품질 책임이 담당 개발자나 개발팀에 있지만 모든 개발팀이나 개발자의 수준이 그에 미칠 수는 없기 때문에 품질을 보증해 줄 수 있는 역할이 필요하고, 이러한 QA팀은 서비스의 품질 상태와 기준을 제시할 수 있어야 한다는 생각으로 QA를 진행했습니다. 서비스 품질을 높여야 하는 필요성과 당위성을 사업팀이 먼저 인지하고 다양한 형태로 스폰쉽을 주면서 협업할 수 있는 조직 구성과 프로세스를 갖추는 것이 기본적으로 먼저 필요하긴 하죠~

QA팀의 모순

일단 여기서는 QA팀이 개발하고 있는 서비스의 품질을 보증하는 역할에 최대한 집중하기로 했고, 개발자들의 모듈 단위 테스트부터 통합 테스트까지 수행했어요. 고객 인수 테스트도 QA팀의 주도 아래 진행했습니다. 이러한 테스트를 하려면 사전에 테스트 케이스 준비해야 하고, 테스트하면 결함 등록해야 하고 관리해야 하는 등의 QA팀 업무 부담이 상당했었습니다. 그런데 개발자가 수행해야 하는 모듈 단위 테스트까지를 함께 수행하다 보니 QA 팀에 과도한(?) 의지가 발생하는 모순이 생기기도 했어요.

QA 침투 전략

부족한 개발 일정이나 요구사항 변경 등으로 인해 개발자 검증의 의무와 책임이 소홀해질 수밖에 없었고, 개발자 스스로의 결함이나, 예상하지 못한 상황을 파악하고 테스팅 환경 등을 구성해야 하는 것에는 한계가 있을 수밖에 없었습니다. 부족한 개발 일정이라는 것을 알고 있었고, 서비스 전반을 파악해 나가고 있던 QA 팀원들은 업무 담당자들이나 현업 그리고 개발자들을 향한 QA 침투를 시도해 나갔습니다. 역설적이게도 이러한 침투 전략 때문에 생긴 QA팀의 모순된 상황은 QA팀이 기획 초기부터 함께 할 수 있게 하는 시금석이 되었고, 이해관계자들에게도 QA팀의 필요성을 각인시킬 수 있는 계기가 되었습니다.

투명화와 추적성

이때 주요하게 염두한 것이 투명화와 추적성이었는데, 투명화를 통해서는 내외부의 모든 이해관계자들에게 QA팀이 동작하고 있다는 사실과 서비스 개발 상황, 품질 상태를 전달하고자 했습니다. 추적성을 통해서는 요구사항을 고객과 기획자에게 전달하고, 결함은 개발자와 디자이너에게 각각 전달해서 주체와 상태를 분명하게 이관해 주고자 했습니다. 여러 시행착오들과 미진함에도 불구하고 애플리케이션 QA의 필요성과 효과가 현장이나 동료들에게 전파된 것은 큰 성과였습니다.

QA 조직의 필요성

IT 서비스 사업 초기부터 서비스의 품질 향상을 목표로 하지 않는 이상에야 품질이 사업 초기의 화두가 되기는 어렵습니다. 특히나 IT 서비스를 구성하고 있는 소프트웨어는 눈에 직접 보이는 것이 아니고, 전적으로 사람이 서비스를 기획하고 디자인하고 개발하기 때문에 이들이 생각하지 못했거나 알 수 없는 품질 저해 요소들이 곳곳에 존재할 수밖에 없습니다. IT 서비스의 출시 시기를 전략적으로 판단할 경우에는 그 판단 기준에 맞춘 품질 수준으로 운영되기도 합니다.

IT 서비스의 빠른 출시와 함께 중요한 것이 서비스 품질인데, 이 양자를 기존 프레임이나 예산으로 모두 확보하는 것은 현실적으로 불가능합니다. IT 기술의 발전과 소비자 수준의 향상은 기술과 품질의 기대치도 함께 끌어올리고 있고, 이를 구성하고 있는 소프트웨어의 복잡성과 불확실성도 함께 급증하고 있기 때문에 이러한 위상 변화에 적합한 조직 구성과 예산을 책정해서 운영해야 합니다.

개발팀 내부의 개발 성숙도는 편차를 가지고 있을 수밖에 없고, 모든 개발자가 품질을 고려하거나 품질을 측정할 수 있지는 않습니다. 그렇다고 서비스의 품질을 포기할 수 없기 때문에 제3자가 테스팅을 할 수 있게 하는 등의 QA 할 수 있는 환경과 조직이 IT 개발 현장에 적극적이면서도 점진적으로 확보되어 가기를 바랍니다.