[ISTQB] 1장 테스팅의 기초 (1)

 

1.1 테스팅이란 무엇인가?

 

What is Testing?

​

☞  소프트웨어 테스팅

-> 소프트웨어 품질을 평가, 운영 중 소프트웨어 장애 발생 가능성을 줄이는 방법

​

☞  테스트 프로세스

-> 테스트 계획, 분석, 설계, 테스트 구현, 테스트 진행 상황 및 결과 보고(완료), 테스트 대상 품질 평가 등의 활동을 포함

​

☞  동적 테스팅

-> 테스트 대상 컴포넌트나 시스템을 실행시켜서 수행하는 테스팅

​

☞  정적 테스팅

-> 테스트 대상 컴포넌트나 시스템을 실행시키지 않고 수행하는 테스팅

​

☞  검증 (verification, 베리피케이션)

-> 요구 사항, 주어진 명세를 충족하는지 확인하는 것

​

☞  확인 (validation, 벨리데이션)

-> 운영 환경에서 사용자 또는 기타 이해관계자를 만족시키는지 확인하는 것

​

테스팅 활동에는 검증(verification)과 확인(validation) 활동 모두를 포함한다.

​

​​

​

1.1.1 테스팅의 일반적인 목적

Typical Objectives of Testing

​

1. 작업 산출물(요구 사항, 설계, 소스 코드 등) 평가에 의한 결함 예방

2. 명시된 모든 요구 사항이 충족됐는지 검증

3. 완성 여부 확인과 사용자와 기타 이해관계자의 기대치 대로 동작하는지 확인

4. 품질 수준에 대한 자신감 획득

5. 장애 및 결함 발견

6. 계약/법률/규제 요구 사항이나 표준을 테스트 대상이 준수하는지 확인

​

테스팅의 목적은 현재의 테스트 레벨과 사용하는 소프트웨어 개발 수명주기 모델 등에 따라 달라질 수 있다.

ex)

ㄴ 컴포넌트 테스팅의 목적은 내재되어 있는 결함을 최대한 조기에 가능한 많이 식별, 또는 코드 커버리지를 높이는 것일 수 있다.

ㄴ 인수 테스팅의 목적은 시스템이 기대한 대로 동작하는지, 또 요구 사항을 충족하는지 확인하는 것이다. 또는 시스템을 배포하는 것에 대한 리스크 정보를 이해관계자에게 제공하는 것일 수 있다.

​

​​

​

1.1.2 테스팅과 디버깅

Testing and Debugging

​

테스트 : 소프트웨어의 결함과 장애를 찾아내는 것 = 테스터

디버깅 : 결함의 원인을 분석하고 수정하는 개발 활동 = 개발자​

​

 

 

 

---

​

1.2 테스팅이 왜 필요한가?

why is Testing Necessary?

​

1. 운영 중 장애 발생 가능성을 줄이는 데 도움이 된다.

2. 결함을 수정하여 시스템 품질에 기여한다.

3. 계약/법적 요구 사항이나 특정 산업 표준을 만족시키는데 필요할 수 있다.

​

​​

​

1.2.1 성공을 위한 테스팅의 기여

Testing's contribution to Success

​

1. 테스터가 요구 사항 리뷰 및 사용자 스토리 개선에 참여하면, 해당 작업 산출물에서 결함을 발견할 수 있다.

ㄴ 잘못된 혹은 테스트 불가한 기능을 개발하는 리스크를 줄일 수 있다.

 

2. 테스터가 시스템 설계자와 협업하는 경우

ㄴ 기능 설계에 결함이 유입되는 리스크를 줄일 수 있고, 필요한 테스트를 좀 더 일찍 식별할 수 있다.

 

3. 테스터가 개발자와 협업하는 경우

ㄴ 코드와 테스트에서의 결함 발생 리스크가 줄어든다.

 

4. 테스터가 릴리즈 전에 소프트웨어를 확인하고 검증하는 경우

ㄴ 놓쳤을 수 있는 장애를 발견할 수 있고, 디버깅에 도움을 줄 수 있다.

​

💡 릴리즈/릴리스(release) : '출시(하다)', '배포(하다)'

​​

​

1.2.2 품질 보증과 테스팅

Quality Assurance and Testing

​

품질 보증과 테스팅은 다른 개념이다.

품질 관리에 품질 보증과 테스팅이 속한다.

​

품질 관리 (QM)

☞ 품질의 측면에서 조직이 나아가야 할 방향을 제시하고, 제어하는 활동

☞ 품질 보증, 품질 제어 등 여러 활동을 포함한다.

​

품질 보증 (QA)

☞ 적절한 품질 수준을 달성했는지 확신을 얻기 위해 적절한 프로세스를 준수하도록 하는 것에 초점을 맞춘다.

☞ 근본 원인 분석, 회고 회의 등의 결과를 활용하여 프로세스를 개선할 수 있다.

​

품질 제어 (QA)

☞ 적합한 품질 수준을 달성하기 위한 다양한 활동을 포함

☞ 이곳에 테스팅 활동을 포함한다.

☞ 테스트 활동은 소프트웨어 개발 및 유지 보수 프로세스의 일부이다.

​

​​

​

1.2.3 오류, 결함, 장애

Error, Defects, and Failures

​

사람은 프로그램 코드 또는 기타 작업 산출물을 작성하면서 결함(결점, 버그)를 발생시키는 오류(실수)를 범할 수 있다.

​

예를 들어, 요구 사항을 도출하면서 범한 오류는 요구 사항 결함이 되고, 요구 사항 결함은 프로그램 작성 시 오류를 일으켜 코드 결함의 원인이 된다.

 

코드의 결함은 장애를 일으킬 수 있지만, 반드시 그런 것은 아니다.

ㄴ 장애는 코드 결함뿐 아니라 환경 조건으로 발생할 수 있다.

ㄴ (방사능, 전자기장, 환경오염 등이 하드웨어를 변화시키면 소프트웨어에도 영향을 줌)

 

테스트 결과가 기대 결과와 다르다고 해서 무조건 장애가 있다고 볼 수 없다.

ㄴ 다양한 이유로 인해 거짓 양성(false positive)과 거짓 음성(false nagative)이 나올 수 있다.

​

​​

​

1.2.4 결함, 근본 원인, 결과

Defects, Root Causes and Effects

​

근본 원인

☞ 결함을 만들어낸 최초의 행동이나 조건

​

예시 > 잘못된 코드로 인한 이자 지급 오류가 초래한 소비자 불만

· 결함 : 코드에 포함된 잘못된 계산식

· 결과 : 소비자 불만

· 장애 : 잘못된 이자 지급

· 근본 원인 : 제품 소유자의 지식 부족

· 오류 : 제품 소유자가 사용자 스토리를 작성할 때 오류를 범함

 

 

 

 

---

Reference

https://m.blog.naver.com/PostList.naver?blogId=jing_new_&tab=1