QA, QC 그리고 테스트 엔지니어링의 차이

 

얼마 전 같은 회사의 다른 부서에서 QA 매니저를 하시는 분이 "QA와 QC의 차이"에 대해서 진지하게 질문을 던진 적이 있다.

나름대로 생각하고 있던 바를 같이 논의해 보긴 했지만 서로가 명확한 개념을 잡고 있지 못했던 것 같았다.
이 참에 인터넷의 여기 저기를 뒤지다가 구글 테스팅 팀 블로그에서 QA와 QC, 그리고 테스트 엔지니어링에 대해 정의해 놓은 글을 실어왔다.

아직도 QA 분야에서 사용되는 단어들이 사전적인 의미로 통일되어 사용되는 예는 드문 것 같다. 그만큼 나름대로의 주관적인 해석도 가능하다는 이야기도 되니 이 포스트는 단지 참조만 하시면 되겠다.

아울러 포스트에 달린 댓글들도 외국의 QA들이 나름대로 이 주제에 대해 생각하고 있는 것들을 보여주는 것 같아 같이 번역했다.

 The difference between QA, QC, and Test Engineering

http://googletesting.blogspot.com/2007/03/difference-between-qa-qc-and-test.html

 

QA, QC와 테스트 엔지니어링의 차이

Tuesday, March 06, 2007 3:22 AM

Posted by Allen Hutchison, Engineering Manager and Jay Han, Software Engineer in Test

The testing world has a lot of terms for the activity that we undertake every day. You'll often hear the words QA, QC, and Test Engineering used interchangeably. While it is usually enough to get your point across with a developer, it is helpful to think about these terms and how they apply to the world of software testing. In the classic definition QC is short for Quality Control, a process of verifying predefined requirements for quality. In the terms of an assembly-line this might involve pulling manufactured units off at the end of the process and verifying different parts of the assembly process. For software the QC function may involve checking the software against a set of requirements and verifying that the software meets the predefined requirements.

 

우리가 매일 수행하는 업무를 뜻하는 많은 단어들이 테스팅의 세계에 존재한다. 당신은 종종 QA, QC 그리고 테스트 엔지니어링이라는 단어들이 서로 혼돈되면서 사용되는 것을 들어봤을 것이다. 이 단어들은 일반적으로 개발자들에게 당신의 의도를 명확하게 전달하기에 충분할 뿐만 아니라, 이 단어들과 어떻게 이 단어들을 실제 소프트웨어 테스팅에 반영할 것인가를 생각해 보는 것도 무척이나 유용할 것이다. QC에 대한 고전적인 정의는 Quality Control(품질 제어)의 줄임말로, 품질에 대해 미리 정의된 요구사항을 검증하는 프로세스이다. 조립 라인에서 이 단어는 제조된 유닛을 프로세스의 마지막 부분에서 획득해서 조립 과정에서 잘못된 부분을 검증하는 것을 의미한다. 소프트웨어에서의 QC 기능은 소프트웨어가 일련의 요구사항에 부합하는지를 점검하는 것과 소프트웨어가 미리 정의된 요구사항을 충족하는지 검증하는 것을 포함한다.   

Quality Assurance, on the other hand, is much more about providing the continuous and consistent improvement and maintenance of process that enables the QC job. We use the QC process to verify a product does what we think it does, and we use the QA process to give us confidence that the product will meet the needs of customers. To that end the QA process can be considered a meta process that includes aspects of the QC process. It also goes beyond that to influence usability and design, to verify that functionality is not only correct, but useful.

 

한편, 품질 보증(Quality Assurance)은 QC 업무를 가능하게 하는 프로세스에 대해 지속적이고 일관된 개선과 유지보수를 제공하는 쪽에 더 가깝다. 우리는 QC 프로세스를 제품이 우리가 의도한 대로 작동하는지를 검증하는데 사용하고, QA 프로세스는 우리에게 그 제품이 우리 고객의 요구를 충족시킬 것이라는 확신을 준다. 이를 위해서, QA 프로세스는 QC 프로세스의 측면을 포함하고 있는 메타 프로세스로 간주될 수 있다. 이것은 또한 사용성과 디자인의 영향을 검증하는 것을 넘어서, 기능이 정확하게 구사되었는지 뿐만 아니라, 그 기능이 유용한 것인지를 검증하는 것까지 포함한다.     

Here at Google, we tend to take a third approach that we call Test Engineering. We look at this as a bridge between the meta world of QA and the concrete world of QC. Our approach allows us to ensure that we get the opportunity to think about customers and their needs, while we still provide results that are needed on day to day engineering projects.

 

여기 구글에서는, 우리가 테스트 엔지니어링이라고 부르는 세 번째 접근법을 택하는 경향이 있다. 우리는 이것을 QA라는 메타 월드와 QC라는 구체적인 세계를 이어주는 교량으로 파악하고 있다. 우리의 접근법은 매일 매일의 엔지니어링 프로젝트에 필요한 결과를 제공해 주기도 하지만, 우리에게 고객과 그들의 요구에 대해서 생각할 수 있는 기회도 제공해 준다.

Our teams certainly work with Software Engineers in QA and QC roles, but we also work with teams to ensure that a product is testable, that it is adequately unit tested, and that it can be automated even further in our teams. We often review design documents and ask for more test hooks in a project, and we implement mock objects and servers to help developers with their unit testing and to allow our teams to test components individually.

 

우리 팀은 분명히 QA와 QC 역할을 하는 소프트웨어 엔지니어들과 함께 일하고 있지만, 이와 함께 우리는 제품이 유닛 테스트를 수행하기에 적합한지를 검증하는, 즉 제품이 테스트 가능한지, 그리고 우리 팀 내에서 더욱 더 자동화를 해야 하는지 평가하는 팀과도 함께 일하고 있다. 우리는 종종 디자인 문서를 리뷰하고 프로젝트에서 테스트 할 소재들을 더 많이 요청하기도 하며, 또한 개발자들의 유닛 테스팅을 도와주고 우리 팀이 컴포넌트 테스트를 개별적으로 수행할 수 있도록 가상의 오브젝트와 서버를 구현하기도 한다.   

We put an emphasis on building automated tests so that we can let people do what people are good at, and have computers do what computers are good at. That doesn't mean that we never do manual testing, but instead that we do the "right" amount of manual testing with more human-oriented focus (e.g. exploratory testing), and we try to ensure that we never do repetitive manual testing.

 

우리는 자동화된 테스트를 구현하는 것에 중점을 두고 있으며 그로 인해 어떤 사람이 유용한지 다른 사람들이 알 수 있도록 하고, 어떤 컴퓨터가 유용한 것인지를 알 수 있도록 한다. 그것은 우리가 수동 테스팅을 전혀 수행하지 않는다는 것을 뜻하는 것이 아니라, “적당한” 양의 수동 테스팅을 조금 더 인간에게 초점을 맞추어 수행한다는 것을 의미하고, 의미 없는 반복적인 수동 테스팅을 하지 않으려고 노력한다는 것을 의미한다. 
 

Permalink | Links to this post |  

The comments you read here belong only to the person who posted them. We do, however, reserve the right to remove off-topic comments.

5 comments:

Jim said...

I love your description of the different roles...right now I work for a small group of a large company...I am a fiarly new employee and up until now the test process has been almost exclusively QC and manual...I am starting to work with developers to implement some automated tests to free test personnel to do more exploratory testing...it's quite the adventure!

서로 다른 역할에 대한 당신의 설명이 정말 좋군요… 저는 지금 대규모 회사의 작은 그룹에서 일하고 있습니다… 전 아직도 입사한지 얼마 되지 않았고 아직까지도 테스트 프로세스는 거의 QC와 수동 테스트에 가깝습니다… 저는 지금 테스트 인원들이 조금 더 탐색적인 테스팅을 할 수 있도록 시간을 주기 위한 몇몇 자동화된 테스트를 구현하려고 개발자들과 함께 노력하고 있습니다... 상당한 도전이 될 것 같아요!

March 7, 2007 7:47:00 PM PST

Andy said...

Test Engineering method is nothing but W-Model (Not waterfall). In W-Model verification and validation process go hand in hand. Reviews play a major role and helps in getting the concrete, strong and stable requirements, which will be base for strong future development process. Everyone knows the impact of fixing any defect at the later stage of the project life cycle and also the benefit of identifying the issues at the beginning of the project life cycle. Give more importance to Review and Analysis process, this will help in building strong Base. If the base is strong, anything can be built on that.
I also tell my team members to spend quality time doing analysis of the work they do. Do not spend the entire day in just doing testing. Spending everyday sometime on Analysis will help them to move in the right direction in the work and also helps them to see in a bigger and broader perspective of the work.
Finally, just spend good amount of time in planning, reviews and analysis, the execution will be done like in no time.
Lest build and grow the Quality and Testing community stronger across the world.

테스트 엔지니어링 방법론은 단지 W-모델(워터폴 모델이 아니라)에 지나지 않습니다. W-모델에 있어 Verification과 Validation 프로세스는 서로 긴밀하게 연관되어 있습니다. 리뷰는 강력한 미래의 개발 프로세스의 기반이 되는 구체적이고, 강력하며 안정적인 요구사항을 획득할 수 있도록 도와주며 이러한 과정에서 아주 중요한 역할을 수행합니다. 모든 사람이 프로젝트 라이프 사이클의 후반부에 결함을 고치는 효과를 알고 있으며, 또한 프로젝트 라이프 사이클의 초기에 이슈를 구별하는 것의 장점을 알고 있습니다. 리뷰와 분석 프로세스에 더 중점을 두는 것이, 강력한 베이스를 만드는 데 도움을 줄 것입니다. 만약 베이스가 견고하다면, 그 위에서 어떤 것이라도 만들어 질 수 있습니다.

나는 또한 나의 팀원들에게 그들이 수행하는 작업을 분석하는 데에도 많은 시간을 할애할 것을 요구합니다. 테스팅을 하는 데에만 하루 전부를 소비하지 마십시오. 매일매일 조금씩 분석하는 시간을 갖는 것이 그들을 작업에서 올바른 방향으로 유도할 것이며 그들의 작업에서 좀 더 크고 넓은 시각을 가지게 도와줄 것입니다.

마지막으로, 계획과 리뷰, 그리고 분석에 충분한 시간을 할애한다면, 실행은 곧바로 완수될 수 있을 것입니다. (무언가를 더) 만들어내지 않도록 하고 품질과 테스팅 커뮤니티를 전 세계에 걸쳐 키워나가야 합니다.   

March 12, 2007 11:20:00 PM PDT

glogger said...

Thanks for the clarification about QA, QC, and Test Engineering.
Any suggestion for regression testing? That might be the reason to do most of repetitive testing.

QA, QC 그리고 테스트 엔지니어링에 대해 분류 고맙습니다.

리그레션 테스팅에 대한 다른 정의는 없나요? 그게 반복적인 테스팅의 가장 주요한 원인일 것 같은데요.

April 16, 2007 10:32:00 AM PDT

dx-blogger said...

hmm..great info for me, anyway..:)

흠… 어쨋거나 저에겐 훌륭한 정보로군요.

September 9, 2007 6:50:00 PM PDT

vishwas said...

Your blog provides sufficient information on QA and QC but testing, I suppose, hasn't been given enough emphasis. It would be appreciable if you post more on Testing and the process you follow for the same.

당신의 블로그가 QA와 QC에 대한 충분한 정보를 제공해 주지만, 테스팅에 관해서는 충분히 설명되지 않은 것 같습니다. 당신이 테스팅과 그를 위해 당신이 따르는 프로세스에 대해 좀 더 많은 내용을 포스팅 해주신다면 감사하겠습니다.

January 25, 2008 4:01:00 AM PST