by
Jul 17. 2024
강연회 Q&A : 질의응답
지난 강연회에서,
참석해주신 참석자분들께서 남겨주신 Q&A의 질문 리스트를 따로 전달받았고, 어떤 내용의 질문들을 남겨주셨는지 궁금해서 살펴보던 중에..
강연회에 참석하진 못했지만, 실무에서 일하고 계신 분들의 공통적인 질문도 될 수 있을 것 같아서, 브런치에서만이라도 질의에 대한 응답을 남겨두면 좋을 것 같아 질문과 그에 대한 답변을 작성해보았습니다.
Q : QA와 Tester의 가장 큰 차이점이 무엇이라고 생각 하시는지 궁금합니다
A : 품질 관리 역할을 설명할 때, 대개 왼쪽의 그림과 같이 역할을 시각화하여 설명합니다. 이것은 '사원-대리-과장-차장'으로 나누듯 직급으로 구분되거나, 직무 계층을 나타내는 것이 아닙니다.
품질을 관리하는 활동과 임무, 책임과 역할의 측면으로 구분한 것으로 이해해야 합니다.
즉, 품질 관리는 '품질 관리(QM), 품질 보증(QA), 품질 제어(QC), Tester' 네가지 측면으로 구성되어있으며 수행하는 업무 범위와 책임에 따라 명칭을 달리 사용하고 있지만, 이 모두는 ‘품질을 검증하고 관리하는 전문가’를 뜻합니다.
각각의 역할에 대한 자세한 내용은 제 책 [부트캠프QA편] page.23~에서 다루고 있으니 참고해주시기 바랍니다.
Q : 자사/아웃소싱으로 테스트 조직 근무 환경을 많이 비교하는데 단순히 연봉이나 복지를 제외하고 직무 능력 향상만 놓고 본다면 아웃소싱은 답이 없고 무조건 자사로 가야할까요..?
A : 답을 하기 전, 자사와 아웃소싱의 품질 관리 차이를 먼저 살펴볼께요.
- 자사 : 소속된 회사에서 서비스하는 제품에 대한 품질을 관리
- 아웃소싱(외주/외부 용역) : 외부의 기업이나 조직과 같은 제 삼자에게 업무(품질 관리)를 위탁해 처리
여기서, 자사에 소속되어있다 하더라도 자사에서 관리되는 품질의 범위와 품질 관리 역할의 책임의 한계에 따라 아웃소싱과 크게 차이가 없는 경우도 존재합니다.
강연회나 제 책에서도 말씀드렸듯이, QA가 관리하는 품질의 범위는 프로덕트의 기능적 오류를 확인하는 것에만 한정되어있지 않습니다.
프로덕트 품질, 프로세스에서 수행되는 각 구성원의 작업의 품질, 프로세스 자체 품질, 서비스를 구성하는 연관된 요소들(코드, 서버, 데이터베이스 등)에 대한 관리와 제어 활동, 품질에 영향을 주는 요소들(리스크, 작업자, 시간 등), 테스팅 활동 품질, 프로젝트 진행 중 발생되는 산출물의 품질까지 QA가 관리해야 하는 품질의 범위는 품질에 영향을 주는 모든 요소가 포함됩니다.
자사에 소속되어 있더라도 프로덕트의 기능적 품질 관리만 수행하거나, 아웃소싱에 소속되어 있더라도 프로덕트 외 프로세스를 설계하고 개선하고, 품질에 영향을 주는 요소를 직접 관리하고 제어하고, 다양한 기술 도구를 활용하여 테스트 수행할 수 있다면..내가 소속한 기업에 따라 직무 능력이 향상 되는 것은 아닐 것입니다. 이런 경우, 오히려 다양한 기업의 다양한 프로젝트를 경험할 수 있는 장점이 있는 아웃소싱이 직무 능력 향상에 더 유리하겠지요. 반대의 경우라면 당연히 자사로 가야하는 것이 맞구요.
하지만, 대개의 경우 아웃소싱에서 관리하게되는 품질의 범위와 역할이 프로덕트의 기능적 품질관리에 한정되는 경우가 많다보니 '직무 능력 향상'라는 측면만 놓고 봤을때 자사로 가는 것이 낫다고 이야기 하는 것입니다.
Q : 테스트 도입으로 개발자들이 품질개선을 직접적으로 도움이 되는 도구(?) 등이 있다면.
A : 개발자분들이 수행하는 테스트가 보통 단위테스트나 통합테스트에 해당되고, 아주 적은 경우 시스템테스트 수준으로 테스트를 수행하게됩니다.
- 단위테스트 : 하나의 모듈이나 프로그램, 클래스, 메서드와 같이 가장 작은 단위의 소프트웨어를 대상으
로 기능이 잘 작동되는지 확인하는 테스트로, 소스 코드를 중심으로 테스트를 수행
- 통합테스트 : 각 모듈에 대한 개발이 완료되면 모듈을 통합하는데, 이때 발생할 수 있는 모듈 간의 인터
페이스, 즉 모듈 간에 서로 상호 작용하는 동작을 확인하는 테스트
- 시스템테스트 : 통합이 완료된 소프트웨어를 하드웨어와 결합한 뒤에 시스템 기능과 하드웨어 통합 간
에 인터페이스 전체를 확인하는 테스트
단위테스트 수준으로 보았을때,
(1)개발 작업시마다 빠르게 테스트가 병행될 수 있도록 자동화를 도입하거나,
(2)테스트 코드를 먼저 작성하는 개발방법론인 TDD(테스트 주도 개발)를 도입하는 방법,
> TDD로 테스트 시 사용할 수 있는 테스트 도구 : Jest, Enzyme, React Testing Library 등
(3)개발자 테스트 범위를 구조 기반 기법을 활용하여 테스트를 설계하는 방법을 활용하여 테스트를 수행해 볼 수 있습니다.
- 구조 기반 기법 : 코드, 개발 설계, 소프트웨어 구현 정보 등 구조를 보여 주는 정보를 기반으로 소프트
웨어나 시스템의 내부 구조를 고려하여 테스트를 설계하는 방법
위의 방법들을 고려해서 적용해본다면, 개발자 테스트에 많은 시간을 소모하지 않으면서 모듈의 품질 향상을 기대해 볼 수 있을 것입니다.
Q : QA는 프리랜서로 활동할 수 있나요? QA 업무로 여러 프로젝트를 동시에 수행하는 경우도 있을까요? 재택근무도 가능한지 알고 싶어요!
A : 답변을 드리자면 세 질문 모두 YES 라고 답을 드릴 수 있습니다. 실제 프리랜서로 활동하고 계신 분들이 많습니다.(예시로 '숨고'같은 서비스에서도 프리랜서 QA를 쉽게 찾아볼 수 있습니다.) 그리고 QA 업무로 여러 프로젝트를 동시에 수행하는 경우는 매~우 많습니다. 기업에 소속된 QA든, 프리랜서든 이건 QA의 역량에 따라 달라질 수 있겠지만 한번에 여러 프로젝트를 동시에 수행하는 경우가 (저의 경우) 단독 프로젝트를 진행하는 경우보다 더 많았던 것 같습니다.
그리고 재택근무도, 기업에 소속된 경우 기업의 문화에 따라 재택근무가 가능한 경우가 있고 프리랜서의 경우 재택 or 출근으로 업무가 수행될 수 있습니다.
Q : 인수테스팅과 End to End 테스트 가장 큰 차이점 궁금해요
A : 각각의 의미를 먼저 설명해드릴께요.
- 인수테스트 : 실제 제품을 사용하게 될 최종 고객이 제품이 요구사항을 충족하는지 확인하고 이에 대한 평
가를 얻기 위해서 수행되는 테스트로, 제품이 실제 운영 환경에서 사용할 준비가 되었는지 확신을 얻기 위
한 과정으로 볼 수 있습니다. ‘알파 테스팅 또는 베타 테스팅'이라는 이름으로 실제 유저가 테스트를 수행
하기도 하고, 고객의 직접 참여가 어려울 경우에는 테스트 조직이나 제품 관련자가 ‘유저 입장'에서 제품
의 완성도를 확인하게 됩니다.
- End to End : 엔드투엔드 테스트는 외부 인터페이스와의 통합과 함께 전체 소프트웨어를 처음부터 끝까
지 검증하는 소프트웨어 테스트 방법으로, 완전한 프로덕션을 실행하는 것입니다. 테스트 레벨 중 '시스템
테스트'에 해당됩니다.
인수 테스트와 E2E 테스트의 가장 큰 차이점은, 테스트를 수행하는 인원와 테스트가 수행되는 환경에 차이가 있습니다. 인수 테스트는 실제 라이브에서 사용하게 될 환경(프로덕트+서버+데이터 등)에서 제품을 사용할 '실제 유저'가 테스트를 수행하고 별도의 테스트 시나리오 없이 사용자 스토리에 따라 테스트가 수행됩니다. E2E 테스트는 테스트 환경에서 테스트 조직에 의해 테스트가 수행되고 테스트를 위한 테스트 케이스를 기반으로 테스트가 실행됩니다.
Q : 한때 TDD 개념이 유행처럼 번지던 시기가 있었는데, 현재 TDD가 더 커지고 있는지 다르게 진화되고 있는지 저자의 생각이 궁금합니다
A : 이건, 개발에서 TDD 방법론에 따라 테스트 코드를 먼저 작성하고 개발을 진행할 것인지 or 그렇지 않을 것인지..개발조직의 문화 또는 개발자의 작업 역량, 일정과 비용 등에 따라 달라질 수 있는 것이라 제가 답변할 수 없는 영역인 것 같습니다. Case by Case 이지요 :)
Q : 이름있는 기업들 위주 jd를 보면 자동화 도구 사용이 핫한 키워드로 분석했는데요. 예를들어 앱피움을 스터디할때, 환경구축은 했지만 그외에 이걸 어떻게 더 활용할수있는지, 해당 도구가 정말 실무에서 활용되는지 등에 대한 궁금증이 생겼습니다. 추천해주실만한 해결방법이 있을까요?
A : 실무에서 자동화를 도입하는 이유는 여러가지가 있습니다. (1)반복되는 테스트에 투입되는 리소스와 시간이 너무 많다는 문제 인식과 이를 줄이기위한 필요성 또는 요구사항의 발생으로인해, 또는 (2)투입되는 인원 대비 확인해야 할 테스트 범위가 많은 경우 투입 인원 대비 높은 품질을 확보하기 위해서, 또는 (3)테스트 효율화를 위해서, 또는 (3)애자일 프로세스의 도입으로 개발 초기부터 반복적이고 점진적으로 테스트 수행이 필요한 경우...등등 필요성이나 요구사항에 따라 자동화를 도입하는 이유가 달라집니다.
그리고, 자동화를 도입하는 이유에 따라 활용방법도 달라질 수 있겠지요.
예를들어, 반복 테스트의 시간과 투입 리소스 비용을 줄이기 위해 자동화를 도입한다면, 리그레션 테스트 / 스모크 테스트 / 개발 테스트 와 같이 테스트 시나리오 상 변화가 크지 않은 반복적인 테스트가 필요한 범위에 자동화를 도입해서 활용할 수 있고, 또는 유지보수 시 변경이나 개선되는 범위와 연관된 기능들에 대한 영향도 확인은 자동화 테스트로 확인하고 테스트 인력은 변경되는 범위만 E2E테스트를 수행하는 것으로 활용할 수 있습니다. 마지막으로, 기능이나 서버의 부하 검증을 위해 데이터를 많이 만들어야 하는 경우(ex) 대량의 주문 건수 유입) 자동화를 활용하여 부하 유입을 줄 수 있습니다.
이렇게 자동화를 왜 도입하고자 하는지, 어디에 활용하고자 하며 어떤 목적으로 사용할 것인지, 자동화를 위한 명확한 범위 선정, 도입 후 유지보수 계획 등이 명확하게 계획되고 설계되어야 지속적으로 실무에서 활용될 수 있습니다. 호기롭게 자동화를 도입해서 적용하더라도 유지보수가 어렵거나 담당하는 인원이 없으면 무용지물이 되버리기 쉽상이거든요.
자동화를 도입하고자 하는 목적과 자동화 도입으로 해결하고자 하는 문제, 이를 고려한 세부적인 계획과 범위가 잘 설계된 경우 실무에서도 활용도가 높고 유용하게 사용되고 있습니다.
Q : 만약 QA가 따로 없는 경우이면, 요구사항 분석을 하면서 해당 내용을 바탕으로 테스트 케이스를 같이 확립하나요??
A : 테스트 케이스를 설계할 때, 고객의 요구사항 명세서 / 기획서 / 개발설계서(서비스 아키텍처) / 테스트 인원의 유사서비스 프로젝트 경험 / 유사 서비스 자료조사를 기반으로 내용을 분석해서 테스트 케이스를 도출하게 됩니다.
질문하신 '요구사항'의 범위를 기획서 수준으로 보고 말씀하신 것이라면 분석할 자료의 부족함은 있지만.. 해당 내용을 바탕으로 테스트 케이스를 도출하는 것은 맞습니다.
Q : 결함 등급을 지정하는 활동은 어떤식으로 진행이 될 수 있을까요?
결함 우선순위, 중요도A : 왼쪽의 표를 참고 & 제 책 [부트캠프QA편]의 302페이지 참고 또는 https://brunch.co.kr/@swtestrecipe/29 글을 참고하시면 좋습니다.
Q : 개발자끼리 QA를 해야한다면 가장 현실적으로 적용할 수 있는 테스팅 기법이 있을까요?
A : 단위와 통합 테스트 수준으로 진행하신다면 구조 기반 기법이 좋구요.
시스템 테스트 수준으로 진행하신다면, 명세기반 기법을 적용하는 것이 좋습니다.
개인적으로 단위와 통합 테스트 수준으로 진행하게되면 개발이 완료된 프로덕트와 하드웨어간의 인터페이스 확인이 누락될 수 있어서, 가급적 개발자끼리 테스트를 수행하시더라도 시스템 테스트 수준으로 테스트를 꼭 수행해보시길 추천드립니다.
Q : Ai를 통해서 테스트준비 시간을 줄이는 방법을 실무에 도입하려하는데 이전사례나 주의점이있는지 궁금합니다.
A : '테스트 준비' 시간이라고 이야기한 부분이 정확히 어떤 범위를 말씀하시는 건지부터 확인이 되어야 할 것 같습니다. 테스트 준비에는 계획, 분석, 설계 단계가 존재하고 AI를 활용해볼 수 있는 범위가..아직은 (문서에 기록된 내용에만 의존한)요구사항과 리스크에 해당하는 주요 기능 분석, 테스트 케이스 설계 및 작성, 자동화 코드에 활용해볼 수 있는 정도이고, 프로젝트 목표에 따라 계획되는 테스트 범위와 전략, 일정, 투입리소스, 품질 목표 기준 조건 등은 프로젝트에 따라 달라지기때문에 사람에 의해 준비될 수 밖에 없습니다.
아직은 업계에서도 AI를 적극 활용한 사례가 거의 없거나 많지 않습니다. 이유는, AI도 아직 기능이 완벽한 상태가 아니여서 도입하거나 활용하는데 대한 리스크가 높기때문입니다.
그래도 테스트 케이스를 작성하거나(또는 작성을 위한 문서를 분석해서 요약 등) 자동화 코드를 작성하는데 활용하는 경우들이 있고 생각보다 AI가 작성해준 TC나 코드의 품질이 높은 편이라, 잘 활용한다면 시간을 많이 단축할 수 있을 것이라 생각됩니다.
Q : 취준생이 따라해볼만한 간단한 소프트웨어 테스트 템플릿이 공개된 자료가 있을까요?
Q : 테스트도 애자일 TDD 유행이 있는거 같은데, 이러한 유행은 어떻게 알 수 있을까요?
A : '소프트웨어 테스트 템플릿'의 범위를 가늠하기가 어려운데요~
테스트 케이스를 작성할 만한 템플릿을 이야기하는 것인지, 아니면 위의 이미지처럼 테스트 라이프 사이클 전체를 같이 따라해볼만한 템플릿을 이야기하는 것인지 모르겠네요.
테스트 케이스 작성을 위한 템플릿이라면 제 책이나 아니면 개발자도 알아야할 소프트웨어 테스팅 실무(예제가 많습니다.) 책을 참고하거나, 아니면 가장 좋은 방법은 취업하고자 하는 업계에 해당되는 애플리케이션이나 웹 서비스를 참고하면서 테스트 케이스를 작성해보는 것도 좋은 방법이 될 수 있습니다.
그 외 자료나 유행하는 테스트 기법들은 STEN이나 네이버 카페 등 커뮤니티를 이용해보는 것도 좋을 것 같습니다.
Q : qa활동에서 가장 중요하게 생각하시는 qa 지표 3가지가 궁굼합니다. (협업 부서와의 커뮤니케이션중 공유할 지표)
A : 협업부서로 공유되는 품질 지표에 중점을 둔다면,
(1) 담당QA의 품질에 대한 의견
: 출시 가능 여부에 대한 의견 공유, 프로젝트 진행 중 이슈와 품질 검증 활동 중 가장 주요하게 공유되
어야 하거나 또는 문제 해결 방안이 필요한 부분에 대한 내용 공유
(2) 테스트 기간 동안 진행된 테스트 활동 기록에 대한 지표와 결과 공유
: 제품의 현재 품질 상태, 테스트 수행 진척도(계획 대비 차이점), 등록된 버그 처리율, 테스트 커버리지
감소 사유(실행할 수 없거나 실패된 테스트 케이스와 이유), 새롭게 식별되거나 처리되지 못한 리스크
와 결함, 합의된 known-issue 등
(3) 프로젝트 진행에 차질을 발생시키는 요인들
: 일정, 인적요인, 각 작업단계에서 산출되는 결과물의 품질, 품질 현황을 파악하기 어렵게하는 위험
요인 등 프로젝트 진행 관련 이슈 및 논의나 협의가 필요한 내용 공유
([부트캠프QA편]의 267페이지를 참고)
Q : 효진님이 생각하시는 QA 라는 포지션의 정의와 본질이 궁금합니다
A : 책의 마지막에 나가는 글에도 썼습니다만, 한마디로 요약한다면,
제가 생각하는 QA란, "발생한 문제에 대응하는 사람이 아니라 문제를 미리 예측하고 예방하는 사람 또는 역할"이라고 생각합니다.
| 여기서 이야기하는 문제는 프로덕트만의 문제만 해당되지 않습니다. 품질에 영향을 주는 모든 요소가
포함됩니다. (시간, 인원, 리스크, 프로세스, 개발구조, 등등)
문제가 발생되지 않았는데 미리 문제를 예측해서 예방하기 위해 선제적인 대응을 한다는 것은 쉬운일이 아닙니다. 논리적인 근거를 찾아 함께 일하는 사람들을 설득해야 하기도 하고, 내 시간을 할애해서 예방적 테스팅 활동을 수행해서 현재의 문제점을 드러내고 품질 대응 활동을 통해 개선이 예상되는 방향을 예측해서 모든 구성원이 함께 필요한 역할과 활동을 할 수 있도록 이끌어내거나, 또는 훈련시키거나 또는 교육해야 할 수도 있습니다.
하지만, 경험해 보신분들은 아실것입니다.
문제가 발생된 이후에 대응하는 것보다 발생이 예상되는 문제를 예측하여 예방하는 것이 훨씬 유익하고 투입되는 비용이 낮으며 결과는 더 효과적이라는 것을요.
그런 의미에서 제가 생각하는 QA는, 품질적 관점에서 프로젝트 전체를 리드하는 포지션에 있는 사람이라고 생각하고 그런 생각을 가지고 업무에 수행해야 한다고 생각합니다. 누가 역할을 주지 않아도, 스스로 품질을 위해 프로젝트를 리드해야합니다. 프로세스에서 수행되는 작업과 결과물을 관리하고, 프로세스 절차를 준수하는지 여부를 통제하고, 커뮤케이션을 관리하고, 리스크를 제어하고 차단하는 등 이러한 활동들이 품질을 향상하게 한다는 믿음하에 프로젝트에 참여한 구성원들이 품질적 관점에서 사고하고 업무를 수행할 수 있도록 리드하고 가이드해주어야 합니다.
Q : 테스트커버리지에서 요구사항이 없거나 구현되었을 때의 비공식테스트란 어떤 것일지 문의드립니다
A : 비공식테스트는 계획이나 문서화된 것 없이 수행되는 테스트 방법입니다. 기획서나 요구사항에 기반하여 개발이 설계되면 공식적이고 예상되는 결과값이 주어지겠지요. 하지만 개발이 기획서나 요구사항에 없는데 기능을 구현한 경우, 또는 경험기반 테스트와 같이 무작위로 테스트가 수행되는 경우, 또는 공식적인 방법으로는 수행할 수 없는 중요한 결함을 빠르게 찾는 경우에는 비공식적이고 예상되는 결과값없이 테스트가 수행되어야 합니다. 이 경우 테스터는 즉석에서 테스트를 설계해서 임의로 실행해야하고 발견되는 결함은 올바른 수정 방향이 없는 상태에서 수정방법을 예측하거나 테스트 도중에 구성원과의 합의를 통해 결과값을 정해주어야 합니다.
Q : 완전 비전공자인 경우 ISTQB 자격증을 시작으로 제일 우선적으로 추천하시는 다른 자격증이나 배워두면 좋은 스킬들이 있을까요? 요즘 테스트가 대두되는 분야도 궁금합니다(게임제외)
A : ISTQB나 CSTS, 정보처리기사, 개발언어 관련 자격증을 배우면 좋습니다.
소프트웨어 테스팅 지식은 자격증 외에 테스트 계획과 전략을 수립하는 방법이나, 테스트 설계 능력, 테스트 프로세스 생명주기, 테스트 수행 경험이나 방법에 대해서 알아보시면 좋겠고,
그 외 기술도구를 활용한 테스트인 셀레니움, 앱피움과 같은 테스트 자동화나 엔그라인더, 제이메터와 같은 서버 성능 테스트, 포스트맨과 같은 API 테스팅, 게임벤치와 같은 클라이언트 성능 테스트 도구 사용과 테스트 방법을 공부해보시는 것도 좋구요.
추가로 소프트웨어 공학에서 개발언어 포함해서 안드로이드, iOS, 웹 등의 플랫폼 운영체제, 서버/데이터베이스/API 등 개발 설계 구조에 대한 이해, 개발 생명주기에 대해서 지식을 보유하면 좋습니다.
그리고, 테스트가 대두되는 분야..라는 것이 딱히 없는데요~ 소프트웨어 테스팅을 희망하시는 것이라면, 대부분의 업계에서 소프트웨어를 사용하고 있기때문에 업계 전반적으로 품질 관리 담당자를 채용하고 있습니다. 업계 중에서 희망하시는 분야가 있으시면 해당 업계에서 요구하는 JD를 참고하셔서 스킬을 올리거나 스펙을 준비하시는 것도 좋을 것 같습니다.
Q : 프로젝트 진행 단계에서는 유관부서 요구사항과 개발 구조 변경 그리고 스펙아웃이 끝없이 이루어지는데 이런 상황에서 QA는 어찌 대처해야 할까요?
A : 가장 기초적인 뿌리부터 수정을 했으면 하신다면, 프로세스를 점검해보심이 좋을 것 같습니다. 회사 내부에 프로세스가 있는지, 프로세스가 있다면 어떤 절차로 진행되고 각 절차에서 완료되는 결과물의 품질 기준과 프로세스 정책(ex)프로젝트 진행 중 변경사항은 없어야 한다와 같은 사내에서 합의한 정책)이 있는지 살펴보시고 프로세스가 없다면 정립을 하셔야 할것같고, 있다면 개선을 해야할 것 같습니다.
예를들어, 폭포수 모델에 기반한 프로세스를 도입한다면 진행 단계에서는 변경사항이 없어야 합니다. 완벽한 계획이 수립되어야 각 작업의 진행이 승인되고, 승인된 이후에 작업이 진행되어야 합니다. 폭포수 모델에 기반한 프로세스가 도입된다면 말씀하신 문제들이 어느정도 해소가 되겠지요.
그리고 QA의 테스트 프로세스에서도 요구사항 분석과 개발 설계 단계에서 기획서와 개발 설계서, 서비스 아키텍쳐 등 상품 개발전에 충분한 리뷰 활동이 진행되었는지 검토해보아야 합니다.
리뷰활동은 실제로 제품이 구현되기 전에 제품 개발에 필요한 요구사항과 명세서, 설계서 등의 문서를 분석하여서 오류를 발견하는 활동입니다. 리뷰 활동이 잘 진행되면 개발 초기 설계 단계에서부터 오류를 발견 할 수 있고 일정 수준의 품질을 확보하고 전체 개발 과정의 효율을 높일 수 있습니다.
그럼에도 불구하고 요구사항과 개발구조 변경, 스펙아웃이 끝없이 이루어진다면,
QA도 상황에 맞게 유연하게 대처해야할 수 밖에 없습니다. ^^;
다만, 그렇게 결정되는 사안들이 QA없이 결정되지 않도록, QA가 반드시 참여한 상태에서 품질적 관점에서 적절하고 합의된 변경이 이뤄지도록 적극적으로 대응하시는 것이 필요합니다.
(품질적 관점에서 봤을때 굳이 변경하지 않고 다른 방안으로 대처할 수 있는 방법도 있을 수 있습니다. 스펙 아웃의 경우에도 기능이나 스펙이 아웃된다 하더라도 문제가 발생되었을때 대응 할 수 있는 방안을 마련하도록 품질적 관점에서 가이드가 필요하기때문에 QA의 참여하에 사안들이 결정 될 수 있도록 가이드 해주시는 것이 필요합니다.)
Q : 프로세스 품질이 무엇인가요?
A : 프로세스 품질은 프로세스의 성숙도 및 수행 능력을 평가하여 현재 조직에 적용된 프로세스의 품질 레벨을 측정하는 것입니다. 프로세스의 품질을 측정하는 모델로 CMMi를 활용하는데, 적용된 프로세스의 상태를 1~5 레벨로 나누어 측정하고 높은 레벨에 도달 할 수 있도록 개선하는 작업을 수행할 수 있습니다.
자세한 내용은 CMMi를 확인해보심이 좋을 것 같고, 간단하게 아래 이미지를 참고하시는 것도 도움이 될 것 같네요.
