본문 바로가기

QA=테스트라는 잘못된 인식과 그리고 마성의 QA

하이지스 발행일 : 2021-11-18

QA활동에 대해서


소프트웨어 QA라고 하면 대부분 생각하는 것이 테스트라고 생각을 하는 경향이 있다 

QA엔지니어라고 하면서 실상은 테스트 엔지니어에 불과한 현실이다.

QA팀이라고 생각하면 대부분 테스트를 하는 부서라고 생각을 한다. 맞을 수 도 틀릴 수 도 있다. 통싱 적으로 개발팀에서 자체 개발 테스트를 하지 않고 QA팀에서 테스트를 진행하고 QA팀에서 테스트가 정상적으로 진행되었다면 QA Off라고도 한다 QA 하면 검증을 하는 업무라고 많이들 이야기를 한다. 반복적인 테스트와 부화적인 스트레스 테스트를 진행하여 통과가 되어야 QA라고 하는데 이건 잘 보면 QC활동이다

QA에 대한 교육이나 컨퍼런스를 찾아보면 QA에 대한 교육은 없고 테스팅에 대한 이론과 교육만 존재한다.

ISO 29119 표준 어디에도 QA= TEST라는말은 없다. 대체 이 오해는 왜 생긴 것 일까?

ISO 29119 1장부터3장까지에는 QA 테스트라는말은없다

QA는 예방활동이다.

QA에 활동에 테스트가 포함되긴 하지만 절대로 QA=TEST가 되서는 안 된다.

기능에 대한 오류가 발생했을 때는 QA제대로 했어? 가 아니라 테스트 제대로 했어?로 말해야 한다 

QA는 리스트 발생에 대한 인자에 대한 예방하는 활동이므로 QA기간이라고 하면

테스트를 포함하여 요구사항 파악하고 테스트를 계획하고 테스트를 수행하고 리포트를 하고

배포까지의 일련의 과정을 QA기간이라고 해야 한다.

단순하게 테스트 기간을 QA기간으로 생각하고 있는지 다시 한번 생각해봐야 한다.

QA는 테스트에 대한 환경, 일정관리 , 이슈에 대한 관리 , 테스트 수행, 테스트 결과보고, 배포까지의 과정을 다루는

큰 툴을 다루고 있고 단순한 테스트업무를 하지않는다.

다시말해 테스트는 QA라고하면 안된다.

테스트는 테스터의 영역이다

테스터나 테스터 엔지니어는 주어진 테스트를 수행하고 이슈를 생성하고보고하는데 그치거나 테스트 일정관리까만 관여하는게 통상적이다. 이건 QA가 아니라 QC의 영역이고 Test Engieneer이다.

다시한번말하지만 QA는 테스트야라고 한 단어로 끝내는게 아니다.

 


테스트를 잘하면 품질이 좋아질까? 

테스트에는 수 많은 테스트 기법과 방법과 방법론들이 존재한다.

테스트는 고객관점 사용자 관점에서 바라보고 테스트를진행하고

QA활동은 고객관점 테스트와 요구사항기반으로 개발이되었지까지의 확인을 하는 과정이다.

단순하게 이슈를 많이 찾아서 리포팅한다고 해서 그에 대한 테스트 커버리지가 확보된다고 할 수 없다.

소프트웨어 테스팅 활동은 소프트웨어의 결함을 찾아내는 활동으로 품질을 보증하는 활동이 아니다.소프트웨어 개발과 소프트웨어 테스팅에서 가장 먼저 시행되는 과정은 요구사항 파악이다.요구사항과 기획의도를 파악하고 기획서문서를 기반으로 되었는지 테스트를 하고 테스트를하면서 리포팅을 하고 결과에 따라 위험인자와 이슈원인과 방지안을 찾는게 QA이다.단순한 테스팅은 Test Engieneer의 영역이지 QA의 영역에서 거리가 있다.그래서 요구사항 기반으로 개발이되었는지 부터 분석하는게 QA의 업무이기도 하다. 물론 프로세스가 에자일기반으로 돌아간다면 설계단계부터 기획 테스트를 돌면서 스프린트로 돌아가기때문에 다른 이야기지만. 그건 나중에 다루도록 하고 

정말 1부터 100까지 모든 일련의 과정을 문서화시키는 곳은 거이 없을 것 이겠지만

테스터도 동일하게 역량에 따라 요구사항명세서에 기재된 기능에 따라 테스트케이스를 역으로 설계하고

이 기능이 만족하는지 테스트 케이스를 명세기반으로 설계를 할 수 있다.

QA는 테스트에 대한 전반적인 일정일 관리하고 테스트에 소요되는 리스크를 분석하고

이뤄진 테스트에 대해서 중요한이슈인지에 대해 판별을 내리는 과정이고

단순한 테스트의 활동은 QA로 분류해서는 안된다.

많은 기업들이 QA를 Test로 오해하고 있고 이게 대중화가 되면서 QA가 테스트가 되버린 거짓말같은 세상이 되었다.

내가 QA라면 과연 테스트만 위주로 사고를 생각했는지를 생각하면 된다.

테스트검증위주의 사고에서 벗어나야한다.


테스트의 설계 

 

명세기반 테스트케이스를 작성할때 요구사항 명세서를 참고하기도 한다.

 

요구사항에 적힌 내용을 기반으로 테스트케이스를 설계를 한다.

명세기반으로 테스트케이스를 작성할 수 도 있지만 스토리보드(기획문서)를 기반으로 한 테스트케이스를 작성 할 수도있다 

테스트케이스를 작성을 하고 테스트를 수행하고 리포트를 작성한

 

자, 그러면 테스터도 Testcase를 작성하는데 QA는 안하냐고?

QA도 Testcase를 쓰는경우도 있다.

단지 QA는 테스트 중심의 사고가 아니라 품질, 이슈에 대한 프로세스에 중심되어야한다. 

QA는 테스트의효율성도 따져야하지만, QC를 수행하는 인력관리를 포함하며

품질의 목표에 달성하는 지, 이슈에 대한 우선순위 산정을 해야한다. 

리스크 분석과 이슈 분석을 해서 좋은 결과를 생각해야 한다 

더 좋은 테스터가 되기 위해서는 테스트를 어떻게 효율적인가를 생각해야하고

더 좋은 QA는 이슈를 찾는 것보다는 이슈를 어떻게 관리할 것인가를생각해야한다.

 

 

 

댓글