Quality Assurence, 사전적 정의로는 성능 보장입니다. 조금 더 의미를 덧붙이면 앱 성능 극대화입니다.
앱외주를 주거나 자체 개발을 할 때 테스트 및 검수과정은 필수입니다.
설계 단계에서 상호 간에 픽스한 기획 문건을 가지고 제대로 기능이 구동되는 지 점검해 보는 것입니다.

그러나 기획 플로우 대로 개발이 진행된다 해도 양자가 생각하는 결과물의 완성도에는 큰 차이가 생깁니다.
기획자는 벤치마킹할 앱을 선정하고 차별화 기능을 얹어서 출시하려고 합니다. 기존 앱보다 더욱 더 좋은 성능을 내야 합니다. 
그렇지 않고서는 시장에서 좋은 반응을 보일 수 없기 때문입니다. 

반대로 개발자나 수주사들은 구현의 기능에만 초점을 맞춥니다. 제공받은 가이드대로 충실히 구현했음을 강조하며
추가 작업을 꺼립니다. 눈으로 보지 않는 것을 기획하고 개발하기 때문에 산출물을 보고 기획자가 느껴지는 주관적인 감정은 개발자로써는 도무지 채워주기가 힘들다고 생각하기 때문입니다.

기획 안을 들고 개발기간과 개발가를 산정합니다. 
그렇기 때문에 모든 계약 이행에 관한 기준은 최초 기획안이 되어 버립니다. 
사람의 인지능력에는 한계가 있기 마련입니다. 앞으로 일어날 일을 빠짐없이 기획으로 확정한 다는 것은 불가능에 가깝습니다. 
이런 한계를 줄이는 데 QA라는 과정이 필요합니다.

QA 단계에 오게되면 대부분 산출물의 모습이 드러납니다.
정상적으로 단위별 테스트 -> 종합 테스트 -> 인수 테스트를 거치면서 기능에 관한 문제를 인지하고 개선작업이 대부분 완료됩니다.
그러나 시장상황은 변하기 마련입니다. 기획자는 생각이 달라진 것에 대해 기능변경을 요하거나 기능에 대해 성능을 높여줄 것을 요구합니다. 그러나 개발사들은 계약을 충실히 이행하는 데 초점을 맞추려고 하기 때문에 이런 요구를 쉽게 받아들이지 않습니다.

요구사항 전달 -> 기획안 픽스 -> 기능 구현 -> 검수 라는 절차를 거치는 것이  통상 외주개발 과정입니다. 
여기에 검수 후 QA라는 과정을 넣어 개발의 완성도를 높일 수 있는 기간을 확보해야 합니다.

즉 계약서에 QA과정을 산입하고 충분히 기간과 견적가를 보장해 주는 것입니다.
이렇게 되면 양자 모두 최초 기획안에 집착하지 않습니다. 
기획자는 변경가능성에 대해 사전에 인지하고 개발과정을 관리할 수 있으며, 개발자는 사후에 기능이 변경되는 것을 대비를 하며
개발을 진행할 수 있습니다.

딱 짜여진 계약사항에만 묶이는 외주개발은 시시각각 변하는 시장상황에 능동적으로 대처할 수 없습니다. 앱QA를 적극적으로 활용하면 보다 시장상황에 변하에 대비하여 보다 완성도 높은 개발물을 산출하실 수 있을 것입니다. 

QA와 테스트를 가장 중요시 여기는 agile개발방식과 scrum방식에 대해 다음 기회에 보다 자세한 내용으로 포스팅 하도록 하겠습니다.