이제 다음주면 새해네요..
벌써 2012년이네요..
지구가 멸망하지는 않겠죠..
제가 테스터로 일한지도 햇수로는 10년째가 되네요.. 중간에 딴짓하고 논 시간을 빼도 8년째네요..
아직 햇병아리에요..
아는것도 많지 않고요.
배워야 할게 더 많지요.
요즘 저는 전국을 돌면서 테스트를 하고 있습니다.
지난 두달간 저는 차를 샀고, 그 차를 타고 전국을 돌며 테스트를 했습니다.
제 차가 두달만에 주행거리 4천킬로를 넘었으니.. 이건 머..
최근 두달 동안 뿐만 아니라 지난 몇년간 테스트를 이곳 저곳 다니면서 하다 보니 이젠 나름 통밥이 조금 늘었습니다.
딱 보면 이 제품은 틀렸다.. 이 제품은 대박이다.. 이런 감이 생겼다고 할까요? 아, 물론 어떠한 객관적인 데이터는 없습니다. 하지만 실제로 사용성 테스트를 수행했을 때 제 감이 맞아 들어가는 경우가 많아지는 걸 보면 대략 저도 통밥이 늘어난 것 같습니다. 어쨌든..
이렇게 여러 곳을 테스트 하면서 다니다 보니 많은 업체가 원하는게 다 비슷 비슷합니다.
그것은 바로 대박이죠.
우리가 개발한 SW가 대박이 나서 잘 살아보고 싶은 열망..
이건 절대 나쁜게 아니죠.
하지만 그게 말처럼 쉽지가 않지요.
뭐, 나름 업체들도 나름의 노력을 열심히 합니다.
하지만 제가 그 업체를 찾아갈 때가 되면 정말 자기들이 해볼 수 있는 건 다 해보고 그래도 안되어서 정말로 최후의 보루처럼 저를 바라보는 경우가 은근 많습니다.
그런 업체들의 이야기를 들어보면 가장 많이 하는 얘기가 품질입니다.
우리가 이러 저러 노력을 했지만 제품 품질에 문제가 있는 것 같다. 제품의 품질을 높이려면 어케 해야하느냐? 고 묻는거죠.
저 질문을 조금 더 쉽게 얘기하면 대략 이런 얘기입니다. 우리가 그동안 개발만 하느라 겁나 바빠서 테스트를 잘 못했다. 고로 테스트 좀 제대로 해서 결함 좀 줄여달라. 결함이 줄어들면 품질이 늘어날거고 그러면 우리도 대박은 아니어도 중박은 날거다. 우리 제품 정말 좋은 제품이다.. 머 이런 얘기입니다.
결론적으로 정리를 해보면 SW의 품질은 잠재된 결함 갯수이고 품질을 높이기 위해서는 테스트를 겁나게 해서 결함을 줄이면 된다.. 그런겁니다.
그런데 이게 정말 맞는 얘기일까요?
많은 사람들이 아직도 테스트와 품질을 동일시하는 경향이 강합니다.
수많은 논란이 있지만 저는 테스트와 품질 보증 활동을 명확히 구분하는 것이 더 좋다라는 입장의 사람입니다.
테스트를 통해서 품질을 일부 높일수는 있겠지만 테스트가 품질을 높이는 활동의 전부는 아니죠.
실제로 여러 곳을 다니면서 테스트를 하다 보면 내가 죽어라 테스트 해서 결함이 아무리 줄어봐야.. 이 제품은 틀렸다.. 라고 생각되는 제품이 있는가 하면..
결함도 많고 어설퍼도 진흙 속의 진주를 보는 것처럼 반짝 반짝 빛나는 제품들도 있습니다.
아무래도 이런 제품을 만나면 일을 해도 흥이 납니다.
ISTQB에서는 이런 경우를 들어서 '오류 부재의 궤변'이라고 합니다.
오류가 없다고 좋은 소프트웨어가 아니라는 거죠..
예를 들면 지난 주에 저는 모처에 가서 안드로이드 앱을 테스트하고 왔습니다. 국가 지원을 수억을 받아서 개발된 앱이죠. 물론 앱 자체에 결함도 있었지만.. 여러분도 아시다시피 앱이 복잡하다고 해도 그 복잡도는 한계가 있습니다. 거기서 거기죠.
중요한 것은 그 앱이 제공하는 내용인데.. 하아.. 테스트 하면서도 정말 눈물날 지경이었습니다.
제가 아무리 열심히 테스트를 하고 결함 없는 앱을 만든다고 해도 그게 중요한 게 아니었습니다.
그 앱이 제공하는 내용이 풍부해야는데 과연 해당 업체가 그런 내용을 얼마나 풍부하게 제공할지 의문이더군요.
머.. 아직 시작이니 잘하겠지 싶지만서도.. 2년을 개발한 앱이라는데.. 이건 머..
그렇다고요..
아.. 뭔가 하고 싶은 말이 있었는데.. 꼭 글을 쓰다보면 용두사미가 되어버리는군요..
제가 하고 싶은 얘기는 정말 대박나는 소프트웨어를 만들고 싶으시다면 물론 테스트도 중요합니다.
하지만 테스트가 전부가 아닙니다.
품질은 테스트 만으로 좋아질 수는 없습니다.
좀 더 넓게 생각해 주시면 좋겠습니다.
벌써 2012년이네요..
지구가 멸망하지는 않겠죠..
제가 테스터로 일한지도 햇수로는 10년째가 되네요.. 중간에 딴짓하고 논 시간을 빼도 8년째네요..
아직 햇병아리에요..
아는것도 많지 않고요.
배워야 할게 더 많지요.
요즘 저는 전국을 돌면서 테스트를 하고 있습니다.
지난 두달간 저는 차를 샀고, 그 차를 타고 전국을 돌며 테스트를 했습니다.
제 차가 두달만에 주행거리 4천킬로를 넘었으니.. 이건 머..
최근 두달 동안 뿐만 아니라 지난 몇년간 테스트를 이곳 저곳 다니면서 하다 보니 이젠 나름 통밥이 조금 늘었습니다.
딱 보면 이 제품은 틀렸다.. 이 제품은 대박이다.. 이런 감이 생겼다고 할까요? 아, 물론 어떠한 객관적인 데이터는 없습니다. 하지만 실제로 사용성 테스트를 수행했을 때 제 감이 맞아 들어가는 경우가 많아지는 걸 보면 대략 저도 통밥이 늘어난 것 같습니다. 어쨌든..
이렇게 여러 곳을 테스트 하면서 다니다 보니 많은 업체가 원하는게 다 비슷 비슷합니다.
그것은 바로 대박이죠.
우리가 개발한 SW가 대박이 나서 잘 살아보고 싶은 열망..
이건 절대 나쁜게 아니죠.
하지만 그게 말처럼 쉽지가 않지요.
뭐, 나름 업체들도 나름의 노력을 열심히 합니다.
하지만 제가 그 업체를 찾아갈 때가 되면 정말 자기들이 해볼 수 있는 건 다 해보고 그래도 안되어서 정말로 최후의 보루처럼 저를 바라보는 경우가 은근 많습니다.
그런 업체들의 이야기를 들어보면 가장 많이 하는 얘기가 품질입니다.
우리가 이러 저러 노력을 했지만 제품 품질에 문제가 있는 것 같다. 제품의 품질을 높이려면 어케 해야하느냐? 고 묻는거죠.
저 질문을 조금 더 쉽게 얘기하면 대략 이런 얘기입니다. 우리가 그동안 개발만 하느라 겁나 바빠서 테스트를 잘 못했다. 고로 테스트 좀 제대로 해서 결함 좀 줄여달라. 결함이 줄어들면 품질이 늘어날거고 그러면 우리도 대박은 아니어도 중박은 날거다. 우리 제품 정말 좋은 제품이다.. 머 이런 얘기입니다.
결론적으로 정리를 해보면 SW의 품질은 잠재된 결함 갯수이고 품질을 높이기 위해서는 테스트를 겁나게 해서 결함을 줄이면 된다.. 그런겁니다.
그런데 이게 정말 맞는 얘기일까요?
많은 사람들이 아직도 테스트와 품질을 동일시하는 경향이 강합니다.
수많은 논란이 있지만 저는 테스트와 품질 보증 활동을 명확히 구분하는 것이 더 좋다라는 입장의 사람입니다.
테스트를 통해서 품질을 일부 높일수는 있겠지만 테스트가 품질을 높이는 활동의 전부는 아니죠.
실제로 여러 곳을 다니면서 테스트를 하다 보면 내가 죽어라 테스트 해서 결함이 아무리 줄어봐야.. 이 제품은 틀렸다.. 라고 생각되는 제품이 있는가 하면..
결함도 많고 어설퍼도 진흙 속의 진주를 보는 것처럼 반짝 반짝 빛나는 제품들도 있습니다.
아무래도 이런 제품을 만나면 일을 해도 흥이 납니다.
ISTQB에서는 이런 경우를 들어서 '오류 부재의 궤변'이라고 합니다.
오류가 없다고 좋은 소프트웨어가 아니라는 거죠..
예를 들면 지난 주에 저는 모처에 가서 안드로이드 앱을 테스트하고 왔습니다. 국가 지원을 수억을 받아서 개발된 앱이죠. 물론 앱 자체에 결함도 있었지만.. 여러분도 아시다시피 앱이 복잡하다고 해도 그 복잡도는 한계가 있습니다. 거기서 거기죠.
중요한 것은 그 앱이 제공하는 내용인데.. 하아.. 테스트 하면서도 정말 눈물날 지경이었습니다.
제가 아무리 열심히 테스트를 하고 결함 없는 앱을 만든다고 해도 그게 중요한 게 아니었습니다.
그 앱이 제공하는 내용이 풍부해야는데 과연 해당 업체가 그런 내용을 얼마나 풍부하게 제공할지 의문이더군요.
머.. 아직 시작이니 잘하겠지 싶지만서도.. 2년을 개발한 앱이라는데.. 이건 머..
그렇다고요..
아.. 뭔가 하고 싶은 말이 있었는데.. 꼭 글을 쓰다보면 용두사미가 되어버리는군요..
제가 하고 싶은 얘기는 정말 대박나는 소프트웨어를 만들고 싶으시다면 물론 테스트도 중요합니다.
하지만 테스트가 전부가 아닙니다.
품질은 테스트 만으로 좋아질 수는 없습니다.
좀 더 넓게 생각해 주시면 좋겠습니다.
댓글
댓글 쓰기