(출처: 소프트웨어 공학센터 웹진 자료-2015년 11월)
SI 개발자들은 솔루션을 개발할 때 난감해 하는 경우가 많다. 가장 큰 이유가 지금 무엇을 해야 할지 모르겠다는 것이다. SI 개발에서는 누가, 언제, 무슨 일을 해야 하는지 모든 것이 절차화 되어 있어 그대로 따라 하면 됐지만, 솔루션 개발이 원활히 진행되기 위해서는 소프트웨어를 개발하면서 확인해야 하는 것들을 솔루션 특성에 맞춰 정리해 나가는 것이 매우 중요하다.
지난 회까지 솔루션의 큰 그림을 그려보는 아키텍처와 사용자의 경험을 바탕으로 인터페이스를 정리하는 UX에 대해 살펴 보았다. 이번 회에서는 소프트웨어 개발에서 절대 빠질 수 없는 테스트에 대해 살펴보도록 한다. SI테스트는 단위 기능을 테스트 하는 단위 테스트, 시나리오에 기반한 통합 테스트, 프로덕트 테스트, 그리고 고객의 승인을 위한 승인 테스트로 나누어 진다. 그리고, 이 모든 테스트는 절차가 있고 심지어는 입출력 값까지 정해주면서 테스트를 하도록 가이드하고 있다. 고객이 요구하는 것이 제대로 동작하고 있는지 확인해야 하기 때문이다. 하지만, 솔루션 테스트는 조금 다르다. 솔루션은 개발자 스스로 시나리오를 만들고 모든 테스트를 진행한다. 그리고 솔루션을 완성한 후에 알파, 베타 테스트 같은 고객 또는 사용자 테스트가 이루어지는 경우가 많다.
이번 회에서는 우선 테스트의 절차와 목적에 대해 먼저 알아보도록 한다. 테스트 방법이나 절차는 잘 알고 있지만 그 절차가 왜 필요한 지에 대해 정확히 정리하고 SI 와 솔루션 테스트의 차이가 무엇인지 알아보기로 한다. 그리고 솔루션 테스트를 위한 최신 트렌드에 대해 살펴보고, 마지막으로 사례를 통해 솔루션 테스트의 역할과 목표를 확인해보기로 한다.
1. 테스트의 절차와 목적
테스트의 절차
소프트웨어 테스트는 사전적인 의미로 "주요 이해관계자들에게 시험 대상 제품 또는 서비스의 품질에 관한 정보를 제공하는 조사 과정이다. 또한 소프트웨어에 대한 객관적이고 독립적인 시각을 제공하여 사업주체가 소프트웨어 구현의 위험성을 올바로 이해하도록 한다" 라고 정의되어 있다. 다시 말해 개발하고자 했던 의도대로 만들고 있는지 확인하는 것이라고 해석 할 수 있다. <그림 1>은 소프트웨어 테스트 절차를 나타내고 있다.
<그림 1> 소프트웨어 테스트 절차
자료: Pegasus Knowledge Solutions, Inc
<그림 1>을 살펴보면, 소프트웨어 프로세스에 의해 개발되는 것을 나타내는 '소프트웨어 개발', 소프트웨어 프로세스에 맞춰 테스트를 수행하는 '품질 보증'이라는 부분으로 나뉘어 있다. 그리고, 이 두 부분을 관리하는 것은 '프로젝트 관리'로 나타나 있다. 잘 살펴보면, 요구사항을 정의하고, 분석, 설계, 개발한 후 테스트를 수행하는 것으로 볼 수 있다. 이러한 프로세스는 SI 프로젝트에 많이 나타나는 모습이다.
테스트의 목적
소프트웨어 테스트의 목적은 소프트웨어의 기능이 제대로 작동하는지, 성능은 만족한지, 안정성이나 확장성은 충분한지 확인하는 것으로 알려져 있다. 하지만, 이것은 일반적인 테스트의 목적으로 볼 수 있다. 개발 프로젝트의 성격에 따라 구분한다면, SI 프로젝트는 고객의 요구사항이 제대로 반영되었는지 테스트를 통해 확인하고 솔루션 프로젝트는 사용자 스토리 워크샵이나 마케팅에서 정의된 사용자 스토리의 내용이 정확히 반영되었는지 테스트를 통해 확인하는 것으로 구분 할 수 있다. <표 1>은 SI와 솔루션 프로젝트의 테스트 목적을 비교한 것이다.
<표 1> SI와 솔루션 프로젝트 테스트의 목적 비교
| 구분 | SI 프로젝트 | 솔루션 프로젝트 |
|---|---|---|
| 목적 | - 고객의 요구사항이 모두 반영되었는지 확인 | - 사용자 스토리에 정의된 기능이 제대로 반영되었는지 확인 - 알파 , 베타 테스트 후 사용자 요구사항을 추가 확인 |
| 확인 방법 | - 프로젝트 종료 전에 테스트 | - 알파 , 베타 테스트 |
그리고, SI 프로젝트에서는 고객의 요구사항이 제대로 반영되었는지 프로젝트 종료 전에 반드시 확인을 해야 하고, 솔루션 프로젝트에서는 알파나 베타 테스트를 통해 사용자가 직접 사용하도록 하여 사용자 스토리에 정의된 기능이 제대로 반영되었는지 확인하고 사용자 요구사항을 추가 확인한다.
이번에는 테스트의 종료에 따른 목적을 알아보자. 소프트웨어의 요류나 부족한 부분은 개발 초기에 발견하는 것이 수정도 쉽고 비용이 적게 들기 때문에 개발 단계별로 전략을 세워 테스트를 하는 것이 좋다.
모듈을 개발 할 때는 단위 테스트를 통해 구문 오류 위주로 테스트를 수행하고, 모듈이 모두 완성된 후에는 고객의 업무나 사용자 스토리와 같이 시나리오 기반으로 통합 테스트를 수행한다. 통합 테스트를 통해 SI는 고객의 요구사항이 모두 반영되었는지, 솔루션은 사용자 소프트웨어가 고객에게 인도되거나 배포가 가능한지 최종 확인을 하게 된다. 그리고, SI에서는 승인 테스트를 통해 고객의 입장에서 요구사항 반영 여부를 최종 확인하고 솔루션은 알파/베타 테스트를 통해 사용자가 기능을 확인한다. 이와 같은 내용을 <그림 2>에 대해 나타내고 있다.
<그림 2> 소프트웨어 테스트의 목적
자료: KOCW의 소프트웨어공학
2. SI 테스트 vs. 솔루션 테스트 비교
SI 테스트
SI에서의 테스트는 많이 언급된 내용이라 이번 회에서는 <그림 3>을 살펴보는 것으로 하겠다. <그림 3>에서 보는 것처럼 설계 단계부터 테스트 계획을 수립하고 계획에 따라 단위 테스트, 통합 테스트를 수행한다. 테스트를 성공적으로 마칠 경우 고객에게 인도되어 프로젝트가 종료되는 것이 SI 테스트의 일반적인 프로세스다.
<그림 3> SI의 테스트 프로세스(예)
솔루션 테스트
이전 회에서 살펴본 SI솔루션 개발의 차이인 아키텍처, UX, 그리고 이후에 다뤄질 개발, 프로세스는 개발 프로젝트를 시작부터 완료할 때까지 과정에 약간의 차이점을 보이고 있다. 하지만, 테스트의 경우는 소프트웨어의 최초 버전을 개발 할 때는 SI의 테스트 프로세스와 크게 다르지 않다.
다만, SI 경우에는 소프트웨어를 고객에게 인도한 이후에는 별다른 테스트 프로세스가 없다. 유지보수 프로젝트도 개발 프로젝트의 테스트 프로세스와 크게 강조되는 것은 없다. 하지만 솔루션은 소프트웨어가 완성되면 사용자에게 알파 또는 베타 버전으로 배포가 된다. 그리고 정식 버전이 배포가 된 후에도 지속적인 모니터링을 통해 기능 보강이나 업그레이드를 위한 테스트가 계속 반복된다. <그림 4>에 이와 같은 내용의 예로 HP 사례를 나타내고 있다.
<그림 4>솔루션 테스트(예)
자료: HP의 애플리케이션 성능 테스트에 대한 유연한 접근 방식
<그림 4>를 살펴보면, 'Application lifecycle'로 표현된 부분이 솔루션 개발 프로세스를 나타내고 'Operation lifecycle'로 표현된 부분이 솔루션 개발 프로세스를 나타내고 'Operation lifecycle' 로 표현된 부분이 배포 이후 이슈에 따른 처리 부분을 나타낸다. 이렇게 배포한 후 업그레이드 또는 필요에 의해 배포 버전을 여러 개 만드는 것을 버저닝(Versioning)이라고 부르고 있으며, 버저닝에는 반드시 테스트를 포함하고 있다. 완성된 후는 오류 수정 또는 일부 기능 추가만 하는 SI와는 달리, 처음 또는 버저닝 후 배포된 솔루션은 이전 버전과는 독립된 소프트웨어로 판단해서 테스트에 임하는 것이 중요하다.
3. 솔루션 테스트의 최신 트렌드
최근에 소프트웨어를 체계적으로 테스트하려는 노력들이 많이 나타나고 있다. 테스트는 시간과 비용이 허락되는 한 계속하는 것이 바람직하지만 단순 반복적인 테스트는 소프트웨어의 품질에 크게 도움이 되지 못한다. 따라서 최근에는 체계적이고 효율적인 테스트 방법들이 ㅁ낳이 소개되고 있다. 이번 절에서는 이 중에 몇 가지를 소개한다.
테스트 자동화
소프트웨어는 매일 수정될 수 있다. 이 때마다 테스트를 수행해야 하는데 모든 테스트는 손으로 직접 해야 한다. 손으로 하는 테스트의 가장 큰 문제점은 사람이기 때문에 테스트를 할 때마다 똑같은 기준을 유지 할 수 없고 경우에 따라 빼먹는 것도 있을 수 있다. 또한 공수가 너무 많이 들어간다는 문제점도 가지고 있다. 이러한 문제점을 해소하기 위해 테스트 자동화의 관심이 높아지고 있다. 검증된 테스트 케이스를 미리 만들어 놓고 반복되는 테스트에 사용을 할 수 있도록 테스트 환경을 구축해 놓은 것이다. 테스트 자동화의 가장 큰 장점은 일관된 테스트를 일관로 처리할 수 있고 결과도 바로 확인 할 수 있다. 또한 개발자가 누구냐에 상관없이 같은 케이스를 사용하여 테스트 할 수 있다는 장점도 있다. 이러한 자동화 테스트는 아래 네 개 단위 별로 테스트 하는 것이 일반적이다.
- 시스템 단위
- 컴퍼넌트 단위
- 클래스 단위
- 메소드 단위
또한, <그림 5>의 좌측과 같이, 일반적인 테스트 계획은 엔지니어에 의해 수동으로 작성되고 테스트가 수행된 후 결과가 작성된다. 하지만 테스트 자동화의 경우, 다수의 단위 테스트 케이스로 구성되고 이러한 단위 테스트 케이스가 모여 통합 테스트가 구성된다. 자동화 테스트는 이러한 단위, 통합 테스트를 검증한 후 반복 사용이 가능하도록 코드화 하는 것이다.(<그림 5-1> 참조). <그림 5>의 우측과 같이, 요구사항을 분서갛고 테스트 케이스를 작성한 후 테스트 자동화 시스템에 넣어두고 테스트 자동화를 수행하는 것이다.
<그림 5> 일반적인 테스트와 테스트 자동화 비교(예)
자료: www.btstech.co.kr
<그림 5-1> 테스트 케이스 작성 방법
자료: SCM-Manager Universe의 TEST MANAGEMENT WITH TESTOPIA
이렇게 작성된 자동화 테스트는 시간과 장소, 개발자에 상관없이 테스트를 수행할 수 있다. <그림 6>은 Microsoft Test Manager를 사용하여 자동화 테스트하는 것을 나타내고 있다. 공통된 테스트 케이스를 테스트 파운데이션 서버에 등록한 후 여러 대의 클라이언트에서 수행 할 수 있게 해준다. 자동화 테스트는 테스트를 체계적으로 할 수 있다는 좋은 점도 있지만 테스트 결과 관리가 가능하다는 것도 장점이다. 해당 결과로 테스트 케이스를 효율적으로 다시 설계할 수 있고, 소프트웨어의 구성을 정량적으로 판단 할 수 있는 근거 자료로 활용할 수 있기 때문이다.
<그림 6>Microsoft Test Manager 사용 예 
자료: MSDN
애자일과 테스트
최근 솔루션 개발에 애자일응ㄹ 많이 적요하고 있다. 빠른 절차를 기본으로 하고 있는 애자일은 빠른 변화에 사용자 중심적이고 사용자 스토리 중심적이다. 따라서 애자일의 한 방법인 스크럼 기반 소프트웨어 개발인 경우 사용자 스토리 단위의 사용자 중심 테스트가 가능하다. 또한 애자일의 점진적인 개발을 끊임없이 반복하는 나선형 프로세스 모델은 솔루션 버전 단위로 개발하는데 적합한 프로세스라고 할 수 있다.
<그림 7>은 최근 많이 사용되는 애자일 방법인 스크럼 기반의 개발을 테스트 중심으로 나타낸 것이다. 스크럼은 스프린트 단위로 개발이 이루어 지며, 스프린트는 2~3주, 길게는 4주 단위로 수행된다.스프린트 단위로 수행되는 경우, 사용자 스토리 단위로 테스트가 이루어지기 때문에 완료된 스프린트에 대한 테스트가 반복될 필요가 없고, 스프린트가 반복되어도 테스트를 다시 만들 필요가 없다는 장점이 있다.
<그림 7> 테스트 중심의 스크럼 기반 개발 프로세스 
<표 2> <그림 7>의 Step별 수행 내용
| 구분 | 수행내용 |
|---|---|
| Step 1. | 사용자 스토리 기반으로 테스트 케이스를 설계하고 , UI 설계 등 사용자 관점의 제품이 구체화되면 이를 바탕으로 테스트 케이스를 상세화해 테스트 데이터를 설계한다 . 사용자 스토리란 소프트웨어를 사용할 사용자를 정의하고 , 그 사용자의 사용 역할 및 빈도를 고려해 사용자가 원하는 기능 및 비기능 요구사항을 정리하여 시작부터 끝까지 사용 과정의 스토리를 작성한 것을 말한다 . |
| Step 2. | 도출된 테스트 케이스에 대해 프로그램 별로 테스트 절차 , 테스트 데이터 등 테스트를 수행할 수 있는 수준으로 작성한다 . 개발자가 작성한 테스트 코드를 검토하여 검증할 테스트 케이스 또는 테스트 데이터를 추가하거나 보완한다 . |
| Step 3. | 사용자 스토리를 통해 구현을 확인하기 위해 테스트를 진행해야 한다 . 작동 가능한 애플리케이션이 완성되면 , 사용자 스토리와 사용자 스토리 통합 관점에서 테스트를 수행한다 . |
| Step 4. | 스프린트가 반복되면 , 이전 개발 부분과 추가 개발 부분을 모두 포함하여 점증적인 검증을 수행한다 . |
자료: (주)와이즈스톤의 소프트웨어 테스트 기술 및 시장 동향
소프트웨어 테스트는 개발자들이 가장 신경을 많이 써야 할 부분이지만 소홀히 하는 경우가 많다. 그리고 테스트를 한다고 해도 오류를 찾아내는 정도로 그치는 경우가 많다. 소프트웨어 테스트의 가장 큰 목적은 오류를 잡는 것보다 원래 의도대로 소프트웨어가 완성되었는지 확인하는 것이다. 따라서 원래 의도가 무엇인지 정의하는 것도 매우 중요하고 어떤 방식으로 테스트 할 것인지도 소프트웨어의 특성에 맞춰 잘 정의해야 한다.
이번 회에서는 테스트를 해야하는 근본적인 목적과 절차에 대해 살펴보았다. 테스트를 왜해야 하는지, 테스트를 통해 무엇을 확인하는지 명확히 기억하면서 테스트 효울성을 높여야 한다. 그리고 SI와 솔루션 테스트를 비교하면서 어떤 관점으로 테스트를 해야 하는지도 살펴보았고 솔루션 테스트의 최신 트렌드도 살펴보았다.
모바일 같은 개인용 디바이스의 증가 추세로 볼 때, 솔루션 소프트웨어가 앞으로 점점 더 증가할 것으로 보인다. 또한 PC 기반 서비스도 모바일과 구분 없이 서비스 될 것으로 보여 모바일 소프트웨어는 더 커지고 복잡해질 것으로 예상된다. 따라서, 솔루션의 특성을 잘 파악해 테스트 방법과 목표가 더 체계적이고 효율적으로 정리될 필요가 있다. 솔루션 개발에서 테스트는 사용자에게 넘기기 전에 하는 마지막 절차가 아니라 사용자가 제일 먼저하는 절차이기 때문이다.
