소프트웨어 테스터로서 겪는 딜레마 중 하나가 도데체 얼마나 테스트를 해야 충분한가?에 대한 문제입니다.
경영진을 포함해서 많은 사람들이 테스트 결과 보고서를 보면서 말합니다.
테스트가 충분히 진행되었나요? 결함은 없나요? 출시해도 괜찮은거죠?
이 질문들에 확신에 찬 대답으로 '물론입니다'라고 대답할 수 있는 테스터가 과연 있을수가 있기나 한지 의문이 듭니다.
이런 문제는 소프트웨어가 형체가 정의되지 않은 불확정성을 내포한 상태이기 때문이라고 생각합니다.
예를 들어, 하드웨어라 한다면 우리가 테스트를 해야할 범위와 한계가 명확해집니다.
우리가 먹는 식품이라면 구성 성분들이 인체에 유해한지 검사하고 그 과정 전체를 관리 감독하는 것이 불가능하지 않을 것입니다.
재료의 선정부터 출시까지 일관된 기준으로 검사와 관리가 가능합니다.
하지만 소프트웨어는 어떨까요?
요구사항을 수집, 분석, 정의해서 나온 산출물과 아키텍처가 설계한 산출물, 개발자의 코드, 디자이너들의 산출물 어느 하나 공통된 것이 없습니다.
다양한 형태의 산출물간의 추적성 설정조차 어려울 지경입니다.
과연 이 모든것들을 일관된 기준으로 검사와 관리가 가능하긴 한걸까요?
소프트웨어란 도데체 무엇일까요?
저는 소프트웨어를 아래 3가지 구성요소로 정의합니다. 이 정의는 테스터로서 바라보는 소프트웨어에 대한 정의입니다.
소프트웨어란 입력값(Input)과 출력값(Output) 그리고 데이터(Data)로 구성된 논리적 집합체이다.
그렇다면 우리가 충분한 테스트를 했는가는 소프트웨어에 입력해야 할 값과 출력되어 나오는 값 그리고 그 과정에 사용되는 데이터를 모두 테스트 했는가로 추적해 볼 수 있다고 생각합니다.
대부분의 설계 기법이 이 과정에 대한 논리식과 데이터 생성에 초점이 맞추어져 있습니다.
경계값 분석이나 동등분할은 입력값 또는 출력값의 데이터 검증에 초점이 맞추어져 있습니다.
결정 테이블, 원인 결과 그래프, 상태 전이, 시나리오 테스팅과 같은 기법들은 논리식의 검증에 초점이 맞추어져 있습니다.
그러면 이렇게 입력값과 출력값 그리고 데이터에 대한 검증만으로 충분할까요?
문제는 이건 소프트웨어 자체에 대한 테스트일뿐입니다.
소프트웨어는 운용하는 사용자와 환경에 따라 매우 다양하게 변용됩니다.
누가 사용하는가? 어떤 환경에서 사용하는가? 에 대한 테스트가 추가로 필요합니다.
그래서 아래와 같은 요소들을 추가로 고려해야한다고 봅니다.
조건(Condition), 정황(Context)
그런데, 조건이나 정황은 입력값, 출력값, 데이터와 달리 쉽게 정의하기 어렵고 변수가 너무 많습니다. 때문에 많은 테스터들이 이 부분에 대한 테스트를 수행하지 못하거나 충분하게 고려하지 못합니다.
RST에서는 이러한 부분에 대하여 아래와 같이 7가지 구성요소를 제안합니다.
1. 구조 (Structure)
2. 기능 (Function)
3. 데이터 (Data)
4. 인터페이스 (Interfaces)
5. 플랫폼 (Platform)
6. 운용 (Operations)
7. 시간 (Time)
그러면 이것으로 충분한가?
사실은 이것으로도 부족합니다.
저는 여기에 ISO/IEC/IEEE 25010 소프트웨어 품질 특성을 추가로 고려합니다.
그렇게 저는 커버리지를 측정할 때 위의 7가지 구성요소와 소프트웨어 품질 특성을 함께 고려해서 사용합니다.
그런데 이로써 문제가 해결된것인가? 아닙니다.
무엇을 측정할지는 정해졌는데 이걸 어떻게 측정하는가에 대한 문제가 남았습니다.
왜냐하면 각각의 요소들마다 모수가 불명확하다는 것이 문제입니다.
모수를 측정할 수 있다는 분들도 계시디만 소프트웨어는 하드웨어와 달리 이 모수가 소프트웨어가 종료되어 사라지는 순간까지 지속적으로 변한다는 것입니다.
고로 어제의 100%와 오늘의 100%는 완전히 다른 얘기가 됩니다.
그러면 도데체 이걸 어떻게 측정하는가?
사실 이 부분에 대해서는 저도 아직까지는 명확하게 얘기를 하지 못합니다.
제임스 바크나 정황 주도 학파에 몸 담고 있는 사람들, RST 진영 쪽에 있는 분들이 강조하는 것은 테스터들의 책임감입니다.
내 이름과 양심을 걸고 하늘을 우러러 한점 부끄러움 없는 테스트를 했는가?
그래서 저도 매번 테스트를 할때마다 저에게 되묻습니다.
내가 놓친것은 없는가?
내가 고려하지 못한 것이 있는가?
충분한 소프트웨어 테스팅이란 결국 자신과의 싸움이고 타인이 나에게 보내는 신뢰라고 생각합니다.
무엇을 테스트할 것인가에 대한 것은 조금만 고민해보면 어느 정도까지는 쉽게 정의할 수 있습니다.
경험이 누적되면 이것은 점점 더 쉬워집니다.
그런데 그것을 얼마나 충분히 고려하여 테스트를 수행했는가는 아직까지도 참 많이 어렵습니다.
경영진이나 이해관계자들 특히 우리 나라처럼 정량 분석 데이터를 좋아하는 사람들이 많을때는 이것이 참 어렵습니다.
가끔은 그 사람들 입맛에 맞춰 보기좋게 포장을 하기도 합니다.
하지만 중요한 것은 그런 숫자보다는 스스로 자부심을 느끼기에 충분할 만큼 떳떳한가? 이해관계자가 내 테스트를 신뢰하고 지원하는가? 가 아닐까 싶습니다.
그런 신뢰를 얻기 위해 나는 최선을 다해 노력하고 있는가? 라고 스스로 물어보는게 중요하다고 생각합니다.
스스로에게 떳떳하고 이해관계자의 신뢰를 얻고 있다면 저는 그것이 충분한 소프트웨어 테스팅이라고 생각합니다.
-----
글을 쓰는 건 항상 어렵습니다. 머리 속에 떠다니던 생각을 끄집어내어 한줄 글로 표현하는 것이 참 어렵습니다.
생각을 글로 적다보면 생각해 두었던 내용이 사라지고 바뀌고 글로 표현하지 못하는 경우도 생깁니다.
글을 쓰는 법을 제대로 배우지 못한 무식의 소치라고 치부하기에도 부끄러운 글을 계속 쓰는 것이 맞는지 가끔 고민을 합니다.
이 글도 용두 사미 같아 부끄럽습니다.
제가 적는 글을 읽어보시고 반론이나 궁금한 내용을 댓글로 적어주시면 저에게 많은 도움이 됩니다.
이번에도 제 글을 읽어주셔서 고맙습니다.
경영진을 포함해서 많은 사람들이 테스트 결과 보고서를 보면서 말합니다.
테스트가 충분히 진행되었나요? 결함은 없나요? 출시해도 괜찮은거죠?
이 질문들에 확신에 찬 대답으로 '물론입니다'라고 대답할 수 있는 테스터가 과연 있을수가 있기나 한지 의문이 듭니다.
이런 문제는 소프트웨어가 형체가 정의되지 않은 불확정성을 내포한 상태이기 때문이라고 생각합니다.
예를 들어, 하드웨어라 한다면 우리가 테스트를 해야할 범위와 한계가 명확해집니다.
우리가 먹는 식품이라면 구성 성분들이 인체에 유해한지 검사하고 그 과정 전체를 관리 감독하는 것이 불가능하지 않을 것입니다.
재료의 선정부터 출시까지 일관된 기준으로 검사와 관리가 가능합니다.
하지만 소프트웨어는 어떨까요?
요구사항을 수집, 분석, 정의해서 나온 산출물과 아키텍처가 설계한 산출물, 개발자의 코드, 디자이너들의 산출물 어느 하나 공통된 것이 없습니다.
다양한 형태의 산출물간의 추적성 설정조차 어려울 지경입니다.
과연 이 모든것들을 일관된 기준으로 검사와 관리가 가능하긴 한걸까요?
소프트웨어란 도데체 무엇일까요?
저는 소프트웨어를 아래 3가지 구성요소로 정의합니다. 이 정의는 테스터로서 바라보는 소프트웨어에 대한 정의입니다.
소프트웨어란 입력값(Input)과 출력값(Output) 그리고 데이터(Data)로 구성된 논리적 집합체이다.
그렇다면 우리가 충분한 테스트를 했는가는 소프트웨어에 입력해야 할 값과 출력되어 나오는 값 그리고 그 과정에 사용되는 데이터를 모두 테스트 했는가로 추적해 볼 수 있다고 생각합니다.
대부분의 설계 기법이 이 과정에 대한 논리식과 데이터 생성에 초점이 맞추어져 있습니다.
경계값 분석이나 동등분할은 입력값 또는 출력값의 데이터 검증에 초점이 맞추어져 있습니다.
결정 테이블, 원인 결과 그래프, 상태 전이, 시나리오 테스팅과 같은 기법들은 논리식의 검증에 초점이 맞추어져 있습니다.
그러면 이렇게 입력값과 출력값 그리고 데이터에 대한 검증만으로 충분할까요?
문제는 이건 소프트웨어 자체에 대한 테스트일뿐입니다.
소프트웨어는 운용하는 사용자와 환경에 따라 매우 다양하게 변용됩니다.
누가 사용하는가? 어떤 환경에서 사용하는가? 에 대한 테스트가 추가로 필요합니다.
그래서 아래와 같은 요소들을 추가로 고려해야한다고 봅니다.
조건(Condition), 정황(Context)
그런데, 조건이나 정황은 입력값, 출력값, 데이터와 달리 쉽게 정의하기 어렵고 변수가 너무 많습니다. 때문에 많은 테스터들이 이 부분에 대한 테스트를 수행하지 못하거나 충분하게 고려하지 못합니다.
RST에서는 이러한 부분에 대하여 아래와 같이 7가지 구성요소를 제안합니다.
1. 구조 (Structure)
2. 기능 (Function)
3. 데이터 (Data)
4. 인터페이스 (Interfaces)
5. 플랫폼 (Platform)
6. 운용 (Operations)
7. 시간 (Time)
그러면 이것으로 충분한가?
사실은 이것으로도 부족합니다.
저는 여기에 ISO/IEC/IEEE 25010 소프트웨어 품질 특성을 추가로 고려합니다.
그렇게 저는 커버리지를 측정할 때 위의 7가지 구성요소와 소프트웨어 품질 특성을 함께 고려해서 사용합니다.
그런데 이로써 문제가 해결된것인가? 아닙니다.
무엇을 측정할지는 정해졌는데 이걸 어떻게 측정하는가에 대한 문제가 남았습니다.
왜냐하면 각각의 요소들마다 모수가 불명확하다는 것이 문제입니다.
모수를 측정할 수 있다는 분들도 계시디만 소프트웨어는 하드웨어와 달리 이 모수가 소프트웨어가 종료되어 사라지는 순간까지 지속적으로 변한다는 것입니다.
고로 어제의 100%와 오늘의 100%는 완전히 다른 얘기가 됩니다.
그러면 도데체 이걸 어떻게 측정하는가?
사실 이 부분에 대해서는 저도 아직까지는 명확하게 얘기를 하지 못합니다.
제임스 바크나 정황 주도 학파에 몸 담고 있는 사람들, RST 진영 쪽에 있는 분들이 강조하는 것은 테스터들의 책임감입니다.
내 이름과 양심을 걸고 하늘을 우러러 한점 부끄러움 없는 테스트를 했는가?
그래서 저도 매번 테스트를 할때마다 저에게 되묻습니다.
내가 놓친것은 없는가?
내가 고려하지 못한 것이 있는가?
충분한 소프트웨어 테스팅이란 결국 자신과의 싸움이고 타인이 나에게 보내는 신뢰라고 생각합니다.
무엇을 테스트할 것인가에 대한 것은 조금만 고민해보면 어느 정도까지는 쉽게 정의할 수 있습니다.
경험이 누적되면 이것은 점점 더 쉬워집니다.
그런데 그것을 얼마나 충분히 고려하여 테스트를 수행했는가는 아직까지도 참 많이 어렵습니다.
경영진이나 이해관계자들 특히 우리 나라처럼 정량 분석 데이터를 좋아하는 사람들이 많을때는 이것이 참 어렵습니다.
가끔은 그 사람들 입맛에 맞춰 보기좋게 포장을 하기도 합니다.
하지만 중요한 것은 그런 숫자보다는 스스로 자부심을 느끼기에 충분할 만큼 떳떳한가? 이해관계자가 내 테스트를 신뢰하고 지원하는가? 가 아닐까 싶습니다.
그런 신뢰를 얻기 위해 나는 최선을 다해 노력하고 있는가? 라고 스스로 물어보는게 중요하다고 생각합니다.
스스로에게 떳떳하고 이해관계자의 신뢰를 얻고 있다면 저는 그것이 충분한 소프트웨어 테스팅이라고 생각합니다.
-----
글을 쓰는 건 항상 어렵습니다. 머리 속에 떠다니던 생각을 끄집어내어 한줄 글로 표현하는 것이 참 어렵습니다.
생각을 글로 적다보면 생각해 두었던 내용이 사라지고 바뀌고 글로 표현하지 못하는 경우도 생깁니다.
글을 쓰는 법을 제대로 배우지 못한 무식의 소치라고 치부하기에도 부끄러운 글을 계속 쓰는 것이 맞는지 가끔 고민을 합니다.
이 글도 용두 사미 같아 부끄럽습니다.
제가 적는 글을 읽어보시고 반론이나 궁금한 내용을 댓글로 적어주시면 저에게 많은 도움이 됩니다.
이번에도 제 글을 읽어주셔서 고맙습니다.
댓글
댓글 쓰기