소프트웨어 QA - 실무 Q&A

지난 강연회 참석자분들께서 남겨주신 Q&A의 질문 리스트를 살펴보던 중에,

QA로 일하고 계신 분들과 소프트웨어 테스팅이나 품질에 관심 있는 개발자분들의 질문들이 눈에 띄여서 그 중 주요 질문과 질의에 대한 응답을 공유해봅니다.

실무에서 일하고 계신 분들의 공통적인 질문도 될 수 있을 것 같아서 평소 가지고있던 질문에 대한 답변이나 답답함이 해소 될 수 있을 것 같습니다.

----- ❖ ------

Q : QA와 Tester의 가장 큰 차이점이 무엇이라고 생각 하시는지 궁금합니다

A :  품질 관리 역할을 설명할 때, 대개 첨부된 그림과 같이 역할을 시각화하여 설명합니다. 이것은 '사원-대리-과장-차장'으로 나누듯 직급으로 구분되거나, 직무 계층을 나타내는 것이 아닙니다. 
품질을 관리하는 활동과 임무, 책임과 역할의 측면으로 구분한 것으로 이해해야 합니다.

즉, 품질 관리는 '품질 관리(QM), 품질 보증(QA), 품질 제어(QC), Tester' 네가지 측면으로 구성되어있으며 수행하는 업무 범위와 책임에 따라 명칭을 달리 사용하고 있지만, 이 모두는 ‘품질을 검증하고 관리하는 전문가’를 뜻합니다.
각각의 역할에 대한 자세한 내용은 [부트캠프QA편] page.23~에서 다루고 있으니 참고해주시기 바랍니다. 

----

Q : 자사/아웃소싱으로 테스트 조직 근무 환경을 많이 비교하는데 단순히 연봉이나 복지를 제외하고 직무 능력 향상만 놓고 본다면 아웃소싱은 답이 없고 무조건 자사로 가야할까요..?

A : 답을 하기 전, 자사와 아웃소싱의 품질 관리 차이를 먼저 살펴볼께요. 
- 자사 : 소속된 회사에서 서비스하는 제품에 대한 품질을 관리
- 아웃소싱(외주/외부 용역) : 외부의 기업이나 조직과 같은 제 삼자에게 업무(품질 관리)를 위탁해 처리

여기서, 자사에 소속되어있다 하더라도 자사에서 관리되는 품질의 범위와 품질 관리 역할의 책임의 한계에 따라 아웃소싱과 크게 차이가 없는 경우도 존재합니다. 
강연회나 제 책에서도 말씀드렸듯이, QA가 관리하는 품질의 범위는 프로덕트의 기능적 오류를 확인하는 것에만 한정되어있지 않습니다. 
프로덕트 품질, 프로세스에서 수행되는 각 구성원의 작업의 품질, 프로세스 자체 품질, 서비스를 구성하는 연관된 요소들(코드, 서버, 데이터베이스 등)에 대한 관리와 제어 활동, 품질에 영향을 주는 요소들(리스크, 작업자, 시간 등), 테스팅 활동 품질, 프로젝트 진행 중 발생되는 산출물의 품질까지 QA가 관리해야 하는 품질의 범위는 품질에 영향을 주는 모든 요소가 포함됩니다. 

자사에 소속되어 있더라도 프로덕트의 기능적 품질 관리만 수행하거나, 아웃소싱에 소속되어 있더라도 프로덕트 외 프로세스를 설계하고 개선하고, 품질에 영향을 주는 요소를 직접 관리하고 제어하고, 다양한 기술 도구를 활용하여 테스트를 수행할 수 있다면...내가 소속한 기업에 따라 직무 능력이 향상 되는 것은 아닐 것입니다. 이런 경우, 오히려 다양한 기업의 다양한 프로젝트를 경험할 수 있는 장점이 있는 아웃소싱이 직무 능력 향상에 더 유리하겠지요. 반대의 경우라면 당연히 자사로 가야하는 것이 맞구요.
하지만, 대개의 경우 아웃소싱에서 관리하게되는 품질의 범위와 역할이 프로덕트의 기능적 품질관리에 한정되는 경우가 많다보니 '직무 능력 향상'라는 측면만 놓고 봤을때 자사로 가는 것이 낫다고 이야기 하는 것입니다.  

---

Q : 이름있는 기업들 위주 jd를 보면 자동화 도구 사용이 핫한 키워드로 분석했는데요. 예를들어 앱피움을 스터디할때, 환경구축은 했지만 그외에 이걸 어떻게 더 활용할수있는지, 해당 도구가 정말 실무에서 활용되는지 등에 대한 궁금증이 생겼습니다. 추천해주실만한 해결방법이 있을까요?

A : 실무에서 자동화를 도입하는 이유는 여러가지가 있습니다. (1)반복되는 테스트에 투입되는 리소스와 시간이 너무 많다는 문제 인식과 이를 줄이기위한 필요성 또는 요구사항의 발생으로인해, 또는 (2)투입되는 인원 대비 확인해야 할 테스트 범위가 많은 경우 투입 인원 대비 높은 품질을 확보하기 위해서, 또는 (3)테스트 효율화를 위해서, 또는 (3)애자일 프로세스의 도입으로 개발 초기부터 반복적이고 점진적으로 테스트 수행이 필요한 경우...등등 필요성이나 요구사항에 따라 자동화를 도입하는 이유가 달라집니다. 

그리고, 자동화를 도입하는 이유에 따라 활용방법도 달라질 수 있겠지요. 
예를들어, 반복 테스트의 시간과 투입 리소스 비용을 줄이기 위해 자동화를 도입한다면, 리그레션 테스트 / 스모크 테스트 / 개발 테스트 와 같이 테스트 시나리오 상 변화가 크지 않은 반복적인 테스트가 필요한 범위에 자동화를 도입해서 활용할 수 있고, 또는 유지보수 시 변경이나 개선되는 범위와 연관된 기능들에 대한 영향도 확인은 자동화 테스트로 확인하고 테스트 인력은 변경되는 범위만 E2E테스트를 수행하는 것으로 활용할 수 있습니다. 마지막으로, 기능이나 서버의 부하 검증을 위해 데이터를 많이 만들어야 하는 경우(ex) 대량의 주문 건수 유입) 자동화를 활용하여 부하 유입을 줄 수 있습니다. 

이렇게 자동화를 왜 도입하고자 하는지, 어디에 활용하고자 하며 어떤 목적으로 사용할 것인지, 자동화를 위한 명확한 범위 선정, 도입 후 유지보수 계획 등이 명확하게 계획되고 설계되어야 지속적으로 실무에서 활용될 수 있습니다. 호기롭게 자동화를 도입해서 적용하더라도 유지보수가 어렵거나 담당하는 인원이 없으면 무용지물이 되버리기 쉽상이거든요.
자동화를 도입하고자 하는 목적과 자동화 도입으로 해결하고자 하는 문제, 이를 고려한 세부적인 계획과 범위가 잘 설계된 경우 실무에서도 활용도가 높고 유용하게 사용되고 있습니다. 

---

Q : qa활동에서 가장 중요하게 생각하시는 qa 지표 3가지가 궁굼합니다. (협업 부서와의 커뮤니케이션중 공유할 지표)    

A : 협업부서로 공유되는 품질 지표에 중점을 둔다면, 
(1) 담당QA의 품질에 대한 의견
     : 출시 가능 여부에 대한 의견 공유, 프로젝트 진행 중 이슈와 품질 검증 활동 중 가장 주요하게

공유되어야 하거나 또는 문제 해결 방안이 필요한 부분에 대한 내용 공유
(2) 테스트 기간 동안 진행된 테스트 활동 기록에 대한 지표와 결과 공유 
     : 제품의 현재 품질 상태, 테스트 수행 진척도(계획 대비 차이점), 등록된 버그 처리율, 테스트

커버리지 감소 사유(실행할 수 없거나 실패된 테스트 케이스와 이유), 새롭게 식별되거나

처리되지 못한 리스크와 결함, 합의된 known-issue 등
(3) 프로젝트 진행에 차질을 발생시키는 요인들
     : 일정, 인적요인, 각 작업단계에서 산출되는 결과물의 품질, 품질 현황을 파악하기 어렵게하는

위험요인 등 프로젝트 진행 관련 이슈 및 논의나 협의가 필요한 내용 공유
([부트캠프QA편]의 267페이지를 참고)

---

Q : 프로젝트 진행 단계에서는 유관부서 요구사항과 개발 구조 변경 그리고 스펙아웃이 끝없이 이루어지는데 이런 상황에서 QA는 어찌 대처해야 할까요?

A : 가장 기초적인 뿌리부터 수정을 했으면 하신다면, 프로세스를 점검해보심이 좋을 것 같습니다. 회사 내부에 프로세스가 있는지, 프로세스가 있다면 어떤 절차로 진행되고 각 절차에서 완료되는 결과물의 품질 기준과 프로세스 정책(ex)프로젝트 진행 중 변경사항은 없어야 한다와 같은 사내에서 합의한 정책)이 있는지 살펴보시고 프로세스가 없다면 정립을 하셔야 할것같고, 있다면 개선을 해야할 것 같습니다. 
예를들어, 폭포수 모델에 기반한 프로세스를 도입한다면 진행 단계에서는 변경사항이 없어야 합니다. 완벽한 계획이 수립되어야 각 작업의 진행이 승인되고, 승인된 이후에 작업이 진행되어야 합니다. 폭포수 모델에 기반한 프로세스가 도입된다면 말씀하신 문제들이 어느정도 해소가 되겠지요. 

그리고 QA의 테스트 프로세스에서도 요구사항 분석과 개발 설계 단계에서 기획서와 개발 설계서, 서비스 아키텍쳐 등 상품 개발전에 충분한 리뷰 활동이 진행되었는지 검토해보아야 합니다. 
리뷰활동은 실제로 제품이 구현되기 전에 제품 개발에 필요한 요구사항과 명세서, 설계서 등의 문서를 분석하여서 오류를 발견하는 활동입니다. 리뷰 활동이 잘 진행되면 개발 초기 설계 단계에서부터 오류를 발견 할 수 있고 일정 수준의 품질을 확보하고 전체 개발 과정의 효율을 높일 수 있습니다. 

그럼에도 불구하고 요구사항과 개발구조 변경, 스펙아웃이 끝없이 이루어진다면, 
QA도 상황에 맞게 유연하게 대처해야할 수 밖에 없습니다.
다만, 그렇게 결정되는 사안들이 QA없이 결정되지 않도록, QA가 반드시 참여한 상태에서 품질적 관점에서 적절하고 합의된 변경이 이뤄지도록 적극적으로 대응하시는 것이 필요합니다. 
(품질적 관점에서 봤을때 굳이 변경하지 않고 다른 방안으로 대처할 수 있는 방법도 있을 수 있습니다. 스펙 아웃의 경우에도 기능이나 스펙이 아웃된다 하더라도 문제가 발생되었을때 대응 할 수 있는 방안을 마련하도록 품질적 관점에서 가이드가 필요하기때문에 QA의 참여하에 사안들이 결정 될 수 있도록 가이드 해주시는 것이 필요합니다.)

---

Q : QA 라는 포지션의 정의와 본질이 궁금합니다 

A : 책의 마지막에 나가는 글에도 썼습니다만, 한마디로 요약한다면, 
제가 생각하는 QA란, "발생한 문제에 대응하는 사람이 아니라 문제를 미리 예측하고 예방하는 사람 또는 역할"이라고 생각합니다. 
 | 여기서 이야기하는 '문제'는, 프로덕트만의 문제만 해당되지 않습니다. 품질에 영향을 주는 모든 요소가 포함됩니다. (시간, 인원, 리스크, 프로세스, 개발구조, 등등)

문제가 발생되지 않았는데 미리 문제를 예측해서 예방하기 위해 선제적인 대응을 한다는 것은 쉬운 일이 아닙니다. 논리적인 근거를 찾아 함께 일하는 사람들을 설득해야 하기도 하고, 내 시간을 할애해서 예방적 테스팅 활동을 수행해서 현재의 문제점을 드러내고 품질 대응 활동을 통해 개선이 예상되는 방향을 예측해서 모든 구성원이 함께 필요한 역할과 활동을 할 수 있도록 이끌어내거나, 또는 훈련시키거나 또는 교육해야 할 수도 있습니다. 

하지만, 경험해 보신분들은 아실것입니다. 
문제가 발생된 이후에 대응하는 것보다 발생이 예상되는 문제를 예측하여 예방하는 것이 훨씬 유익하고 투입되는 비용이 낮으며 결과는 더 효과적이라는 것을요. 

그런 의미에서 제가 생각하는 QA는, 품질적 관점에서 프로젝트 전체를 리드하는 포지션에 있는 사람이라고 생각하고 그런 자세로 업무에 수행해야 한다고 생각합니다. 누가 역할을 주지 않아도, 스스로 품질을 위해 프로젝트를 리드해야합니다.

프로세스에서 수행되는 작업과 결과물을 관리하고, 프로세스 절차를 준수하는지 검사하고, 커뮤케이션을 관리하고, 리스크를 제어하고 차단하는 등 이러한 활동들이 품질을 향상하게 한다는 믿음하에 프로젝트에 참여한 구성원들이 품질적 관점에서 사고하고 업무를 수행할 수 있도록 리드하고 가이드해주어야 합니다. 

----

[개발자 분들께서 남겨주신 질문 중]

Q : 테스트 도입으로 개발자들이 품질개선을 직접적으로 도움이 되는 도구(?) 등이 있다면.

A : 개발자분들이 수행하는 테스트가 보통 단위테스트나 통합테스트에 해당되고, 아주 적은 경우 시스템테스트 수준으로 테스트를 수행하게됩니다. 
- 단위테스트 : 하나의 모듈이나 프로그램, 클래스, 메서드와 같이 가장 작은 단위의 소프트웨어를 대상으로 기능이 잘 작동되는지 확인하는 테스트로, 소스 코드를 중심으로 테스트를 수행
- 통합테스트 : 각 모듈에 대한 개발이 완료되면 모듈을 통합하는데, 이때 발생할 수 있는 모듈 간의 인터페이스, 즉 모듈 간에 서로 상호 작용하는 동작을 확인하는 테스트
- 시스템테스트 : 통합이 완료된 소프트웨어를 하드웨어와 결합한 뒤에 시스템 기능과 하드웨어 통합 간에 인터페이스 전체를 확인하는 테스트

단위테스트 수준으로 보았을때, 
(1)개발 작업시마다 빠르게 테스트가 병행될 수 있도록 자동화를 도입하거나, 
(2)테스트 코드를 먼저 작성하는 개발방법론인 TDD(테스트 주도 개발)를 도입하는 방법,
      > TDD로 테스트 시 사용할 수 있는 테스트 도구 : Jest, Enzyme, 

React Testing Library 등
(3)개발자 테스트 범위를 구조 기반 기법을 활용하여 테스트를 설계하는 방법을 활용하여 테스트를 수행해 볼 수 있습니다.
   - 구조 기반 기법 : 코드, 개발 설계, 소프트웨어 구현 정보 등 구조를 보여 주는 정보를 기반으로 소프트웨어나 시스템의 내부 구조를 고려하여 테스트를 설계하는 방법

위의 방법들을 고려해서 적용해본다면, 개발자 테스트에 많은 시간을 소모하지 않으면서 모듈의 품질 향상을 기대해 볼 수 있을 것입니다. 

---

Q : 만약 QA가 따로 없는 경우이면, 요구사항 분석을 하면서 해당 내용을 바탕으로 테스트 케이스를 같이 확립하나요??

A : 테스트 케이스를 설계할 때, 고객의 요구사항 명세서 / 기획서 / 개발설계서(서비스 아키텍처) / 테스트 인원의 유사서비스 프로젝트 경험 / 유사 서비스 자료조사를 기반으로 내용을 분석해서 테스트 케이스를 도출하게 됩니다. 
질문하신 '요구사항'의 범위를 기획서 수준으로 보고 말씀하신 것이라면 분석할 자료의 부족함은 있지만.. 해당 내용을 바탕으로 테스트 케이스를 도출하는 것은 맞습니다. 

---

Q : 개발자끼리 QA를 해야한다면 가장 현실적으로 적용할 수 있는 테스팅 기법이 있을까요?

A : 단위와 통합 테스트 수준으로 진행하신다면 구조 기반 기법이 좋구요. 
시스템 테스트 수준으로 진행하신다면, 명세기반 기법을 적용하는 것이 좋습니다. 
개인적으로 단위와 통합 테스트 수준으로 진행하게되면 개발이 완료된 프로덕트와 하드웨어간의 인터페이스 확인이 누락될 수 있어서, 가급적 개발자끼리 테스트를 수행하시더라도 시스템 테스트 수준으로 테스트를 꼭 수행해보시길 추천드립니다. 

그 외 더 자세한 질문과 답변은 브런치에서 확인해볼 수 있습니다.

https://brunch.co.kr/@swtestrecipe/37