설계단계에도 테스트를 하자

  보통 SI 에서 테스트 관련 업무는 뭐 이정도 되겠다.

 

- 테스트 계획 세우기

- 테스트 환경 만들기

- 테스트 열씸히 하기

- 나온 오류 수정하기

- 테스트 결과 보고하기

 

  이런 테스트 업무를 하는 시기는 설계 단계에서 계획을 세우고 시나리오를 만드는 것 외에는 구현 단계에 들어와 본격적으로 이루어진다. 하지만 설계 단계에서도 테스트는 이루어 져야 한다. SW 개발에 있어 설계가 가정 중요하다고 하면서 그 설계가 잘 되었는지는 검증하는 메쏘드가 거의 없다.

 

  사실 SI 에서 설계는 고객의 요구사항을 설계도로 보여주는 것이다. 건축으로 따지면 조감도를 그리는 것이다. 여기에 그림으로는 그럴듯 하지만 과연 그렇게 구축될 수 있는지 설계상 검토가 필요하다. 다시 건축을 거들떠 보면 하중은 견딜 수 있는지, 동선은 원할한지 등을 살펴 봐야 하는 것이다.

즉, 설계는 일종의 테스트 사상을 겸하고 있어야 한다. 좀 더 나아가서 발주자가 낸 세부 요구사항이 맞는지, 최종 목적을 구현하는데 부합한지 점검되어야하지 않는가.

 

 

  무조건 고객이 요구하는 대로 개발할 수는 없다. 여러가지 이유가 있겠지만, 그들은 사실 기간과 비용이 얼마나 들지 모르고 발주를 내기 때문이다. 그래서 변경 부분 - 아니 엄밀히 말해서 요구사항의 오류부분이 생기면 고객을 설득할 수 있어야 한다. 그러려면 최대한 최종 목적에 부합하면서 충분한 대안을 제시할 수 있는 분석, 설계가 나와야 한다.
그래서 설계 단계가 끝나면 반드시 고객과 세부적인 설계리뷰가 필요하다. 단순히 형식적인 워크숍을 갖지 말자. 그것이야 말로 돈낭비, 시간낭비, 헛지랄이다. 사무실을 떠나 근교의 세미나 장소로 나가는 것은 좋다. 고객도 다른 업무의 방해로 부터 차단할 필요가 있기 때문이다.

 

  아주 세부적인 사항까지 검토하고 의견을 나누는 것이다. 가능하다면 발표자료는 최대한 이해하기 쉽게 만들고 필요하다면 화면도 비주얼하게 만들자. 힘들겠지만 이것이 오히려 나중에 시행착오를 줄여준다.

리뷰가 끝난 후 고객과 개발팀 모두 만족하는 결과가 나왔다면 시원하게 기분좋게 축하주를 드는 것이다.

 

이것이 설계 단계에 행해지는 테스트이다.