통합테스트 시 폭탄 피하기
SI 개발이 무리없이 잘 순항하는 프로젝트도 통합테스트 단계에서 갑자기 많은 문제가 드러나는 경우가 있다.
이런 현상이 일어나는 근본적인 원인은 프로젝트 자체에 있을 수 있다.
SI 개발에 적용된 개발방법론이나 사업관리 툴은 대부분 건설이나 건축분야에서 온 것이 많다고 한다. 그 작업과정을 보면 거의 일치 하니까 자연스럽게 적용되었을 것이다.
하지만 건설과 SI 개발은 뚜렷이 다른점이 있는데, 요구사항의 불확실성이 바로 그것이다. 건축은 설계단계에서 이미 완성된 모습을 볼 수 있다. 물론 공사 도중 요구사항이 변경되기되 하지만 구조공학이나 역학적 문제에 한계를 갖고 있어 좀처럼 허용하지 않는다.
반면 프로그램은 너무나 유연해서 요구사항 변경에 거의 무방비나 다름없다.
프로젝트 막바지인 통합테스트 단계에 가서 치명적인 결함이 발생하는 불상사를 방지하기 위해 다음과 같은 방안을 항상 고려하자.
1. 요구사항 정의 시 고객과 눈높이를 최대한 맞추자.
설계가 끝나고 하는 워크샵이 매우 중요하다. 설계사항은 물론 정의된 요구사항 하나하나를 고객의 생각과 일치시키는 작업을 해야한다.
고객은 낮은 수준으로 생각한 것을 높게 잡은 경우도 있을 수 있으며, 우리는 작게 생각한 범위가 실은 더 큰 범위를 함축할 수도 있는데, 이런 부분을 일일이 검토해서 일치시키는 작업이 필요한 것이다.
2. 그렇게 도출된 업무나 기능의 우선순위를 정하자.
고객과 함께 중요 업무와 기능을 식별하는 것이 좋다. 우리가 WBS의 크리티컬 패스를 구할 때 연관 개발의 최대 일정 기준을 고려하는데, 이것보다는 이렇게 식별된 최우선 순위의 업무 개발에 중점을 두는 크리티컬 패스를 설정해야 된다. 이는 나중에 각종 테스트 단계에서 덜 취급하여 중요기능 결함을 제거하는데 집중하도록 하는데 활용되어야 한다. 낮은 순위 업무와 기능은 오히려 안정화 부분에서 다뤄야 한다.
3. 설계 단계에서도 테스트는 하자.
건축분야는 이것이 가능하고, 또 설계 결함이 없는지 툴을 사용해 체크를 한다. SI 개발에도 설계된 내용에 결함이 없는지 테스트를 할 수 있다면 개발공수와 문제점을 대폭 줄일 수 있을 것이다.
문제는 비용이다. 그동안 어떤 SI 개발에서도 잘 적용하지 않은 생소한 것이라 어떻게 테스트를 하는지 우려할 수도 있지만, 이미 테스트 전문가들은 알고 있으니 걱정할 필요는 없다.
4. 단위테스트는 단순 단위테스트와 기능 단위테스트로 구분하자.
단위테스트를 편법으로 하는 경우가 종종 있는데, 단순 기능 점검 체크리스트를 만들어 막 코딩을 끝낸 모듈에 대해 그에 맞는 기능이 올바르게 작동하는지 테스트하는 시나리오를 만들어서 적용해야 한다. 개발방법론에서 단위 또는 통합테스트 시나리오를 설계 단계에 만들게 한 이유가 바로 여기에 있다. 문제는 개발자들이 이 시나리오 작성을 귀찮아 한다는 것이다. 이 부분을 간과하게 되면 통합테스트에서 날벼락을 맞는 단초를 제공하는것이다.
5. 요구사항 변경이 발생하면, 우선순위를 정해 관리하자.
개발 도중 요구사항이 변경되거나, 추가된다면 이 부분에 대한 중요도를 검토해서 전체 업무에 대해 우선순위를 재설정하는 작업을 해야 한다. 그리고 그 우선순위대로 개발 내용을 수정해야 한다. 고객의 설득은 그 우선순위 관리대장을 근거로 객관적인 수치를 갖고 대응해야 한다. 변경을 수용하기로 했다면 재설정된 우선순위에 맞춰서 개발하고, 뒤로 밀린 업무는 안정화 기간에 처리하는 것으로 하면 전체일정이나 공수에 거의 무리를 주지 않게 된다.
6. 단위 기능테스트나 통합테스트에 상관없이 우선순위가 높은 업무만 테스트 하자.
이렇게 함으로써 단위 기능과 통합테스트 시나리오를 근사하게 작성하고 중요 기능 개발에 품질을 높일 수 있다고 본다. 나머지 하위 기능이나 업무 테스트는 하되 그 결함 처리를 안정화 기간에 하는것이다. 물론 최종 검수 시 이 부분이 이슈가 될 수 있는데, 이는 고객과 잘 협의해야 한다. 결함이 발견된 하위 기능에 대해서는 블라인드 처리 등으로 처리하는 방법 등을 적용하면 된다.
계획대로 진행되었다면, 대부분 자잘한 업무나 기능만 남게 되었을 것이다.
이런 현상이 일어나는 근본적인 원인은 프로젝트 자체에 있을 수 있다.
SI 개발에 적용된 개발방법론이나 사업관리 툴은 대부분 건설이나 건축분야에서 온 것이 많다고 한다. 그 작업과정을 보면 거의 일치 하니까 자연스럽게 적용되었을 것이다.
하지만 건설과 SI 개발은 뚜렷이 다른점이 있는데, 요구사항의 불확실성이 바로 그것이다. 건축은 설계단계에서 이미 완성된 모습을 볼 수 있다. 물론 공사 도중 요구사항이 변경되기되 하지만 구조공학이나 역학적 문제에 한계를 갖고 있어 좀처럼 허용하지 않는다.
반면 프로그램은 너무나 유연해서 요구사항 변경에 거의 무방비나 다름없다.
프로젝트 막바지인 통합테스트 단계에 가서 치명적인 결함이 발생하는 불상사를 방지하기 위해 다음과 같은 방안을 항상 고려하자.
1. 요구사항 정의 시 고객과 눈높이를 최대한 맞추자.
설계가 끝나고 하는 워크샵이 매우 중요하다. 설계사항은 물론 정의된 요구사항 하나하나를 고객의 생각과 일치시키는 작업을 해야한다.
고객은 낮은 수준으로 생각한 것을 높게 잡은 경우도 있을 수 있으며, 우리는 작게 생각한 범위가 실은 더 큰 범위를 함축할 수도 있는데, 이런 부분을 일일이 검토해서 일치시키는 작업이 필요한 것이다.
2. 그렇게 도출된 업무나 기능의 우선순위를 정하자.
고객과 함께 중요 업무와 기능을 식별하는 것이 좋다. 우리가 WBS의 크리티컬 패스를 구할 때 연관 개발의 최대 일정 기준을 고려하는데, 이것보다는 이렇게 식별된 최우선 순위의 업무 개발에 중점을 두는 크리티컬 패스를 설정해야 된다. 이는 나중에 각종 테스트 단계에서 덜 취급하여 중요기능 결함을 제거하는데 집중하도록 하는데 활용되어야 한다. 낮은 순위 업무와 기능은 오히려 안정화 부분에서 다뤄야 한다.
3. 설계 단계에서도 테스트는 하자.
건축분야는 이것이 가능하고, 또 설계 결함이 없는지 툴을 사용해 체크를 한다. SI 개발에도 설계된 내용에 결함이 없는지 테스트를 할 수 있다면 개발공수와 문제점을 대폭 줄일 수 있을 것이다.
문제는 비용이다. 그동안 어떤 SI 개발에서도 잘 적용하지 않은 생소한 것이라 어떻게 테스트를 하는지 우려할 수도 있지만, 이미 테스트 전문가들은 알고 있으니 걱정할 필요는 없다.
4. 단위테스트는 단순 단위테스트와 기능 단위테스트로 구분하자.
단위테스트를 편법으로 하는 경우가 종종 있는데, 단순 기능 점검 체크리스트를 만들어 막 코딩을 끝낸 모듈에 대해 그에 맞는 기능이 올바르게 작동하는지 테스트하는 시나리오를 만들어서 적용해야 한다. 개발방법론에서 단위 또는 통합테스트 시나리오를 설계 단계에 만들게 한 이유가 바로 여기에 있다. 문제는 개발자들이 이 시나리오 작성을 귀찮아 한다는 것이다. 이 부분을 간과하게 되면 통합테스트에서 날벼락을 맞는 단초를 제공하는것이다.
5. 요구사항 변경이 발생하면, 우선순위를 정해 관리하자.
개발 도중 요구사항이 변경되거나, 추가된다면 이 부분에 대한 중요도를 검토해서 전체 업무에 대해 우선순위를 재설정하는 작업을 해야 한다. 그리고 그 우선순위대로 개발 내용을 수정해야 한다. 고객의 설득은 그 우선순위 관리대장을 근거로 객관적인 수치를 갖고 대응해야 한다. 변경을 수용하기로 했다면 재설정된 우선순위에 맞춰서 개발하고, 뒤로 밀린 업무는 안정화 기간에 처리하는 것으로 하면 전체일정이나 공수에 거의 무리를 주지 않게 된다.
6. 단위 기능테스트나 통합테스트에 상관없이 우선순위가 높은 업무만 테스트 하자.
이렇게 함으로써 단위 기능과 통합테스트 시나리오를 근사하게 작성하고 중요 기능 개발에 품질을 높일 수 있다고 본다. 나머지 하위 기능이나 업무 테스트는 하되 그 결함 처리를 안정화 기간에 하는것이다. 물론 최종 검수 시 이 부분이 이슈가 될 수 있는데, 이는 고객과 잘 협의해야 한다. 결함이 발견된 하위 기능에 대해서는 블라인드 처리 등으로 처리하는 방법 등을 적용하면 된다.
계획대로 진행되었다면, 대부분 자잘한 업무나 기능만 남게 되었을 것이다.
댓글
댓글 쓰기