테스터를 QA라 부르는 현상. Methodoloy

테스터와 QA는 다르다. 
- 테스트(quality control - after the fact) 
- QA(quality assurance - built into the product)
용어의 오용에서 기인하는 문제에 대해 생각해 볼 부분이 있다.

1. 팀 업무, 정체성 혼동
팀 명칭을 틀린 용어로 사용하는건
팀 업무와 정체성에 대해서 틀리게 혹은 다르게 인식하고 있다는 증거다


2. "품질 = 결과 확인"이란 잘못된 인식 강화
다른 말로 '과정은 품질과 별개'란 인식이 강화된다
우린 과정만 통제할 수 있다. 품질 향상은 과정의 향상을 통해 획득된다
따라서 결과물의 품질을 향상 시키려는 QA는 과정에 많은 리소스를 할애한다
조직이 과정을 품질관리 대상으로 인식하지 못하면 품질을 좌우하는 근본적인 부분을 놓치게 된다


3. 테스트 이전 활동에 대한 품질인식 저하
테스트를 품질로 동일시 하는 조직에선 테스트 이전 활동에 대한 품질 인식이 낮다.

소프트웨어 엔지니어링에 상식적인 것들이 있다
- 구축 완료 후 테스트는 제품 품질에 영향을 주는 일부 요소, seguetech
- 결함 제거 비용, 설계(x1), 구현(x6.5), 테스트(x15), 운영(x100), ibm sci
- 첫 테스트 케이스를 실행하기 전에 리뷰를 통해 오류의 90%까지 제거 가능, IEEE 2001
- 오류의 대부분은 요구사항 및 설계단계의 오류로 전체 결함 비용의 64%, journal of dse

품질향상 비용 효과성은 테스트 이전 활동들이 높다. 상식이다

그래서 QA는 테스트 이전의 프로세스와 프로덕트 품질 개선 활동들을 활발히 진행한다.
하지만 이름만 QA인 테스트팀을 가진 조직에선
이러한 활동을 수행하거나 관심을 갖긴 커녕 인식 조차 없다
품질을 결과확인으로 바라보는 의식이 조직에 굳게 자리잡았기 때문이다.


4. 정체되는 조직
소프트웨어 개발 조직의 성숙도를 알아볼 수 있는 CMMI란 성숙도 모델이 있다
여기서 PPQA(프로세스와 제품 품질보증)와 MA(측정과 분석)란
프로세스 영역은 성숙도 레벨 2(managed - 관리가 존재하는 조직)에서 등장한다

이것을 풀어 말하자면 관리되고 향상되는 조직은 
제품, 과정, 과정을 좌우하는 요소들에 대해서 점검, 측정, 분석, 개선하는 태스크들을
조직 차원에서 롤, 직무, 프로세스로 명시하고 수행하며 관찰/개선이 이루어진다는 의미다
조직에 이러한 부분이 없다면 CMMI 레벨1, 개인역량이 전부인 조직이라 할 수 있다

QA란 이름의 테스트팀을 가진 조직에선 팀 롤이 테스트로 규정되었기 때문에
프로세스 품질과 프로덕트 품질 영역이 공란으로 남겨지기 마련이다
그렇게 품질 향상의 근간이 되는 PPQA, MA 영역이 방치된다. 

그래서 이러한 조직은 공식적인 롤, 권한, 직무가 없기 때문에
대개 조직의 자산이 빈약하고, 프로세스와 기법이 낙후되어 있다
후진적 기법, 프로세스에 허덕이며 무엇이 문제인지 모르는 사태를 겪기 쉽다
문제는 조직이 대격변을 겪지 않는 이상 조직의 현상은 유지되고, 후진성 또한 지속된다는 점이다

측정하고 향상해야 할 부분은 언제까지고 개인 성향과 능력에 좌우되고
조직의 지식과 자산으로 누적되고 향상되어야 할 부분은 계속 공란으로 유지된다
역량이 뛰어난 개인이 있어도 직무, 성과와 무관하므로 조직에 쌓이지 않고 소실되기 쉽다.
그렇게 조직은 정체된다.
(self organized란 이름의 조직들이 스스로 기법을 개선하거나 도출하지 못하고
(유행이 휘몰아칠때까지 현상을 그대로 유지하고 정체되는 이유를 생각해 보자


5. 쓸모없는 QA팀
개발자나 관리자의 리소스 낭비를 막기 위한 지원이 주 업무인 QA팀들이 있다.
결과 확인과 리포트가 주 업무로 테스트 작성, 관리, 진행, 확인, 보고, 사업관리 지원을 한다.

정체성이 리소스 낭비를 막기 위한 팀인 경우
개발 전문성, 관리 전문성이 없으면서 현상/결과를 보고하다 보니
개발팀과 관리팀 입장에서 반갑지 않은 팀, 무능의 아이콘으로 취급되기 쉽다

과정에 어떠한 도움도 없이 결과만으로 현상을 해석하려 하고
리소스 절약을 위한 롤인데도 리소스를 크게 증가시키는 피드백을 하니
일을 하는 사람들은 달가워 하지도 않고 크게 필요로 하지도 않는다

그래서 QA란 이름의 테스터, 지원 인력들은 무능하다는 평가를 듣고
시간이 지나도 전문성이 생기지도 않고 커리어가 나아지지 않는다
그렇게 이름만 QA인 팀은 스스로의 정체성, 미래, 업무에 대해 고민하곤 한다
(연 수백~천억 이상 매출을 올리는 대기업들의 QA팀도 그러한 경우를 본다


결론, 테스트팀은 테스트팀이라고 호칭하면 된다.
QA라 칭하는 테스트팀도 그러한 팀을 가진 회사도 
몇 분 시간을 내서 위키에서 QA항목을 읽어봤으면 좋겠다.


## 잡다 ##

- 테스트가 중요치 않다는게 아니다. 테스트는 테스트고 QA는 QA다.

QA 채용공고에 필요역량으로 테스트 케이스 작성, 테스트 수행, ISQTB.. 
  이런 것들이 적혀있다. 테스터 채용이 맞다.

- 프로젝트에서 QA가 하는 일을 적어보면 테스트와 다름을 알 수 있다.
  QA는 프로젝트 계획을 돕고 개발/관리 프로세스와 기법을 정의, 가이드, 교육, 개선한다
  (진척, 소통, 관리 대상, 이슈, 위험, 형상을 규정하고 관리하는 방법을 정의한다
  (수행사의 개발/관리 프로세스를 수용하는 유형별 개발 프로세스
  (요구, 분석, 설계, 이행 기법, 절차, 산출물, 샘플, 가이드, 체크리스트를 제공하고 교육한다
  (분석하거나 설계할 때 도움이 필요한 인력, 팀에 도움을 준다. 기법을 개선한다
  활동과 결과를 측정, 분석, 모니터링, 통제하고 결과가 기대와 일치하는지 확인한다
  관련, 문제 발생시 대안을 제시한다. 위험/이슈 완화 계획 수립에 참가한다.
  (맨먼스 미신에서 언급되는 상황 - "지체되는 프로젝트에 개발인력을 더하는건 의미가 없다"
  (이런 상황에서 무얼 어떻게 해야 하는지 아이디어, 해법을 제공하는 것도 QA다
  (개발/관리 프로세스 정의 책임이 있기 때문에 그러한 활동을 한다.

- 레거시에 기능을 덧붙여 나갈때 겪는 어려움을
 기법과 조직 차원에서 해결책을 개발자와 함께 만들어 가는 것도 QA다
 보통 개발조직에선 이걸 개인의 윤리, 프로의식으로 취급하지만 그렇게 다루어질 건이 아니다
 (레거시에 기능을 덧붙이거나 차츰 리팩토링해가며 개선해 나가는 작업이 쉬웠으면
 (애초에 프로젝트가 발생할 일이 생기질 않는다. 개인 차원의 문제가 아니다
 



덧글

댓글 입력 영역