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

테스터와 QA는 다르다. 아래 이미지를 참고하자.
용어의 오용, 기인하는 문제에 대해서 생각해 볼 부분이 있다.

1. 팀 업무, 정체성 혼동
용어를 틀리게 사용하는건 정의를 잘못 이해한다는 증거.
팀 명칭을 틀린 용어로 사용하는건 팀 업무, 정체성에 대한 인식 부족.


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


3. 개발조직의 테스트 이전 제품의 품질인식 저하
"품질 = 테스트"란 인식이 강화된 조직에선 테스트 이전 제품의 품질에 대한 인식이 낮다.
개발팀이 보증할 최소한의 품질, 확인 마저 테스트팀의 책임으로 전가되곤한다.
(너무도 당연한 얘기지만 개발자 손을 떠난 결과물은 원칙적으로 버그가 없어야 한다.

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

품질향상 비용 효과성은 테스트 보다 테스트 이전의 것들이 훨씬 높다.
그럼에도 개발팀은 그러한 인식이 희미해지고 테스트팀의 책임이라는 식으로 인식하는 경우가 잦다.
개발팀의 테스트는 그저 빌드 통과가 목적이 되며 개발 결과물의 실제 품질은 대체로 매우 낮다.
개발조직 - 테스트조직 간 피드백 핑퐁도 잦고 거기서 발생하는 비용이 상당한데도 문제로 인식못한다


4. 정체되는 조직
PPQA(프로세스와 제품 품질보증), MA(측정과 분석)는 
cmmi 레벨 2(managed - 관리가 존재하는 조직)에서 등장한다.
즉, 관리되는 조직은 제품, 만들어가는 과정, 과정을 좌우하는 요소들에 대해
점검하고, 측정하며, 분석하고, 개선하는 일을 명시(롤, 직무, 프로세스로 정의)하고 수행한다.
그와 같은 부분이 없으면 cmmi 레벨1. 개인역량에 좌우되는 조직이라 할 수 있다.

QA란 이름의 테스트 조직은 사실상 테스트 외에 간섭할 권한, 책임, 역할이 없다.
책임, 롤이 모호한 경우 문제 제기, 향상은 분쟁영역이 되거나 누구도 손대지 않는 영역이 되기 쉽다.
관리와 향상의 근간이 되는 PPQA, MA 영역은 방치된다. 그렇게 조직은 정체된다.

ex) 현실에서 결과확인, 리포트만 하는 QA팀을 가진 회사들이 있다.
    이러한 QA팀은 테스트 관리, 작성, 진행, 제출 확인, 취합보고, 사업관리 지원을 주업무로 삼는다.
    이런 조직에선 개인의 역량이 모든 것을 좌우하고 결정한다. 
    과정에 대한 노하우와 역량은 QA팀의 관심사가 아니므로 조직에 쌓이지 않고 그대로 소실된다.
    그래서 그러한 조직은 대개 조직의 자산이 빈약하고, 프로세스와 기법이 낙후되어 있다.
    결과적으로 조직은 이유도 모른체 정체되고 QA들은 무능하다는 평가를 듣고 
    QA 스스로의 정체성, 미래, 업무에 대해 고민하곤 한다. 
    (연 수백억, 수천억 이상 매출을 올리는 대기업들도 마찬가지 모습을 보인다.


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


## 잡다 ##

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

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

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



도메인 모델은 유용할까? Methodoloy

도메인 모델은 두가지 관점에서 유용하다.
1. 설계를 이끌어 가는 도구.
2. 정보와 지식을 집약시켜 문제영역을 학습/소통/향상 시키기 위한 도구.

첫째, 설계를 이끌어 가는 도구로 무엇이 유용할까?
비즈니스 프로세스(유스케이스, 동적관점)  ㄱ
도메인 모델(정적 관점)                     - + 책임할당(GRASP) - 정제 - 설계 모델 + 구현
위은 접근은 과거 객체지향 기법들이 취하는 익숙한 방식이다.
유엠엘 컴포넌트, 유니파이드 프로세스, 도메인주도설계 모두 큰 틀에서 동일하다.

thing, 엔터티로 부터 개념 클래스 후보를 마련하고
각각의 유스케이스와 시스템간 상호작용을 도출한 뒤 개념 클래스에 할당하고
클래스간 협력관계를 보고 전체 구조에 일관성을 더하기 위해 병합/분리 하는 식으로 설계해 나간다.

과거엔 도메인 모델이란 용어는 개념의 정적관계를 나타내는 용어였고
데이터 모델, 설계, 용어집의 근간이며, 개념 설계와 책임 할당의 근간으로 유용했다.
현재 도메인 모델이란 용어는 정적관계 표현 ~ 설계모델 까지를 모두 포함하는 용어로 두루 쓰인다.


둘째, 문제영역을 학습, 소통하기 위한 도구로 유용할까?

초기 도메인 모델은 문제영역의 개념들을 소개한다.
정제된 도메인 모델은 문제영역을 소프트웨어로 해결하기 위한 
개념간의 관계, 개념묶음들간의 관계, 정책을 기술한다. 정적인 관점을 대변한다.
그렇다면 동적인 정보는 도메인 모델 어디에 담길까? 당연한 얘기지만 담기지 않는다.
(단순 도메인 모델이건 행위를 표현한 풍부한 도메인 모델이건 정적인 관점이다.
(간단히 예를들어 보자. 입금 흐름이 도메인 모델에 표현될까?

도메인 모델의 존재 이유에 해당하는
비즈니스 행위들은 정적인 도메인 모델과 분리되어 있다.
물론, 개념들간 연관관계로 행위의 면면을 이해할 수는 있지만 전체를 이해하기엔 부족하다.
비즈니스 모델링의 워크플로우를 보자.
비즈니스 모델링(조직, 워커, 프로세스 정의)과 도메인 모델링 트랙이 분리되어 있다.

비즈니스 프로세스를 SW로 떨어트리는 관점으로 살펴보면 이해가 쉽다.
도메인 모델은 어셈블리 라인들의 관계로 이해하면 된다.
어셈블리 라인과 그 관계를 살펴봐서는 
내부에 개념이 왜 있는지 어떻게 협력되는지 이해할 수 없다
어셈블리 라인이 복잡하고 밀접하게 얽혀있으면 더더욱 이해가 어렵다.
시스템 인터페이스를 분리해낸 비즈니스 타입 모델의 관점에서도도 마찬가지다.
(uml component 149 page)

즉, 정보와 지식을 집약시켜 
문제영역을 학습, 소통, 향상 시키기 위한 도구로 
정적인 관점(구조적 관계, 행위의 의존성)을 갖는 도메인 모델만으론 부족하다다.
동적인 정보나 그에 준하는 단서가 있어야 해석할 수 있다.
동의하기 어렵다면 analysis patterns, ddd, appliying uml and patterns 책을 펴보길 권한다
책에 등장하는 도메인 모델을 봤을때 업무가 머리에 그려질까? 
도메인 모델을 보고 업무에 대해서 설명할 수 있을까? 쉽지않을 것이다.

DDD에서는 설계를 주도하는 모델과는 별개로 설명을 위한 모델의 필요성을 언급한다.
설계를 위한 모델은 이를 해석하기 위해서는 맥락이 수반되어야 한다.
맥락이란 위 이미지 처럼 프로세스 흐름, 프로세스의 이유, 목적, 관련 리소스 이유 같은 것들이다. 
과거에 곧잘 사용되던 분석단계의 프로세스 엔터티 매트릭스도 설명목적으로 활용할 수도 있다.

결론, SE관점에서 도메인 모델은 유용하다.
설계를 이끌어 가는 도구로 유용하며,
개념을 집약하고 구조화하며 차츰 향상시켜 나갈 수 있다.
허나, 도메인 모델의 배경, 맥락을 이해하기 위해선 설명을 위한 모델이 적절히 수반되어야 한다.
도메인 모델은 이후 책임 할당, 구조화, 정제를 거치며 코드로 나아간다.


- 기타 잡다 -

1. 모 서적에선 말-도메인 모델-코드로 민첩하게 가자고 말한다. 

현실에서 그런 방식으로 진행하면 어떻게 될까? 사례를 들어보자. 
차세대 프로젝트에서 재무업무를 개발했던 적이 있다.
고객사 보안정책상 업무 범위를 벗어나는 정보는 의도적으로 차단된다.
그래서 개발자의 손에 쥐어진건 도메인 모델과 말(BA-업무를 설명하는 직원) 뿐이다.

애자일스럽고 가벼운 최고의 환경일까? 전혀,. 
개발이 진행되어도, 개발을 완료해도 업무에 대한 지식이 깊어지지 않았다.왜?

도메인에 대한 근본적인 이해는 도메인 모델에 담기지 않는다.
BA가 말로 전달하는건 why와 what이 빠진 how에 대한 편린이다.
단편적인 말로 도메인의 배경과 의사결정이 반영된 how가 적절한 지를 판단할 수 없다.

설계의 적정성은 상호작용, 관계에 의해서 판단된다.
설계의 이유가 되는 상호작용을 일으키는 업무흐름, 요구사항, 배경에 대한
이해없이 내가 정의한 클래스만 바라봐서는 무엇이 올바른 설계인지 판단할 수 없다.

가령, 재무 컨텍스트는 계약 컨텍스트, 계약의 전체 프로세스에 대한 깊은 이해가 수반되어야 한다.
(당시엔 도메인을 이해하기 힘든 이유가 뭘까 꽤나 스트레스 받았었고
(DDD책을 아마존에서 주문해서 뒤적뒤적 읽곤했다.14년 전 이야기다.

원천적인 맥락에 대한 배경지식은 편린과 휘발되는 '말'이 아닌 다른 형태로 제공되어야 한다.
BA의 단편적이고도 휘발되는 말이 뭔가 민첩해 보이지만 실제론 전혀 민첩하지 않다.
국외 애자일 컨퍼런스나 포럼에서 product manager를 없애자는 성토가 이어지는 이유다.
(지식, 이해가 포함된 합의된 결정이 아닌 product manager에 의존하는 것은 좋지 않은 형태다.


2. 현실에서는 도메인 모델을 차근차근 작성하는 경우는 적다
설계와 구현을 "모델"에서 출발한다는 관점을 취하는 경우가 적거니와
구현에 최대한 가까운 지점부터 출발하여 도메인 모델을 생략하는게 보통이다. 아래처럼 말이다.
요구사항 - 구현
요구사항 - 테스트 정의 - 설계+구현
요구사항 - 후보아키텍처가 적용된 분석모델 + 설계(초기 설계) - 구현 + 테스트
어느정도의 규모가 되는 프로젝트에서는 
DA가 여러 업무로부터 주제영역별 개념 데이터를 획득하고
레거시 모델을 참고해서 개념 모델을 정제하고 업무 분석설계자와 검증하는 식으로 진행한다.


3. 모델의 필요성을 부정하거나 과대평가하는 것만 조심하자
- 대형 SI프로젝트에서는 MDD를 많이 채용하지만 
  작은 시스템,앱 구축 프로젝트에선 구현이 우선이다.
  도메인이 작고 직관적이며 프로세스도 간단하고 정보처리성인 경우가 많기 때문이다.
- 현실에서는 간단한 도메인들이 많다.
  따라서 MDD(Model-Driven Design)의 필요성을 크게 체감치 못한다.
  그렇다고 해서 그것이 잘못되었다거나 후진적인 것을 의미하진 않는다.
- 도메인이 단순하면 설계와 업무설명을 요약한 작은 sheet로도 충분하다. 괜찮다.

4. 이해를 돕는 책들
  business modeling with uml - 비즈니스 view의 존재 이유, 모델링 하는 방법
                                  - 비즈니스 view를 sw 아키텍처 까지 이어가는 방법.
  applying uml with patterns -도메인 모델의 목적과 전후에 무엇을, 왜, 어떻게 하는지 설명.
  uml component - 개념을 조직하고 책임을 할당하는 방식에 대한 이해 획득.
  analysis patterns - 도메인 모델 레퍼런스
  lean architecture - 구조에 컨텍스트를 분산시킨 것의 문제점에 대한 이해
  domain driven design - ddd관점에서의 도메인 모델.

5. 혼란스러운 용어
같은 의미를 갖는 것도 있고 다른 의미를 갖는 것도 있다.
   비즈니스 컨셉 모델, 비즈니스 타입 모델, 비즈니스 오브젝트 모델, 
   도메인 모델(일반적인 용어), 도메인 모델(DDD), 개념 데이터 모델..
- 참고로, DDD의 도메인 모델이란 용어는 기존의 도메인 모델이란 용어와 완전히 다르다.
- 최근엔 도메인 모델을 ORM의 모델 용어나 
   Hexagonal architecture 레이어 의미로 사용하기도 한다. 
- 도메인 이라는 말을 남발했지만 현실에선 도메인이란 용어는 줄이는게 낫다.

wow 정복의 섬 - 93.3%의 승률에 대해서.. 휴식

월드오브 워크래프트. 
야전사령관 위업이 있을 만큼 열심히 했었는데 한동안 쉬고 있다.
계정 끊을까 살피던 중 업적과 통계를 봤는데 재미있는게 있어서 올려본다.

[월드오브워크래프트 40인 전장. 정복의 섬 승률 - 93.3%]
- 정복의섬 얼라이언스 승률은 대개 60~70% 내외. 
- 패배직전에 입장한 게임도 그대로 플레이 하고 패배하는 즐겜러의 기록이다.





팀멤버를 사전에 구성하지 않는 개인이
파티원이 유동적인 무작위 전장에서 높은 승률을 기록하는 건 어렵다.
하지만 300번의 무작위 전장 개인신청에 93.3% 승률엔 무언가 있지 않을까? 그걸 얘기하고 싶다.

--
개인의 역량이 남다르면 상황을 극적으로 호전시킬 수 있다.
하지만 뛰어난 개인도 집단으로 보면 가치가 희석되기 마련이다. 
그렇다면 비슷한 역량을 가진 두 그룹의 승패를 가르는 것은 무엇일까? 

난 집단의 경험, 마인드라고 생각한다.
마인드는 순간에 영향을 주고 개개인의 마인드가 복리효과로 거대한 결과로 이어진다.
또, 좋은 경험의 반복은 이기는 방법을 체화시키고 긍정적인 마인드를 가지도록 한다.
(그렇게 평범한 개개인이 1%씩 더 발휘하는 환경이 조성되고 승리의 반복으로 이어진다.


게임내에서 오더를 맡아서 커뮤니케이션을 돕고 분위기를 환기시키고 
불리할 때 입으로만 긍정하기 보다 플레이로 가능하다는 것을 증명하고 동참을 끌어낸다.
가급적 즐겁게 이기거나 지는 방향으로 게임을 한다. 이러한 별거 아닌 행동의 반복이 전부다.
(이러한 것들이 전장에 참여하는 개개인의 경험에 누적되어 
(그것이 어떤 분위기로 정착되고 본인이 게임하는 환경에 플러스로 돌아온다.

93.3%는 그렇게 만들어졌다.

1 2 3 4 5 6 7 8 9 10 다음