S/W 테스팅과 품질관리..

몰라서 못하면 배우는 맛이라도 있다.. 하지만, 모르는 것도 아니고 어떻게 해야 제대로 된다는 것을 알면서도 그렇게 하지 못하는 좌절감은 어떻게 달래야 할까? 테스트 인력이 없으니 프로그래머가 설계도 하고, 프로그래밍도 하고, 테스트도 하며, 메뉴얼도 쓴다.. 이로 인해 일정과 품질을 맞출 수 없게 되고 사례1, 사례2와 같은 일들이 자주 반복됨에도 불구하고, 단순히 프로그래머의 책임으로 넘기고 있다.. 개발팀의 능력부족(?)이라 탓하고 있는 이런 상황은 정말 아이러니다..

가장 이상적인 것은 QA팀을 별도로 두는 것이지만, 현실이 그렇지 못하다면 개발팀이 일정의 일부를 할애받아 테스팅을 수행할 수 있다.. 하지만, 이것도 품질관리를 위해서는 부족하니 전문화된 경력을 갖추고 학습된 QA 전담팀이 운영되어야 하는 것인데, 개발팀의 인력이 테스트를 제대로 수행할 수 있는 시간과 인력조차 확보하기 힘든 현실은, 정말 슬픈 현실이다..

개발팀이 테스트를 병행하여 수행할때의 어려운 점이 보완사항을 기민하게 반영시키기 어렵다는 것이다.. 이 효과를 극대화 시키는 것이 효율적인 프로젝트 운영인데도 불구하고 막판에 개발자 더 넣을 생각은 해도, 초기부터 QA팀 운영할 생각은 전혀 못한다.. 막판에 개발자 더 들어갈 상황이면 이미 프로젝트는 망가졌다고 봐야한다..

최재훈님의 리스크 관리를 못하는 조직라는 글의 내용에 전적으로 동감이다.. 이런 조직은 리스크를 제대로 인식하지 못하는 조직이라 부르고 싶다.. 가장 기본적이고 큰 리스크를 그저 두고보고 있는 것은 아닐까? 그저~ 바라만 보고 있지~

이런 상황에서 전체적인 분위기는 어떻게 될까? "에라 나도 모르겠다"가 아닐런지.. 실용주의 프로그래머에서 강조했던 "깨진창문 방치하지 않기"가 전반적인 분위기로 형성되려면 고객과 회사, 팀 그리고 개인이 할 역할수행이 모두 이루어져야지 개인에게만 책임을 전가시켜서는 제대로 될 수가 없다.. 하지만, 대한민국의 SI 프로젝트는 아무렇지도 않은듯 여전히 이렇게 돌아간다.. 원인은 저가 수주 혹은 도덕적 헤이에 빠진 수행사, 둘중 하나다..

남 탓하여 뭐하리.. 프로젝트를 이렇게 수행하도록 만들지 못하는 내탓이오~