"테스팅은 품질 보증 활동의 하나" vs "품질 보증과 테스팅은 다른 개념"

질문

ISTQB Syllabus 2007에는 "테스팅은 품질 보증 활동의 하나"라고 표현되어 있고, ISTQB Syllabus 2018에서는 "품질 보증과 테스팅은 다른 개념이다"라고 되어 있는데, 버전 2개의 내용이 상반된 거 아닌가요? 어떤 게 맞는 건가요?

ISTQB 버전

ISTQB Syllabus 2018

답변

오늘의 이야기를 진행하기 전에 먼저 나누고 싶은 이야기

이번 주제는 조금은 철학적인 내용이 들어 있습니다. 어쩌면 QA와 Testing을 업(業)으로 삼은 사람들이 한 번 쯤은 하게 되는 고민이 아닐까 싶습니다.

오늘 나눌 이야기는 실무와 관련이 있다면 있고, 없다면 없습니다. 받아들이는 사람에 따라 실무에 적용 가능할지/아닐지 다릅니다. 이런 종류의 고민은 어느 정도 실무와 이론을 잘 혼합해서 업무에 적용할 수 있는 내공이 쌓여야 실무에서 수행할 수 있는 내용이기 때문입니다. 그러니 이 글을 읽으시는 분들은 지금 한 번 심심풀이용으로 읽어보시고, 조금 더 높은 자리로 이동하실 때쯤 다시 한번 이 글을 곱씹어 읽어보시기를 필자들은 제언드립니다.

ISTQB가 뭐길래 테스트와 품질관리에 대해 정하는걸까요?

지난 번에 본 블로그의 다른 포스팅에서 ISTQB에 대해 이야기 "[특별 기고] ISTQB는 어디에서 왔을까?" 글에서 소개한 바와 같이 ISTQB는 국제표준으로 널리 알려져 있지만, 사실 「유럽연합에서 시작된 소프트웨어 테스팅 표준」이라고 보시는게 더 맞습니다.

한국에서 보기엔 소프트웨어 테스팅의 모든 이론이 ISTQB로 통합된 거로도 보일 수 있지만, 사실 ISTQB는 Software Testing의 여러 부류 중 하나의 철학입니다. Bret Pettichord가 정의한 "4 schools of software testing(소프트웨어 테스팅의 4대 학파)"라는 글에서 볼 수 있듯이 ISTQB는 「QA학파」를 기반으로 한 정의라 보아야 옳습니다. 이와 관련한 자세한 이야기는 필자의 블로그에서 따로 다룰 예정이니, 시간이 좀 지난 뒤 페이지 하단의 "STEEG 개인 의견"란을 확인해 주세요.

Bret은 Google의 테스팅 방법론인 Exploratory Testing의 창시자로 알려져 있습니다. 또한, Bret은 Cem Kaner, James Bach, Michael Bolton과 함께 Context Driven School of Software Testing(정황기반 소프트웨어 테스팅 학파)을 주장하시는 분입니다.

물론 소프트웨어 지식 체계가 각 학파/부류마다 완전히 다르거나, 다른 학파를 위해 무언가를 새롭게 배워야 하지는 않습니다. 다만, 소프트웨어 테스팅이라는 행위를 고찰하는 시각에 철학적 차이가 있습니다. Bret이 정의한 분류별 접근에는 소프트웨어 테스팅을 바라보는 각 분야 전문가들의 각자 다른 철학의 차이를 나타내고 있습니다.

ISTQB의 분류로 보아야 하는 「QA학파」가 다른 분야의 테스팅 철학들과 다른 점 중 가장 큰 부분은 아래와 같습니다.

① 소프트웨어 테스팅 자격증을 '역량 향상'의 기회로 본다는 것

② "테스팅" 보다는 "품질보증"을 선호

③ 테스팅은 "프로세스 개선"을 위한 징검다리라는 관점으로 접근

④ 테스트 전문가들은 개발자들을 멀리해야 한다고 한다고 이야기함

모두 어디선가 들어본 이야기 같으시죠? 네, ISTQB 공부하시면서 들어보신 이야기들입니다. 이게 바로 「QA학파」의 기본 철학입니다. 대한민국 IT업계는닷컴(dot-com)버블과 함께 ISTQB가 강세가 되면서 ISTQB의 근간인 「QA학파」의 철학을 그대로 받아들였습니다. 그래서 20년 가까운 경력이 있는 프로그래머들 중에도 다른 테스팅 학파가 있다는 사실조차 모르시는 분들이 꽤 많습니다.

「QA학파」는 서기 2000년 이후 Agile Programming이 소프트웨어 개발 방법론의 대세가 되며, 많이 바뀌었지만(=정황기반학파의 철학을 상당 부분 차용하였지만) 본 포스팅에서 다루는 이 질문이 발생한 근본 이유에 대해서는 아마 Bret의 글에서 답을 찾을 수 있을 거 같아 Context Driven School of Software Testing (소프트웨어 테스팅 정황기반 학파) 관련 자료를 짧게나마 위에서 소개했습니다.

문의에 대한 실제 ISTQB의 영문은 어떤 표현이었을까요?

질문자가 질문 주신 내용에 대해 영문으로는 어떻게 표기되어 있는 지 확인해 보았고, 일단 문의 주신 부분의 원문을 가능한 있는 그대로 직역해 보겠습니다.

먼저, ISTQB 2007에서는 이렇게 표현되어 있습니다.

• Testing should be integrated as one of the quality assurance activities

이를 해석하면 "테스팅은 품질 보증 활동 중 하나로 통합되어 있어야 한다" 정도의 표현입니다.

또, ISTQB 2018에서는 이렇게 표현되어 있습니다.

• quality assurance and testing are not the same, but they are related

이를 해석하면 "품질 보증과 테스팅은 같지 않지만, 연관되어 있다" 정도의 표현으로 되어 있습니다.

2007년 판과 2018년 판, 두 번 모두 "Testing과 QA는 다르다"라는 식으로 표현되어 있습니다. 내용을 알고 있는 분들은 영문 표현을 보자마자 딱~ 감이 오지만, 처음 보시는 분들은 "그래서 대체 어쩌라는거지?" 하는 느낌을 받으실 수 있습니다. 정상이십니다. ISTQB는 '수험서' 같은 느낌이 있어서 쉽게 해석되었으면 하는 우리의 바람이 있지만, 사실 ISTQB는 「QA학파」의 표준 철학이기 때문에 실무와 다르게 느껴지거나, 한국 사람으로서는 쉽게 와닿지 않는 부분이 있습니다. 이는 ISTQB가 이론이어서 발생하는 느낌이 아니라, ISTQB를 만든 미국-영국 등과 한국의 산업구조, 개발 문화 등이 달라서 생기는 현상입니다. 그러니 필자들 같은 테스트 전문가들의 해석이 실무 적용에 필수적인 역할을 합니다.

하지만 모든 도(道)는 하나로 통한다고 하죠. ISTQB 역시 소프트웨어 테스팅의 진리를 담고 있다고 필자는 생각합니다.그래서 우리는 한 분야에 대해 오랜 시간 동안 공부를 해야 하나 봅니다.

정식 번역본과 제가 번역한 내용이 조금 다를 수 있습니다. 그럴 수 밖에 없는 것이 ISTQB의 경우는 '수험서'의 느낌이 있는 문서이기 때문에 번역에 참여하신 분들이 가능한 공부하시는 분들이 이해하기 쉽게 번역하려 노력하셨을 겁니다. 그러다보니 오히려 처음 접하는 사람에게는 오해하기 쉬운 애매한 표현들이 보일 수 있습니다.

필자는 블로그나 세미나에서 해설을 하려다보니 독자/청중이 지나칠 정도로 알아먹을 수 있게 노력하려 집중해서 문장을 길게 해석하곤 하는데, 실제 번역할 때는 필자의 방식이 옳지 않은 방식입니다. 그러니 초창기 번역하신 분들의 해석이 맞는 방향입니다. 처음 번역하신 분들이 틀린게 아니라, ISTQB 자체가 이에 대한 설명을 좀 적게 한다고 보시는게 좋겠습니다. 그래서 필자들이 이런 블로그를 만들고 글을 쓰고 있습니다.

소프트웨어 테스팅과 소프트웨어 품질관리 등 용어를 정리해볼까요?

소프트웨어에서의 테스팅과 품질 관리 등 우리가 흔히 사용하는 용어들은 여러가지로 표현할 수 있지만, 굳이 용어들을 연관시켜 이해하자면 아래와 같이 설명할 수 있습니다.

용어	설명
소프트웨어 Testing - 테스팅	테스팅은 소프트웨어 내에 오류가 있음을 증명하기 위한 활동이다. 소프트웨어 테스팅 활동은 단순히 완성된 제품을 검사하는 활동만을 말하지 않으며, 소프트웨어 테스팅에 필요한 환경 설정, 문서 리뷰, 테스트 결과와 고객에게서 돌아온 오류를 비교한 실패비용 추적 등까지 포함한다.
소프트웨어 QC - Quality Control - 품질 제어	소프트웨어 테스팅을 수행한 후 소프트웨어 내에서 발견한 오류 데이터를 근간으로 수행한다. 소프트웨어 QC는 제품의 품질 기준을 달성하기 위한 목적으로 제품의 공정에 투입되는 조직 및 조직원들의 "검사(inspection)" 역량을 향상시키기 위한 지속적인 활동이다. QC는 검사를 기준으로 품질을 향상시키는 관점이며, 소프트웨어에서의 검사 기법은 거의 테스팅과 관련된 기법들이다.
소프트웨어 QA - Quality Assurance - 품질 보증	소프트웨어 테스팅을 수행한 후 소프트웨어 내에서 발견한 오류 데이터를 근간으로 수행한다. 소프트웨어 QA는 소프트웨어 오류의 문제점을 분석하고, 소프트웨어의 품질 특성 지표를 만들어 내어 소프트웨어 공학이나 프로세스를 도입하는 등 개선을 통해 오류의 발생을 "예방(prevention)"하도록 하기 위한 지속적인 활동이다. QA는 조직 내 문화와 프로세스를 개선함으로써 당연히 발생하지 않아야 할 오류들로 생기는 낭비를 줄여, 품질을 향상시키는 관점으로 접근한다.
소프트웨어 QM - Quality Management - 품질관리	소프트웨어 QC와 QA 활동을 통해 고객의 요구사항을 충족시키고, 사업에 필요한 제품의 품질 기준/요건을 만족시키도록 하며, 제품 관련 규제 기준에 맞게 제작되도록 하며, 소프트웨어를 제작하는 엔지니어들의 여러 작업 요구사항들을 충족시키는 일련의 활동을 기반으로 한다. 소프트웨어 QM은 조직이 제품 및 서비스를 제공하는데 사용되는 수단(QC, QA)이 일관되도록 조직 내에서 수행하는 다양한 활동과 작업, 결과의 수준과 개선 활동의 수준 등을 지속적으로 감독하고, 수행하며, 유지하기 위한 활동이다.

위의 정의들은 Wikipedia의 내용을 보고 필자가 번역한 내용입니다. 영문 내용과 다른 부분을 발견하시면 소프트웨어 테스트 전문가 커뮤니티에 알려주세요.

흔히 위 용어들을 설명할 때, 어떤 분들은 어떤 용어가 더 크고 다른 용어를 포함한다거나, 어떤 정의가 더 작고 세분된 활동이라는 식으로 표현하시곤 합니다. 그게 맞을 수도 있습니다. 하지만, QA와 QC는 제품이나 산업군에 따라 서로 같은 의미일 수도 있고, 전혀 다른 활동일 수도 있기 때문에 정확히 상하 관계를 용어로만 구분지을 수는 없습니다. 그러므로 필자들은 위 용어들을 정리하며 어느 것이 더 큰 개념이고, 더 중요한 개념이라는 의미로 정리하지 않았습니다. 위의 내용은 각 용어는 각기 목적하는 바와 개념이 서로 다름을 설명하려 했습니다.

위 용어를 정리하고 보니 결국 소프트웨어 테스팅의 정의와 이해가 가장 중요한 근본처럼 보이네요. 소프트웨어 테스팅과 관련된 내용에 대해서는 많은 국제 표준들에도 정의되어 있고, IEEE/ISO/IEC 29119 표준을 참고하면 좀 더 명확한 내용을 보실 수 있습니다. 이 블로그에서도 ISO 25010과 관련된 테스트와 품질 이야기에서 대략적인 내용을 언급하였으므로 참고하여 주세요.

'Quality'는 '품질'로 번역되어도 되는걸까?

사실 이 글에서 설명하고 있는 모든 내용의 근원적 오해는 「① QA와 Testing이 같다는 오해」와 「② Quality Assurance에서 Quality를 '품질'로 번역하는 오해」에서 발생합니다. 또한 이런 오해들이 발생하는 이유는 「'제품의 품질'과 '프로젝트의 품질'은 서로 다를 수 있다」는 점을 쉽게 간과하기 때문에 발생합니다. 한 회사 내에도 제품의 품질을 고민해야 하는 사람들과 사업 운영상의 여러 요소들(프로젝트 품질)을 고민해야 하는 사람들이 동시에 존재하기 때문에 흔히 혼동하지만, 결코 쉽게 해결되지 않는 문제이다보니 "다들 그렇게 해"라며 깊게 생각하지 않는 경우들이 많습니다.

이 글을 읽으시는 분이 만약 '품질관리(Quality Management)' 라는 분야에서 나름대로 "전문가" 수준까지 도달하고 싶다면, 반드시 소프트웨어 제품의 품질과 프로젝트의 품질을 구분하실 수 있어야 한다는 필자의 의견을 전달하고 싶습니다.

테스트 전문가로 살다보면 한 번쯤 '제품 품질'과 '프로젝트 품질'에 대한 고민을 하게 됩니다. 그 생각들을 이어가면 그 다음은 「Quality Assurance에서 Quality가 '품질'로 번역됨」에 이상함을 느끼게 됩니다. QA라는 말은 대체 뭘 보증한다는 의미일까요?

소비자 관점에서의 '제품 품질'은 실무자들이 생각하는 품질과 정확히 같지 않을 수 있습니다. '제품 품질'에서는 흔히 사람들이 막연하게 '품질'이라는 단어에서 느끼는 '뭔가 좋은 경험을 주고, 올바르고, 제대로 된 것' 즈음의 느낌을 말하는 경우가 많기 때문입니다. 명확하게 측정할 수 있는 경우도 있지만 그렇지 못한 경우도 많습니다. (관련한 내용은 본 블로그의 다른 글인 "품질 수준에 대한 자신감 획득" 관련 포스팅을 참고해 주세요.)

프로젝트 관리 관점에서의 Quality는 사업 운영에 대한 관점을 의미합니다. 「투자 대비 효율에 기준한 결과」를 의미하는 경우가 더 많습니다. 투자 금액, 투자 인력, 투자 시간 등을 고려하는 측면으로 접근하는 거죠.

자, 그러면 우리가 매일의 일상 업무에서 말하는 품질은 '제품' 측면일까요? 아니면 '프로젝트' 측면일까요?

정답은, 둘 다입니다. 왜냐하면 일반적인 경우 이를 명확히 구분하지 않고 혼용해서 사용하기 때문입니다. 이를 구분하는 행위가 실무적이지 않다고 느끼는 경우들이 대부분입니다. 그리고 이들을 명확히 구분하지 않기 때문에 프로젝트 참여자들간의 이해 문제가 발생합니다. 자신들이 수행하는 업무에 따라서 품질 기준을 다르게 해석할 여지를 주는거죠. 관점 차이입니다.

혹시라도 이 글을 읽으시는 독자의 주변에 있는 누군가가 "Quality Assurance에서 Quality의 번역은 품질이 아니다."라고 말하는 사람을 찾는다면 그에게 음식을 대접하든, 치맥을 사주든, 무엇을 하든, 어떻게든 친해지시길 바랍니다. (물론 필자에게 사줘도 됩니다. 미리 감사합니다.) 왜냐하면 그런 사람은 품질 기준을 명확히 수립할 수 있는 사람일 가능성이 매우 높기 때문이며, 사실 이런 사람이 많지 않습니다.

Quality Assurance에서 영어 단어 Quality의 어원은 무엇일까요?

quality | Search Online Etymology Dictionary

The online etymology dictionary is the internet's go-to source for quick and reliable accounts of the origin and history of English words, phrases, and idioms. It is professional enough to satisfy academic standards, but accessible enough to be used by any

www.etymonline.com

위 사이트는 영어 단어의 어원을 설명하는 사전입니다. 이 사전에서 말하길 Quality의 어원은 '어떤 성격, 자연스러움, 상태'를 의미한다고 합니다. 현재는 영어 문화권 사람들도 'Quality'라는 단어를 우리 말 '품질'이라는 단어와 비슷하게 인식하지만, Quality라는 단어의 어원을 찾아보면 그 단어의 의미 자체는 '원래 가지고 있었어야 하는 어떤 자연스러운 상태'를 의미한다고 보아야 합니다. 즉, 국제 표준에 의거하여 물컵의 품질을 이야기하는 것은 물컵 자체가 가지고 있어야 하는 어떤 자연스러운 특성과 상태를 표현한다는 의미입니다.

그럼 우리 선배님들이 번역을 잘 못한 것일까요? 한글 사전에는 어떻게 나와있을까요?

국립국어원 표준국어대사전

선택 항목 어휘, 구성단위, 고유어 여부, 원어, 어원, 주표제어, 부표제어, 발음, 활용, 검색용 이형태, 품사, 공통 문형, 의미 문형, 공통 문법, 의미 문법, 뜻풀이, 용례, 범주, 전문 분야, 속담, 관

stdict.korean.go.kr

한글로도 '품질'이라는 단어는 "물건의 성질과 바탕"이라고 되어 있습니다. 영어의 어원과 거의 비슷한 용어로 사용된다는 의미입니다.

그러니, 번역이 잘 못된 것은 아닙니다. 본 포스팅에서 제기하는 문제는 이렇습니다.

우리는 Quality Assurance라는 업(業)이 무엇인가를 고민하기 전에 Quality라는 영어 단어에 집착하고, 그 뒤 Assurance라는 단어에 집착하기 때문에 'Quality = 품질, Aaurance = 보증'이라는 식으로 되어서 QA를 흔히 '품질 보증'이라고 인식합니다. Quality Assurance가 무엇이며 어떤 활동이냐를 탐구하는 데에 집중하기보다, 그 단어들에 먼저 집중하게 되기 때문에 발생하는 인식의 문제입니다. 또한, "품질" 이라는 단어를 받아 들일 때 막연하게 "좋다, 싫다"라는 개인의 감정과 연계되어 읽히기 때문에 발생하는 문제이기도 합니다.

이를 옳은 방향으로 변화시키려면 품질은 단어의 어원 그대로 그냥 '기준, 성질, 어떤 상태' 정도의 의미라고 해석해야 한다는 의미입니다. 그러므로, 「Quality Assurance」를 번역할 때는 ('품질보증' 보다는) 이 업이 지향하는 바를 고려하여 '제품/프로젝트의 기준의 옳고/그름을 증명하는 행위'라고 해석되어야 합니다.

한 마디로 말해 "Quality Assurance"라는 업(業)의 한글명은 "품질 보증" 이라 쓰고 "(제품 혹은 프로젝트의) 기준 만족/준수 보증"으로 해석해야 합니다.

'품질이란 무엇인가?'에 대한 고찰을 다루기엔 글이 너무 길어질 거 같기도 하고, 단어의 어원 정도로도 충분히 논리를 풀어갈 수 있기 때문에 「공학적 관점 + 실무적 관점에서의 품질에 대한 이야기」는 필자들의 개인 블로그에서 따로 설명하기로 하겠습니다.

프로젝트 관리 관점에서의 품질관리

프로젝트 관리는 경영을 목적으로 수행하는 행위입니다. 그리고 이 프로젝트 관리 관점에서 품질관리를 바라보자면, 제품/서비스의 품질과 프로젝트의 품질은 다르기 때문에 사업을 진행하면서 제품/서비스의 모든 품질 기준을 만족시키는 경우는 거의 없습니다. 대부분의 경우 제품/서비스의 어떤 부분을 포기하는 댓가로 다른 부분의 장점을 살리는 형식으로 사업이 흘러가게 됩니다.

소프트웨어 테스팅을 수행하는 목적은 소프트웨어 제품 내의 상황을 판단하기 위해 오류를 검출할 목적으로 수행하는 행위입니다. (실제로 이것이 영어로된 여러 국제표준들에서 Testing의 정의입니다.) 그리고 품질관리를 수행하는 목적은 '투자 대비 효율'을 증가시키기 위해 '생산성 증가'를 목적으로 하는 프로젝트 관리 및 경영을 목적으로 하는 행위입니다. 그 모든 세부 활동들을 나열하여 설명하기에는 너무 내용이 방대하므로 이 정도로만 설명할까 합니다.

어쨌든, 위에서부터 쭉 설명한 그런 내용과 같이 Testing과 QA는 업(業)의 원론적 의미로도, 단어의 의미로도 결코 같은 의미가 될 수 없습니다. 하지만 산업군에 따라 서로 상호 보완적이기도 하고, QA를 수행하기 위한 목적으로 Testing을 수행하기도 하며, 또 어떤 산업군에서는 그냥 Testing과 QA 활동이 아예 다른 활동일 수도 있습니다. ISTQB는 바로 그 점을 설명하고 있습니다.

필자는 애자일을 도입한 회사에서의 실질적인 품질보증 활동은 CTO가 책임지는 영역이라 생각합니다. 변화하는 요구사항에 맞게 대응하며 품질기준을 변화시키기 때문에 테스트 전문가 혹은 QA가 모두 Tracking하며 관리하기 무척 어렵기 때문입니다. 그러므로, 대충 연봉이 낮은 QA를 뽑아서 맡겨놓으면 품질관리가 잘 될거라 믿고 계시면 안됩니다. 이와 관련해서는 너무 길어지지 않도록 필자가 개인 블로그에 의견을 개재할 예정입니다.

결론 : 다시 질문으로 돌아가서 "그래서 테스팅과 품질 보증은 같은 활동인가?"

앞서 설명한 바와 같이 "테스팅, Testing"과 "품질 보증, Quality Assurance" 라는 표현 자체에는 문제가 없습니다. 그러나 그 각 표현을 받아들이는 개인들이 그 단어들에서 느끼는 개인적인 감정, 선입관, 개인 기준이 이미 과거의 경험 및 무언가에 의해 형성되어 있기 때문에 마치 같은 활동으로 느껴지기도 하고, 다른 활동으로 보이기도 함일 뿐입니다.

자, 그래서 필자들의 결론은 이렇습니다.

테스팅을 수행 해서 품질보증이 이루어지는게 아니라, 품질보증 활동 중 하나가 테스팅입니다. 무엇이 더 큰 개념, 작은 개념인게 아니라 두 개가 서로 다른 목적을 지향하고 있다... 라고 표현하겠습니다.

이를 명확히 풀어서 말하면 아래와 같습니다.

(1) 테스트를 열심히 수행한다고 해서 품질이 향상된다고 보장할 수는 없으나, 품질을 향상하려면 올바른 테스트를 해야 한다.

(2) 무슨 테스트를 왜, 누가, 언제, 어떻게 하느냐를 결정하는 바가 중요한 것이고, 그에 대한 후속 조치로 공정의 프로세스 개선이나, 사업 프로세스 개선까지 이어져야만 품질이 개선되고, 조직의 생산성이 향상되며, 이를 통해 품질이 보증된다.

(3) 이런 테스트를 구성하고, 관리하고, 품질 관리 영역까지 확대할 수 있는 건 다양한 분야에서 경험을 한 오랜 경험과 경력을 가진 전문가가 필요하다.

그 외 - 필자들의 사족

사족1. 사실 "실무에서 Testing과 QA는 다른가? 같은가?" 라고 하는 부분에 대한 이야기는 소프트웨어 테스팅과 품질 커뮤니티에서 1년에 한 두 차례 씩은 거대하고 격한 논쟁이 벌어지기도 하는 논제입니다. 어떤 분들은 테스팅과 품질 관리는 같은 선상에서 해석해야 한다는 생각을 가지고 계시고, (필자들과 같은 생각을 가지신) 어떤 분들은 두 개가 연관은 되어 있되 다른 활동이므로 다른 선상에서 해석해야 한다는 생각을 가지고 있기 때문에 좁혀지지 않는 논쟁은 현재도 계속 되고 있습니다. 필자들은 이를 분리하고, 서로 다르게 이해해야 한다는 입장입니다. 최근에는 Quality Audit 관련 글이 올라와서 또 한참 뜨거워졌었네요.

사족2. 사실 이 이야기는 우리 SW Tester 커뮤니티에서는 한 12여년 전부터 꾸준히 논의해오던 이야기 입니다만... 다시 한 번 강조해봅니다. 필자들의 입장에서는 테스트 인력을 채용할 때도 부르는 직무를 QA라 하지 말고 Test Engineer라 해야 맞는 표현이라 주장해 왔습니다.

사족3. 동시에 이 글을 읽으시는 분은 오늘부터 "QA합시다, QA했어요? QA기간"라는 말 대신 "테스트 합시다, 테스트 했어요? 테스트 기간"으로 고쳐서 말해 보는건 어떨까요? (개발생명주기 합시다, 개발생명주기 했어요? 라고 말하지는 않잖아요. QA는 활동의 집합히며, Testing과 동일한 단어가 아닙니다.)

사족4. 흔히 "Quality"는 "품질"이라고 번역 됩니다. 하지만, QA에서의 Quality는 "품질"이라 번역되면, 이에 대해 사람들의 오해가 발생할 수 있습니다. 그러므로, QA(Quality Assurance)는 '품질 보증'이 아니라 '기준 적합성 보증'이라 번역하는게 더 옳으며, "QA라는 업(業)"을 더 잘 표현한다고 볼 수 있습니다.

참여자 정보

• 글쓴이 : 천년나무

• 검토한이 : 품생품사, 아이티마니, 현의노래, Bykj

STEEG 개인 의견

※ STEEG 전문가들의 개인 의견은 각 전문가 개인이 경험한 경력에 따른 주관적 견해입니다.
이런 개인 의견들의 경우는 그룹 전체의 의견을 대표하지 않음을 알립니다.

본 글과 관련한 전문가 의견이 아직 없습니다.

[팀블로그] 소프트웨어 테스팅 참고서