[소프트웨어공학] 8장 Software Testing

실제 개발한 소프트웨어를 실험하고 검증하는 단계

 

주요의제

• Development testing(개발에서 테스트가 무엇인지)
• Test-driven development(민감한 소프트웨어를 짤 때 많이 사용됨)
• Release testing(실제 사용자에게 내놓기 위한 테스트)
• User testing(사용자입장에서 테스트)

 

Program testing

>테스트를 할 때 우선적으로 확인해야할 것은 주어진 입력에 맞춰서 출력이 제대로 나오는 것에 대한 정상의 입력에 대해 정상의 출력이 나오는지 확인해야 한다.

>어떠한 상황에서 프로그램이 잘못 동작하는 것에 대해 발견하고 그것에 대해 수정하거나 개선하거나 대응 할 수 있어야 한다.

-테스트에 사용되는 데이터는 임의적으로 만들어지거나 아니면 이전 제품이 다루었던 내용을 기반으로 한다.

-테스트를 통해서 오류를 확인하고 비기능적인 것들에 대해서도 확인을 한다.

-하지만 무조건적으로 테스트를 진행했다고 해서 오류가 없는 것이 아닌 특정행위를 통해 오류를 찾아가는 과정이다.

-테스트는 우리가 생각한 기능이 요구사항대로 제대로 구현이 되었는지를 확인하고 이 소프트웨어가 사용자에게 전달되어 사용자가 돈을 지불하고 사용할만한 가치가 있는지 판단한다.

 

Program testing goals(프로그램 테스트의 목표)

-개발자와 고객에게 요구사항에 맞춰 소프트웨어가 잘 구현되었는지 보여준다.

각각의 소프트웨어에 부분적인 요소들에 대해서도 적어도 한번 이상의 테스트가 이루어져 그것들이 요구사항(명세서)에 맞춰 구현되었는지를 확인해야한다.(테스트에도 시간이 많이 필요하다. -> 입력과 출력이 명확하다.)

-입력을 명확하게 했으나 엉뚱한 결과를 내는 경우, 입력이 제대로 나오다가 간혹 틀린 결과가 나오는 경우, 제대로 되지 않은 입력을 넣었을 때 제대로 된 결과가 나오는 것

-> 문제 찾기(defect testing, 비정상적인 결과가 나온 것에 대해 원인을 찾아 고치고 대응하는 것)

 

Validation and defect testing

-프로그램이 제대로 동작해야하는 상황에서 제대로 동작하는지를 확인하기 위해 테스트케이스들을 만들고 실행한다.(Validation testing)

-오동작하고 문제가 있는 부분을 찾아내기 위해 입력된 값이 제대로 일 때 항상 제대로 된 결과가 나오는지 유지되지 못하는 부분들을 찾아가는 과정을 한다.(defect testing)

 

 

Verification vs Validation

>Verification – 소프트웨어를 맞게 만들었나를 명세서(요구사항)에 따라 잘 만들어졌는지 -> 입력에 따라 제대로 된 결과가 나오는지(개발과 관련된 테스트 대부분이 이것)

>Validation – 만들어진 소프트웨어가 의미가 있는 것인지 -> 정말 고객이 원한 소프트웨어가 맞는지

 

 

V & V confidence
>Software purpose – 기능, 신뢰성, 성능과 같이 소프트웨어의 목적에 맞는 동작을 하는지

>User expectations – 사용자의 눈높이에 맞추기(사용자는 일반적으로 처음 소프트웨어를 만났을 때의 기대감이 그렇게 많지 않음, 기대감보단 의심의 눈으로 보게 되는데 이러한 부분을 만족 시킬 수 있어야한다.)

>Marketing environment – 여기가 V&V와 테스트에 지대한 영향을 미침 -> 마케팅적인 관점에서 보면 회사에서 합리적인 시간을 갖고 소프트웨어를 개발함에 있어 동류의 다른 회사가 동일한 소프트웨어를 더 단시간 안에 개발이 가능하게 된다면 우리 입장에서 경쟁에서 이기기 위해 더 단시간에 소프트웨어 개발을 하려는 노력하는데 이때 많이 시간적으로 많이 줄어드는 것이 테스트 시간이다.(더불어 테스트 중에서도 실패를 찾는 시간이 더 많이 줄어든다.)

-> 이에 따라 소프트웨어 테스트 시간이 줄기 때문에 사용자의 기대치가 낮아지는 것을 이해할 수 있다.

>>우리는 소프트웨어를 개발할 때 요구사항들만을 만족시키는 것이 아닌 마케팅적으로 오는 변화들에 따라 전반적인 개발일정의 변화에도 적응 할 수 있어야하고 어느 부분의 시간을 줄일 것인지에 대한 판단 역시 필요하다.

>>버그가 없는 프로그램을 만들 수는 없다. -> 이에 따라 우리가 무한적 테스트를 할 시간을 가지고 있지도 않다.

 

Inspections and testing

>static verification(code review) – 소프트웨어를 관찰 분석하는 것, 실제 작동은 하지 않음(머리로 생각해 보는 것), 다른 사람도 같이 테스트에 참여함, 코딩과정에서도 꾸준하게 진행할 수 있다.(software inspections)

>dynamic verification – 일반적으로 기능적인 측면에서 입력 값을 주었을 때 제대로 된 출력이 나오는지 테스트하는 것, 오동작하는 것은 없는지

 

 

Software Inspections

-소스코드를 보고 오작동할 것 같은 부분을 찾아내는 것(소스코드를 읽는 것)

-소프트웨어가 개발 중이더라도 테스트를 하는 과정을 할 수 있다.

-소프트웨어 개발이 완료되고 할 수 있는 것이 아니고 전반적인 과정들 속에서 진행할 수 있다.

 

장점

-정적인 과정이다.

-특정프로그램이 다른 프로그램과 상호작용을 해야 실행시킬 수 있는 경우에도 각 프로그램 별로 진행이 가능하다.

-큰 비용이 들지 않는다.

-비기능적인 부분, 호환성이 좋은지, 재상용 가능한지에 대한 판단도 가능하다.

 

Inspections and testing

-기능적으로 입력 값과 출력 값에 오류여부를 판단 할 수 있다.

-V & V과정을 둘 다 진행한다.

 

Software testing process

>동적으로 소프트웨어를 테스트하는 것은 테스트케이스를 만들어서 진행한다.(시나리오 등에서 시퀀스 차트와 같이 입출력에 대한 것에 따라 정리)

>테스트 데이터를 준비(데이터를 만들기)

>데이터를 가지고 실행

>실행결과를 가지고 예측했던 결과가 제대로 나왔는지를 확인

>그러한 결과들을 가지고 테스트 레포트를 작성

 

Stages of testing(테스트는 전반적인 과정에서 많이 진행됨)

>Development tesing(개발 테스트) - 개발하는 측면에서 스스로 해보는 테스트

>Release testing – 테스트를 전담한 팀에서 개발테스트를 마친 소프트웨어를 실제로 사용자에게 전달하기 위해 빌드 또는 패키징함(사용자에게 전달되기 전의 중간과정, 사용자의 요구사항을 가져와서 개발자들이 개발을 위해 요구사항을 정리하고 정리된 명세서에 따라 제대로 구현이 되었는지 전체적으로 테스트 하는 것)

>User testing – 사용자 관점에서 자신의 원하는 소프트웨어가 만들어진 것인지를 테스트함

 

 

Development testing(개발하는 팀에서 본인들이 만든 결과물을 스스로 테스트 해보는 것)

>Unit testing – 가장 작은 단계인 함수나 객체오브젝트(클래스)와 같은 것들이 제대로 작동하는지를 테스트 하는 것(ex. 머신러닝에서 각각의 데이터를 읽는 부분, 머신러닝을 동작하는 부분들이 잘 동작하는지를 봄)

-각각의 요소들을 테스트

-클래스하나 또는 묶여져 있는 클래스를 테스트

>>Object class testing

- 클래스가 가지고 있는 메서드들이 잘 동작하는지를 테스트 -> 데이터 같은 것들을 잘 구성해서 적용이 가능한지를 봄

- 가능하다면 많은 테스트케이스를 통해 확인을 함

- 유전의 법칙을 통해 가져온 베이스 클래스의 요소들이 개발하려는 소프트웨어에 꼭 부합하지 않을 수 있음을 염두해야함.

- 테스트케이스를 만들어서 테스트를 하는데 시나리오를 기반으로 테스트케이스를 작성한다. (page22) -> 테스트도 역시 프로그램을 개발하는 과정이다.

>>Automated testing

- 자동화를 진행하여 테스트를 진행함

- 테스트를 짜는 framework(라이브러리)같은 것들도 존재함 ex. JUnit(자바용)

- framework를 이용한다면 자체적으로 레포트를 만들어주기도 함

테스트 단계(test step)

-setup part -> 테스트를 하기 위해 구성하는 것

-call part -> 테스트 대상을 실제로 실행

-assertion part -> 실행결과가 맞는지 틀린지를 판단함

unit test case(2가지)

-정상적인 입력을 주었을 때 정상적으로 동작을 하는지

-잘못된 동작을 찾아내는 것(가장 중요한 것은 잘못된 동작이 들어와도 죽지 않고 다시 올바른 입력이 들어올 때까지 기다리게 하는 것)

 

>>Testing strategies

-Partition testing, 입력을 어떻게 줄 것인지

테스트할 것들을 군으로 묶어서 대표되는 것에 대해 테스트를 하는 것(잘 못 선정하면 오류가 발생함) -> 수많은 테스트들을 모두 진행할 수 없기 때문임 ex. (page29)

입력수의 범위의 가장 끝부분에 경계부분에 있는 것들을 테스트 해봄

-Guideline-based testing, 경험에서 나온 이전의 것들을 미리 체크해 보는 것

어떤 식으로든 오류를 유발하는 것들을 입력해 보는 것

입력 값을 계속 주어 그 값들을 업데이트하는데 오류가 있는지를 확인함

계산을 굉장히 큰 값 또는 작은 값을 입력하여 오류를 확인해 본다.

 

Component testing – 함수들이 다른 함수를 호출하거나 클래스가 다른 클래스의 메서드를 호출하는 인터페이스가 제대로 이루어졌는지를 테스트함, 결합도, 연결도를 봄(ex. 머신러닝의 각 요소들 간의 상호작용이 잘 이루어지는지를 봄), 수많은 객체들이 서로 호출하고 데이터를 가져가는 과정을 테스트함, 메소드를 직접 호출하는 것이 아닌 파일, 컴퓨터메모리 등의 다양한 기법을 사용해서 객체 간의 정보를 주고받을 수 있다. -> unit test를 통해서 함수 또는 클래스에 대한 테스트를 마쳤다고 할 수 있다.

-> 우리가 여기서 관심을 가져야할 것은 인터페이스이다.

>>Interface testing(객체와 객체 혹은 같은 컴퓨터에 있지 않은 객체들 간의 인터페이스를 하기 위해 다양한 방법이 사용되는데 이것들이 제대로 사용되고 호출되는지에 대한 테스트)

- Parameter interfaces -> 입력 파라미터로 제대로 된 값을 주었을 때 제대로 동작하는지, 제대로 된 값을 주지 않았을 때 어떤 상황이 벌어지는지

- Shared memory interfaces -> RAM(컴퓨터 메모리)을 사용해서 데이터를 공유함

- Procedural interfaces -> 여러 절차들이 한 번에 묶여서 호출되는데 이러한 절차들이 제대로 지켜지는지 호출

- Message passing interfaces -> 컴퓨터들이 통신을 통해서 서로 떨어져있는 경우에 메시지를 통해 통신을 하는데 이러한 것들이 잘 이루어지는지

-> 대분의 것들은 unit test에서 이루어졌다고 생각하고 위와 같은 것들이 컴포넌트 테스트에서 이루어짐

주요목적 – unit test를 거친 이후에 외부에서 테스트 케이스를 보내서 결론적으로 우리의 컴포넌트들이 제대로 인터페이스가 되는지를 확인하는 것

 

>>Interface errors(에러발생 경우, 오류발생)

- Interface misuse -> 줘야할 파라미터 타입을 지키지 않은 경우(ex.정수를 입력해야 하는데 실수를 입력함), 준 파라미터의 순서가 잘못된 경우(ex. A(사람이름)를 주고 B(주민번호)를 주어야하는데 B를 주고 A를 줌)

- Interface misunderstanding(문서의 중요성 대두) –> 줘야하는 데이터의 요구사항을 읽지 않음, 형태는 맞지만 그렇게 입력된 값이 잘못된 경우 (ex. 이진트리에서 정렬이 되어있는 입력을 달라고 했는데 비정렬 입력 값이 들어옴)

- Timing errors - > 쉐어드 메모리 방식과 메시지 패싱 방식에서 많이 일어나는 에러(ex. 컴퓨터 메모리에 기능을 호출했을 때 미쳐 호출된 기능을 가져오지 못함, 똑같은 값을 가지고 입력되어야하는데 서로 다른 값을 가지고 있는 것 – 동기화되지 않은 것)

>>객체들 간에 인터페이스를 잘하고 있는지를 확인하는 것 -> 컴포넌트 테스트

>>인터페이스(컴포넌트) 테스트할 때 어떻게 해야 하는지

값을 줄 때 경계 값이 있다면 최대, 최소, 경계 값을 입력 값으로 줘볼 필요가 있음

주소 값을 전달하는 경우에는 NULL 포인터 (의미없는 주소값)을 주었을 때 프로그램이 잘 방어 할 수 있는지

제대로 되지 않은 값을 주었을 때 시스템이 죽는지 사는지

통신 프로그램에서 필요한 것과 필요없는 것을 거르면서 수행이 되는지

shared memory system에서 서로 공유해서 사용하는 자원에 대한 동기화가 잘되고 있는지

 

>System testing – 컴포넌트들이 전부 모여져 있는 소프트웨어 개발 최종단계에서 테스트를 함 -> system integrated(시스템 빌드)

>>컴포넌트들 간에 제대로 정보를 주고받는지 테스트 -> 컴포넌트 테스트가 커진 느낌

>>시스템에서 해야 될 일을 테스트한다.

>>앞에서 있는 unit test는 개발팀이, 컴포넌트 테스트는 개발팀 혹은 개발팀 외의 전담부서가 진행함 여기서 시스템 테스트는 대부분 전담팀이 담당을 함(개발팀x).

>>COTS에서 사온 요소(상용)들도 우리의 것들과 통합되는 작업이 이루어짐

>>개발, 디자인 부분과는 완전히 독립된 팀이 작업을 함

>>유스케이스, 시나리오 기반으로 테스트하는 것이 일반적으로 이루어진다.

>>시나리오 작업을 할 때 사용된 시퀀스 다이어그램에 맞춰서 테스트 프로그램을 구성함

 

ex) weather station 시스템 테스트, 시퀀스 차트

>테스트 소프트웨어로 정상적으로 입력을 하고 정상적인 응답을 받는지 테스트 -> 분량에 제한으로 간단히 나오지만 잘 못된 입력이 들어왔을 때 생기는 잘못된 결과도 표현을 해줌 -> 지속적으로 시나리오를 참고함 -> 전반적인 요청과 응답이 잘 이루어지고 있는 지를 테스트

>>시퀀스 다이어그램으로부터 테스트케이스 구성(test case)

요청을 보내는 사람은 응답(acknowledgement)을 반드시 받아야함 -> 이것에 대한 확인이 필요, 맞는 요구를 했다면 올바른 응답이 왔는지 확인이 필요(본인이 제대로 된 결과를 가지고 있어야 확인이 가능), 엉뚱한 요구와 그에 대한 결과도 확인을 위해 필요하다.

>>컴포넌트들 간의 integration과 이 모든 것들의 integration에 대해서 유저의 요구를 받아 제대로 된 결과가 나오는지를 확인하는 과정임 -> 그를 위한 프로그램이 만들어져야 하며 그것은 시나리오에 맞춰서 요구에 따라 예상되는 결과들을 모두가지고 확인 할 수 있어야한다.

 

Testing policies(테스트 규칙)

-사람, 시간, 자원은 항상 부족하니 제한된 자원 속에서 어디까지 테스트를 할 것인지를 정해야함, 일정가이드라인이 있어야함

ex)

- 시스템을 사용하는 사용자가 접하는 메뉴들은 모두 확인해야 한다.

- 버튼을 눌렀을 때 연결해서 같은 기능을 하는 부분은 모두 연계해서 테스트를 진행해야한다.

- 입력 값이 맞게 왔을 때 맞지 않게 왔을 때 모두 테스트가 진행되어야한다.

 

>Test-driven development(TDD, 도구적 기법임, 테스트가 주도하는 개발)

-> 에이자일과 같은 최근 개발 방식에서 많이 사용됨

-> 내가 구현할 코드에 대한 결과를 기반으로 테스트할 프로그램을 먼저 만드는 것

>>순서 : 테스트 할 프로그램을 먼저 구현 -> 테스트 당할 프로그램을 이후에 구현

->처음에 생각한 입력에 따른 결과에 맞춰 구현을 하는 것

에이자일 기법에 사용

페이지 별로 테스트 프로그램을 먼저 구현 후 프로그램을 구현함

코드를 구현하는 것과 테스트를 하는 과정이 상호 밀 결합 되어있음.

페이지에 따라 나눠보면 내가 만들 클래스에 메소드 별로 각각의 테스트를 먼저 만들어서 구현을 진행함

테스트 코드와 실제 본 코드가 incremental하게 자라남

에이자일과 같이 개발 페이지가 incremental하고 개발주기가 짧은 곳에서 주로 사용된다.

plan based, waterfall에서도 사용가능한 기법임

(page 44)

ex. 클래스를 하나 만들 때 멤버 메서드가 10개라고 하면 맨 처음에는 우리가 실행시킬 클래스가 있어야함 -> 클래스를 정의 -> but 함수는 없는 것 -> 테스트 할 함수는 없지만 테스트를 해버림 -> 바로 fail이 나옴 -> fail이 난 그 기능들을 이후의 과정에서 진행함 -> 본 코드 구현을 해서 다시 테스트를 진행해서 수행되면 pass함 -> 각 메서드 별로 루프가 진행되어 누적시키며 진행해 나감 -> (에러가 나면 그때 구현을 시작함)

>>목적 : incremental하게 함수를 구현함

-> 지속적으로 테스트를 함으로써 안정화된 프로그램을 만듦

 

TDD의 이점 -> 반드시 이후에 도움이 됨(책을 읽고 프로젝트에 적용해 볼 것)

>Code coverage – 코드별로 테스트가 각각 진행되기 때문에 요구사항을 만족함

>Regression testing - 회귀 테스트 세트는 프로그램이 개발됨에 따라 점진적으로 개발된다.

이전에 제대로 작동하던 것이 새로운 것에 도입으로 문제가 발생하는 것에서 테스트를 다시 생각해 봄으로써 이후에 디버그 시간을 단축시킬 수 있다.

>Simplified debugging - 테스트가 실패하면 문제가 어디에 있는지 분명히 밝혀야 한다. 새로 작성된 코드를 확인하고 수정해야 한다.(점점 에러는 줄어든다. -> 효율적인 과정임)

>System documentation - 테스트 자체는 코드가 수행해야 하는 작업을 설명하는 문서의 한 형태이다.(문서를 최소화할 수 있음, 테스트 프로그램 자체가 대체해줌)

>>가장 중요한 철학 -> 테스트 코드를 통과할 수 있을 만큼의 코드만 작성해라 -> 너무 많은 코드는 바람직하지 않음

 

Release testing – 소프트웨어가 개발팀을 완전히 떠나가는 것

- 소프트웨어를 사용자입장에서 테스트하는 것

시스템 내부 자체의 기술을 고객님이 모른다는 가정 하에 테스트가 이루어짐(black box testing), 사용자가 한 요청에 따라 응답이 잘 오는지에 대해서만 테스트를 진행하는 것

시스템 레벨의 요구기능이 잘 갖추어 졌는지를 테스트함

개발팀이 아닌 전담팀이 꾸려져서 검증을 담당함

시스템 요구사항을 기반으로 테스트가 이루어짐

ex) 멘탈 케어 시스템

환자가 있는 경우 이 환자가 알러지를 가지고 있을 수 있기 때문에 처방이 이루어질 때 warning 메시지가 떠야함 -> 처방을 하는 사람에게(의사-시스템 사용자)

warning 메시지를 무시했다면 왜 무시하였는지 근거를 남기는 작업도 진행함

 

>Requirements tests

환자가 알러지가 없는 경우 별도의 warning 메시지가 생성되지 않음 -> 알러지 없는 임의의 환자 정보를 입력해서 확인해봄

환자가 -> 알러지가 있는 정보를 입력을 해서 알려지 관련 약품을 처방했을 때 warning 메시지가 나타나는지 확인을 함

여러 개의 약에 대해서 알러지가 있다면 모든 병명에 대해서 warning 메시지를 나타나게 함 -> 임의 설정 후 테스트를 진행함

두 개의 약에 대해서 알러지가 있다면 두 개의 warning 메시지가 뜨는지 확인함

경고를 무시했을 때 이유를 물어보는 알림

 

 

>기술적인 부분 테스트

- 로그인 관련 테스트

정보를 업로드 하는데 제대로 되는지 확인

스케줄링이 제대로 되는지에 대한 확인

정보가 암호화되는 부분에 대한 확인

약 관련 정보에 대한 것들이 잘 관리가 되는 확인

 

>Performance testing

제한된 사용자 정원에 따라 제한사항들이 잘 처리되는 확인

접속에서 예를 들어 1000명까지라고 한다면 1000명까지는 잘 받고 나머지는 버리는 행위->이러한 행위가 잘 이루어지는지

가상의 부하를 걸어서 테스트를 진행함

 

 

User testing

사용자, 고객을 대상으로 진행되며 돈을 줄지 말지도 결정이 됨

 

>Types of user testing

-Alpha testing -> 선별적인 사용자를 모아서 그들에게 의견을 묻는 것, 돈을 주고 개발자에게 요구를 했던 그룹에게 테스트를 진행함(어느 정도 소프트웨어에 지식이 있음)

-Beta testing -> 소프트웨어에 대한 정보를 가지고 있지 않고 기존의 소프트웨어를 사용해 오던 사람들을 기반으로 테스트를 진행함

-Acceptance testing -> 제대로 된 테스트가 진행되었음을 확인해주는 테스트 -> 가장 중요함

 

>acceptance testing process

-> 요구사항에 따라 어떤 부분을 테스트할 것인지 정의를 함 -> 테스트에 대한 계획(인력, 시간, 비용)을 세움 -> 테스트를 할 구체적인 방법론, 소프트웨어, 장비들이 구축이 됨 -> 그리고 실행(테스트)을 해서 결과가 나옴 -> on/off로 나온다고 할 때 안 되다면 되게 해야 하고 수치가 논란을 일으킨다면 협상을 해야 함 -> 레포트에 따라서 accept를 할지 reject를 할지 아니면 조건부 accept 언제까지 수행을 할지 정함

>>여기까지 마치면 배포가 시작됨

-Define acceptance criteria

-Plan acceptance testing

-Derive acceptance tests

-Run acceptance tests

-Negotiate test results

-Reject/accept system -> 가장 중요

 

 

Agile methods and acceptance testing

-> 사용자와 고객이 개발자의 일부이다.

-> 회사에 따라 개발팀과 오퍼레이션 팀이 다를 수 있는데 오퍼레이션 팀이 acceptance testing을 함 -> 구글이나 네이버가 사용자에게 알파, 베타 테스트를 하는 경우가 있음 에이자일이나 상용 소프트웨어에서도 사용됨.

이번 단원이 plan based, top down 방식으로 설명이 되지만 에이자일이나 여러 곳에서 두루 사용할 수 있다.

의미론적으로 생각할 것(테스트가 가지는 의미는 두루 적용됨)

 

Key points

- 테스트에서는 프로그램에 오류가 있는지만 확인할 수 있습니다. 결함이 남아 있지 않다는 것을 증명할 수 없습니다.

- 개발시험은 소프트웨어 개발팀의 책임입니다. 고객에게 시스템이 공개되기 전에 별도의 팀이 시스템 테스트를 책임져야 합니다.

- 개발시험은 개별 객체 및 방법 구성요소 시험을 통해 관련 객체 그룹을 시험하는 단위시험과 부분 또는 전체 시스템을 시험하는 단위시험이 있다.

- 소프트웨어 테스트 시 경험과 가이드라인을 활용하여 다른 시스템의 결함을 발견하는 데 효과적이었던 테스트 케이스의 유형을 선택하여 소프트웨어를 '파쇄'하도록 합니다. -> 창조적인 생각은 시스템에 오류/예외 처리를 할 때 많이 사용된다.

- 가능한 경우 자동 테스트를 작성해야 합니다. 테스트는 시스템에 변경이 발생할 때마다 실행할 수 있는 프로그램에 포함되어 있습니다.

- TDD(Test-Driven Development)는 시험할 코드 앞에 시험을 작성하는 개발 접근법이다.

- 시나리오 테스트에서는 일반적인 사용 시나리오를 작성하고 이를 사용하여 테스트 사례를 도출합니다.

- Acceptance testing은 소프트웨어가 운영 환경에 배치되고 사용하기에 충분한지 여부를 결정하는 것을 목적으로 하는 사용자 시험 과정이다. -> 사용자가 결국 결정을 내리는 것

 

배포(release)를 했다고 끝나는 것이 아님