[ISTQB] 1장 테스팅의 기초 요약

1장. 테스팅의 기초 목차

테스팅이란 무엇인가? What is Testing?

• 테스팅의 일반적인 목적 (Typical Objectives of Testing)
• 테스팅과 디버깅 (Testing and Debugging)

테스팅이 왜 필요한가? Why is Testing Necessary?

• 성공을 위한 테스팅의 기여 (Testing’s Contributions to Success)
• 품질 보증과 테스팅 (Quality Assurance and Testing)
• 오류, 결함, 장애 (Errors, Defects, and Failures)
• 결함, 근본 원인, 결과 (Defects, Root Causes and Effects)

테스팅의 7가지 원리 Seven Testing Principles

 

테스트 프로세스 Test Process

• 정황에 따른 테스트 프로세스 (Test Process in Context)
• 테스트 활동과 작업 (Test Activities and Tasks)
• 테스트 작업 산출물 (Test Work Products)
• 테스트 베이시스와 테스트 작업 산출물 간의 추적성 (Traceability between the Test Basis and Test Work Products)

테스팅의 심리학 The Psychology of Testing

• 인간 심리학과 테스팅 (Human Psychology and Testing)
• 테스터와 개발자의 사고방식 (Tester’s and Developer’s Mindsets)

---

테스팅이란 무엇인가?

소프트웨어 테스팅은 소프트웨어의 품질을 평가하고, 운영 중 소프트웨어 장애의 발생 가능성을 줄이는 하나의 방법이다.

 

소프트웨어 테스팅이란 다양한 활동을 포함하는 프로세스이며 테스트 실행(결과 확인 포함)은 그 많은 활동 중 하나일 뿐이다. 테스트 프로세스는 테스트 계획, 분석, 설계, 테스트 구현, 테스트 진행 상황 및 결과 보고, 테스트 대상 품질 평가 등 많은 활동을 포함한다.

 

테스팅 활동에는 테스트 대상 컴포넌트나 시스템을 실행하는 것도 있다. 이런 테스팅을 동적 테스팅이라 부른다. 반면 테스트 대상 컴포넌트나 시스템을 실행하지 않는 테스팅도 있다. 이런 테스팅은 정적 테스팅이라 부른다. 따라서 요구사항, 사용자 스토리, 소스 코드와 같은 작업 산출물에 대한 리뷰 역시 테스팅에 포함된다.

 

테스팅의 일반적인 목적

일반적인 프로젝트에서 테스팅은 다음과 같은 목적을 가질 수 있다.

• 결함 예방
• 요구사항 충족 검증
• 완성 여부 확인 및 기대치 대로 동작하는지 확인
• 품질 수준에 대한 자신감 획득
• 장애 및 결함 발견
• 품질 수준을 결정하는 데 필요한 정보 제공
• 계약/법률/규제/요구사항과 표준을 준수하는지 확인

테스팅의 목적은 테스트하고 있는 컴포넌트나 시스템의 정황 즉, 현재의 테스트 레벨과 사용하는 소프트웨어 개발 수명주기 모델 등에 따라 달라질 수 있다.

 

테스팅과 디버깅

테스팅

• SW 결함으로 인한 장애 찾기.
• 동적 테스팅을 통해 장애의 발생을 보여줄 수 있음
• 테스팅은 결함 원인 식별 x
• 직접적인 예방 x 단지 결함의 존재를 찾는 것

디버깅

• 장애의 원인을 찾고 분석하여 수정하여 결함 제거
• 디버깅은 결점의 원인이 되는 결함을 제거하는 활동

 

---

 

테스팅이 왜 필요한가?

 

성공을 위한 테스팅의 기여

테스터를 최종 작업 후가 아닌 요구 사항 리뷰 혹은 스토리 개선 등 앞 단계에서부터 참여시킨다면 해당 작업 산출물에서 결함을 발견할 수 있으며 잘못된 혹은 테스트할 수 없는 기능이 개발되는 리스크를 줄일 수 있다.

 

시스템을 설계하는 동안 테스터가 시스템 설계자와 적극적으로 협업할 경우, 설계와 그것을 어떻게 테스트해야 하는지에 대해 서로 좀 더 깊이 있게 이해하게 된다. 이렇게 이해도가 올라가면 기능 설계에 결함이 유입되는 리스크가 줄어들게 되고, 필요한 테스트를 좀 더 일찍 식별할 수 있다.

 

코드를 개발하는 동안 테스터가 개발자와 적극적으로 협업할 경우, 코드와 그것을 어떻게 테스트해야 하는지에 대해 서로 좀 더 깊이 있게 이해하게 된다. 이렇게 이해도가 높아지면 코드와 테스트에서의 결함 발생 리스크가 줄어든다.

 

테스터가 릴리스 전에 소프트웨어를 확인하고 검증하면, 그러지 않았을 경우 놓쳤을 수 있는 장애를 발견하고 그 장애의 원인인 결함을 제거(즉, 디버깅)하는 데 도움을 줄 수 있다. 이렇게 함으로써 소프트웨어가 이해관계자의 필요와 요구사항을 충족시킬 가능성을 높일 수 있다.

 

품질 보증과 테스팅

품질 보증과 테스팅은 다르지만 포괄적인 개념인 품질 관리에 속한다. 품질 관리는 품질 보증과 품질 제어를 포함한 여러 가지 활동을 포함한다.

 

QA (품질보증)

• 적절한 품질을 달성했는지 확신을 얻기 위해 프로세스를 준수하도록 하는 것에 초점을 둠
• 조직이 표준을 준수했는가?

테스팅 (품질제어)

• 품질 목표 달성에 기여.
• sw의 개발 및 유지보수 프로세스의 일부
• 품질 저하 리스크 수준을 낮춰줌

 

오류, 결함, 장애

오류 : 결함을 발생시키는 실수

결함 : 코드 또는 작업 산물의 결점이나 버그

장애 : 결함 실행 및 환경 조건(방사능, 오염등의 HW 변화)으로 인해 발생하는 눈에 확연히 띄는 문제

 

 

대표적인 오류 발생 원인은 다음과 같다:

• 시간적인 압박
• 사람의 단순한 실수
• 경험이 적거나 기술이 부족한 프로젝트 참여자
• 요구사항과 설계 등에 대한 프로젝트 참여자 간의 의사소통 문제
• 코드, 설계, 아키텍처의 복잡성, 해결해야 하는 근본 문제, 사용하는 기술의 복잡도
• 시스템 내/외부 인터페이스에 대한 이해 부족, 특히 내/외부 인터페이스 수가 많은 경우
• 새롭고 익숙하지 않은 기술

 

결함, 근본 원인, 결과

단 한 줄의 잘못된 코드로 인한 이자 지급 오류는 소비자 불만을 초래한다.

 

근본 원인 : 해당 결함을 만들어낸 최초의 행동이나 조건. 결함을 분석하여 찾기 가능

결과 : 소비자의 불만

장애 : 잘못된 이자 지급

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

최초 결함 : 사용자 스토리의 모호성

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

 

---

 

테스팅의 7가지 원리

• 테스팅은 결함이 존재함을 밝히는 활동이지, 결함이 없음을 밝히는 활동이 아니다.
• 완벽한 테스팅은 불가능하다.
• 조기 테스팅으로 시간과 비용을 절약할 수 있다.
• 결함은 집중된다.
• 살충제 패러독스에 유의하라
• 테스팅은 정황에 의존적이다.
• 오류 부재는 궤변이다. : 충분히 오류를 수정해도 충족시키지 못할 수 있음

 

---

 

테스트 프로세스 Test Process

 

정황에 따른 테스트 프로세스

조직의 테스트 프로세스에 영향을 줄 수 있는 정황 요소

• SW 개발 수명주기 모델과 프로젝트 방법론
• 테스트 레벨과 테스트 유형
• 제품 및 프로젝트 리스크
• 비즈니스 도메인
• 운영상의 제약사항(예산, 일정, 복잡도, 계약 및 규제 요구사항)
• 운영 정책과 프랙티스
• 준수해야 하는 내부 및 외부 표준

조직 테스트 프로세스의 일반적인 요소

• 테스트 활동과 작업
• 테스트 작업 산출물
• 테스트 베이시스(요구사항을 내포하는 모든 문서)와 테스트 작업 산출물 간의 추적성

 

테스트 활동과 작업

용어	정의	주요활동
테스트 계획	테스트 계획서의 수립 또는 수정 활동 (계획서 : 테스트 활동 조정에 사용되며 ,달성할 목표와 방법 일정을 설명하는 문서)	적합한 테스트 기법과 작업 명시 정해진 출시 일정 전에 완료하기 위한 테스트 일정 수립
테스트 모니터링과 제어	테스트 모니터링 : 테스트 계획에 정의된 테스트 모니터링 메트릭을 활용해 실제 진행 상황을 계획한 진척 상황과 지속적으로 비교하는 활동 테스트 제어 : 시간이 지나면서 업데이트될 수 있는 테스트 계획의 목적 달성을 위해 필요한 행동을 취하는 활동	종료 조건 평가 명시된 커버리지 조건 대비 테스트 결과와 로그 확인 테스트 결과와 로그를 기반으로 컴포넌트나 시스템의 품질 수준 평가하여 추가 테스트 필요 여부 결정
테스트 분석	무엇을 테스트할 것인가? :  테스트 컨디션을 기반으로 상위 수준 테스트 케이스,  상위 수준 테스트 케이스 세트,  기타 테스트웨어를 생성한다.	적합한 테스트 베이시스 평가 테스트 베이시스와 테스트 항목을 평가해서 다양한 형태의 결함 식별 테스트할 기능과 기능 세트 식별 테스트 컨디션의 정의 및 우선순위 선정 테스트 베이시스의 개별 요소와 연관된 테스트 컨디션 간의 양방향 추적성 포착
테스트 설계	어떻게 테스트할 것인가? :  테스트 설계에서 테스트 컨디션을 기반으로 상위 수준 테스트 케이스,  상위 수준 테스트 케이스 세트,  기타 테스트웨어 생성한다.	테스트 케이스와 테스트 케이스 세트 설계 및 우선순위 선정 테스트 컨디션과 테스트 케이스에 필요한 테스트 데이터 식별 테스트 환경 설계와 필요한 인프라 및 도구 식별
테스트 구현	테스트를 실행하기 위해 필요한 모든 것이 갖춰져 있는가? :  테스트 실행에 필요한 테스트웨어를 생성하고 완성하며, 테스트 케이스를 배치하여 테스트 프로시저를 만듬	테스트 프로시저의 개발과 우선순위 선정, 가능하다면 자동 테스트 스크립트 생성 테스트 프로시저와 자동 테스트 스크립트로부터 테스트 스위트 생성 효과적인 테스트 실행이 가능하도록 테스트 스위트를 테스트 실행 일정 내에 배치 테스트 환경 구축, 가능하다면 테스트 하네스, 서비스 가상 현실화, 시뮬레이터, 기타 인프라 항목까지, 또 필요한 모든 사항을 제대로 구현했는지 확인 테스트 데이터를 준비하고, 테스트 환경에 제대로 입력했는지 확인 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 스위트 서로간의 양방향 추적성 검증과 업데이트
테스트 실행	테스트 스위트를 테스트 실행 일정에 따라 실행한다.	테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등의 고유번호(ID)와 버전 기록 등 테스트를 수동으로 혹은 테스트 실행 도구를 활용해서 실행 기대 결과와 실제 결과 비교 이상현상을 분석해 원인 파악 관찰 장애를 기반으로 결함 보고 이상 형상 때문에 취한 활동의 결과로 인해 또는 계획된 테스팅의 일부로 테스트 활동 반복(ex. 수정된 테스트 실행, 확인테스팅,리그레션 테스팅등) 테스트 베이시스, 테스트 컨디션, 테스트 케이스, 테스트 프로시저, 테스트 결과 간의 양방향 추적성 검증과 업데이트
테스트 완료	완료한 테스트 활동에서 데이터를 수집해서 경험, 테스트웨어, 기타 관련 정보를 축적하는 활동	모든 결함 보고 처리를 완료했는지, 테스트 실행 후 해결되지 않은 모든 결함에 대해 수정 요청서 또는 프로젝트 백로그 항목을 생성했는지 확인하여 이해관계자에게 전달할 테스트 요약 보고서 생성 차후 재사용을 위해 테스트 환경, 테스트 인프라, 기타 테스트웨어의 마무리 및 보관 테스트웨어를 유지보수팀, 다른 프로젝트팀, 그것을 활용할 수 있는 기타 이해관계자 등에게 인계 완료한 테스트 활동을 통해 얻은 교훈을 분석해서 향후 반복주기, 릴리스, 또는 프로젝트를 위해 수정해야 하는 사항 판단 테스트 프로세스 성숙도 개선을 위해 수집된 정보 활용

 

테스트 작업 산출물

용어	산출물
테스트 계획	하나 이상의 테스트 계획(테스트 베이시스에 대한 정보 포함)
테스트 모니터링과 제어	테스트 요약 보고서와 같은 여러 형태의 테스트 보고서 산출물은 작업완료, 리소스 할당과 사용, 공수등과 같이 프로젝트 관리에서 관심을 가지는 사항에 대해서도 다뤄야 함.
테스트 분석	분석을 통해 식별되고 우선순위가 선정된 테스트 컨디션은 테스트 분석 작업 산출물 이상적으로는 각 테스트 컨디션과 그것이 커버하는 테스트 베이시스 요소와의 양방향 추적성이 성립 되어야함. 탐색적 테스팅에서는 테스트 분석 중 테스트 차터를 생성할 수 있음. 테스트 베이시스의 결함을 발견 보고 가능.
테스트 설계	테스트 케이스와 테스트 케이스 세트
테스트 구현	테스트 프로시저와 이 프로시저의 배열. 테스트 스위트 테스트 실행 일정
테스트 실행	개별 테스트 케이스나 테스트 프로시저의 상태에 대한 문서
테스트 완료	테스트 요약 보고서 차후 프로젝트나 반복주기의 개선을 위한 액션 아치템 수정요청서 혹은 제품 백로그 항목 완성된 테스트웨어 등

 

테스트 베이시스와 테스트 작업 산출물 간의 추적성

장점

• 수정으로 인한 영향 평가를 가능하게 한다.
• 테스팅에 대한 감사를 가능하게 한다.
• IT 통제 조건을 충족할 수 있게 한다.
• 테스트 베이시스 개별 요소의 상태에 대한 정보를 포함함으로써 테스트 진행 상황 보고서와 테스트 요약 보고서를 좀 더 쉽게 이해할 수 있게 한다.
• 테스팅의 기술적인 내용을 관계자가 이해할 수 있는 형태로 전달한다.
• 제품 품질, 프로세스 역량, 프로젝트 진행 상황 등의 정보를 제공한다.

 

---

 

테스팅의 심리학

 

인간 심리학과 테스팅

요구사항 리뷰나 사용자 스토리 개선 세션에서 결함을 식별하거나 동적 테스트 실행 중 장애를 발견하는 것은 테스트 대상 제품과 제작자에 대한 비판으로 오해받을 소지가 있다.

 

예를 들어, 개발자는 자신의 코드가 옳다고 생각하기 때문에 코드가 잘못됐다는 사실을 받아들이기 힘들게 하는 확증 편향을 가지고 있다. 또한, 나쁜 소식을 전달하는 사람을 탓하는 것은 인간이 가지고 있는 기본 성향 중 하나인데 테스팅으로 얻은 정보는 나쁜 소식을 포함하고 있는 경우가 많다.

 

테스터와 테스트 관리자는 결함, 장애, 테스트 결과, 테스트 진행 상황, 리스크 등을 효과적으로 전달하기 위해, 또는 동료와 긍정적인 관계를 구축하기 위해 좋은 대인 관계 기술을 가질 필요가 있다. 다음은 의사소통을 더 잘할 수 있는 방법에 대한 예제이다:

• 다툼보다는 협력으로 시작하라
• 테스팅의 이점을 강조하라
• 테스트 결과와 발견 사항을 중립적 사실에 기반으로 전달해야 한다.
• 상대방이 부정적으로 반응하는 이유가 뭔지를 이해하려고 해야 한다.
• 상대방이 한 말을 이해했는지 확인해야 한다.

 

테스터와 개발자의 사고방식

개발자와 테스터는 생각하는 방식이 다른 경우가 많다. 개발의 일차적인 목표는 제품을 설계하고 구축하는 것이며 테스팅의 목적은 제품에 대한 확인과 검증, 릴리스 전 결함 발견 등 다양하다.

이처럼 목적이 다르기 때문에 필요한 사고방식도 다르다. 이런 사고방식을 적절히 조합해서 사용하면 더 높은 수준의 제품 품질을 달성할 수 있다.

 

테스터 : 호기심, 전문적인 비평, 비판적 시각, 세밀한 것에 주목하는 태도, 긍정적인 의사소통 관계 수립

 

개발자 : 개발자들은 종종 어떤 부분이 잘못될 수 있다는 생각보다는 제품/서비스를 설계하고 구축하는 것에 더 관심이 있다.