시스템 테스트 관점과 7원칙

들어가기 앞서

최근, 시스템 장애에 의한 서비스의 일시 중단 또는, 시스템 결점을 이용한 사이버 공격으로 개인 정보 유출 등 시스템 결함이 원인으로 여러 가지 문제들에 대해 들을 기회가 많아졌습니다. 매일 IT 시스템을 다루거나 관리하는 사람들에게, 이러한 뉴스는 결코 남의 일이 아닙니다.

이러한 시스템 결함에 의한 문제들은 시스템 릴리즈 전 내지, 기능 수정 시에 있어 적절한 검증(테스트)를 실시하는 것으로 미연에 방지할 수 있습니다. 이번 글에서는 시스템 테스트의 기본적인 것들에 대해 설명하겠습니다. 

시스템 테스트의 4가지 관점

현대 시대에서, 경제활동과 일상생활 거의 모든 곳에서 컴퓨터 시스템이 활동되고 있으며, 사람이 만든 OS와 어플리케이션 등 소프트웨어에 의해 관리 및 제어되고 있는 것이 당연하듯이 매일 사용자들에게 서비스가 제공되고 있습니다.

하지만, 이러한 시스템을 "올바르게" 동작시키는 것은, 실제로는 매우 어려운 일입니다. 시스템을 "올바르게" 동작시키기 위해서는 다음의 네 가지 관점에서 normality를 보장할 필요가 있습니다.

• 편리성(쾌적하게)
• 가용성(멈추지 않고, 느려지지 않고)
• 정확성(에러가 없이)
• 안정성(안전하게)

시스템은 많은 경우, H/W, OS, 미들웨어, 어플리케이션이 층(레이어)을 이뤄 구성되어 있으며, 각각이 상호 연계하여 동작하고 있기 때문에, 모든 층의, 모든 컴포넌트에 있어, 위에서 언급한 요건에 대해 만족한다는 것을 보장한다는 것은 매우 어렵습니다. 그 중에서도 어플리케이션은 기본적으로 인터넷을 통한 네트워크 통신을 필요로 하는 경우가 대부분으로, 브라우저와 같은 유저 에이전트나 클라이언트 어플리케이션과의 accessibility에 대해서도 주의를 기울여야 하기 때문에, 시스템의 동작의 "올바름"을 보증하는 것은 날로 어려워 지고 있습니다.

시스템 테스트의 중요성

거의 모든 소프트웨어는 개발자가 요구사항을 만족하기 위해 비즈니스 로직과 비즈니스 플로우를 분석하고, 그것을 프로그램으로 표현해감으로써 구현됩니다. 하지만, 개발자도 사람이기 때문에, 때대로 실수를 하기도 합니다. 그래서 그러한 실수는 구현의 불완전성, 문서의 결함으로써의 징후가 나타나고, 다양한 장애의 원인이 되며, 결과적으로 여러 손해가 발생하게 됩니다.

<시스템 결함에 의한 손해의 구체적인 사례>

    

경제적 손실                    시간 손실                 신뢰의 붕괴

이러한 리스크를 회피하기 위하여 제품 개발자와 품질관리자는 서비스 릴리즈 전에 또는, 기능 수정 시에, 소프트웨어가 사양서대로 동작하는지를 점검하고, 시스템에 결함이 존재하는지를 확인하는 "시스템 테스트"를 실행할 필요가 있습니다. 소스 코드와 문서, 구현 결과물 등 산출물을 철저하게 테스트하고, 시스템이 가동하기 전에 결함을 찾아 수정할 수 있다면, 실제 환경에서 예측하지 못한 장애가 발생할 리스크를 감소시킬 수 있으며, 결과적으로 제품 품질의 최소한의 보장이 가능하게 됩니다.

| 시스템 테스트의 목적

• 결함 발견
• 대상 SW 품질 수준이 충분한지 확인
• 의사 결정을 위한 정보 제공
• 결함 생성의 사전 예방

시스템 테스트의 7원칙

하지만, 시스템 테스트의 중요성은 이해하고 있으나, 일정 또는 비용적인 제약이 있는 상황에서 어떠한 접근으로 테스트를 계획/설계/실행하면 좋을지 잘 모르는 사람도 많을 겁니다.

여기에서, 보다 효율적이면서 유효한 테스트 실행에 도움이 될 지도 모르는 "시스템 테스트의 7원칙"을 소개하겠습니다. 7원칙은 세계 공통의 일반적인 가이드라인으로 되어 있으며, 시스템 테스트의 40년 이상 역사 속에서 발전해온 이른바, 지혜의 집약이라고도 할 수 있습니다.

| 7원칙

원칙 1 : 테스트는 결함이 있다는 것만을 나타냄

테스트로 결함을 추출하는 것은 가능하나, 위에서 언급했듯이 시스템의 모든 층에서의 동작 정상을 보장하는 것은 어려우며, 또한 테스트 자체도 인간이 실시하는 이상, 모든 결함을 찾을 수 없으며, 결함을 찾지 못했다고 하여(결함이 전혀 검출되지 않았다고 하여), 결함이 존재하고 있을 가능성이 Zero라고 할 수 없습니다. 그렇기 때문에 테스트에서는 결함이 없다는 것을 증명할 수는 없습니다.

원칙 2 : 전수 테스트는 불가능

매우 심플한 구조의 소프트웨어를 빼고는, 모든 입력치를 체크하는 것은 불가능에 가까우며, 이에 따라 테스트 기법 등을 구사하여 잠재적 리스크가 있을 법한 파라미터를 선별해 테스트를 실행해야만 합니다. 아주 간단한 제품의 경우 완벽한 테스팅이 가능할 수도 있으나, 대부분의 프로젝트에서는 다양한 변수가 존재하며 발생하기 때문에 그 변수들에 대해서 전수 테스트를 한다는 것을 불가능합니다.

원칙 3 : 초기 테스트

코딩 또는 프로토 타입 개발 단계와 개발 공정 초기 단계에서 테스트를 실시하여, 결함을 발견하고 수정이 가능하다면, 결과적으로 테스트에 소요되는 공수를 줄일 수 있습니다.

원칙 4 : 결함의 집중

결함이 모든 곳에 걸쳐 골고루 분포되어 있는 경우는 극히 드물며, 릴리즈 전 테스트에서 발견하는 결함이나 실제 운용 시에 드러다는 고장의 대부분은 특정한 한 모듈 또는 컴포넌트, 클래스에 집중되어 있는 경우가 많습니다.

원칙 5 : 살충제 파라독스

같은 성분으로 구성된 살충제를 반복하여 사용하면 내성이 생긴 벌레가 나타나 결국 효과가 없어지는 것과 같이, 동일 종류의 테스트를 계속하여 반복하기만 하면, 최종적으로 그 테스트에서는 새로운 결함을 찾을 수 없게 됩니다. 예를 들면, API 테스트에 있어서, 입출력 관점으로 TestCase를 작성하고 이것을 반복 실행하면 해당 테스트 자체로는 다음에 새로운 결함을 발견할 수 없게 됩니다. 그렇기 때문에, 별도의 파라미터를 사용한 TestCase를 추가하여 보안성이나 성능 등 다른 관점에서의 테스트 실행을 검토할 필요가 있습니다.

원칙 6 : 정황에 따른 테스트 실행

테스트 대상의 특성과 목적에 따라, 테스트 관점과 내용을 결정할 필요가 있습니다. 예를 들면, 정적 콘텐츠 밖에 없는 홈페이지와, 사내의 모든 리소스를 집중관리하는 ERP를 테스트 할 때에 필요로 하는 관점과 실행 레벨은 매우 다릅니다. 테스트를 진행해야 하는 프로젝트의 성격에 따라, 테스트 방식을 달리 할 필요가 있습니다.

원칙 7 : 오류-부재의 궤변

당연한 말이겠지만, 얼마간의 결함을 찾아 수정했는데, 구축한 시스템이 올바르게 동작하지 않거나, 사용자 요구사항이나 기대에 충족되지 않는다면 의미가 없습니다. 결함 보고가 거의 없는 게임이 있다고 가정할 경우, 스토어에서 다운로드되지 않고, 플레이 되지 않는다면 아무런 의미가 없습니다. 즉, 개발하려는 시스템이 쓸모가 없다면 결함을 찾고 수정하는 행위는 소용이 없다는 것입니다.

이러한 원칙들을 의식하는 것으로 어떻게 하면 테스트의 효율적으로 수행될 수 있는지 생각할 수 있습니다.

대규모 프로젝트/ 비교, 검증 테스트 / 그 외 프로젝트 QA에 대한 QA Service 지원 및 기타 관련 아웃소싱 업무가 필요한 경우 아래 연락처나 이메일로 연락 주시면 성실히 대응 하겠습니다. 

---

Contact US

Address

서울특별시 금천구 가산디지털1로 19 
대륭테크노타운 18차 20층

2018.12.27 | 지도 크게 보기 ©  NAVER Corp.

Phone
02-6190-7296

E-mail
qa_partner@infrawaretech.com

Homepage
http://infrawaretech-qa.tistory.com/