Iterative-Incremental model

저번 포스팅에 이어 Interative 및 Incremental model에 대해서 설명해보고자 합니다.

 

과제별로 특성에 따로 Waterfall model이나 Interative model을 선택해서 과제를 진행하게 되는데 개발 및 검증도 완전히 다르게 진행됩니다.

 

보통 Agile 개발론에서 많이들 사용하죠. 혹은 Prototyping으로 빠르게 demo를 만들때 사용하기도 합니다.

 

이는 전통적인 Waterfall model은 각 단계별 호흡이 길고 실제 개발 산출물과 사용자의 needs가 다른 경우가 빈번하기에 이를 극복하기 나온 model입니다.

 

또한, 중요한 기능을 우선 개발함으로써 Test의 복잡성을 줄이고 빠르게 defect를 검출하기 위한 이유도 있습니다.

Defect를 미리 검출해서 수정한다는건 Risk 비용 감소로 이어지죠.

 

이를 실무에서는 Shift-Left라고도 합니다. (이것에 대해서는 별도로 포스팅할께요.)

 

Iteration이라는 짧은 주기안에 구현 가능한 요구사양을 list up하고 해당 기능만을 완벽하게 구현 및 test하고 사용자의 feedback을 받습니다. 그리고 다음 주기에 다시 다른 요구사양 및 앞서 구현한 기능의 bug를 수정하는 작업을 반복(interation)하게 되는게 특징입니다.

 

Tester입장에서는 V-Model처럼 충분히 요구사양을 분석하고 test plan 및 test case를 작성하는 시간이 주어지지 않습니다. 항상 개발자들과 소통하며 Test Plan 및 전략을 수립해야하며 Test주체도 개발자, Tester 구분없이 진행하게 됩니다.

 

그리고 문서를 최소화해야하기에 자동화된 도구를 많이 사용하게 됩니다.

저는 Jira, Confluence, TestRail를 사용해서 실시간으로 요구사양의 변경과 defect를 추적하였고 Test Plan및 Test case를 수정했습니다.

 

그리고 개발자도 PyDocs, JavaDoc같은 자동화된 문서화 도구를 사용해서 별도의 문서 작성없이 자동으로 문서 산출물을 관리하였습니다.   

※ 특히 API 개발 시 swagger같은 tool은 매우 유용합니다.

 

또한 Tester는 요구사양을 기반으로 code개발전에 미리 dumy component를 작성해서 test를 시작할 수도 있습니다.

 

명세 조건을 기반으로 input및 기대결과를 정리하고 그에 맞게 testcase를 미리 작성을 해놓는다면?

개발자가 개발 중간에도 작성된 test case를 수행해서 Code의 품질을 확보한 상태로 System test를 수행할 수 있게 됩니다.  Smoke test와 Senety test를 동시에 만족하죠?

 

또한 이 TC가 중요한 기능에 대한 TC라면 Regrassion Test시에도 사용할수 있습니다.

(TC 작성 시 이런점을 고려해서 유연하게 작성할 필요가 있습니다.)

 

물론 개발자와 tester는 사전에 이에 대한 충분한 교육이 되어있어야 적용 가능하기에 project별로 수준이 다를수는 있습니다.

 

하지만 결국 빠른 S/W Release주기와 품질을 만족시키기 위해서는 각 담당자들의 노력이 필요하다고 생각합니다.

 

이론 정리하다가 이야기가 한참 딴데로 셌네요.

그래도 실무에서 적용하는 case라고 참고하시라고 그냥 쭉 적어봤습니다.