사용성 테스팅 - TDD(Testability Driven Design)

사용성 테스팅 만큼 쉬우면서도 어려운 것이 있을까?

사용성 테스팅에서 가장 어려운 것은 역시 테스트 오라클이 명확하지 않다는 것이다.

그리고 테스트 오라클을 협의하고 정하는 것 자체도 쉽지 않다.

더 큰 문제는 협의하고 정한 테스트 오라클이라 할지라도 고객이 그것에 동의할 것인지, 테스트 오라클이 제대로 정해졌는지에 대해 확신할 만한 근거가 부족하다는 것이다.

아래 글은 이러한 사용성 테스팅에 대한 테스트 오라클을 정하는 데에 있어 그 기준으로 생각할 만한 것에 대한 나의 의견이다.

자 한가지 예를 통해서 설명해 보도록 하겠다.

우리가 윈도우를 사용하면서 어떤 이유로든 더 이상 필요없는 파일은 깔끔하게 삭제해 버림으로써 하드 디스크의 용량을 늘리고 있다. 아 .. 머 요즘은 하드 디스크 용량이 좀 널널하게 남아돌기도 하지만서도..

어쨌든..

여기서 중요한 것은 파일 삭제이다.

그럼 첫번째.. 파일 삭제에 있어서 고객에게 가장 큰 가치는 무엇일까?

사람마다 모두 다른 답이 나오겠지만 적어도 나에게는 삭제하면 제깍 삭제되고 혹시라도 잘못 삭제했다면 제깍 복구할 수 있어야 한다라고 답하고 싶다..

그러면 윈도우의 파일 삭제 과정을 한번 낱낱이 생각해 보자.

첫눈에 딱 봐도 복잡하지 않는가?

일반적으로 우리는 가장 오른쪽의 경우만을 알고 있다. 그리고 왜 문제인지 잘 알지 못한다.

가장 오른쪽의 경우 첫번째 문제점은 파일 삭제 여부를 묻는 확인창이다.

많은 사람들은 그것이 왜 문제인가? 라고 물을 것이다.

내가 처음에 파일 삭제의 가치에 대해 말을 할 때 전제조건은 제깍이었다. 이것은 즉시 삭제되기를 원한다는 것이었다.

실제 생활에서 만약 당신이 화장실에서 편안함 속에 화장지를 휴지통에 버리려는 순간 이 휴지통이 건방지게 당신이 휴지를 버리겠다는 확고한 확신을 보여야만 휴지를 버릴 수 있습니다라는 메시지와 함께 지문 인식을 원한다면 어떤 느낌이 들 거라고 생각하는가?

동일한 경우지만 이것을 받아들이는 느낌은 사뭇 다르다. 이것이 학습의 결과이다.

많은 사람들은 대부분 파일 삭제를 할 때 경고창의 메시지는 확인하지 않는다. 그냥 예스를 누를 뿐이다. 왜냐하면 예스를 누른다고 하더라도 휴지통에서 파일을 복원할 수 있다는 것을 알고 있고 그것이 신뢰할 수 있다는 것을 학습을 통해 이미 알고 있기 때문이다.

하지만 이러한 흐름은 고객의 가치를 해치게 된다. 우선은 확인창이 떠야 하고 확인 버튼을 누르는데 아주 작지만 약간의 시간이 필요하다. 그 짧은 시간이 무슨 의미가 있느냐고 하겠지만 티끌 모아 태산인 것이다.

이러다 보니 이제 윈도우 좀 안다는 파워 유저들은 이 확인창이 무척이나 신경이 쓰이고 귀찮아졌다. 그리하여 나온 편법이 Shift+Del이었다.

하지만 이 역시 키를 조합하여 눌러야 하기 때문에 무척이나 귀찮은 일이 되어버렸다.

그리하여 마침내 휴지통의 속성창을 열어서 설정을 아예 바꿔버리게 되었다.

파일 하나를 지우기 위해 우리는 이렇게 많은 경우의 수를 생각하고 투자를 하게 되었다. 그렇게 함으로써 어찌 되었든 파일을 바로 즉시 즉시 지울 수 있게 되었다.

하지만 우리는 그렇게 함으로써 파일을 복원할 수 있는 가치를 영구히 훼손해 버렸다.

빠르게 지우기 위해서 우리는 단축키나 설정을 바꾸기 위해 투자를 하였다. 하지만 그 투자는 파일 복원이라는 가치를 영원히 훼손시켜 버렸다.

만약 우리가 파일 복원이라는 가치를 지키기 위해서는 파일을 삭제하기 위한 투자를 늘려야 한다.

왜 이런 일이 벌어진 것일까? 왜냐하면 인간은 게으르기 때문이다. 인간은 특정한 가치를 동일하게 얻을 수 있다면 더 적은 노력과 유지비용만을 지불하기를 원하기 때문이다.

다만 이 경우는 더 적은 노력과 유지 비용을 지불하기 위한 노력이 결국은 쓰루풋을 훼손시켜 버린 것이다.

TOC적인 관점에서 본다면 이 두가지 모두 좋지 않은 것이 된다.

첫번째는 투자를 늘렸지만 쓰루풋은 훼손되어 버렸다.

두번째는 투자를 늘렸지만 쓰루풋은 늘어나지 않았다.

이러한 이유로 윈도우의 파일 삭제는 고객에게 아무런 가치를 줄 수 없는 사용성이 낮은 경우가 된 것이다.

기능상으로는 아무런 문제도 없다. 그리고 많은 경우 이것이 왜 사용성이 낮은 것인지에 대한 아무런 반감이 없다. 그 이유는 우리가 학습이 되어버렸기 때문이다.

아래는 우분투의 파일 삭제 과정이다.

이 얼마나 아름다운가?

내가 처음 우분투에서 파일을 삭제했을 때 난 커다란 혼란과 두려움에 사로잡혔다.

왜냐하면 윈도우에서 언제나 보던 확인창이 뜨지 않았던 것이다. 이것은 내가 학습해 놓은 상황에 완전히 대치되는 상황이었다.

하지만 내가 삭제한 파일은 안전하게 휴지통에 들어가 있었고 난 이로써 새로운 학습에 성공하고 새로운 신뢰를 쌓았다.

우분투의 경우는 쓰루풋을 훼손하지 않으면서 내가 투자해야할 대상은 획기적으로 줄였다.

난 단축키를 사용하지 않아도 되고, 난 설정을 바꿀 필요도 없었다.

그저 지우면 휴지통으로 파일이 이동되었고 원하면 복원하면 되었다.

사용성을 평가하기 위한 과정을 간단히 정리하면 아래와 같이 생각해 볼 수 있다.

먼저

1. 테스트하고자 하는 대상 또는 기능에 대한 핵심적인 가치를 정의한다.
2. 가치에 도달하기 위한 가장 적은 투자와 유지비용이 들어가는 경로를 산출한다.

즉, 고객의 가치를 도달하기 위한 가장 적은 투자와 유지비용이 들어가는 경로가 바로 테스트 오라클이 되는 것이다.

다른 말로 하면 사용성이 높은 제품은 고객이 적은 투자와 유지 비용만을 사용한 상태에서 최상의 가치를 얻을 수 있는 제품이다.

우리는 의외로 주변에서 그런 제품을 쉽게 찾아볼 수 있다.

대표적인 것이 삼성과 애플의 MP3만 봐도 알 수 있다.

그런데 이 내용을 잘 살펴보면 이것은 테스팅 보다는 설계에 관한 내용에 더욱 가깝다.

난 이것을 TDD(Testability Driven Design)이라고 부른다.

내가 만들어낸 말이지만 실제로 나와 유사한 생각을 하는 사람들이 있는 것으로 안다.

요지는 설계를 할 때 테스트 가능성, 용이성을 고려하여 설계해야한다는 것이다.

윈도우의 경우가 테스트 용이성을 고려하지 않고 설계한 것이라고 가정한다면 윈도우의 경우는 많은 경우의 수를 테스트 해야한다.

확실히 우분투보다는 테스트를 수행하기 위한 리소스가 더 많이 필요하다는 것을 알 수 있다.

처음부터 고객에게 전달해야하는 핵심 가치와 그 가치에 도달하는 최단 과정을 고려하고 그러한 과정이 테스트를 수행함에 있어 얼마나 용이한지 고려하여 설계한다면 분명 테스트에 들어가는 리소스를 획기적으로 줄일 수 있다고 생각한다.

많은 경우 테스팅이 전체 개발 과정에서 가장 많은 비용과 일정이 들어가는 병목이 된다. 이것을 기획 단계 즉 설계 부터 고려한다면 분명 획기적인 개선이 있을 것이다.

이것이 TOC에서의 DBR의 핵심과 일맥상통한다고 생각한다.

위의 경우에서 생각해 보더라도 윈도우의 경우에 싸이클로메틱 복잡도(cyclomatic complexity)로 계산해본다면 3의 복잡도를 가진다. 하지만 우분투는 0이다.

Cyclomatic Complexity = 분기노드 개수 + 1로 계산할 수 있다.

Cyclomatic Complexity는 쉽게 말해서 테스트해봐야 하는 경로의 개수라고 할 수 있다. 이것이 높다는 것은 필요한 테스트케이스가 그만큼 많으므로 오류를 모두 확인하지 못할 확률이 더 높다는 것이다. 보통 3~7 사이의 값을 권장하며, 10 이상은 지양하는 것을 권장한다.

처음 설계에 있어서 테스트 용이성을 고려하여 설계함으로써 코딩과 테스트 모두에 들어가는 리소스를 절약하고 고객에게 전달해야 하는 가치를 지킬 수 있다는 것이 나의 생각이다.

이에 관련해서 의견 있으신 분은 트랙백이나 댓글로 의견을 좀 더 나누었으면 한다.