소프트웨어 테스팅 노트

출처: 책 Software Testing: Testing Across the Entire Software Development Life Cycle, by G. D. Everett and R. McLeod, Jr., 2007년

7장 Functional Testing, 103~106페이지

소프트웨어 기능 테스팅에서 일반적으로 다루게 되는 하위 테스팅 유형을 식별한 것이다.

7.3 기능 테스팅에 대한 접근 방식

모든 기능 테스팅에서는 비즈니스 요구사항 및 관련 소프트웨어 설계 사양을 검증 기준으로 사용한다. 예를 들어, 비즈니스 요구사항에서 소프트웨어가 "x"를 수행해야 한다고 한다면 기능 테스트에서는 "x"를 예상 결과로 검증한다. 기능 테스팅 목표에는 일반적으로 다음과 같은 것들이 포함된다.

7.3.1 사용자 네비게이션 테스트(User Navigation Testing)

애플리케이션이 엄격하게 배치 프로세싱인 경우는 사용자 네비게이션 테스트가 해당 없다. 대부분의 소프트웨어에는 소프트웨어 작동을 지시하기 위한 일련의 최종 사용자 화면과 관리자 화면이 있다. 최종 사용자 화면은 네비게이션과 트랜잭션이라는 두 가지 범주로 나눌 수 있다. 네비게이션 화면은 소프트웨어에 대한 액세스를 제어하는 로그온 및 로그오프 화면, 소프트웨어 내 여러 활동 경로(activity paths)를 제공하는 메뉴, 일부 비즈니스 활동의 연속성을 나타내는 화면 간 연결을 의미한다. 사용자 네비게이션 테스팅은 사용자가 적절한 권한으로 소프트웨어에 로그온할 수 있는지, 원하는 트랜잭션 화면으로 갈 수 있는지, 트랜잭션 화면 사이를 올바르게 이동할 수 있는지, 소프트웨어에서 로그오프할 수 있는지에 중점을 둔다. 이러한 종류의 테스팅은 트랜잭션 화면에서 어떤 트랜잭션이 수행되고 있는지는 중요하지 않으며 단지 화면이 올바른 순서로 나타나는지 여부에 관심을 둔다. 트랜잭션 화면 자체가 더 복잡해지면 비즈니스 활동을 완료하는 데 필요한 화면 이동 수가 줄어든다. 즉, 네비게이션이 화면 간 이동보다 화면 내 이동(탭 이동)이 더 많아진다.

모든 유효한 네비게이션 경로(valid navigation paths) 그리고 가능한 많은 유효하지 않은 네비게이션 경로(invalid navigation paths)를 지나가는 테스트를 설계하고 실행하는 것이 테스터의 임무이다. 유효한 네비게이션 경로는 주로 사용자 가이드에서 찾을 수 있다.

개발 및 테스트를 하기가 더 복잡한 사용자 네비게이션의 측면 중 하나는 "상태가 없는(stateless)" 사용자 화면이다(앞선 화면 시퀀스 없이 다양한 다른 화면에서 바로 시작할 수 있는 사용자 화면). 실제로 여러 "stateless" 화면이 동시에 활성화되는 것이 일반적이다.

7.3.2 트랜잭션 화면 테스트(Transaction Screen Testing)

최종 사용자 또는 관리자가 트랜잭션 화면으로 이동을 하면 해당 화면에서 뭔가 의미 있는 비즈니스 활동을 수행할 것이다. 트랜잭션 화면에는 일반적으로 입력 데이터 필드, 선택 항목 리스트, 옵션, 액션 버튼(추가, 변경, 삭제, 제출, 취소, 확인 등)이 있다. 어떤 액션 버튼을 누른 후에는 트랜잭션 화면에 일종의 결과가 표시되기도 한다.

테스터의 임무는 비즈니스 요구사항, 사용자 가이드 및 관리자 가이드를 기준으로 각 트랜잭션 화면의 모든 필드, 리스트, 옵션, 액션 버튼의 작동을 검증하는 테스트를 설계하는 것이다. 결과가 트랜잭션 화면에도 표시되는 경우, 블랙박스 기법의 입력 및 예상결과를 사용하여 표시된 결과를 검증한다.

7.3.3 트랜잭션 흐름 테스트(Transaction Flow Testing)

트랜잭션 흐름 테스트에서는 테스팅을 통해 검증된 트랜잭션 화면의 종합적인 네비게이션 결과가 의도된 비즈니스 활동을 완성하는지를 확인한다. 예를 들어, 다음은 고객 프로필 업데이트를 확인하는 트랜잭션 흐름 테스트이다.

고객 이름, 주소, 담당자에 대한 트랜잭션 화면 1

고객 신용 한도 승인을 위한 트랜잭션 화면 2

고객 결제 조건 및 할인에 대한 트랜잭션 화면 3

프로필 요약 및 업데이트 액션을 위한 트랜잭션 화면 4

업데이트된 고객 프로필을 볼 수 있는 트랜잭션 화면 5

5개 화면의 시퀀스가 완료되면 트랜잭션 화면에서 수집된 모든 정보가 포함된 마스터 파일 또는 데이터베이스 파일이 업데이트될 것으로 예상된다. 트랜잭션 흐름의 또 다른 예는 온라인에서 무언가를 구매할 때인 데, 사용자가 주문하고 결제한 제품에 대한 구매 오더(a purchase order)가 예상 결과이다. 트랜잭션 흐름의 세 번째 예는 온라인으로 청구서를 지불하는 경우이다. 예상되는 결과는 사용자의 은행 계좌에서 자금이 이체(transfer)되거나 또는 신용 카드를 통해 사용자가 지불하는 회사로 이체(posting)되는 것이다.

일련의 트랜잭션 화면을 올바르게 완료하면 올바른 결과가 나오는지 검증하는 것이 테스터의 임무이다. 또한 테스터는 시스템의 비즈니스 규칙 중 하나라도 위반되면 시스템이 결과를 제공하지 않는다는 사실도 검증해야 한다. 트랜잭션 화면 테스트보다 트랜잭션 흐름 테스트를 위한 테스터의 작업이 더 복잡하지만, 효율적인 테스터는 성공적인 트랜잭션 화면 테스트 액션의 시퀀스를 사용하여 더 복잡한 트랜잭션 흐름 테스트를 진행한다. 즉, 단지 흐름 테스트를 위해 트랜잭션 화면 테스트 액션을 다시 만들 필요는 없다.

7.3.4 보고서 화면 테스트(Report Screen Testing)

보고서 화면 테스트는 트랜잭션 화면 테스트와 유사하다. 차이점은 트랜잭션 화면을 사용하여 데이터를 입력하는 대신 보고서 화면을 사용하여 시스템에서 데이터를 검색하고 표시하려고 한다는 것이다. 보고서 화면 테스트의 어려움은 일반적으로 최종 사용자가 검색할 데이터(검색 기준)와 이러한 데이터가 표시되는 방법(정렬 및 포맷팅 옵션)을 다양하게 지정할 수 있다는 점에 있다.

테스터의 임무는 검색되고 화면에 표시되는 데이터에 특별한 주의를 기울이는 것이다. 잘못된 데이터가 선택되었거나 또는 더 나쁜 경우 요청된 모든 데이터가 표시되지 않을 수도 있기 때문이다.

7.3.5 보고서 흐름 테스트(Report Flow Testing)

보고서 결과가 화면 표시(on-screen display) 이외의 다른 방식으로 제공되는 경우 보고서 흐름 테스트가 보고서 화면 테스트와 달라진다. 예를 들어, 하드카피 출력은 가장 널리 사용되는 대체 보고서 형식 중 하나이다. 테스터는 "소프트웨어가 보고서 화면에 표시되는 것과 정확히 동일한 결과를 프린터로 보내는가?"라는 질문을 해야 한다. 프린터 옵션이 있다는 것은 보고서 화면이 인쇄 글꼴을 선택할 수 있는 가능성을 의미하며, 이는 또 다른 유용한 테스팅 영역이다. 또 다른 보고서 방식으로 파일을 디스크로 인쇄하는 것(플로피, 하드 디스크, CD 또는 이메일)이 있다.

소프트웨어에서 지원하는 모든 대체 보고서 양식에 대한 보고서 결과를 검증하는 것이 테스터의 임무이다. 트랜잭션 흐름 테스트에서 제안했던 것처럼 성공적인 보고서 화면 테스트를 사용하여 보고서 흐름 테스트를 진행한다.

7.3.6 데이터베이스 생성/검색/갱신/삭제(CRUD) 테스트

많은 애플리케이션은 트랜잭션 및 보고서 화면 뒤에서 데이터베이스를 사용하여 애플리케이션의 데이터를 관리한다. 데이터베이스 기능 테스팅은 보통 두 단계로 수행된다. 첫 번째 단계는 애플리케이션 외부에서 애플리케이션 데이터 조작을 성공적으로 수행함으로써 데이터베이스 설계 실현가능성(viability)을 테스트하는 것이다. 테스터는 데이터베이스의 데이터가 애플리케이션 요구사항에 따라 관리될 수 있는지 확인해야 한다. 위의 트랜잭션 흐름 테스트 예를 가지고 말하자면 테스터는 DBMS 명령만으로 새 고객 프로필을 추가하고, 기존 고객 프로필을 업데이트하고, 고객 프로필을 삭제할 수 있어야 한다. 이러한 종류의 테스트를 통해 검증되는 것은 의도한 애플리케이션을 위한 데이터베이스 설계의 실현가능성(viability)이다. 데이터베이스 설계가 실현 가능하지 않으면 애플리케이션 프로그래머의 전문 지식에 관계없이 애플리케이션이 그 데이터를 절대 정확하게 유지할 수 없다.

두 번째 단계는 검증된 데이터베이스 설계를 애플리케이션 소프트웨어가 사용하는 것을 테스트하는 것이다. 이 테스트는 성공적인 흐름 테스트가 완료된 후 애플리케이션의 "뒷면"을 살펴보는 것과 같다. 테스트 결과가 화면상에 좋게 보인다 하더라도, 테스터는 "애플리케이션이 동일한 결과를 데이터베이스에서 올바르게 관리하는가?"라는 질문을 해야 한다. 이러한 종류의 테스트는 검증된 트랜잭션 흐름 화면과 검증된 보고서 흐름 화면이 짝을 이룸으로써 가장 쉽게 수행할 수 있다. 트랜잭션 화면으로 들어가는 내용이 보고서 화면에 나타나면 이러한 화면을 지원하는 기저 데이터베이스 구조가 올바르게 조작될 가능성이 높다(100%는 아님).

애플리케이션 데이터베이스를 테스트하려면 DBMS 언어, 설계 및 운영의 복잡성으로 인해 테스터와 데이터베이스 관리자 간의 협력과 협업이 필요하다.