테스팅 히치하이커를 위한 안내서

콘웨이의 법칙이라는 것이 있습니다. 콘웨이의 법칙은 '소프트웨어의 구조와 그 소프트웨어를 개발하는 팀의 구조는 유사해진다는 법칙'으로 정의됩니다. 이에 대한 해석은 여러 곳에서 다양한 형식으로 인용되고 있습니다. 저는 이 내용을 '맨-먼스 미신'이라는 책에서 접했습니다. 한동안 잊어버렸던 내용인데.. 최근에 린 프로세스와 TOC에 대해 공부하면서 다시 한번 생각해 보게 되었습니다. 저는 이것을 조금 다르게 해석해 보았습니다. '팀의 프로세스가 복잡할수록 소프트웨어는 매우 복잡해진다.' 간단하게 볼 때 MS 워드를 본다면 여러분은 MS 워드의 모든 기능이 모두 몇가지나 되는지 혹시 아시는 분 계시나요? MVP 분들 중에 혹시 아시는 분이 있다면 제보 부탁드립니다. 사실 우리가 워드에서 실제로 사용되는 기능은 그다지 많지 않습니다. 그러면 이것은 왜 이렇게 복잡한 기능을 가진 거대한 공룡이 되어 버렸을까요? 그것은 MS가 거대해진것과 고객의 요구사항을 너무 많이 수용했기 때문이라고 생각합니다. 하지만 이런 과도한 커스터마이징을 통해서 MS는 고객에게 어떤 가치를 전달하고 있을까요? 우리가 워드를 통해서 어떤 이득을 얻고 있을까요? 사용성 테스트를 하다 보면 특정한 결과를 얻기 위해서 과도한 단계를 거치는 경우가 가끔 있습니다. 이러한 경우 이러한 단계를 설정하게 된 배경을 조사해 보면 많은 경우 과도한 커스터마이징을 통해서 서로 연관이 없던 기능이 통합되거나 여러 사이트에서 독립적으로 제공되던 유사한 기능들이 통합되는 경우에 발생하는 경우가 많습니다. 너무 거대해지고 자주 사용되지 않는 기능들로 채워진 소프트웨어는 고객으로부터 버림 받을 수밖에 없습니다. 그리고 그 빈자리는 다시 한번 혁신으로 뭉친 작은 기업들이 내놓은 작은 소프트웨어가 차지합니다. 그리고 그 회사가 커지면 그 소프트웨어도 다시 이전에 사라졌던 소프트웨어의 전철을 밟습니다. 린이나 TOC는 이러한 악순환을 끊기 위해 끊임없는 혁신과 고객에게 전달하고자...

품질이란 무엇일까요? 위에서는 사장님부터 아래로는 사원들까지 밖에서도 안에서도 언제나 메아리 치는 소리.. 품질... 하지만 품질이 무엇인지 정확히 말할 수 있는 사람은 많지 않습니다. 어떤 사람은 ISO 25000 표준을 얘기하는 사람도 있고, 어떤 사람은 사용성 같은 것을 이야기 하기도 합니다. 왜 그런걸까요? 여러분은 사랑을 정의 내릴 수 있나요? 가치관이나 부성애 같은 것은 어떠신가요? 꿈은 어떻습니까? 품질도 위와 같은 개념과 매우 비슷합니다. 품질을 정의하기 위한 노력을 지금 그만두는 것이 자원을 절약하는 지름길입니다. 왜냐하면 품질이란 매우 상대적인 가치관에 가깝기 때문입니다. 때문에 여러분 회사 제품의 품질이 낮다고 여겨진다면 고객의 불만이 크다고 생각된다면 대부분의 원인은 대화 부족인 경우가 많습니다. 소프트웨어 개발과 관련된 수많은 사람들 고객을 포함해서 개발자, 테스터, 기획, 그래픽, 경영진 등 많은 이해관계자들의 품질에 대한 가치과 우선순위가 틀리기 때문입니다. 서로 대화를 하지 않으면서 서로 다른 꿈을 꾸게 된다면 그 목적지는 전혀 다르게 됩니다. 개발팀에서는 기능의 풍부함을 품질로 보고 테스터는 기능의 정확성을 품질로 보고 경영진은 돈을 많이 벌어다 줄 제품을 품질로 보고 고객은 사용이 편한 제품을 품질로 여긴다고 가정할 때 각각의 이해 관계자의 의사소통이 없이 제품의 개발이 달려가게 된다면 그 끝은 자명한 일입니다. 품질의 정의와 가치에 대한 얘기는 탁상공론일 뿐입니다. ISTQB에서는 이러한 개념을 '오류-부재의 궤변'으로 설명합니다. 품질은 매우 중요합니다. 하지만 무엇을 품질의 가치로 삼을 것이고 그 가치의 기준을 제공할 당사자가 누구인지에 대해 명확하게 정의할 필요가 있습니다. 그런 선행과정이 있어야 품질이 무엇이고 품질을 어떻게 측정할 것인지에 대한 논의를 시작할 수 있을 것입니다. 세상에는 결함은 별로 없지만 잘 팔리지 않는 제품이 있는가 하면 끊임없이 결함이 생겨나고 문제가 있다고 해도 불티나게 팔리는 아...