[ISTQB] - ISTQB CTFL 취득을 위한 Syllabus 총 정리 - 1

본 포스팅은 ISTQB 공식 Syllabus와 공식 Udemy 강의를 기반으로 학습한 내용입니다.

1장

테스팅이란 무엇인가?

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

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

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

테스팅의 일반적인 목적

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

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

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

테스팅과 디버깅

테스팅

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

디버깅

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

---

테스팅이 왜 필요한가?

성공을 위한 테스팅의 기여

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

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

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

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

품질 보증과 테스팅

품질 보증과 테스팅은 다른 개념이다. 둘다 품질 관리에 속함.

품질 관리는 또한 품질 보증과 품질 제어를 포함한 여러 가지 활동을 포함한다

프로세스를 따를 경우, 해당 프로세스를 바탕으로 생성되는 작업 산출물의 품질은 더 월등한 경우가 많으며, 높은 작업 산출물 품질은 결함 예방에 도움이 된다. 또한, 결함의 원인을 찾아서 제거하기 위한 근본 원인 분석(root cause analysis)의 활용과 회고 회의(retrospective meetings)의 결과를 적절하게 적용해서프로세스를 개선하는 것은 효과적인 품질 보증에 매우 중요한 사항들이다.

QA (품질보증)

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

테스팅 (품질제어)

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

오류, 결함, 장애 (Errors, Defects, and Failures)

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

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

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

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

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

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

장애는 코드 결함뿐만 아니라 다양한 외부 환경 조건으로 인해 발생할 수도 있다.

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

결함, 근본 원인, 결과

근본 원인 : 해당 결함을 만들어낸 최초의 행동이나 조건. 결함을 분석하여 찾기 가능
결과 : 소비자의 불만
장애 : 잘못된 이자 지급
결함 : 코드에 잘못된 계산식
최초 결함 : 사용자 스토리의 모호성
근본원인 : 제품 소유자의 지식

테스팅의 7 가지 원리

1. 테스팅은 결함이 존재함을 밝히는 활동이고, 결함이 없음을 밝히는 활동이 아니다.
   1. 결함이 발견되지 않아도 완벽한 소프트웨어라는 뜻은 아니다.
2. 완벽한 테스팅은 불가능하다.
   1. 완벽히 하는 것보다는 우선순위를 만들어서 하자.
3. 조기 테스팅으로 시간과 비용을 절약할 수 있다.
4. 결함은 집중된다.
   1. 결함이 집중되는 부분을 리스트 분석을 통해 리스크를 완화하자.
5. 살충제 패러독스에 유의하라
   1. 같은 테스트를 반복 실행하면 해당 테스트로는 결함을 발견할 수 없다.
   2. 살충제를 계속 사용하다보면 면역이 생기듯이.
6. 테스팅은 정황(context)에 의존적이다.
   1. 테스트는 정황에 따라 달라진다.
   2. 테스팅은 도메인의 특성이나 범위, 법적규제등 다양한 상황에 맞게 한다.
7. 오류 부재는 궤변이다
   1. 테스터가 모든 가능한 결함을 발견하길 기대하지만, 불가능하다.
   2. 많은 결함을 발견하고 수정했다고 해서 좋은 시스템은 아니다.

테스트 프로세스

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

다음은 조직의 테스트 프로세스에 영향을 줄 수 있는 정황 요소 중 일부이다:

• 사용 중인 소프트웨어 개발 수명주기 모델과 프로젝트 방법론
• 적용하고자 하는 테스트 레벨과 테스트 유형
• 제품 및 프로젝트 리스크
• 비즈니스 도메인
• 다음과 같은 운영상의 제약사항:
  • 예산과 자원 (resource)
  • 일정
  • 복잡도
  • 계약 및 규제 요구사항
• 운영 정책과 프랙티스 (practices)
• 준수해야 하는 내부 및 외부 표준

다음 절은 아래의 관점에서 조직 테스트 프로세스의 일반적인 요소에 대해 설명하고 있다:

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

테스트 활동과 작업

테스트 프로세스

순차적으로 이루어지는 것처럼 보이지만, 반복적이고, 지속적으로 구현된다.

테스트 계획

테스트 모니터링과 제어

계획 대비 테스트 진행 상황은 이해관계자에게 테스트 진행 상황 보고서의 형태로 전달된다.

테스트 분석

• 정적 테스트를 바탕으로 한 테스트 컨디션 식별을 위한 테스트 베이시스 분석
• 요구사항이 기타 이해관계자의 요구를 만족하는지 확인

테스트 설계

• 양방향 추적성은 추후 유지보수를 할 때 등 필요하다.
• 테스트 베이시스에서 유사한 결함 확인 가능

테스트 구현

테스트 실행

• 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등의 고유번호(ID)와 버전 기록
• 테스트를 수동으로 혹은 테스트 실행 도구를 활용해서 실행
• 기대 결과와 실제 결과 비교
• 이상 현상(anomalies)을 분석해 원인 파악 (예를 들어, 장애가 코드 결함 때문에 발생할 수도 있지만 거짓양성일 수도 있다 (1.2.3 절 참조))
• 관찰한 장애를 기반으로 결함 보고 (5.6 절 참조)
• 테스트 실행 결과 기록 (예: 합격, 불합격, 실행할 수 없음)
• 이상 현상 때문에 취한 활동의 결과로 인해 또는 계획된 테스팅의 일부로 테스트 활동 반복 (예: 수정된 테스트 실행, 확인 테스팅이나 리그레션 테스팅 등)

테스트완료

이해관계자에게 테스트 요약보고서를 만들어 보고

테스트 작업 산출물

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

좋은 추적성은 테스트 커버리지에 대한 평가를 가능하게 할 뿐만 아니라 아래와 같은 장점도 제공한다:

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

테스팅의 심리학

편견을 줄이기 위해 결함과 장애에 대한 정보는 건설적인 방법으로 전달할 필요가 있다. 그렇게 함으로써 테스터와 분석가, 제품 소유자, 설계자, 개발자 간의 긴장을 완화할 수 있다. 이것은 정적, 동적 테스팅 모두에 해당한다.

개발자 vs 테스터

 

2장 ~ 5장도 노션에 정리는 해놓았으나,,,, 티스토리로 옮기면서 표가 깨지는 등 오류가 너무 많아 업로드는 포기하였습니다. 필요하신 분은 댓글 남기시면 노션 페이지로 공유해드리겠습니다.