이 블로그에 소프트웨어 테스팅에 대한 글을 써본지가 언제인지 기억조차 없을 정도로 오래되었습니다.
워낙에 방문자도 없는 변방의 불모지인지라.. 소홀했음을 인정합니다.
그래서 오랜만에 테스팅에 대한 글을 간단하게 적어보고자 합니다.
이 글은 지극히 제 개인적인 생각이므로 반론에 대해서는 언제나 환영입니다. 댓글 달아주시기 바랍니다.
제가 언제부터인가 이 블로그에 테스팅 관련 글을 적지 않은 이유는 제가 지식의 저주에 걸려서 그렇습니다.
무엇인가를 배우고 생각할 때는 이것 저것 많이 적었는데..
어느 시점으로 지나고 나니 모든게 재미가 없어졌고.. 그냥 당연한 것이 되었습니다.
그런데 어느 정도 시간이 지나고 나니.. 저는 당연한건데.. 당연하지 않다고 말씀하시는 분들이 꽤 많다는 것을 알게 되었습니다.
제가 틀렸을 수도 있지만.. 제가 생각하는 테스팅을 잘하기 위해서 당연하게 필요한 두가지를 적어보고자 합니다.
이 두가지가 제대로 되지 않는다면.. 전 그것 자체가 문제라고 봅니다.
첫번째는.. 테스트의 목적을 명확히 하는 것입니다.
개발 수명 주기에 대응해서 다양한 수준의 테스트 레벨과 테스트 유형에 따른 테스트를 수행함에 있어 가장 중요한 것은 내가 언제 어떤 테스트를 진행할 것인가이고.. 그에 대한 큰 그림을 이해하느냐 입니다.
그 모든 테스트에 대한 큰 그림과 그 그림안의 수많은 테스트 활동의 구분은 테스트의 목적에 따라 달라지게 됩니다.
테스트의 목적은 테스트로 측졍해야 하는 각종 지표(예를 들어, 품질 지표)와 연계됩니다.
테스트의 목적은 테스트의 시작과 끝을 결정짓는 가장 중요한 요소입니다.
많은 분들이 우리는 당연히 테스트의 목적을 설정한다고 말씀하시지만 막상 자기가 현재 수행하고 있는 테스트 활동의 목적에 대해 팀 또는 조직에서 합의된 형태로 공유되지 않는 경우를 종종 보았습니다.
테스트 목적 설정은 모든 테스트 활동에 있어 가장 중요하고 가장 먼저 해야 하는 활동입니다.
두번째는 내가 아무리 테스트를 잘하고 싶어도.. 절대로 테스트를 잘 할 수 없는 경우는...
바로.. 명세나 개발과 관련된 이해관계자와 함께 테스트를 하지 못하는 경우입니다.
조직이 더 나은 테스트를 원한다면 개발과 관련된 이해관계자는 자신의 작업 산출물에 대해 스스로 테스트를 수행해서 더 나은 산출물을 생산하고 테스터와 함께 협업할 수 있어야 합니다.
애자일이나 탐색적 테스팅, DevOps에서 공통적으로 협업을 강조하는 것은 다 이유가 있습니다.
명세, 코드, 모델에 명시된 사항이나 이해관계자의 마음 속에 있는 기준은 테스터가 결함 또는 장애를 식별하기 위한 가장 신뢰할 수 있는 기준입니다.
기준이 명확하지 않다면 테스트를 통해 결함을 식별할 수 없습니다.
물론, 명세도 없이 개발자와 얼굴 한번 마주치지 않고도 테스트를 진행할 수는 있겠지만.. 그 테스트 결과를 과연 믿을 수 있을까요?
기준을 개발 초기에 함께 검토하는 것과 개발 후반부에 테스트 결과로서 검토하는 것은 엄청난 차이입니다.
테스터는 테스트를 실행하기 전에 기준을 명확히 이해하고 설정해야 합니다.
결론은.. 테스터가 테스트 팀이 아무리 테스트를 잘하고 싶어도.. 테스트의 성공 여부는 개발 성숙도와 아주 밀접한 관계가 있습니다.
개발과 관련된 이해관계자가 자신이 작성한 산출물을 스스로 테스트하지 않고 개발 과정에 테스터가 적극적으로 참여할 수 없다면 테스트는 절대 성공하지 못할 것입니다.
테스트 결과를 가지고 테스터를 욕하고 테스터를 쥐어짜기 전에 개발자를 교육시키고 개발자가 테스트를 수행할 수 있도록 시간과 비용과 인력을 지원해 주시기 바랍니다.
우리도 이제 좀 변해야 하지 않을까요?
적은 사람을 갈아넣어서 무조건 빨리 빨리 외치기보다는..
한걸음을 걷더라도 돌다리인지 확실히 두들겨 보면서..
솔직하게 우리가 만드는 제품이나 서비스에서 고객이 항상 쓰는 기능이 몇개나 됩니까?
많이 만든다고 블로우션 시장이 생기는 것도 아니고 차별점이 생기는 것도 아니지 않습니까?
좀 천천히 개발해도 좋다고 생각합니다. 좀 적게 개발해도 좋다고 생각합니다.
돌다리를 대충 만들고 두들기기보다는 하나의 주춧돌을 놓더라도 확실하게 놓으면서 만들면 좋겠습니다.
워낙에 방문자도 없는 변방의 불모지인지라.. 소홀했음을 인정합니다.
그래서 오랜만에 테스팅에 대한 글을 간단하게 적어보고자 합니다.
이 글은 지극히 제 개인적인 생각이므로 반론에 대해서는 언제나 환영입니다. 댓글 달아주시기 바랍니다.
제가 언제부터인가 이 블로그에 테스팅 관련 글을 적지 않은 이유는 제가 지식의 저주에 걸려서 그렇습니다.
무엇인가를 배우고 생각할 때는 이것 저것 많이 적었는데..
어느 시점으로 지나고 나니 모든게 재미가 없어졌고.. 그냥 당연한 것이 되었습니다.
그런데 어느 정도 시간이 지나고 나니.. 저는 당연한건데.. 당연하지 않다고 말씀하시는 분들이 꽤 많다는 것을 알게 되었습니다.
제가 틀렸을 수도 있지만.. 제가 생각하는 테스팅을 잘하기 위해서 당연하게 필요한 두가지를 적어보고자 합니다.
이 두가지가 제대로 되지 않는다면.. 전 그것 자체가 문제라고 봅니다.
첫번째는.. 테스트의 목적을 명확히 하는 것입니다.
개발 수명 주기에 대응해서 다양한 수준의 테스트 레벨과 테스트 유형에 따른 테스트를 수행함에 있어 가장 중요한 것은 내가 언제 어떤 테스트를 진행할 것인가이고.. 그에 대한 큰 그림을 이해하느냐 입니다.
그 모든 테스트에 대한 큰 그림과 그 그림안의 수많은 테스트 활동의 구분은 테스트의 목적에 따라 달라지게 됩니다.
테스트의 목적은 테스트로 측졍해야 하는 각종 지표(예를 들어, 품질 지표)와 연계됩니다.
테스트의 목적은 테스트의 시작과 끝을 결정짓는 가장 중요한 요소입니다.
많은 분들이 우리는 당연히 테스트의 목적을 설정한다고 말씀하시지만 막상 자기가 현재 수행하고 있는 테스트 활동의 목적에 대해 팀 또는 조직에서 합의된 형태로 공유되지 않는 경우를 종종 보았습니다.
테스트 목적 설정은 모든 테스트 활동에 있어 가장 중요하고 가장 먼저 해야 하는 활동입니다.
두번째는 내가 아무리 테스트를 잘하고 싶어도.. 절대로 테스트를 잘 할 수 없는 경우는...
바로.. 명세나 개발과 관련된 이해관계자와 함께 테스트를 하지 못하는 경우입니다.
조직이 더 나은 테스트를 원한다면 개발과 관련된 이해관계자는 자신의 작업 산출물에 대해 스스로 테스트를 수행해서 더 나은 산출물을 생산하고 테스터와 함께 협업할 수 있어야 합니다.
애자일이나 탐색적 테스팅, DevOps에서 공통적으로 협업을 강조하는 것은 다 이유가 있습니다.
명세, 코드, 모델에 명시된 사항이나 이해관계자의 마음 속에 있는 기준은 테스터가 결함 또는 장애를 식별하기 위한 가장 신뢰할 수 있는 기준입니다.
기준이 명확하지 않다면 테스트를 통해 결함을 식별할 수 없습니다.
물론, 명세도 없이 개발자와 얼굴 한번 마주치지 않고도 테스트를 진행할 수는 있겠지만.. 그 테스트 결과를 과연 믿을 수 있을까요?
기준을 개발 초기에 함께 검토하는 것과 개발 후반부에 테스트 결과로서 검토하는 것은 엄청난 차이입니다.
테스터는 테스트를 실행하기 전에 기준을 명확히 이해하고 설정해야 합니다.
결론은.. 테스터가 테스트 팀이 아무리 테스트를 잘하고 싶어도.. 테스트의 성공 여부는 개발 성숙도와 아주 밀접한 관계가 있습니다.
개발과 관련된 이해관계자가 자신이 작성한 산출물을 스스로 테스트하지 않고 개발 과정에 테스터가 적극적으로 참여할 수 없다면 테스트는 절대 성공하지 못할 것입니다.
테스트 결과를 가지고 테스터를 욕하고 테스터를 쥐어짜기 전에 개발자를 교육시키고 개발자가 테스트를 수행할 수 있도록 시간과 비용과 인력을 지원해 주시기 바랍니다.
우리도 이제 좀 변해야 하지 않을까요?
적은 사람을 갈아넣어서 무조건 빨리 빨리 외치기보다는..
한걸음을 걷더라도 돌다리인지 확실히 두들겨 보면서..
솔직하게 우리가 만드는 제품이나 서비스에서 고객이 항상 쓰는 기능이 몇개나 됩니까?
많이 만든다고 블로우션 시장이 생기는 것도 아니고 차별점이 생기는 것도 아니지 않습니까?
좀 천천히 개발해도 좋다고 생각합니다. 좀 적게 개발해도 좋다고 생각합니다.
돌다리를 대충 만들고 두들기기보다는 하나의 주춧돌을 놓더라도 확실하게 놓으면서 만들면 좋겠습니다.
댓글
댓글 쓰기