QA(Quality Assurance)란?
우리의 일상인 QA, 정확히 무엇일까?
IT 프로덕트를 개발하고 있는 팀에 속해있다면 누구나 한 번쯤 QA를 해보셨을 거예요.
특히 저희 팀큐에잉처럼 1-2주의 스프린트로 운영되는 팀이라면 QA는 거의 일상이지 않을까 싶어요.
이렇게 우리의 일상이 된 QA란 정확히 무엇일까요?
이번에는 QA(Quality Assurance)의 정의에 대해서 알아보려고 해요. (이 글은 관련 해외 아티클들을 번역해 편집한 글입니다!)
소프트웨어 QA는 개발 주기에서 아주 중요한 역할을 하죠. 기업은 증가하는 수요에 부응하기 위해 서비스를 만들다 보면 기계적으로 생산하게 될 때가 있는데, 서비스 배포 시 그 서비스가 내가 원하는 방향대로 작동하는지 체크하는 것이 중요해요. 유저들은 그저 다양한 소프트웨어 선택지뿐만 아니라 품질 높은 제품을 원하기 때문이죠.
소프트웨어 품질 보증이란?
소프트웨어 품질 보증(Software Quality Assurance)이란 프로덕트의 품질이 팀내에서 미리 정의한 기준을 따르는지 확인하기 위한 방법론이에요.
이러한 QA는 단순 개발 단계뿐만 아니라, 프로덕트 전반적인 PLC(Product Life Cycle)와 병행하여 이루어 져야 해요. 팀원들은 프로덕트의 내외부 모든 부분이 특정 품질 기준을 충족시키는지 확인해야 해요. 이를 통해 QA는 프로덕트의 이슈가 미래에 더 큰 문제가 되기 전에 미리 평가하고 방지해주는 역할을 하죠.
QA 시 평가해야 할 것들
- 외부적으로는 효율성, 신뢰성, 유지비용을 평가한다
- 내부적으로는 프로덕트의 구조, 복잡성, 가독성, 유연성, 테스트 가능성, 그리고 개발자들이 따르던 코딩 관행(practices)이 포함된다
QA 실행 단계
QA를 효율적으로 하기 위해선, 구조화된 단계에 따라 차근차근 준비하는 것이 중요해요.
1. 품질 기준 정의하기
본격적인 QA 진행 전, 먼저 우리 프로덕트가 만족시켜야 할 팀 내 퀄리티 기준을 분명히 정의해요. 프로덕트에 대한 요구사항과 수용 가능 기준, 그리고 성능 측정 기준 등을 정의할 수 있죠. 단 이 기준들은 개발팀, 운영 팀, 유저들을 포함한 모든 이해관계자들이 동의할 수 있을 만한 기준이어야 해요.
2. QA 작업 기획하기
품질 기준을 정했다면, 이제 QA의 구체적인 작업을 기획해요. 여기에는 리뷰와 테스트 그리고 문서화 작업이 포함될 수 있죠. 주로 많은 팀이 이 단계에서 테스트 케이스와 QA 시트를 작성하기도 하죠. 테스트 시 포함되어야 할 시나리오들을 정리해 두고, 각 작업을 누가 담당하는지, 수행되어야 할 기한은 언제인지 등의 정보를 구체적으로 담는 것이 중요해요.
3. 테스트 진행
준비가 모두 끝났다면 이제 본격적으로 QA를 진행할 차례죠. QA 전담 팀이 따로 있다면 해당 팀에게 테스트 케이스와 같은 체크리스트를 전달하거나, 따로 QA 팀이 없다면 팀원들이 각자 태스크를 맡아 수행하게 돼요.
QA에도 다양한 종류가 있는데, 유닛 테스트, 통합 테스트, 시스템 테스트, 디자인 테스트, 기능 및 성능 테스트, 피쳐에 대한 일반적인 유효성 테스트 등.. 다양한 방식으로 진행할 수 있어요.
이전 단계에서 정리한 테스트 케이스를 먼저 각각 수행한 후, 체크리스트에서 각 태스크의 통과와 불통과를 판단해요. 불통과인 것들은 개발자들에게 넘겨져 개선 작업에 들어가겠죠. 테스트 케이스 말고도 예상치 못한 버그를 잡기 위해서는 다양하 방식으로 서비스를 사용해 보는 방법도 있어요. 이슈가 발생할 수 있을 만한 환경 및 경로라던가, 예외 처리에서 생략되었을 수 있을 만한 사소한 부분들을 테스트 해 보는 것도 방법이 될 수 있어요.
4. 결과 분석 및 지속적인 개선
개발자들은 전달 받은 이슈들의 로그 데이터를 분석하며 개선 작업에 들어가요. 개선이 완료되면 다시 한번 전체적으로 서비스를 돌려보고 문제가 없는지 최종적으로 확인 후 배포해요. 배포 후 끝이 아니라 QA 결과를 분석하는 것도 도움이 되는데, 각 주기마다 오류 발생 빈도와 개선 작업 진행률을 체크하면 전체적인 서비스 관리 현황을 파악할 수 있어요. QA 자체를 꼼꼼히 진행하는 것도 중요하지만, 그 전에 디자인 및 개발 단계에서 이슈 발생률을 줄이는 것이 더 중요하기 때문이죠. QA 결과를 분석하고 회고하는 시간을 가지면 서비스 품질을 더 철저히 괸리할 수 있겠죠.
많은 스타트업이 리소스 부족으로 효율적인 QA를 진행하는 데 어려움이 있어요. 그러다 보니 조기에 문제를 발견하고 해결하는 것보다 빌딩 과정에서 뒤늦게 처리하는 일도 비일비재하죠. 그렇게 결국 들어가는 리소스 비용이 더 증가하고 유저들은 불안정한 서비스를 이용하게 돼요. 이를 방지하기 위해서라도 QA 프로세스를 구축하는 것이 스타트업의 리소스를 더 아끼고, 모든 요구사항을 만족하는 신뢰성 있는 프로덕트를 만드는 데 더움이 될 수 있어요.
https://www.turing.com/blog/software-quality-assurance-and-its-importance/
