한 택시회사가 있다.
그 택시회사에는 100명의 운전기사가 있는데 99명은 친절하고 1명은 불친절하다.
한 승객이 그 회사의 택시를 몇번 이용해 보았는데 매번 운전기사들이 너무 친절하여 단골이 되었다.
그러던 어느날 그 승객은 여느때처럼 이 회사의 택시를 불렀는데 하필 불친절한 운전기사의 택시를 타게 되었다.
그리고 그 승객은 다시는 그 택시회사의 택시를 이용하지 않게 되었다.
게다가 주변의 다른 사람들에게 그 회사의 택시가 불친절하다고 소문을 내게 되었다.
근래에 트위터 덕분에 쫄딱 망했다던 냉면가게 사건을 듣다가 생각나는게 있었다.
사람들은 대체로 아무리 긍정적인 경험이 많다고 하더라도 단 한번의 불쾌한 경험을 더 강렬하게 기억하는 경향이 있다.
이 불쾌한 경험은 그 회사 입장에서는 마치 주홍글씨처럼 따라 붙어다니는 족쇠가 되는 경우가 많다.
우리는 아이폰에 열광하는 수많은 사람들의 미사여구를 접하지만 그것보다 더 강렬하게 남아있는 기억은 아이폰 4의 핸드 그립으로 인한 통화 품질 저하인 것처럼 말이다.
이와 유사한 것이 블랙 스완이다.
모든 백조가 하얗다고 생각했지만 단 한마리의 검은 백조만으로 그 모든 가정이 와르르 부서져 버린것처럼..
소프트웨어를 테스트 하면서 이와 같은 일이 발생하는 경우가 심각도에 따라 결함을 처리하는 경우이다.
심각도는 결함에 대한 데이터를 가공할 때 가장 많이 사용되는 매트릭 중 하나이다.
우리는 심각도와 리스크에 따라 결함 수정의 우선순위를 정하기도 하고 심각도가 높은 결함을 더 많이 발견하기 위해 노력을 한다.
하지만 조금만 더 생각해보면 심각도란 무척이나 애매모호한 매트릭 중 하나이다.
심각한 결함과 아주 심각한 결함의 경계는 어디일까? 많은 회사들이 나름의 기준을 가지고 있지만 모두가 납득할 만한 기준이 많지 않다. 그리고 그러한 기준들은 새로운 유형의 결함이 발견될때마다 바뀌고 가이드라인은 점점 더 복잡해진다.
더 큰 문제는 결함에 대한 여러 관점 중 심각도에 조금 더 매진할 때 많은 테스터들은 심각도가 높은 결함을 더 많이 발견하기 위해 노력하게 되고 개발자를 포함한 모든 이해관계자는 심각도가 높은 결함에만 집중하는 경향이 생기게 된다.
이러한 경우 우리가 심각하다고 생각한 결함이 실제로 사용자에게도 심각한 결함이라면 문제가 없지만 만약에 사용자에게는 그 결함이 그다지 심각하지 않은 결함이라면? 문제는 커진다.
우리가 테스트를 하고 결함을 수정하는 과정에서 심각도가 낮다는 이유만으로 수정이 미뤄지고 결국에는 잊혀지는 결함이 생각보다 많다.
출시 일정을 정해 놓고 개발을 하는 우리 나라의 고질적인 개판 개발환경에서 많은 결함들은 수정 우선순위에서 밀려나고 결국 결함을 수정되지 않고 출시되는 경우가 많다.
이러한 경우 핑계는 그 결함은 심각도가 높지 않기 때문에 괜찮다는 것이다.
그리고 그 결함은 유지보수 단계에서도 쉽게 잊혀진다. 유지보수 단계에서도 수정의 우선순위가 높은 결함은 고객들이 회사에 보고하는 결함들 뿐 그렇지 못한 결함들은 정말 쉽게 잊혀지고 고쳐지지 않는다.
그러한 결함 중 어떤 결함은 언젠가는 회사에 아주 큰 손실을 가져다 줄수도 있는데 말이다.
심각도는 분명 아주 유용하고 필요한 매트릭임에는 분명하다.
하지만 테스터라면 결함에 대해 최소한 공평하게 대우를 해줘야 한다.
열손가락을 깨물어 아니 아픈 손가락이 없고 아무리 많은 자식이 있다 한들 누구만 이쁘고 누구는 이쁘지 않은 경우는 없다.
열손가락이라도다 쓰임새가 틀리고 많은 자식들 중에서도 누구는 좀더 이쁘고 누구는 좀더 미울수도 있지만 결국 모두가 소중한 것임에는 변함이 없다.
정해진 시간과 예산에서 효과적이고 효율적으로 소프트웨어를 개발하고 테스트하고 결함을 수정하기 위해서는 객관적인 기준이 필요하고 심각도는 그러한 기준 가장 유용한 기준임에는 분명하지만 결국에는더 중요한 결함과 덜 중요한 결함은 없는 것이다.
모두가 잊는다 하더라도 테스터만은 잊지 않고 해결되지 않은 결함을 일깨워주고 찾아내기 위한 노력을 게을리 하면 안된다고 생각한다.
나는 최소한 테스트를 수행할 때 심각도만 높은 결함을 찾기 위해 애쓰기보다는 좀 더 많은 다양한 결함을 발견하기 위해 애를 쓴다.
결함은 모두 소중하니까...
그 택시회사에는 100명의 운전기사가 있는데 99명은 친절하고 1명은 불친절하다.
한 승객이 그 회사의 택시를 몇번 이용해 보았는데 매번 운전기사들이 너무 친절하여 단골이 되었다.
그러던 어느날 그 승객은 여느때처럼 이 회사의 택시를 불렀는데 하필 불친절한 운전기사의 택시를 타게 되었다.
그리고 그 승객은 다시는 그 택시회사의 택시를 이용하지 않게 되었다.
게다가 주변의 다른 사람들에게 그 회사의 택시가 불친절하다고 소문을 내게 되었다.
근래에 트위터 덕분에 쫄딱 망했다던 냉면가게 사건을 듣다가 생각나는게 있었다.
사람들은 대체로 아무리 긍정적인 경험이 많다고 하더라도 단 한번의 불쾌한 경험을 더 강렬하게 기억하는 경향이 있다.
이 불쾌한 경험은 그 회사 입장에서는 마치 주홍글씨처럼 따라 붙어다니는 족쇠가 되는 경우가 많다.
우리는 아이폰에 열광하는 수많은 사람들의 미사여구를 접하지만 그것보다 더 강렬하게 남아있는 기억은 아이폰 4의 핸드 그립으로 인한 통화 품질 저하인 것처럼 말이다.
이와 유사한 것이 블랙 스완이다.
모든 백조가 하얗다고 생각했지만 단 한마리의 검은 백조만으로 그 모든 가정이 와르르 부서져 버린것처럼..
소프트웨어를 테스트 하면서 이와 같은 일이 발생하는 경우가 심각도에 따라 결함을 처리하는 경우이다.
심각도는 결함에 대한 데이터를 가공할 때 가장 많이 사용되는 매트릭 중 하나이다.
우리는 심각도와 리스크에 따라 결함 수정의 우선순위를 정하기도 하고 심각도가 높은 결함을 더 많이 발견하기 위해 노력을 한다.
하지만 조금만 더 생각해보면 심각도란 무척이나 애매모호한 매트릭 중 하나이다.
심각한 결함과 아주 심각한 결함의 경계는 어디일까? 많은 회사들이 나름의 기준을 가지고 있지만 모두가 납득할 만한 기준이 많지 않다. 그리고 그러한 기준들은 새로운 유형의 결함이 발견될때마다 바뀌고 가이드라인은 점점 더 복잡해진다.
더 큰 문제는 결함에 대한 여러 관점 중 심각도에 조금 더 매진할 때 많은 테스터들은 심각도가 높은 결함을 더 많이 발견하기 위해 노력하게 되고 개발자를 포함한 모든 이해관계자는 심각도가 높은 결함에만 집중하는 경향이 생기게 된다.
이러한 경우 우리가 심각하다고 생각한 결함이 실제로 사용자에게도 심각한 결함이라면 문제가 없지만 만약에 사용자에게는 그 결함이 그다지 심각하지 않은 결함이라면? 문제는 커진다.
우리가 테스트를 하고 결함을 수정하는 과정에서 심각도가 낮다는 이유만으로 수정이 미뤄지고 결국에는 잊혀지는 결함이 생각보다 많다.
출시 일정을 정해 놓고 개발을 하는 우리 나라의 고질적인 개판 개발환경에서 많은 결함들은 수정 우선순위에서 밀려나고 결국 결함을 수정되지 않고 출시되는 경우가 많다.
이러한 경우 핑계는 그 결함은 심각도가 높지 않기 때문에 괜찮다는 것이다.
그리고 그 결함은 유지보수 단계에서도 쉽게 잊혀진다. 유지보수 단계에서도 수정의 우선순위가 높은 결함은 고객들이 회사에 보고하는 결함들 뿐 그렇지 못한 결함들은 정말 쉽게 잊혀지고 고쳐지지 않는다.
그러한 결함 중 어떤 결함은 언젠가는 회사에 아주 큰 손실을 가져다 줄수도 있는데 말이다.
심각도는 분명 아주 유용하고 필요한 매트릭임에는 분명하다.
하지만 테스터라면 결함에 대해 최소한 공평하게 대우를 해줘야 한다.
열손가락을 깨물어 아니 아픈 손가락이 없고 아무리 많은 자식이 있다 한들 누구만 이쁘고 누구는 이쁘지 않은 경우는 없다.
열손가락이라도다 쓰임새가 틀리고 많은 자식들 중에서도 누구는 좀더 이쁘고 누구는 좀더 미울수도 있지만 결국 모두가 소중한 것임에는 변함이 없다.
정해진 시간과 예산에서 효과적이고 효율적으로 소프트웨어를 개발하고 테스트하고 결함을 수정하기 위해서는 객관적인 기준이 필요하고 심각도는 그러한 기준 가장 유용한 기준임에는 분명하지만 결국에는더 중요한 결함과 덜 중요한 결함은 없는 것이다.
모두가 잊는다 하더라도 테스터만은 잊지 않고 해결되지 않은 결함을 일깨워주고 찾아내기 위한 노력을 게을리 하면 안된다고 생각한다.
나는 최소한 테스트를 수행할 때 심각도만 높은 결함을 찾기 위해 애쓰기보다는 좀 더 많은 다양한 결함을 발견하기 위해 애를 쓴다.
결함은 모두 소중하니까...
댓글
댓글 쓰기