테스트는 그 수행 주체와 목적, 환경 등에 따라 크게 4단계의 레벨로 구분한다.
물론 각 조직이나 회사, 프로젝트의 성격, 환경 등에 따라 더 세분화 되는 경우도 있고 축소되기도 하지만 기본적으로 테스트 레벨은
로 나뉘어 진다.
각 테스트 레벨에 대한 자세한 설명은 다른 곳을 참조하시고..
내가 하고 싶은 말은 다른 것이다.
이러한 테스트 레벨은 원래 V-모델이라 불리는 모델에서 나온 것이다.
V-모델은 폭포수 모델의 변형 모델로 폭포수 모델에 테스트 수행에 대한 활동을 강화한 모델이라고 이해해도 무방하다.
즉, 폭포수 모델의 각 개발 단계와 대응되는 테스트의 활동을 도식화 한것이 V-모델이다.
그말은 이 테스트 레벨도 폭포수 모델의 컨셉을 그대로 물려받고 있다는 것이다.
무슨 의미냐 하면 단위 테스팅이 끝나야 통합 테스팅을 할 수 있고 통합 테스팅이 끝나야 시스템 테스팅을 할 수 있다는 것이다.
그래서 테스트 계획 문서에는 시작 조건과 완료 조건 추가로 지연 조건이나 재개 조건과 같은 시작과 끝점에 대한 항목을 협의하여 명시하도록 권고하고 있다.
이러한 테스트 레벨은 테스트 수행 활동을 체계적으로 이해하고 개발 단계와 테스트 단계의 대치점에 대한 이해를 하기에는 좋지만 한가지 취약한 점이 있다.
조금 추상적이긴 하지만.. 품질이라는 관점에서 살펴보도록 하자..
우리는 각 연예인들의 가장 이쁜 부분 또는 가장 호감이 가는 부분만을 모아서 몽타쥬를 만들었을 경우 완성된 모습이 우리가 꿈꾸던 모습과는 사뭇 거리가 있다는 것을 익히 들어서 알고 있다.
중요한 것은 조화이다. 아무리 아름다운 것을 모아 놓는다고 해서 그 전체가 아름답지는 않다.
하지만 우리는 아주 자주 이러한 사실을 잊어버린다.
그것은 우리가 1+1=2라는 논리적이고 수리적인 사고 방식에 아주 익숙해져 있기 때문이다. 하지만 이것이 언제나 참이라고는 죽어도 확신할 수는 없다.
1+1=2가 아닐 수도 있다. 그런 예는 언제 어디서나 차고도 넘치도록 찾을 수 있다. 1+1=2일 수도 있고 그 이상 또는 그 이하일 수도 있다.
이것은 우리 주변의 사물이 분명 수학자들의 주장대로 숫자 위에 있을 수는 있지만 조화라는 과정 종속성이라는 속성에 따라 변하기 때문이다.
테스트 레벨도 마찬가지의 영향을 받는다.
각 테스트 레벨을 아무리 잘한다고 해도 완벽한 테스팅을 했다고 말할 수는 없다.
잘한다는 것과 적절하게 했다는 것은 전혀 다른 의미가 된다.
이것은 ISTQB의 테스팅의 기본원리 7가지 중
과 닿아있다.
많은 경우 테스트 프로세스를 구축하고 개선하는 데 있어서 초점이 빗나간 경우가 많다.
각각의 테스트 레벨에 대해 잘 수행하는 것도 분명 중요하다.
하지만 각 테스트 레벨의 목적이 서로간에 잘 조화되지 못한다면 오합지졸이나 마찬가지이다.
때문에 각 테스트 레벨을 조율하고 목적한 바 즉, 고객이 만족하는 품질의 제품이 개발될 수 있도록 전체적인 품질 지표를 측정하고 결정하기 위한 계획이 필요하다.
즉, 조직 차원의 테스트 정책과 전략이 필요하다는 것이다.
하지만 국내에서 조직 차원의 테스트 정책이나 전략을 가진 조직은 생각보다 찾기가 쉽지 않다.
대부분의 조직은 거의 따로 국밥이다. 개발자들이 하는 테스트는 개발팀에서 테스팅 팀에서 하는 테스트는 QA 부서에서 각자 관리하고 각자의 결과에 대한 커뮤니케이션이 원할하지 못하고 서로의 목적을 모르기 때문에 곳곳에서 충돌이 나고 결국에는 목적하는 품질에 도달하지 못하는 경우를 많이 볼 수 있다.
각 테스트 레벨을 아무리 최적화 한다고 해도 제품의 품질은 나아지지 않는다. 전체적인 입장에서 프로젝트에 관련된 모든 조직과 부서를 아울러 관통할 수 있는 흐름을 살피고 조율할 수 있는 정책과 전략에 대해서 고민하고 계획을 수립할 수 있어야 할 것이다.
최근에 ISO/IEC 29119에서는 이러한 테스트 레벨에 대한 관점에서 벗어나서 소프트웨어의 속성과 목적에 따른 Fundamental Test Process 라는 것을 제안하고 있다. 이 프로세스에는 기존의 레벨 프로세스 뿐만 아니라 보안성, 성능, 사용성과 관련된 특정 테스트 수행에 관련된 프로세스를 모두 언급하고 있다.
중요한 것은 프로세스가 아니라 우리가 원하는 품질 목표를 달성하기 위해 프로젝트에 관련된 모든 부서, 조직, 인원, 자원이 얼마나 효과적이고 효율적으로 계획되고 수행되는 가이다.
단순히 개발자는 단위 테스트를 잘 수행하고 테스터는 시스템 테스트를 잘 수행해야한다는 것이 아니다.
개발자도 고객의 요구와 품질에 대한 인식을 가져야 하고 그에 따라 개발을 하고 테스트를 할 수 있어야 하는 것이고 테스터 역시 제품의 설계와 구성, 작동 원리 등에 대한 기본적인 이해를 가지고 있어야 하는 것이고 그러한 것이 고객의 요구에 최적으로 동작할 수 있도록 구성되었는지 테스트 할 수 있어야 한다.
프로젝트의 모든 구성원이 프로젝트의 목적하는 바 즉, 고객이 바라는 것 그리고 품질에 대한 이해를 공유할 필요가 있다.
그러기 위해서는 부분 최적화의 관점에서 벗어나 전체를 바라보고 기획할 수 있는 조직 차원의 정책과 전략을 수립할 필요성이 있다.
물론 각 조직이나 회사, 프로젝트의 성격, 환경 등에 따라 더 세분화 되는 경우도 있고 축소되기도 하지만 기본적으로 테스트 레벨은
- 단위 테스팅
- 통합 테스팅
- 시스템 테스팅
- 인수 테스팅
로 나뉘어 진다.
각 테스트 레벨에 대한 자세한 설명은 다른 곳을 참조하시고..
내가 하고 싶은 말은 다른 것이다.
이러한 테스트 레벨은 원래 V-모델이라 불리는 모델에서 나온 것이다.
V-모델은 폭포수 모델의 변형 모델로 폭포수 모델에 테스트 수행에 대한 활동을 강화한 모델이라고 이해해도 무방하다.
즉, 폭포수 모델의 각 개발 단계와 대응되는 테스트의 활동을 도식화 한것이 V-모델이다.
그말은 이 테스트 레벨도 폭포수 모델의 컨셉을 그대로 물려받고 있다는 것이다.
무슨 의미냐 하면 단위 테스팅이 끝나야 통합 테스팅을 할 수 있고 통합 테스팅이 끝나야 시스템 테스팅을 할 수 있다는 것이다.
그래서 테스트 계획 문서에는 시작 조건과 완료 조건 추가로 지연 조건이나 재개 조건과 같은 시작과 끝점에 대한 항목을 협의하여 명시하도록 권고하고 있다.
이러한 테스트 레벨은 테스트 수행 활동을 체계적으로 이해하고 개발 단계와 테스트 단계의 대치점에 대한 이해를 하기에는 좋지만 한가지 취약한 점이 있다.
조금 추상적이긴 하지만.. 품질이라는 관점에서 살펴보도록 하자..
우리는 각 연예인들의 가장 이쁜 부분 또는 가장 호감이 가는 부분만을 모아서 몽타쥬를 만들었을 경우 완성된 모습이 우리가 꿈꾸던 모습과는 사뭇 거리가 있다는 것을 익히 들어서 알고 있다.
중요한 것은 조화이다. 아무리 아름다운 것을 모아 놓는다고 해서 그 전체가 아름답지는 않다.
하지만 우리는 아주 자주 이러한 사실을 잊어버린다.
그것은 우리가 1+1=2라는 논리적이고 수리적인 사고 방식에 아주 익숙해져 있기 때문이다. 하지만 이것이 언제나 참이라고는 죽어도 확신할 수는 없다.
1+1=2가 아닐 수도 있다. 그런 예는 언제 어디서나 차고도 넘치도록 찾을 수 있다. 1+1=2일 수도 있고 그 이상 또는 그 이하일 수도 있다.
이것은 우리 주변의 사물이 분명 수학자들의 주장대로 숫자 위에 있을 수는 있지만 조화라는 과정 종속성이라는 속성에 따라 변하기 때문이다.
테스트 레벨도 마찬가지의 영향을 받는다.
각 테스트 레벨을 아무리 잘한다고 해도 완벽한 테스팅을 했다고 말할 수는 없다.
잘한다는 것과 적절하게 했다는 것은 전혀 다른 의미가 된다.
이것은 ISTQB의 테스팅의 기본원리 7가지 중
- 완벽한 테스팅은 불가능하다.
- 오류-부재의 궤변
과 닿아있다.
많은 경우 테스트 프로세스를 구축하고 개선하는 데 있어서 초점이 빗나간 경우가 많다.
각각의 테스트 레벨에 대해 잘 수행하는 것도 분명 중요하다.
하지만 각 테스트 레벨의 목적이 서로간에 잘 조화되지 못한다면 오합지졸이나 마찬가지이다.
때문에 각 테스트 레벨을 조율하고 목적한 바 즉, 고객이 만족하는 품질의 제품이 개발될 수 있도록 전체적인 품질 지표를 측정하고 결정하기 위한 계획이 필요하다.
즉, 조직 차원의 테스트 정책과 전략이 필요하다는 것이다.
하지만 국내에서 조직 차원의 테스트 정책이나 전략을 가진 조직은 생각보다 찾기가 쉽지 않다.
대부분의 조직은 거의 따로 국밥이다. 개발자들이 하는 테스트는 개발팀에서 테스팅 팀에서 하는 테스트는 QA 부서에서 각자 관리하고 각자의 결과에 대한 커뮤니케이션이 원할하지 못하고 서로의 목적을 모르기 때문에 곳곳에서 충돌이 나고 결국에는 목적하는 품질에 도달하지 못하는 경우를 많이 볼 수 있다.
각 테스트 레벨을 아무리 최적화 한다고 해도 제품의 품질은 나아지지 않는다. 전체적인 입장에서 프로젝트에 관련된 모든 조직과 부서를 아울러 관통할 수 있는 흐름을 살피고 조율할 수 있는 정책과 전략에 대해서 고민하고 계획을 수립할 수 있어야 할 것이다.
최근에 ISO/IEC 29119에서는 이러한 테스트 레벨에 대한 관점에서 벗어나서 소프트웨어의 속성과 목적에 따른 Fundamental Test Process 라는 것을 제안하고 있다. 이 프로세스에는 기존의 레벨 프로세스 뿐만 아니라 보안성, 성능, 사용성과 관련된 특정 테스트 수행에 관련된 프로세스를 모두 언급하고 있다.
중요한 것은 프로세스가 아니라 우리가 원하는 품질 목표를 달성하기 위해 프로젝트에 관련된 모든 부서, 조직, 인원, 자원이 얼마나 효과적이고 효율적으로 계획되고 수행되는 가이다.
단순히 개발자는 단위 테스트를 잘 수행하고 테스터는 시스템 테스트를 잘 수행해야한다는 것이 아니다.
개발자도 고객의 요구와 품질에 대한 인식을 가져야 하고 그에 따라 개발을 하고 테스트를 할 수 있어야 하는 것이고 테스터 역시 제품의 설계와 구성, 작동 원리 등에 대한 기본적인 이해를 가지고 있어야 하는 것이고 그러한 것이 고객의 요구에 최적으로 동작할 수 있도록 구성되었는지 테스트 할 수 있어야 한다.
프로젝트의 모든 구성원이 프로젝트의 목적하는 바 즉, 고객이 바라는 것 그리고 품질에 대한 이해를 공유할 필요가 있다.
그러기 위해서는 부분 최적화의 관점에서 벗어나 전체를 바라보고 기획할 수 있는 조직 차원의 정책과 전략을 수립할 필요성이 있다.
좋은 글 감사합니다~
답글삭제