누가 소프트웨어 품질을 책임질 것인가?

해외 현업 소프트웨어 테스터들의 생생한 경험과 지식을 담아내고 있는 “Software Testing Help(http://bit.ly/9yDnPN)”에서 흥미로운 아티클을 발견해 여기 소개한다.

테스팅을 하다 보면 누구나 한 번쯤 생각하게 되는 주제를 적절한 비유와 이해하기 쉬운 논조를 사용해 자칫 심각해 지기 쉬운 주제를 재미있게 풀어쓴 것 같다. 저자인 Pradeep Soundararajan 의 개인 블로그(http://testertested.blogspot.com)에도 흥미로운 아티클들이 많으므로 한 번 방문해 보시기를 권한다.   

 

번역 및 포스팅에 대해서는 원 저자의 승인을 받았다.
해당 글의 저작권은 원 저자인 Pradeep Soundararajan에게 있다. 

늘 부족한 제 번역에 전문 번역가로서의 조언을 아끼지 않으시는 고은혜 님에게도 이 자리를 빌어
감사드린다.

“존재하지도 않는 품질의 신” vs. “인간” – 누가 소프트웨어 품질을 책임질 것인가?

 

By Pradeep Soundararajan

 

지금까지 내가 만났던 수많은 소프트웨어 테스터들은 그들만이 테스팅을 수행하고, 그들만이 품질에 대한 책임을 질 수 있다는 생각을 가지고 있었다. 심지어는 그들 스스로를 제품의 품질에 관한 한 “신”이라고 생각하는 일부 테스터들도 있었다.

 

당신에게 묻고 싶다. 이것이 과연 올바른 것인가?

 

여기서 이에 관한 내 생각을 밝히고, 여러분들과 이에 대해 논의하고 싶다.

 

품질은 모두가 책임져야 하는 것이지, 한 사람이든 수 천명이든 테스터가 책임을 져야 하는 것은 아니다(Quality is everyone’s responsibility and not just a tester out there or thousands of them out there). 당신의 가족이 행복하기를 바란다고 해서 가족 중의 한 사람에게 행복을 책임지라고 맡길 수 없으며, 뭔가가 잘못되었다고 해서 그 사람을 추궁할 수는 없는 것이다. 영원토록 가족이 행복하기를 바란다면, 모든 사람들이 동참하고 이를 위해 노력해야 하는 것이다.

 

이와 유사하게, 제품이 양질의 품질을 가지기 위해서는 고객을 포함하는 모든 이해당사자들과, 요구사항, 설계, 개발, 테스팅과 지원에 이르는 모든 활동들이 똑같이 품질에 대한 책임을 져야 한다.

 

그러나, 테스팅 활동을 비중 있게 생각하지 않거나 혹은 비중 있게 생각한다고 꾸밀 필요가 있는 일부 조직에서는 모든 프로젝트에 대해 테스터를 고용한 다음, 고객들이 버그를 찾아낼 때마다 이들을 희생양으로 삼고는 한다. 이런 테스터들은 스스로가 품질에 관한 신이라고 생각하게 되며, 버그를 놓쳤을 경우 죄책감을 느끼고 놓친 버그에 대해 어떻게든 책임을 지려고 든다.

 

이런 현상들이 발생하는 이유는 대부분의 테스터들이 테스팅이 무엇인가에 대해 개념을 잘못 세워놨기 때문이다. 실제로 테스팅은 품질을 향상시키는 것이 아니라 품질에 관한 정보를 찾아내는 활동임에도 불구하고, 대부분 테스팅은 품질을 향상시키는 작업이라고 오인하고 있는 것이다(They carry an idea of testing as improving quality while it is not improving quality but finding information about quality).

 

버그 리포팅은 누군가 신경 써서 해당 버그를 수정하지 않는 한 그 자체만으로 품질을 향상시킬 수가 없다. 게다가 테스터로 일한 경험이 있다면 누구나, 버그 한 개를 수정할 때마다 이로 인해 새로운 버그들이 꼭 두 개 이상씩 생겨난다는 사실을 알고 있을 것이다. 따라서 테스터가 보고한 버그들이 수정될 때마다 새로운 버그들이 생겨나기 때문에, 버그 리포팅은 품질을 더더욱 떨어뜨리게 만들 소지도 있는 것이다.

 

버그가 적다고 해서 꼭 품질이 좋다고 볼 수도 없다는 점 역시 생각해 봐야 한다. 1960년대에 처음으로 테스팅 팀이란 것을 도입했던 소프트웨어 테스팅 업계의 살아있는 전설 제리 와인버그(Jerry Weinberg)는 “품질이란 중요한 사람들이 가치 있다고 평가하는 것들이다(Quality is value to some person who matters)”라고 정의했으며, 이후 마이클 볼튼(Michael Bolton)은 이 정의를 “테스터의 의무는 중요한 사람들이 누군지, 그리고 무엇이 그들에게 중요한지를 찾아내는 것이다(It is a testers responsibility to find out who matters and what matters to them)”라고 확장한 바 있다.

 

테스터들이 계속 스스로를 품질의 신이라고 생각한다면 다음과 같은 문제가 발생할 수 있다.

 

개발자들과의 갈등: 테스터들은 개발자들을 품질을 망치고 늘 문제를 일으키는 골칫덩어리 정도로 보기 시작한다. 이는 전체 팀의 퍼포먼스에 영향을 미치고, 개발자들이 테스터들을 업신여기게 만드는 계기가 될 수도 있다. 따라서, 이러한 문제를 일으키는 테스터들은 자기 이름뿐이 아니라 우리 전체의 이름에 먹칠을 하는 것이다.  

 

이것은 마치 타자가 투수에게 너무 많은 안타를 허용한다고 비난하는 것과 같다. 야구팀이 제대로 돌아간다면 타자와 투수가 모두 합심해서 팀을 승리하게 만들 것이다. 타자가 그 역할을 못할 때도 있고, 투수가 그럴 때도 있다. 테스터나 개발자나 사람이니, 똑같이 실수를 할 수 있다는 아량을 품는 것이 좋다. 어떻게 생각하는 지에 따라서, 즉 사고의 기술(Skills of thinking)에 따라서 팀의 성공에 도움을 줄 수 있는 것이다.  

 

버그를 놓친 것에 대한 죄책감: 버그를 놓치게 되면 테스터 혼자 모든 책임을 져야 하는 것처럼 느끼는 사람들이 많다. 그런 테스터들은 그들이 팀의 일부라는 생각을 하지 못하는 것이다. 나는 모든 이해당사자들이 이런 실수에 대해 책임이 있다고 말하고 싶다.

 

9회 말 홈런이 필요한 상황에서 타자가 삼진을 당했다면, 그 타자가 팀의 패배에 대한 모든 책임을 져야 하는가?

 

학습 실패(Failing to learn): 스스로를 품질의 신이라고 간주하는 테스터들을 보면 일정한 패턴이 있는데, 바로 학습에 실패한다는 것이다. 책임자라는 생각을 갖게 되면 관련된 거의 모든 것을 이미 다 배웠다고 생각하고, 또 자신이 배운 것들은 절대적으로 옳다고 간주하게 되는 경향이 있다.

 

내가 장담하는데, 인도 곳곳을 다니면서 만났던 테스터들 중 90%는 수 년 간의 테스터 경력이 있음에도 불구하고, 테스팅에 관한 책은 단 한 권도 읽은 적이 없었다. 개발과 관련된 책을 읽어본 적이 없는 개발자는 분명 찾아보기 어려울 것이다. 하지만 테스터만은 온라인에 게시된 내용들 정도면 충분하고 훌륭한 것들이라고 생각하고 있다.

 

테스터란 사람들이 정작 그들이 학습한 것은 테스트하지 않는다는 것, 정말 놀랍지 않은가? 그들이 스스로 주장하는 수준의 절반 정도라도 테스트 할 수 있을지를 도대체 어떻게 믿으란 말인가? 

 

변화(The Change)

이 시점에서, 나는 여러분들에게 변화해야 한다고 강요하는 건 아니다. 다만 세계적으로 존경 받는 테스터들 중에서는 스스로가 품질의 신이라고 생각하거나, 품질에 대해서 전적으로 혼자 책임을 져야 한다고 생각하는 사람이 없다는 사실을 말해주고 싶을 뿐이다. 당신이 이 글에서 변화의 실마리를 발견하고 스스로를 바꿀 수도 있겠지만, 그러한 변화를 일으킬 수 있는 것은 내가 아니라 바로 당신이다.

 

만약 당신이 조금이라도 변화하길 바란다면, 다음과 같은 사항들을 고려해보기 바란다.

 

-       품질에 대한 정보를 제공하는 개념으로서의 테스팅(Testing as providing information about quality)

-       정보를 제공해주는 원천지로서의 개발자(Developers as sources of information)

-       테스트 팀이 성공할 수 있는 핵심 요인으로 작용하는 테스트 커버리지(Test Coverage as a key factor for success of a test team)

-       전체 팀의 성공이 곧 테스트 팀의 성공(Success of the entire team is the success of a test team)

-       버그를 놓치는 것이 항상 테스터의 잘못은 아님(Missing bug is not always a tester’s fault)

-       테스터도 사람이며 사람은 실수할 수 있음(Testers are humans and humans are fallible) – 그리고
실패하게 마련임(They fail)

-       테스터도 개발자만큼이나 불완전한 사람들임(Testers are as imperfect as developers)

-       이런 테스팅에 대한 올바른 개념을 다른 테스터들에게 전파할 것(Helping other testers to get the idea right after you have got it)

 

About Author:

Pradeep 은 저명한 테스터이자 소프트웨어 테스팅에 관한 국제적인 연사로 호응을 얻고 있다. 테스팅과 관련된 사고 분야의 리더로서 이와 관련된 문제를 해결하는 데에서도 명성을 얻고 있다. 테스팅과 관련해 인기 있는 블로그인 『Tester Tested!』(http://testertested.blogspot.com)를 운영하고 있으며 테스팅 및 테스터들에 관한 코칭, 컨설팅, 관리를 수행하고 있다.