[SW공학 동영상 15화] 인수테스트 주도 개발 (Acceptance Test Driven Development) [상]

다른 동영상 보기 >>>

소프트웨어 설계 - 애자일 테스팅 편

소프트웨어 개발이 문서 작업이 많은 분석, 설계에 집중하던 것에서 최근에는 개발에 더 집중하는 애자일(Agile)로 옮겨가는 추세이다. 미리 정해진 계획만 따르기보다 상황에 따라 유연하게 대처하는 애자일은 고객(사용자)과의 빠른 커뮤니케이션으로 품질을 높이고 있다.

애자일 성공을 위해서는 고객의 적극적인 참여(고객 참여; Communication)와 개발팀의 지속적인 커뮤니케이션과 협업(전체 팀; Whole-Team)이 필요하다. 애자일 테스트도 품질보증팀 뿐만 아니라 고객 참여를 이끌어내고 개발팀 전체가 테스트에 참여하도록 한다.

애자일 테스트는 누구나 테스트에 참여할 수 있고 결함을 빨리 발견하도록 도와준다. 최근에 확산되고 있는 테스트 주도 개발(TDD; Test Driven Development)이 애자일 테스트를 가장 잘 적용한 예라고 볼 수 있다.

이번에는 애자일 테스팅에 대한 정의를 명확히 하고, 애자일 팀에서의 테스트 프로세스와 테스팅 전략에 대해 살펴보고자 한다.

애자일 테스팅의 정의

전통적인 테스팅과의 차이

개발팀은 소프트웨어가 의도한 대로 만들어 졌는지, 오류는 없는지 반드시 확인해야 하기 때문에 소프트웨어 개발에서 테스팅은 절대 빠질 수 없다. 전통적인 개발방법론의 테스팅은 개발 후에 하였다(그림 1 참조).

<그림 1> 전통적인 프로세스의 테스팅

요구분석부터 개발까지 매우 오랜 시간이 흘러야 하지만 테스팅은 개발이 끝난 후에 할 수 있었다. 만약, 테스팅 중에 요구분석부터 다시 해야 하는 치명적인 오류가 발생하면 개발팀은 일정 연장을 피할 수 없었다. 또한, 전통적인 프로세스는 기술 중심의 테스팅이었다. 기술을 모르는 고객은 테스팅에 관심이 없을 수 밖에 없었다.

애자일은 반복적이고 점진적인 개발을 지향하기 때문에 애자일 테스팅은 개발자가 개발한 점진(Increment) 단위로 테스팅을 수행한다. 점진은 고객에게 전달하는 개발의 최소 단위이기 때문에 개발팀이 거의 수시로 테스팅을 한다고 볼 수 있다(그림 2 참조).

<그림 2> 애자일 테스팅

<그림 2>를 살펴보면, 테스팅은 하나의 점진이 끝날 때마다 수행한다. 각 점진 단위의 테스팅이 끝난 후에는 점진을 모아 통합적인 테스팅을 수행한다. 개발자는 점진의 테스팅을 완료한 뒤 다음 점진 개발로 넘어간다. 테스팅이 끝나기 전에는 완료된 것이 아니기 때문에 개발자는 다음 점진을 개발하지 못한다.

<참고사이트>

애자일 테스팅의 목적

애자일 테스팅은 기술보다는 비즈니스 중심으로 만들어지기 때문에 반드시 사용자(고객)가 참여해야 한다. 완성된 소프트웨어를 사용하는 사람은 개발자가 아니고 사용자이기 때문이다. 사용자의 의견은 테스팅에 매우 중요하게 반영된다.

또한, 애자일 테스팅에는 전문 테스터 뿐만 아니라 분석/설계에 참여한 모든 팀원이 참석한다. 사용자의 경험은 비즈니스 요구사항을 반영한 테스팅 케이스를 만들 수 있고, 기술적 요구사항은 모든 팀원과 상의하여 반영할 수 있다(그림 3 참조). 이러한 접근을 전체 팀 접근법(whole-team approach)라고 한다. 이러한 접근을 위해 애자일 테스팅에서는 3개의 역할이 필요하다(표 1 참조).

<그림 3> Whole Team의 장점

자료: http://cmforagile.blogspot.kr/2014/06/robust-agile-requirements-its-about.html

<참고사이트>

<표 1> 애자일 테스팅에서의 역할

정리하면, 애자일 테스팅은 요구사항이 수시로 변하는 애자일 프로젝트에 맞게 능동적으로 움직이는 테스팅 방식이고 테스팅 결과를 빠르게 받을 수 있다. 이 것은 프로젝트 진행 중에도 소프트웨어의 품질을 더 높일 수 있는 기회를 제공한다.

애자일 테스팅의 또 다른 목적은 사용자에게 요구사항이 어떻게 반영되었는지 사용자의 용어로 보여줄 수 있다는 것이다. 이렇게 확인된 요구사항을 개발과 테스팅을 반복하며 소프트웨어의 최종 모습을 그릴 수 있다.  

더 보기 >>>

SW유지보수 기간 중 신뢰성 보장을 위한 회귀테스트(Regression Test)의 적용

운영 중인 소프트웨어는 기능 수정 및 오류 조치를 위해 유지보수를 하게 된다.

최종 개발 서비스 운영 중인 소프트웨어라고 할지라도 요구사항의 변경 및 사용자 만족도를 높이기 위해서는  SW 프로그램의 수정이 불가피하다.

그러나 이 수정에 따라 정상적으로 작동하던 서비스가 수정 패치 이후 정상 작동하지 않는 경우가 발생할 수 있는데, 이를 예방하기 위해 회귀테스트를 사용하게 된다. 또한, 대형 소프트웨어에 대해 전체 테스트를 반복하는 것은 시간과 금전적인 측면에서 상당한 부담일 수 밖에 없다. 이 경우에 있어서도 회귀 테스트는 수정이 의도하지 않은 결과를 초래하지 않는다는 것을 검증하기 위해 사용되게 되는데, 이는 SW프로그램의 유지보수에 있어서 매우 중요한 역할을 하게 된다.

SBI저축은행의 금융여신시스템 개발 및 관리 프로젝트를 맡고 있는 박주형 과장을 통해 수정에 따른 SW의 신뢰성을 높이기 위한 회귀테스트 방식과 기법들을 들어봤다.

< SBI저축은행 정보시스템실 박주형과장 >

1. 회귀테스트란? 2. 회귀테스트 진행 상의 애로사항 3. 효과적인 회귀테스트가 되기 위해 고려할 점

Q.  ‘회귀테스트’란 구체적으로 어떤 테스트 방식인가요?

 회귀 테스트는 “수정(Modification)이 기대하지 않은 결과를 발생시키지 않는다는 것을 증명하기 위한 시스템이나 컴포넌트에 대한 선택적 재테스트” [IEEE610.12-90] 라고 정의되어있습니다.

즉, SW의 수정된 모듈에 의해 정상적인 기능들이 문제가 있어서는 안된다는 겁니다.

저도 금융 전산 시스템을 관리하면서 수많은 현업의 요구사항의 변화와 지속적으로 발견되는 개선사항들로 인해 프로그램을 수시로 변경하고 있는데요. 신속한 요구사항을 반영을 원하는 환경에서 소수의 프로그램을 수정하고 retest All 하기는 사실상 어렵습니다. 관련성 있는 모듈과 이전 테스트 케이스를 활용하여 검증을 해야 하죠. 이럴 때 필요한 테스트 기법이 ‘회귀테스트’입니다.

Q.   회귀테스트는 어떤 방식으로 하는건가요?

간단히 말해서 오류를 발견하여 수정하고, 다시 원래 문제를 일으켰던 것을 테스트 확인하고, 수정한 부분이 계획했던 대로 수정되었는지 확인, 그리고 수정된 부분이 다른 부분에 영향을 주어 예상하지 않은 오류를 발생시키지 않는지 확인하는 절차를 거치게 됩니다.

<그림 1> 회귀테스트 진행 방식

첫째, 테스트 수행 전 확인 사항을 먼저 체크 합니다. (Smoke test를 함께 진행할 수도 있습니다.) 프로그램 변경 후 단위 기능 테스트의 수행이 완료 되어야 하고, 변경된 각 모듈의 통합 , 배포 수정까지 빌드를 실시합니다.

두 번째로, Test Case Library 같은 도구로 회귀 테스트를 진행합니다.

단위 기능 중심의 이전 기능과 통합 기능의 시나리오 기반의 테스트를 실시하고, 반복 및 제약 부하 환경에서의 성능 테스트를 실시합니다.

마지막으로, 결과 기록 및 사후 검증을 진행합니다.

테스트 수행 결과를 기록하고 성공 여부를 점검한 뒤, 테스트 성공 이후 기존 단위 테스트의 회귀 테스트를 Repository 에 저장합니다. 그리고 변경된 기능 및 시나리오를 감안한 테스트 절차를 최신화 실시(재사용) 합니다.

인터뷰 더 보기 >>>