[Project design] 최종 테스트 - ST(Standard(Scenario) test) 테스트


Study/Project design  2021. 1. 11. 15:29

안녕하세요. 명월입니다.


이 글은 프로그램 최종 테스트 - ST(Standard(Scenario) test) 테스트에 대한 글입니다.


프로그램이 납품 되기 전의 최종 테스트로서 ST 테스트라고 하는데, 약자가 좀 불분명합니다. 시스템(System) 테스트라고 하는 사람도 있고 표준(Standard) 테스트나 시나리오(Scenario) 테스트라고 하는 사람도 있습니다.

약어만 다를 뿐이지 거의 테스트의 형태는 비슷하게 인지하고 있습니다.


예전에 테스트 범위에 대해서 설명한 적이 있습니다.

거의 위의 표의 형태로 테스트가 실시되는 데 이 최종 테스트는 기본 설계에 관한 테스트입니다.

즉, 이전 단위 테스트(UT)나 결합 테스트(IT)에서는 프로그램에 대한 버그나 조작에 관한 테스트가 주요 항목이었으면 ST에서는 이 프로그램 사양에 대한 테스트가 주요입니다. 즉, 프로그램적인 버그가 아닌 논리적인 데이터에 대한 테스트입니다.

예를 들면 특정 요청 페이지로 데이터를 생성해서 특정한 절차를 통해 최종적인 데이터가 표시되는 것이 제대로 것인가에 대한 테스트입니다.


그러다보니 이전까지는 프로그램 툴이나 라이브러리를 통해 자동화 테스트를 할 수 있었던 것에 비하면 ST는 거의 100% 사람이 해서 그 값이 정확한 것인지 확인을 해야합니다.


테스트의 방법에 대해서는 프로그램의 종류나 형태에 따라 다릅니다.

가령 게임 같은 경우는 보통 알파, 클로즈 베타, 오픈 베타식으로 테스트가 이루어 지는 경우가 많고, 일반 프로그램 툴이나 도구에 관해서는 Unstable 버전, stable 버전(안정화 버전)으로 구분을 해서 Unstable 버전이 보통 테스트 버전이고 stable 버전이 정식 버전입니다.

그리고 웹 환경에서는 테스트 버전(dev 환경 버전), 정식 버전으로 구분해서 배포하는 경우도 많이 있습니다. 이건 프로그램의 종류나 버그 인지 중요성에 따라 방법과 기간이 구분이 됩니다.


그리고 테스트 사양서를 작성할 때의 스탭 수, 즉 테스트의 항목 수는 보통 프로그램 코드 라인의 5%~10%를 작성합니다.

즉, 프로그램 코드가 총 10만 라인이라고 한다면 테스트 항목을 5천건에서 1만건 정도를 작성합니다. 테스트의 사양서의 내용은 기본 설계에 의한 논리적인 데이터 확인이기 때문에 단순한 UT나 IT에서 확인되었을 만한 항목은 제외합니다.

예를 들면, PDF나 장표를 출력하는 버튼이 눌렀을 때, 제대로 다운로드가 되는 지에 관한 테스트는 ST의 항목이 아닌 것이지요.


ST의 항목이라고 한다면 어느 특정 권한을 가졌을 경우 의뢰 페이지로 데이터가 생성되는 데, 다른 권한을 가졌을 경우 생성 권한을 갖지 않고 데이터 표시는 제대로 되는지, 혹은 권한에 따른 데이터가 제대로 보이는 지 안 보이는지, 데이터 계산을 바르게 되어지는 지에 대한 검사입니다.

물론, 이러한 것도 IT에서 체크가 되는 부분입니다만, 좀 더 사람이 조작을 했을 때, 느껴지는 스크립트에 대한 부드러움(?)과 성능, 그리고 데이터의 정확도에 대한 테스트라고 볼 수 있습니다.

예를 들면, 웹 테이블 태그에 대한 값을 정확하게 표시됩니다만, 화면에 표시되는 게 이상하게 표시되서 계산상으로는 맞겠지만 사람이 잘못 인지할 확률이 있다던가 버튼을 찾기 힘들다던가 이런 여러가지 변수에 대한 검사입니다.


ST는 보통 프로그램 납품하기 전에 최종 테스트 단계인 만큼, 프로젝트에서의 그 권한도 상당합니다.

프로젝트를 구성할 때 핵심 맴버가 PM(Project Manager)와 수석 개발자(Senior Developer)와 품질 관리자(Quality manager)입니다만 PM은 프로젝트의 스케줄과 전체적인 관리고 수석 개발자는 개발에 대한 총 책임을 진다고 할 경우, 품질 관리자는 프로젝트의 테스트를 책임진다고 볼 수 있습니다.

프로젝트의 크기와 구성에 따라 그 책임 달라지지만, 보통 프로그램의 에러나 요구 사항의 에러에 관한 것이면 품질 관리자(Quality manager)가 책임을 지는 경우가 많습니다. (이것은 프로그램의 형태나 비중에 따라 확연히 바뀌는 부분이지만, 가장 흔한 일반적인 사항입니다.)

그러다 보니 품질 관리자가 권한이 꽤 있는 편이고 그러다 보니 프로젝트에서의 ST의 영역은 꽤 중요한 부분이기도 합니다.


프로젝트 특성에 따라 ST의 기간과 인력가 바뀌고 그에 따른 프로그램의 가격이 바뀌는 경우도 많습니다.

중대형 미들 웨어나 Offline 프로그램으로 배포 후에 패치나 버그 수정이 어려운 프로젝트의 경우는 ST의 기간과 인력이 꽤 많이 배치되어 그 기간에 따라 비용이 올라가는 경우가 많고, 배포 후에도 패치나 수정 배포가 가능한 경우에는 ST의 기간과 인력이 많이 내려가는 편이라 가격이 내려가는 경우가 많습니다.

Offline 제품보다는 Online 제품이 좀 더 싸지는 경향이 있습니다만 Online 제품이라고 하면 보통 게임이나 웹 서비스, 모바일 앱 서비스가 정도 밖에 없겠네요.


대부분의 소프트웨어 프로그램은 Offline이거나 Online이어도 쉽게 업데이트가 불가능한 제품이 많이 있습니다. 예를 들면 기간 산업(철도, 비행기, 전기, 가스)나 금융, 의료등등의 소프트웨어등은 소프트웨어가 한번 깔리면 바꾸기가 어렵기 때문에 프로그램의 제조 가격도 상당하지만 테스트 공정의 가격도 어마어마합니다.


웹 서비스라고 해도 사내 포털 서비스로 시작되면 그 사양대로 회사의 조직이 구성되고 업무 표준이 이루어지는 경우가 많이 있기 때문에 잘못 작성되어 데이터가 잘못 쌓이게 되면 중간에 바꾸기가 생각보다 쉽지가 않습니다.


작은 프로젝트라면 보통 개발자가 테스트까지 진행하여 납품을 이루어지는데 그럴 때 꽤나 소홀하게 넘기는 경우가 많이 있습니다.

이유는 UT나 IT에서 기술적인 테스트는 다 끝나고 ST에서 또 따로 테스트할 것이 있을까 싶은 생각이 많기 때문인데, 저도 신입 시절이나 지금도 가끔씩 실수하는 부분이기도 합니다.

그럴 때마다 저의 경험은 UT나 IT에서 기술적인 실수로 생긴 버그보다 ST에서 소홀히해서 넘긴 버그가 꽤나 치명적인 것이 많이 있었습니다.

예를 들면, 유저가 동작할 때마다 특정 데이터를 누적하는 값이 있다고 할 때, 그 데이터가 잘못 입력이 되어서 한 3~4개월 쓴 후에 그 데이터가 잘못 되었다는 걸 발견하고 수정할려고 하다보니 데이터가 이미 몇만건이나 쌓여 있더군요.

보통, UT나 IT에서의 기술적인 실수는 데이터가 NULL 입력되거나 규칙적인 데이터 오류가 많은데, ST에서 발생하는 것은 에러가 발생하는 것도 아니고 불규칙적인 요소가 많이 있기 때문에 이전 데이터를 확인하고 수정하려면 만만치 않습니다.


ST가 딱히 정해진 방법으로 테스트를 하는 것이 아니기 때문에 설명할 수 있는 정도가 이 정도뿐입니다. 딱히 기술적인 요소는 없네요..


여기까지 프로그램 최종 테스트 - ST(Standard(Scenario) test) 테스트에 대한 글이었습니다.


궁금한 점이나 잘못된 점이 있으면 댓글 부탁드립니다.