잔글편집 요약 없음 |
편집 요약 없음 |
||
| 5번째 줄: | 5번째 줄: | ||
흔히들 다 된 제품 검사해서 하자찾는 사람 정도로 생각되는 직책이지만, 본질적인 QA의 의미는 생산의 전 프로세스를 모두 관리개선하는 것이다. QA의 품질이란 생산된 제품의 것만을 뜻하는 것이 아니라 기획부터 사용자 반응까지 포함하는 포괄적인 의미인 것이다. 예를 들어 [[컵]]을 생산하는 공장에서 '튼튼한 컵'을 목표로 신제품을 내놓는다고 할 때, 신제품 기획단계에서 깨지기 쉬운 재료를 주 재료로 채택해버리면 공정을 어떻게 하고 검품을 어떻게 하든 결국 나오는 제품은 쉽게 깨지는 컵이 되지만<ref>굉장히 멍청한 예시같지만, [[기획]]이 개판이라 처음부터 답이 없는 상황은 현업에서 의외로 자주 일어나는 일이다!</ref>, QA가 기획단계에 개입해 '이 재료는 너무 깨지기 쉽지 않은가?' 라며 기획수정요구를 한다면 재료를 튼튼한 것으로 바꿀 수 있다는 것이다. 이렇듯 QA가 하는 일은 단순한 테스트가 아니라 [[소비자]]의 요구 및 기획 의도와의 끊임없는 [[교차검증]]이며 완성된 제품의 테스트는 그 일련의 과정 중 일부에 지나지 않는 것이다. | 흔히들 다 된 제품 검사해서 하자찾는 사람 정도로 생각되는 직책이지만, 본질적인 QA의 의미는 생산의 전 프로세스를 모두 관리개선하는 것이다. QA의 품질이란 생산된 제품의 것만을 뜻하는 것이 아니라 기획부터 사용자 반응까지 포함하는 포괄적인 의미인 것이다. 예를 들어 [[컵]]을 생산하는 공장에서 '튼튼한 컵'을 목표로 신제품을 내놓는다고 할 때, 신제품 기획단계에서 깨지기 쉬운 재료를 주 재료로 채택해버리면 공정을 어떻게 하고 검품을 어떻게 하든 결국 나오는 제품은 쉽게 깨지는 컵이 되지만<ref>굉장히 멍청한 예시같지만, [[기획]]이 개판이라 처음부터 답이 없는 상황은 현업에서 의외로 자주 일어나는 일이다!</ref>, QA가 기획단계에 개입해 '이 재료는 너무 깨지기 쉽지 않은가?' 라며 기획수정요구를 한다면 재료를 튼튼한 것으로 바꿀 수 있다는 것이다. 이렇듯 QA가 하는 일은 단순한 테스트가 아니라 [[소비자]]의 요구 및 기획 의도와의 끊임없는 [[교차검증]]이며 완성된 제품의 테스트는 그 일련의 과정 중 일부에 지나지 않는 것이다. | ||
=== 테스팅 과정 === | |||
위에 저렇게 적어놓긴 했지만 업무량으로 따지면 테스트가 가장 큰 부분인것은 엄연한 사실이다(...). 소규모 업체라면 엑셀 등의 프로그램을 사용하여 단순히 관리를 하지만 좀 더 전문화되면 테스팅 솔루션 소프트웨어를 구매해 사용하게 되며, 형상관리 프로그램도 사용하게 된다. 테스팅 과정은 단순히 기본 기능만 슥 둘러보는게 아니라, 가능한한 모든 케이스를 테스트 해야한다. 그래서 정말 뻔한 행동들을 엄청나게 반복해야 한다. 특히 하드웨어 QA보다 소프트웨어 QA에서 이런 반복노동이 더욱 두드러지는데, 이유는 다른 것 없이 '''버그'''때문이다. 무슨 문제가 어디서 어떻게 터질지 모르는게 현대의 소프트웨어이므로(...), 정말이지 뻔해보이는 과정을 살뜰하게 테스트 해야된다. 가령 윈도우즈의 내장 소프트웨어인 노트패드를 테스트한다고 할 경우, 일단 실행에서부터 더블클릭으로 실행, 우클릭 후 실행으로 실행. 클릭 후 엔터키로 실행, 탐색기에서 실행, 커맨드 프롬프트 상에서 실행, 바로가기로 실행 등 적게 잡아도 5개가 넘어간다. 도대체 어느 미친놈이 윈도우 환경에서 커맨드 프롬프트를 열어서 노트패드를 실행하느냐고 반문한다면, 아마 당신은 QA와는 영 맞지 않는 사람일 것이다. <s>그런 미친놈은 생각보다 많다.</s> 뭐 이정도야... 라는 생각이 든다면 기본 기능이자 핵심기능인 키보드 입력에 대한 테스트케이스는 과연 몇 개일까를 생각해도록 하자(...). | |||
이렇듯 테스트 작업은 단순반복 속에서도 집중력을 잃지 않아야 하는 기계적인(?) 정신력을 요구함과 동시에 자주 발생하는 결함, 이전에 발생했던 결함 등에 대한 직관적 테스트 및 신속한 테스트가 요구될 때 최대한 빠르게 테스트 하면서도 테스트 신뢰도룰 낮추지 않는 방법 강구 등 인간의 경험과 직관 역시도 요구하는 골치아픈 작업이다. | |||
== 하드웨어 QA == | == 하드웨어 QA == | ||
2015년 5월 14일 (목) 21:55 판
Quality Assurance 품질관리. 줄여서 QA라고도 부른다. 게이머들에게 QA란 말은 왠지 익숙한데 Quality Assistance로 아는 사람이 많다고충공깽
개요
QA는 모든 유/무형의 생산에 관여하여 생산되는 품질의 개선을 꾀하는 직책이다. 현장 생산직(공장 등)에서는 QC(Quality Check)라고도 한다.
흔히들 다 된 제품 검사해서 하자찾는 사람 정도로 생각되는 직책이지만, 본질적인 QA의 의미는 생산의 전 프로세스를 모두 관리개선하는 것이다. QA의 품질이란 생산된 제품의 것만을 뜻하는 것이 아니라 기획부터 사용자 반응까지 포함하는 포괄적인 의미인 것이다. 예를 들어 컵을 생산하는 공장에서 '튼튼한 컵'을 목표로 신제품을 내놓는다고 할 때, 신제품 기획단계에서 깨지기 쉬운 재료를 주 재료로 채택해버리면 공정을 어떻게 하고 검품을 어떻게 하든 결국 나오는 제품은 쉽게 깨지는 컵이 되지만[1], QA가 기획단계에 개입해 '이 재료는 너무 깨지기 쉽지 않은가?' 라며 기획수정요구를 한다면 재료를 튼튼한 것으로 바꿀 수 있다는 것이다. 이렇듯 QA가 하는 일은 단순한 테스트가 아니라 소비자의 요구 및 기획 의도와의 끊임없는 교차검증이며 완성된 제품의 테스트는 그 일련의 과정 중 일부에 지나지 않는 것이다.
테스팅 과정
위에 저렇게 적어놓긴 했지만 업무량으로 따지면 테스트가 가장 큰 부분인것은 엄연한 사실이다(...). 소규모 업체라면 엑셀 등의 프로그램을 사용하여 단순히 관리를 하지만 좀 더 전문화되면 테스팅 솔루션 소프트웨어를 구매해 사용하게 되며, 형상관리 프로그램도 사용하게 된다. 테스팅 과정은 단순히 기본 기능만 슥 둘러보는게 아니라, 가능한한 모든 케이스를 테스트 해야한다. 그래서 정말 뻔한 행동들을 엄청나게 반복해야 한다. 특히 하드웨어 QA보다 소프트웨어 QA에서 이런 반복노동이 더욱 두드러지는데, 이유는 다른 것 없이 버그때문이다. 무슨 문제가 어디서 어떻게 터질지 모르는게 현대의 소프트웨어이므로(...), 정말이지 뻔해보이는 과정을 살뜰하게 테스트 해야된다. 가령 윈도우즈의 내장 소프트웨어인 노트패드를 테스트한다고 할 경우, 일단 실행에서부터 더블클릭으로 실행, 우클릭 후 실행으로 실행. 클릭 후 엔터키로 실행, 탐색기에서 실행, 커맨드 프롬프트 상에서 실행, 바로가기로 실행 등 적게 잡아도 5개가 넘어간다. 도대체 어느 미친놈이 윈도우 환경에서 커맨드 프롬프트를 열어서 노트패드를 실행하느냐고 반문한다면, 아마 당신은 QA와는 영 맞지 않는 사람일 것이다. 그런 미친놈은 생각보다 많다. 뭐 이정도야... 라는 생각이 든다면 기본 기능이자 핵심기능인 키보드 입력에 대한 테스트케이스는 과연 몇 개일까를 생각해도록 하자(...).
이렇듯 테스트 작업은 단순반복 속에서도 집중력을 잃지 않아야 하는 기계적인(?) 정신력을 요구함과 동시에 자주 발생하는 결함, 이전에 발생했던 결함 등에 대한 직관적 테스트 및 신속한 테스트가 요구될 때 최대한 빠르게 테스트 하면서도 테스트 신뢰도룰 낮추지 않는 방법 강구 등 인간의 경험과 직관 역시도 요구하는 골치아픈 작업이다.
하드웨어 QA
상기했듯 주로 QC로 칭하는 편이다. 단순 제품 테스트에서부터 제품 프로토타입 생산시 도면을 받아 직접 시험제작하고 수정하는 역할도 수행한다.
소프트웨어 QA
한국의 상황
한국의 소프트웨어 QA는 도입 시기도 늦었고 전문적 교육을 통해서가 아니라 어깨너머식으로 도입된 곳이 많아서 전문화되지 않은 업체라면 QA가 아예 없거나, 잡무를 담당하면서 겸사로 버그도 잡는 수준의 업무와 대우를 받는다. 이런 환경에서는 품질 개선은 커녕 테스트 실패로 버그가 터지면 개발팀 대신 깨지기나 하는 경우가 허다하다. 대기업을 위주로 전문화, 세분화된 QA팀을 꾸려나가고 있는 추세이긴 하지만 갈 길은 여전히 먼 편.