QA의 진짜 목적
QA를 해야 할 때, 여러분은 어떤 기분이 드시나요?
저희 팀큐에잉도 매주 업데이트를 하면서 QA를 자주 진행하고 있는데요, 그 과정 자체가 오래 걸리고 번거롭다 보니 귀찮은 기분이 어쩔 수 없이 들더라구요. 인터뷰 하면서 많은 분들도 같은 생각을 하고 계시다는 걸 알게 되었어요.
이렇게나 번거로운 과정인데, 우리는 왜 QA를 해야 할까요? 이번에는 QA가 프로덕트 빌딩에 꼭 필요한 이유에 대해서 이야기 해보려 해요.
가장 당연한 이유 중 하나죠. 바로 지속적인 프로덕트 품질 개선 문화를 형성할 수 있게 된다는 점인데요.
QA는 프로덕트를 배포하기 전 에러를 발견하고 해결하는 과정이죠. 예상 유저 시나리오와 그 외의 케이스에서 발견될 수 있는 오류를 해결함으로써 유저는 더 높은 품질과 사용성의 서비스를 이용할 수 있어요.
이러한 QA를 정기적으로 프로세스화하면, 서비스는 꾸준히 발전할 수밖에 없죠! 이렇게 배포전 QA를 거치는 프로세스를 만들어 지속적인 개선 문화를 만들 수 있어요.
만약 서비스 배포 전에 발견하지 못한 이슈가 있다면 어떨까요? 지금 당장 고치지 못했다면 언젠가 꼭 해결해야 하는 순간이 오겠죠. QA는 이러한 이슈를 사전에 발견함으로써, 뒤늦게 유지보수 단계에서 버그를 고치는 데 드는 비용을 절약할 수 있게 돼요. 초기에 놓친 이슈를 나중에 더 많은 기능이 붙은 상태에서 해결하려고 하면 더 큰 리소스가 들게 돼요. 어떤 다른 기능의 로직과 얽혀있을 지 모르기 때문이죠. 국방 소프트웨어 공학의 저널인 Cross Talk에서는 설계 단계에서 에러를 고치는 것보다 이미 프로덕션 단계에 있을 때 에러를 고치는 것이 150배의 시간이 더 든다고 해요. 따라서 초기에 꼼꼼한 QA를 통해, 이렇게 커다란 눈덩이로 불어날 수 있는 이슈는 바로 조치하는 것이 좋아요.
QA는 팀의 동기부여 역할도 할 수 있어요. QA 과정에 많은 팀원이 참여할수록 그 효과도 커지죠.
함께 QA를 진행하면서 팀원들은 자신의 프로덕트에 대해 더 깊이 이해할 수 있게 돼요. 프로덕트의 모든 기능과 시나리오를 직접 이용해보는 것이기 때문에, 유저의 관점에서 우리 프로덕트를 바라볼 수 있는 기회가 되기도 하죠. 그렇게 QA를 하다 보면 우리 프로덕트가 만족시켜야 할 기대 수준과 실제 현재 수준의 간극을 파악할 수 있어요. 결국 팀원 전체가 '앞으로 프로덕트를 이런 방향으로 더 발전시켜야겠구나'를 깨달으면서 동기부여의 기회가 될 수 있죠.
품질 높은 프로덕트는 결국 브랜드 및 기업의 신뢰도 향상으로 이어지죠.
저도 유저로서 여러 서비스를 사용할 때 많이 느끼는 부분인데요, 서비스의 UI가 너무 많이 깨진다거나, 주요한 기능이 제대로 작동하지 않고 끊임없이 오류가 터질 때면 자연스럽게 그 서비스에 대한 신뢰도가 확 떨어지는 것 같아요. 그게 금융이나 보험 서비스라면 더 크리티컬한 문제가 되죠.
품질은 곧 유저의 신뢰를 얻냐 마냐의 문제와 직결되기 때문에 더욱 꼼꼼하고 꾸준한 QA가 필요한 것 같아요.
QA는 프로덕트 품질 자체를 도울 뿐 아니라, 산업내 지켜야 할 표준과 규제에 적합한 서비스가 될 수 있도록 돕기도 해요. 이는 특히 의료, 금융 등 규정을 준수하지 않았을 경우 타격을 크게 입게 되는 서비스에 더욱 중요한 문제죠. QA를 하면서 사용성에 더해 우리 서비스가 현재 산업 표준이 요구하는 사항들을 잘 갖추고 있는지 또한 함께 점검할 수 있어 이에 대비할 수 있어요.
https://testfort.com/blog/qa-qc-testing-the-basics-of-quality-management