소프트웨어 개발이 문서 작업이 많은 분석, 설계에 집중하던 것에서 최근에는 개발에 더 집중하는 애자일(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> 애자일 테스팅에서의 역할
정리하면, 애자일 테스팅은 요구사항이 수시로 변하는 애자일 프로젝트에 맞게 능동적으로 움직이는 테스팅 방식이고 테스팅 결과를 빠르게 받을 수 있다. 이 것은 프로젝트 진행 중에도 소프트웨어의 품질을 더 높일 수 있는 기회를 제공한다.
애자일 테스팅의 또 다른 목적은 사용자에게 요구사항이 어떻게 반영되었는지 사용자의 용어로 보여줄 수 있다는 것이다. 이렇게 확인된 요구사항을 개발과 테스팅을 반복하며 소프트웨어의 최종 모습을 그릴 수 있다.
댓글 없음 :
댓글 쓰기