inpa: <웹진 168호 : 공학 트렌드> 소프트웨어 설계 - 애자일 테스팅 편

출처:아래링크

http://www.sw-eng.kr/member/customer/Webzine/BoardView.do?boardId=00000000000000038318&currPage=&searchPrefaceId=&titOrder=&writeOrder=®DtOrder=&searchCondition=TOT&searchKeyword=

소프트웨어 개발은 문서 작업이 많은 분석, 설계에 집중하던 것에서 최근에는 개발에 더 집중하는 애자일(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> 애자일 테스팅에서의 역할

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

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

애자일 테스팅의 프로세스

일반적인 애자일 개발 프로세스에는 테스팅이 포함되어 있다(그림 4 참조). <그림 4>를 살펴보면, 개발 사이클(Development Cycles) 안에 3개의 이터레이션(Iteration)이 있고 각 이터레이션에 테스트가 포함되어 있다.

<그림 4> 애자일 개발 프로세스

자료: https://sravan2j.wordpress.com/2014/09/10/details-about-agile-and-user-stories/

<그림 4>를 살펴보면, 하나의 점진을 3번의 이터레이션으로 사용자가 만족하는지 확인하고, 이를 바탕으로 점진을 보완한다. 애자일 테스팅은 각 점진을 사용자 스토리에 맞춰 테스팅 시나리오를 작성하고 테스팅 한다(그림 5 참조). 앞 부분 이터레이션의 결과에 따라 뒤 부분 이터레이션의 테스팅 시나리오는 수정될 수 있다.

<그림 5> 애자일 테스팅 프로세스

자료: Scrum Expert

애자일 테스팅의 주의사항

애자일 테스팅의 가장 큰 주의점은 테스팅을 마치지 않은 상태에서 다음 점진을 시작하는 것이다. 앞 점진 테스팅 결과에 따라 뒤 점진의 방향이 바뀔 수도 있기 때문에 반드시 점진의 테스팅까지 마치고 다음 점진을 시작해야 한다.

하지만, 현실에서는 촉박한 일정으로 테스팅이 끝나지 않았는데 다음 점진을 수행하는 경우가 많다. 최악의 경우에는 이미 시작한 점진을 처음부터 새로 수행할 수도 있다.

예를 들면, <그림 6>은 하나의 점진을 이터레이션 순서대로 표시한 것이다. 각  이터레이션의 테스팅을 마친 후에 피드백을 반영한 후 다음 이터레이션을 수행해야 하는데 이터레이션 1(Iteration 1)의 테스팅(Test)를 수행하는 중에 이터레이션 2를 시작했다고 가정하자. 테스팅 결과에 따라 요구사항 2(Requirement 2)가 변경되었는데 이터레이션 2는 벌써 시작했기 때문에 처음부터 다시 하는 경우가 나타나게 된다.

<그림 6> 점진에 따른 테스팅 프로세스

애자일 테스팅 프로세스는 정형화 되지는 않았지만, 테스팅을 위한 사용자 스토리가 필요하다는 것과 각 점진 단위로 테스팅이 반드시 포함되어야 한다는 것을 기억하면서 프로세스를 정의하도록 한다.

애자일 테스팅 전략

전통적인 개발팀에서 테스터는 별도 조직으로 운영되는 경우가 많았지만 전체 팀을 추구하는 애자일에서는 테스터도 개발팀에 상주한다. 테스터도 완성하려는 소프트웨어에 대해 많이 알아야 하는 사람 중의 하나이기 때문이다.

프로젝트 팀 구성

애자일 팀에서 필요한 역할은 PM(Project Manager), BA(Business Analyst), 개발자(Developer)와 QA(테스터; Quality Assurance)로 정의되는 것이 일반적이다. 최근에는 이 4개 역할 외에 UX(User eXperience)가 포함되는 경우가 많아지고 있다.

페어 프로그래밍(Pair Programming), TDD(Test Drivenk Development)와 같은 애자일 기법들에서는 대부분 테스팅을 포함하고 있다. 개발자는 테스팅을 고려하면서 개발해야 소프트웨어의 품질을 높일 수 있다고 보기 때문이다.

하지만, 개발자에 대한 가이드는 많지만 테스팅에 대한 가이드는 거의 없는 것이 사실이다. 테스팅의 중요성을 공감하지 않는 사람들이 아직도 많기 때문이다. 테스트는 각 점진을 검증하고 완성하는 마지막 프로세스라는 것을 기억해야 한다.

개발팀에서는 테스팅을 위한 교육과 가이드를 적극 지원하고 테스터는 프로젝트 성공을 위해 각종 기술 습득과 이해를 위해 노력해야 한다. 개발자와 테스터가 효율적으로 협업한다면 소프트웨어 품질과 의사소통이 매우 효과적이다.

애자일 테스팅의 선택

전통적으로 테스팅은 수작업인 경우가 많아 시간이 오래 걸리고 모든 테스트 케이스를 찾아내지는 못했다. 이후에 다양한 테스팅 툴이 나타났고, 애자일에서도 테스팅을 위한 다양한 툴과 기법을 제공하고 있다.

애자일 테스팅은 비즈니스, 개발팀, 소프트웨어(제품), 기술 등 4개 분야로 나누어 정의된다(그림 7 참조). <그림 7>을 살펴보면, 접근 방법에 따른 테스팅을 나타내고 있다(표 2 참조).

<그림 7> 애자일 테스팅의 관점

<표 2> 애자일 테스팅의 접근 방법

애자일 테스팅을 위한 원칙

개발자들은 대부분 SI(System Integration)에서 일했던 것을 끄집어 내려 한다. SI는 상당 기간 동안 소프트웨어 산업을 이끌어 왔다. 애자일은 SI와 다른 점이 많지만 SI만 생각하는 개발자에게는 선입관으로 인해 애자일 적용이 쉽지 않다.

“애자일 테스팅 테스터와 애자일 팀을 위한 실용 가이드(저자: 리사 크리스핀, 자넷 그레고리)”에서는 성공적인 애자일 테스팅을 위해 지켜야 할 몇 가지 원칙을 가이드하고 있다. 아래의 원칙은 테스팅에 필요한 접근 자세로 사용자와 개발팀의 협업과 적극적인 참여를 권하고 있다.

1) 끊임없는 피드백 고객으로부터 확인된 요구사항과 피드백을 팀원들과 함께 실행 가능한 테스팅으로 만들어 나간다. 2) 고객에 가치 제공 애자일 테스팅은 일부 기능이 아닌 비즈니스 중심의 큰 그림에 집중해야 한다. 3) 직접적인 의사소통 애자일은 협업을 위해 끊임없는 의사소통이 필요하다. 4) 실패를 두려워 않는 용기 완벽한 테스팅은 처음부터 만들어지지 않는다. 실패를 두려워 말고 접근해야 한다. 5) 최소한의 단순함 애자일 테스팅은 가능한 최소한의 테스팅을 통해 해당 기능이 정상인지 알아내야 하며, 고객이 이해할 수 있어야 한다. 6) 지속적인 개선 회고를 통해 더 나은 테스팅 수행 환경이 될 수 있도록 노력해야 한다. 7) 변경에 적응 변경에 대한 대응을 위해서는 테스팅의 수작업보다 자동화가 좋다. 강력한 자동화를 추구해야 한다. 8) 자기 조직화 애자일 테스터는 개발팀의 한 부분이다. 테스팅 철학을 모든 팀원에게 전파되도록 해야한다. 9) 사람중심 전체 팀원은 기술적인 기량 향상과 성장의 기회가 동등하게 주어져야 한다. 10) 즐기기 전체 팀원은 자신의 일에서 즐거움을 찾을 수 있어야 한다.

애자일 테스팅은 고객과 개발팀이 높은 완성도를 가지는 소프트웨어를 개발하도록 지원하는 것이 근본적인 목표이다. 하지만, 테스터가 있으니 품질이 알아서 높아진다라는 것은 위험한 생각이다.

애자일의 기본 사상은 적극적인 협업과 능동적인 대처다. 애자일 전문가들은 테스터를 전문화하여 따로 운영하는 것보다는 개발자와 테스터는 하나라는 인식을 가져야 프로젝트의 성공률을 높일 수 있다고 말한다.

사용자, 개발팀, 테스터는 상호 이해도를 높이기 위해 항상 의사소통을 해야 하고, 업무를 서로 도와가며 협업해야 한다. 애자일 테스팅은 기존의 테스팅에 비해 특별한 것이 많지 않다. 다만, 테스터는 테스팅 외에도 프로젝트에 대해 함께 알아야 하고 사용자와 다른 개발 팀원도 테스팅에 대해 함께 이해를 해야만 효율적인 테스팅이 된다는 것을 명심하자.