반응형
당신은 QA가 되시겠습니까? QC가 되시겠습니까? 아니면 테스터가 되시겠습니까?
(위 이미지는 오락실에서 많이 즐기던 서유기라는 게임입니다. 개인적으로는 사오정을 많이 즐겨했었드랬습니다.)
지인의 블로그를 살피던 중 재미난 글을 보게 되었습니다.
그 내용은 바로 QA와 QC에 대한 구분입니다. 조직적으로 현실적으로 개념적으로 아주 잘 파악해두셨습니다.
- 트랙백 걸어두었습니다. ㅎ
QA와 QC에 대한 조직의 차이에 대해서 한말씀 거들어서 포스팅합니다.
아무쪼록, 제 경험에 비춰 이야기 하는 것이니 내용이 다소 난해하고 개인적인 성향을 띄더라도 이해해주길 바랍니다.
(응~? 근데 왜 급 존대지? 이왕 이렇게 쓴거 끝까지 이렇게 써보렵니다.)
저는 처음에 테스트 인력이였습니다.
테스트 인력으로 몇년간 주어진 제품에 대한 테스트만 수행하였습니다.
제품을 죽이고 죽이고 죽인 끝에 지금은 관리자 역할을 수행하고 있습니다.
첫 직장에서는 주어진 테스트 케이스를 기반으로 블랙박스 테스팅을 위주로 주로 제품에 대한 검수하는 수준이였습니다. 그리고는 휴대폰 회사에 갔었습니다. 다름아닌 QE팀이였습니다.
그 QE팀에서는 아래와 같은 활동들을 하였습니다.
(위 이미지는 오락실에서 많이 즐기던 서유기라는 게임입니다. 개인적으로는 사오정을 많이 즐겨했었드랬습니다.)
지인의 블로그를 살피던 중 재미난 글을 보게 되었습니다.
그 내용은 바로 QA와 QC에 대한 구분입니다. 조직적으로 현실적으로 개념적으로 아주 잘 파악해두셨습니다.
- 트랙백 걸어두었습니다. ㅎ
QA와 QC에 대한 조직의 차이에 대해서 한말씀 거들어서 포스팅합니다.
아무쪼록, 제 경험에 비춰 이야기 하는 것이니 내용이 다소 난해하고 개인적인 성향을 띄더라도 이해해주길 바랍니다.
저는 처음에 테스트 인력이였습니다.
테스트 인력으로 몇년간 주어진 제품에 대한 테스트만 수행하였습니다.
제품을 죽이고 죽이고 죽인 끝에 지금은 관리자 역할을 수행하고 있습니다.
첫 직장에서는 주어진 테스트 케이스를 기반으로 블랙박스 테스팅을 위주로 주로 제품에 대한 검수하는 수준이였습니다. 그리고는 휴대폰 회사에 갔었습니다. 다름아닌 QE팀이였습니다.
그 QE팀에서는 아래와 같은 활동들을 하였습니다.
- 하드웨어 성능, 호환성 검사 및 개선안 도출
- 소프트웨어 품질 검수 및 개선안 도출
- 전체 프로세스에 대한 개선안 도출 및 사내 교육 전담
- 경쟁 제품과 자사 제품 벤치 마킹 및 리뷰
이러한 일을 하던 중에 이게 왜 QE팀이라는 지 몰랐습니다.
시간이 지난 뒤에 생각해보니 주업무는 물론 품질 보증이였겠지만...
개선안을 도출한다던가 프로세스나 공정에 대한 문제점을 공학적인 요소로 풀어나가는 모습이 영락없는 QE였습니다.
이름하여 Quality engineering 이였다. 그래서 QE였던 것이다.
그러고는 QA 부서로 이직을 하게 되었다.
이곳에서 하는 일을 좀 살펴보니 이랬다.
- 테스트 일정 산정 및 프로젝트의 전체 일정에 참여
- 전체 프로덕트에 대한 품질 관여
- 테스트 결과에 대한 이후 프로젝트 개선
- 테스트 프로세스에 대한 전반적인 개발 라이프 사이클 정리
- 인스펙션, 리뷰, 워크 스루를 통한 양질의 산출물 정리
이 조직의 경우에는 위의 QE보다는 보다 실무적인 접근을 한다라는 생각이었습니다.
하지만, 조금이나마 다른 점이 있다면, 아마도 개발 라이프 사이클에 언져서 비비며 출발한다는 것입니다.
이것이 QE와 QA의 차이라고도 볼수 있겠습니다.
(실제로 이후 QE팀이 존재하는 경우는 많이 보지 못했습니다. 현재는 QA나 QM이 그일을 대신 한다고 생각합니다.)
이로써 QA와 QE에 대해서 제 견해를 조금 알아보았습니다.
그럼 남은 것은 바로 QC와 QM입니다.
수행했던 한 임베디드 프로젝트에서 외부 업체가 QC에 대한 아주 좋은 예를 보여주었습니다.
임베디드 프로젝트의 QC의 역할은 말그대로 조사 및 탐색입니다.
그것은 바로 제품의 품질의 1차적 접근이라고 생각합니다.
그 조직의 QC는 제품에 대한 테스트 접근 방법, 프로세스 및 프로덕트에 대한 산출물에 대한 고민들이 전부였습니다.
그렇게 따진 다면, 이는 QA와 다르게 보다 프로덕트에 중심적인 부분에 집중적인 것으로 알 수 있습니다.
마지막으로 QMO롤을 수행했던 프로젝트의 이야기를 해보겠습니다.
QM는 위에서 이야기했던 모든 부분을 집중하여 관리합니다. 단, 관리자이긴 하지만 모든 부분의 대한 스킬이 있어야 합니다. 이는 프로덕트를 뺀 프로젝트와 프로세스를 뺀 프로젝트는 생각할 수 없기 때문입니다.
만약, 관련 스킬이 부족한 QM들이 있다면, 어서 스터디를 하시기 바랍니다. 이후에는 그런 분들은 삶의 여유없는 1차산업으로 치닫기 좋은 케이스니까요.
주섬 주섬 이런 저런 이야기를 해보았습니다.
구지 제가 생각하는 것을 순서를 매기자면...
QM는 위에서 이야기했던 모든 부분을 집중하여 관리합니다. 단, 관리자이긴 하지만 모든 부분의 대한 스킬이 있어야 합니다. 이는 프로덕트를 뺀 프로젝트와 프로세스를 뺀 프로젝트는 생각할 수 없기 때문입니다.
만약, 관련 스킬이 부족한 QM들이 있다면, 어서 스터디를 하시기 바랍니다. 이후에는 그런 분들은 삶의 여유없는 1차산업으로 치닫기 좋은 케이스니까요.
주섬 주섬 이런 저런 이야기를 해보았습니다.
구지 제가 생각하는 것을 순서를 매기자면...
Test < QC =< QA =< QE <QM
내 경력에 비춰볼 때 이렇다.
누구든지 태클을 걸 수 있을 것이다.
하지만, 자기 영역에 대한 프라이드도 있으리라 믿는다.
이건 지극한 내 생각을 뿐이고, 지극히 내 경험일 뿐이다.
악플을 달려거든... 이에 상응하는 경험과 이론을 펼치셈~ㅋㅋㅋ
ps. 어제는 History, 내일은 Mistery, 오늘은 Present...
오늘을 살아가는 우리가 되도록 합니다. 늘 감사하며~
누구든지 태클을 걸 수 있을 것이다.
하지만, 자기 영역에 대한 프라이드도 있으리라 믿는다.
이건 지극한 내 생각을 뿐이고, 지극히 내 경험일 뿐이다.
악플을 달려거든... 이에 상응하는 경험과 이론을 펼치셈~ㅋㅋㅋ
ps. 어제는 History, 내일은 Mistery, 오늘은 Present...
오늘을 살아가는 우리가 되도록 합니다. 늘 감사하며~
Written By 밤의카사노바
반응형
'Certificate' 카테고리의 다른 글
깨진 유리창의 법칙 - in Software Development Lifecycle (0) | 2010.11.03 |
---|---|
조엘 온 소프트웨어 _ about BOS (0) | 2010.08.24 |
QA 관련 모집요강(?) (0) | 2010.02.03 |
소프트웨어 개발및 시스템 문서화 에서의 품질 관련 규격들 (0) | 2010.01.26 |
베타(Beta)테스트의 진정한 의미! (0) | 2010.01.16 |
댓글