프로젝트에서 개발자가 할 일 : 통합테스트

프로젝트에서 개발자가 할 일 : 통합테스트

 

혹자의 말에 의하면, 본격적인 개발단계입니다!

물론 프로젝트 입장은 다릅니다..

 

개발단계와 단위테스트 단계를 거치며 기능상 문제가 없다(개발은 다 되었다)는 전체로 수행되는 단계입니다.  주요 목적으로는 전체적인 업무흐름이 맞춰 (마치 실무에서 사용하는 것처럼) 테스트를 하고자 함입니다. 오픈을 상정하고 진행합니다. 

 

그런데, 프로젝트의 현실이 이론적으로 딱딱 맞아떨어지지 않습니다. 여러가지 이유로 개발이 완료되지 못하는 경우도 많습니다. 이 단계까지 요구사항이 확정되지 않은 경우도 있으며, SR건의 반영 부분도 남아있고, 대응 개발이 안되어 있을 수도 있습니다. 물론 개발자의 개인역량 부족으로 지연되는 경우도 있습니다.

 

현실이 이렇다보니 제대로된 통합테스트는 거의 불가능에 가깝습니다. 물론 소규모(10명 내외)의 단위업무 프로젝트들은 예외입니다. 규모가 적을수록 (일반적으로) 엮여있는 유관 업무들이 적어 소위 나만(내것만) 잘하면 되기 때문입니다. 그래서 요즘 통합테스트를 기본 2차에서 5차까지 진행을 합니다.

 

5차까지 수행하는 기준으로 보면,

1차는 그냥 개발의 연장선이다! 라고 생각하는 분위기입니다. "자! 이제 통테잖아. 하던 것 빨리 마무리 해!" 라고 하는 단계입니다.

 

2차는 "이제 개발은 끝났지? 그럼 유관업무랑 엮인거 단위테스트에 못했잖아. 되는지 한번 더 체크해봐. 빠진거 없나 확인하고", 유관 업무와 연계 점검을 비롯하여 최종점검을 합니다.(원래 의미의 단위테스트)

 

3차는 "자! 이제 제대로 해 봅시다. 안되는 건 이슈이니 별도 보고하시고 현황 및 캐치업방안 가져오세요" 시나리오에 따라 본격적인 테스트를 시작합니다. 안되는 기능을 관리하고 적용계획을 수립합니다. 이 기간에도 대응 개발, 대외업무 등 불가피하게 테스트하지 못하는 그능과 뒤늦은 요구사항, 개발팀의 지연 등이 발생합니다.

 

4차에는 분위기가 많이 바뀝니다. 오픈 지표를 두고 테스트하기 때문입니다. 3차의 결과부터 오픈 가능여부를 판단합니다. 그리고 최종 4차 결과를 보고 Go or Stop를 판단하기 때문입니다. 이 단계는 모든 테스트를 다 포함해서 한다고 생각하면 됩니다. 안 되면 이슈로 보고/관리 됩니다.

 

5차는 오픈을 위한 최종 점검테스트를 진행합니다. 이 기간에도 개발을 하고 있다면, .... OTL 입니다.

 

사실 개발자는 (개발이 잘 되었다면) 이 단계에서는 좀 편해야(?) 합니다. 일정에 맞춰 테스트만 돌려주면 되기 때문입니다. 그리고, 결과를 스샷 등으로 증비하여 제출하는 정도가 전부입니다.

테스트 기간은 보통 차수당 1주정도 진행하고 1주 보완작업, 1주 계획, 1주 진행, 1주 보안 등의 순서로 이뤄집니다. 프로젝트 기간이 짧거나 소규모인 경우, 이 일정들을 축약해서 2~5차에 걸쳐 진행합니다. 1차(1번)로 끝내는 경우는 대부분 4~5명으로 진행되는 단독 소규모 프로젝트들이라 예외로 하겠습니다.

 

개발자는 본인이 개발한 업무를 각 테스트 시나리오에 맞춰 수행하고, 결과를 증빙하는 것이 전부입니다. 물론 말처럼 심플하지는 않지만, 이 외에 할것이 없는것 또한 사실입니다. 

결함 발생 등의 이유로 정신없이 바쁜 개발자들이 속출하는것이 현실이지만, ... 잘 해야겠죠?!

 

각 단계에 맞춰 미리미리 준비를 하고 챙긴다면 대부분 큰 이슈없이 진행되리라 생각합니다. 프로젝트에 참여한 모든 관리자와 개발자들이 각자의 업무에 책임감을 가지고 잘 해준다면, 즐거운 프로젝트가 되지 않을까 생각합니다. 

 

P.S. 통합테스트에 가장 바쁜 개발직군의 언급이 빠졌네요. 배치파트 중 데이터 이행과 관련된 개발자들입니다. 각 차수별 이행 배치를 수행하여 테스트 환경을 세팅해줘야하고 데이터 검증도 해야 합니다. 통합테스트 전까지는 운영데이터를 볼 수 없기 때문에 진정 바쁜 시기라 할 수 있겠습니다.

 

The End.