Testing Experience 9호 에서 발췌해서 번역한 글.
웹 QA와 관련된 글이기는 하나, 게임 및 기타 도메인에서도 사용자 환경을 어떻게 에뮬레이팅 해서 테스팅을 진행할 지에 대한 조언이 담겨있다. 구체적인 툴과 서비스 명을 명시해서 제시하기는 했지만, 방대한 사용자 환경을 어떻게 담보할 것인지, 그리고 테스트 자동화를 어떻게 구현할지에 대한 고민을 조금이나마 덜어줄 수 있으리라 기대해 본다.
필자가 몸담고 있는 곳에서도 가상 이미지 제작 툴인 고스트(Ghost)를 사용해 사용자가 많이 사용하는 OS와 애플리케이션들을 가상 환경으로 꾸미고 테스트하고 있다. 원 저자가 제안한 툴들이 아니더라도, 다양한 툴이 존재하는 만큼 자신이 처한 환경에서 가장 적합한 툴을 선택할 수 있는 가이드가 되길 바란다.
Cloud QA
by Rodrigo Guzmán
e-커머스 비즈니스는 인터넷이라는 복잡한 세계에서 구현되며, 1년 365일 24시간 내내 사용이 가능해야 한다.
클라이언트가 인터넷에 접속하기 위해, e-커머스 사이트를 검색하기 위해, 그리고 트랜잭션을 만들기 위해 사용하는 서로 다른 플랫폼들은 이러한 세계의 일부를 구성하고 있다. 모든 플랫폼 상에서 각 사이트의 사용성과 사용자 경험을 보장하는 것이야말로 e-커머스 비즈니스에서 중요한 목표가 되고 있다.
QC(Quality Control) 팀의 역할은 사용자가 제품을 통해 긍정적인 경험을 할 수 있도록 하고, 지속적으로 트랜잭션을 창출할 수 있도록 보장하는 것이다. 이것은 소프트웨어의 동작이 복잡한 인터넷 세계에서 정확하게 수행되는 것을 보장함으로써 이루어진다. QC팀의 이러한 작업들 역시 제품을 시기 적절한 시점에 시장에 내놓아야 한다는 지상 과제를 준수할 수 있는 범위 안에서 수행되어야 하지만 늘 예측할 수 없는 지속적인 변화라는 도전에 당면하기 마련이다. 작업에 투입할 수 있는 리소스는 항상 부족하고, 아울러 사용자에 의한 플랫폼 사용이라는 측면에서 고려되어야 하는 불명확성은 언제나 높기 마련이다.
해결해야 할 문제들(Challenges)
이런 상황에서 QC 팀은 아래와 같은 3 가지 주요 과제에 직면하고 있다.
플랫폼. 사용자들이 인터넷에 접속하고 사이트를 검색하기 위해 어떤 플랫폼을 사용하는지 정확하게 이해하고 알고 있어야 한다. 우리는 테스팅에 필요한 대표적인 샘플을 결정하기 위해 가능한 모든 조합을 규명해 볼 필요가 있다. 만약 우리가 특정한 플랫폼을 사용할 수 없다면, 우리는 실제 환경 하에서 해당 사이트를 테스트할 수 없을 것이다.
하드웨어. 다양한 플랫폼을 구성하고 테스트 랩을 꾸미기 위해 필요한 하드웨어를 갖추고 있어야 한다.
하드웨어에 과중한 투자 없이도 테스트 랩을 확보할 수 있다. QC 팀에게 하드웨어 리소스를 관리하고 구성을 설정할 수 있는 자율권을 보장해주어야 한다. 기술팀에게만 의지할 때 발생할 수 있는 병목을 제거해야만 한다.
테스트. 모든 가능한 테스트 케이스를 생성하라. 가장 대표적인 샘플을 선정하고 이를 각 플랫폼에서 수행해보라. 소프트웨어가 시장에 출시될 시점이 연기되지 않는 범위 안에서, 각각의 플랫폼에서 소프트웨어가 정확하게 동작하는지를 확인하라.
구현된 해결 방법들(Implemented Solutions)
지난 2009년 동안 우리는 우리 회사에서 앞서 언급된 3가지 도전 과제를 해결할 수 있도록 도와주는 다양한 솔루션을 구현해 보았다.
Google Analytics
Google Analytics 는 우리에게 고객들이 사용하는 클라이언트의 플랫폼을 알게 해주었다.
우리는 우리의 사이트를 방문하는 모든 방문자의 자세한 정보를 알 수 있다. 즉 국가, OS, 브라우저 버전 별 정보, 스크린 해상도, 플래시 사용 여부와 같이 우리의 사이트를 둘러보는데 필요한 모든 것들의 정보를 획득할 수 있다.
이러한 정보는 사이트를 방문함으로 인해 제공되며, 전체 방문자 대비 어느 정도의 비율을 차지하고 있는지로 표시될 수 있다.
예를 들어, 우리는 전체 사용자 대비 인터넷 익스플로러 8.0 버전이나 7.0 버전, 혹은 6.0 버전을 사용하는 사용자의 비율을 알 수 있는 것이다.
이러한 측정 방법을 통해 저장되는 사용자들의 플랫폼은 무척 다양하며, 이를 모두 테스트 하는 것은 이론상 불가능하다. 또한, 많은 플랫폼들이 대표성을 가질 만큼의 비율을 차지하지도 못한다. 우리는 소프트웨어 테스팅에 사용될 샘플을 결정하기 위해 가장 많은 비율을 차지하고 있는 것들을 선정해야 한다. 예를 들어, 플랫폼이 전체의 7% 이상의 점유율을 나타낸다면, 그 사이트에서 발생하는 동작들은 테스팅의 대상으로 간주되어야 할 것이다.
내부 테스트 랩 클라우드(Internal Test Lab Cloud)
우리는 내부 테스트 랩 클라우드를 만들기 위해 오라클 VM 제품을 사용한다.
오라클 VM 콘솔을 통해, 버추얼 머신의 이미지가 출력된다. 이러한 이미지는 하드웨어 리소스에 따라 필요한 만큼 출력하는 것이 가능하다.
우리는 구글 분석법에 따라 얻게 된 정보를 활용해 특정한 환경을 선택하고, 버추얼 머신을 사용해 각각의 테스트 환경을 구축하고 이를 사용했다.
오라클 VM을 통해 우리는 더 적은 서버로 다양한 테스팅 환경을 쉽고 빠르게 가상화 할 수 있었다.
이 솔루션을 사용하는 것은 QC 팀에게 하드웨어 리소스와 환경을 관리하는 데 있어 독립성을 부여하는 장점이 있다. 우리는 새로운 하드웨어에 대한 의존성을 배제할 수 있었고, 테스트 환경을 신속하게 구축할 수 있었다.
외부 테스트 랩 클라우드(External Test Lab Cloud)
하드웨어 자체가 제한된 리소스를 가지고 있고, 그럼으로 인해 아마 점점 더 많은 하드웨어 환경이 필요해 질 것이라는 것을 잘 알고 있기 때문에, 우리는 아마존 클라우드 솔루션(Amazon Cloud Solution)[1]을 구축했다. 이 솔루션을 통해 우리는 하드웨어에 대한 추가 투자 없이 더 많은 가상 환경을 외부 서버에 쉽고 신속하게 구현할 수 있었다. 가상 환경을 사용해 내부 클라우드를 쉽게 만들었던 것처럼, 아마존 클라우드를 통해 단지 아마존 클라우드를 구매하는 경비만으로 다른 모든 환경을 언제라도 구축할 수 있는 것이다.
테스트 케이스를 정의하라(Define the Test Cases)
그 다음 도전 과제는 서로 다른 플랫폼에서 돌아가는 모든 테스팅 환경을 구축하는 것이다. 우리는 시기 적절하게 제품을 시장에 내보낼 수 있는 기한을 지키면서도 모든 가능한 테스트 케이스를 만들어내고, 이를 각각의 모든 환경에서 수행할 필요가 있다.
우리는 각기 다른 테스트 케이스에서 존재할지도 모르는 서로 다른 변수(Variables)를 식별하고 이러한 각각의 변수들이 가질 수 있는 가능한 값(Values)을 판별해야 한다. 그 이후에 우리는 이러한 값들의 가능한 조합을 만들어낼 수 있다.
이러한 과정을 달성하기 위해서, 우리는 서로 다른 변수와 그들의 값들을 로딩할 수 있는, 루비(Ruby)로 개발된 애플리케이션을 사용했으며, 이는 모든 가능한 조합을 자동적으로 만들어 주었다.
대부분의 경우, 이러한 테스트 케이스 자동 생성은 우리가 가지고 있는 제한된 시간과 자원의 가용성을 고려해 봤을 때, 수행하기가 불가능한 아주 방대한 양의 테스트 케이스를 만들어준다.
자동화된 테스팅(Automated Testing)
앞서 언급한 실행 불가능할 정도의 방대한 테스크 케이스 생성이라는 문제를 해결하기 위해, 우리는 테스트 케이스 작성을 자동화하는 프레임워크를 개발했다. 이 프레임워크의 개발은 “루비 온 레일즈(Ruby on Rails)”를 통해 완성되었다. 이 자동화 프레임워크는 품질보증 팀의 어느 누구에게라도 그들의 테스트를 자동화하고, 어떤 환경에서도 생성된 테스트 케이스들을 수행할 수 있도록 만들었다.
QC 분석가들은 그들이 자동화하기 원하는 트랜잭션을 기록하고, 인터페이스를 통해 프레임워크에 스크립트를 업로드 할 수 있었다. 또한, 프레임워크는 사용자에 의해 입력된 값들을 수동으로 식별하고 그들을 입력 변수(Input variables)로 정의할 수도 있다. 이런 방식을 통해 분석가는 그가 자동적으로 테스팅 되길 원하는 모든 값들을 시험할 수 있게 된다. 제어판(Control panel)을 통해 자동화 테스트 수행에 사용될 테스트 환경을 선택할 수 있고, 테스트 수행 이후에는 결과에 대한 로그를 볼 수도 있다.
이러한 솔루션을 통해 현재 우리는 방대한 양의 테스트 케이스를 각각의 가상화된 환경 하에서 병렬로 수행할 수 있다. 아울러 이를 통해 적절한 시기에 제품을 출시하는 데 지장을 주지 않으면서 각각의 플랫폼에서 동일한 테스트 케이스가 정확하게 동작하도록 할 수 있는 것이다.
비즈니스 정보와 위험 분석(Business Information and Risk Analysis)
모든 테스트 케이스를 항상 자동화 할 수는 없는 노릇이다. 이러한 상황에서, 우리는 수동 테스트 케이스 중에서 효율적인 예제들을 고를 수 있도록 해주는 두 가지 방법을 사용하고 있다. 우선, 우리는 변수들이 가질 수 있는 실제 값들을 알기 위해 비즈니스 정보(Business information)를 사용할 수 있다. 이러한 정보에 기초해 현실 세계에서는 일어날 가능성이 없는 값의 조합들을 제거할 수 있으며 의미 없는 방대한 양의 테스트 케이스를 삭제할 수 있다. 이를 위해 우리는 데이터 웨어하우스(DW; Data Warehouse)의 보고서를 사용한다.
예를 들어, 우리가 모든 나라의 지불 프로세스를 테스트 해야 하고, 변수를 구성하는 요소 중의 하나로 달러($) 필드를 정의했다면, 각 변수에서 상정 가능한 변수값에 소수점이 포함되어야 할 것이다. DW 보고서를 통해서 우리는 몇몇 국가에서는 달러를 사용함에도 불구하고 소수점 표시를 사용하지 않는다는 것을 알게 되었다. 이러한 정보는 우리에게 상당한 양의 테스트 케이스 조합을 줄일 수 있도록 해주었으며, 이로 인해 테스트에 소요되는 시간 역시 절약할 수 있었다.
다른 방법은 일련의 테스트 케이스에 위험 분석을 적용해 보는 것이다. 이것은 테스트 케이스가 수행할 가치가 있는 중요한 것인지, 혹은 무시하고 넘어갈 수 있는지를 결정하기 위해 테스트 케이스와 관련된 위험을 분석한다는 것을 의미한다.
위험은 경제적인 손실(Economic loss), 회사와 제품의 이미지(Image)와 사용자 경험(User experience)과 같은 사업적인 영향(Business impact)에 기반해 정의된다.
이러한 위험에 기반해 각기 다른 상황의 우선순위가 결정되며, 이러한 상황을 커버할 수 있는 테스트 케이스들이 선택되는 것이다.
이러한 방법들을 사용함으로써, 위험에 기반해 테스트 케이스에 우선순위를 부여할 수 있고, 아울러 위험이 없거나 적은 테스트 케이스를 줄일 수 있는 것이다.
예를 들어, 검색 프로세스를 테스트 해야 한다고 가정할 때, 우리는 모든 가능한 부정적인 상황 즉, 예를 들어 느린 페이지 응답 속도, 검색 결과창에 아무 것도 표시되지 않는 것 등을 사전에 정의할 필요가 있는데 이는 모두 필드에서 발생할 경우 사업적으로 심각한 영향을 끼치는 것들이다. 이러한 상황들은 연관된 위험 수준이 무척 높으며, 이에 걸맞는 적합한 테스트 케이스가 적절하게 수행되어야 한다.
결론(Results)
앞서 언급한 모든 해결책을 수행함으로써 우리는 다음과 같은 결과를 달성할 수 있었다.
▪ QC 팀에게 테스팅 환경과 테스팅 자동화를 제공해 주는 클라우드 서비스 플랫폼 생성
▪ 테스트 환경 구축을 위한 하드웨어 병목구간 감소
▪ 하드웨어에 막대한 비용 소모 없이 신속하게 일정한 규모의 테스트 환경 구축
▪ QC 팀이 하드웨어 리소스와 다양한 테스트 환경을 설정하고 관리할 수 있는 자율권(Autonomy) 부여
▪ 사이트의 호환성을 확보하고, 다양하고 주요한 플랫폼 상에서 새로운 개발 사항들이 정상 동작함을 확인할 수 있음
▪ 사이트의 사용성을 확인하고 사용자 경험(User Experience)을 개선할 수 있음
▪ 타임 투 마켓에 영향을 끼치지 않고 테스트 커버리지를 증가시킬 수 있음
▪ 인터넷이라는 복잡한 세계에서 동작하는 소프트웨어를 정확하게 테스트해야 한다는 도전과제를 충족시킬 수 있음
'QA' 카테고리의 다른 글
누가 소프트웨어 품질을 책임질 것인가? (2) | 2010.04.28 |
---|---|
생활 속의 QA - Early Testing (4) | 2010.04.20 |
실용적인 심각도 선정 가이드 (2) | 2010.03.11 |
게임 QA를 꿈꾸는 분들에게 (89) | 2010.02.19 |
소프트웨어 테스팅의 종류 (0) | 2010.02.08 |