QA(Quality Assurance) 목록 작성 중…

빠르면 다음 주에 오픈할 기능 때문에 QA(Quality Assurance) 목록을 작성하고 있습니다. 이달 초에 오픈한 새글쓰기개편에서도 기능 오픈 전에도 QA를 거쳤는데 사실 QA에 대한 경험이 없다보니 서비스 오픈 후에 사용자들이 리포팅한 버그들이 수두룩합니다. QA가 잘 되었다면 사용자들이 겪을 불편을 꽤 많이 해소할 수 있었을텐데요.
QA를 해보니 이런걸 느끼겠더군요.
QA목록을 작성하는 사람은 QA를 하는 사람들이 명확히 자신이 해야하는 테스트의 내용을 알 수 있도록 QA항목을 작성해야합니다. 자기 혼자 작성하고 자기 혼자 테스트 하는거라면 상관없지만 다른 사람은 자신이 작성한 리스트를 가지고 테스트를 해야 하기 때문에 의미가 명확하지 않으면 테스트를 할 수 없거나 잘못된 테스트를 수행할 수 있습니다. 예를 들자면 이런 항목이죠.

“계속 버튼을 눌렀을 때 기존 목록은 잘 나오는가?”

“계속”이라는 버튼을 누르는 것인지, 아니면 어느 버튼을 한번 누른 채로 있는 것인지, 아니면 한번 누르고 또 누르고 또 누르고 또 누르는 것인지 모호합니다. 기존 목록이 뭔지도 모르겠구요. 어떻게 나와야 “잘~”나오는 것인지도 알 수 없지요. 원래는 나와야 하는 목록의 가장 최근 항목 한개는 굵은 글씨로 표시되어야 하는 것이 맞는데 그냥 보통 글씨 모양으로 목록이 나와도 테스트를 하는 사람은 “아~ 잘 나오는구나. OK!” 라고 해당 QA항목이 성공적으로 동작했다고 보고한다는 것입니다.
버그가 생기는 이유중의 하나는 커뮤니케이션을 하지 않았거나 잘못된 커뮤니케이션을 했기 때문이라고 하더군요. (Why does software have bugs? ) 그런데 그 버그를 잡기위해 하는 QA에서조차 스스로 그 버그를 재현하고 있을 수 있다고 하니 이놈의 “커뮤니케이션 문제”는 언제나 생기는, 가장 중요한 문제인 듯 합니다.
어제 밤에 QA리스트 만드는걸로 머리 싸매다가 Tong팀의 QA 리스트의 샘플을 구해서 봤습니다. (sepia 과장님 고맙습니다.^^) 저는 통을 쓰지 않는데도 QA리스트의 항목을 보고나니까 마치 QA테스트를 할 수 있을것 같은 자신감이 들더군요. 짧은 항목은 10글자 내외짜리도 있고 긴 항목도 두 줄을 넘기지 않지만 명확하게 테스트를 해야 할 항목이 명시되어 있었습니다. “[대상A]가 [상황A 또는 동작A]일 때 [대상B]가 [동작B]를 하는가?”처럼 오해의 소지가 없이 명확한 테스트를 할 수 있도록 항목이 잘 짜여져 있었습니다. 각 항목이 포함된 기능분류도 잘 되어 있었구요. 해당 항목의 테스트를 진행할 사람이 명시되어 있었고, 처리여부(○,△,Ⅹ)와 코멘트를 입력할 수 있도록 되어 있더군요. 이글루스가 했던 방법과는 조금 차이가 있던게 저희는 하나의 QA 리스트를 가지고 테스트 참여하는 사람은 전체 항목을 다 테스트를 했었습니다. 한명은 IE6, 한명은 IE7, 한명은 Firefox 이렇게 브라우저별로 나누어 전체 항목을 테스트 했는데 이런 차이는 서비스별로 최적화의 영역이 아닐까 싶네요.
QA를 시작하고 서비스를 오픈하는데까지는 QA목록을 만드는 것보다 100배는 골치아픈 일이 생기고 복잡,미묘한 기류를 헤처 나가야 합니다. 그렇지만 당장의 서비스오픈날짜에 쫒겨 그 힘든 과정을 회피하거나 포기한다면 서비스 사용자들이 그 불편함과 고통을 겪게 되고 서비스 제공자는 결국 댓가를 치뤄야겠지요.
동작은 하는가, 하려고 하는 모든 기능이 제대로 되는가, 혹시 잘못 동작할 우려는 없는가에 대한 테스트는 각각 50점짜리,80점짜리, 100점짜리 서비스가 되느냐 마느냐의 차이같습니다.
QA에 대해 참고할만한 사이트나 책이 있으면 소개도 부탁드릴게요.