목적

---

본 글은 ISTQB 자격증 취득 시험을 목적으로 학습한 내용을 기록하였습니다.

내용

---

1.1 테스팅이란 무엇인가?

1.1.1 테스팅의 일반적인 목적

1. 요구사항, 사용자 스토리, 설계 소스코드 등과 같은 작업 산출물 에 의한 결함 예방.
2. 명시된 모든 요구사항이 충족되었는지 검증.
3. 테스트 대상의 완성 여부 확인과 사용자와 기타 이해관계자의 기대치대로 동작하는지 확인.
4. 테스트 대상의 품질 수준에 대한 자신감 획득
5. 부적절한 소프트웨어 품질의 리스크 레벨 감소로 장애와 결함을 발견.
6. 이해관계자가 테스트 대상의 품질 수준을 결정하는 데 필요한 충분한 정보 제공
7. 계약/법률/규제 요구사항이나 표준의 준수 및 테스트 대상이 이러한 요구사항이나 표준을 준수하는지 확인.

• 테스팅 목적은 정황에 따라 달라질 수 있다.
  • 컴포넌트 테스팅의 목적
    1) 내재되어 있는 결함을 최대한 조기에 가능한 많이 식별하고 수정.
    2) 코드 커버리지 ⬆
  • 인수 테스팅의 목적
    1) 시스템이 기대한 대로 동작하는지, 요구사항을 충족하는지 확인
    2) 특정 시점에 시스템을 배포하는 것에 대한 리스크 정보를 이해관계자에게 제공

1.1.2 테스팅과 디버깅을 구분하기

💡 테스팅

: 소프트웨어 결함으로 인한 장애를 찾아낼 수 있음.

💡 디버깅

: 장애의 원인을 찾고 분석해서 수정 하는 개발 활동.

1.2 테스팅이 왜 필요한가?

1.2.1 테스팅이 필요한 이유

1. 운영 중 장애 발생 가능성을 줄이기 위해
2. 계약/법적 요구사항이나 특정 산업 표준을 만족시키기 위해
3. 컴포넌트나 시스템의 품질에 기여하기 위해

1.2.2 품질 보증과 테스팅의 관계 설명 및 높은 품질 확보를 위한 테스팅 기여 방식에 대해 설명하기

💡 품질 보증

• 적적한 품질 수준을 달성했는지 확신을 얻기 위해 적절한 프로세스를 준수하도록 하는 것에 집중.
• 프로세스를 바탕으로 생성되는 작업 산출물의 품질은 높은 경우가 많으며, 높은 작업 산출물 품질은 결함 예방에 도움이 됨.
• 근본 원인 분석과 회고 회의의 결과로 프로세스를 개선하는 것은 효과적인 품질 보증에 매우 중요한 사항.

💡 테스팅

• 품질 요구사항을 준수하는 데 중점을 둔 운영상의 기술과 활동인 품질 제어에 포함되는 활동.
• 테스트 활동은 여러 가지 품질 제어 활동 중 하나로 전반적인 소프트웨어 개발 및 유지보수 프로세스에 포함됨.

💡 높은 품질 확보를 위한 테스팅 기여 방식

1. 결함을 발견하고 수정하는 것은 컴포넌트나 시스템 품질에 기여
2. 요구사항 리뷰 or 사용자 스토리 개선에서 결함 식별 및 제거
3. 시스템을 설계하는 동안 테스터가 시스템 설계자와 적극적으로 협업할 경우, 설계와 그것을 어떻게 테스트해야 하는지에 대해 서로 좀 더 깊게 이해할 수 있음.
4. 코드를 개발하는 동안 테스터가 개발자와 적극적으로 협업할 경우, 코드와 그것을 어떻게 테스트해야 하는지에 대해 서로 좀 더 깊이 있게 이해하게 됨.
5. 테스터가 릴리즈 전에 소프트웨어를 확인하고 검증하면 장애 발견 및 결함 제거를 지원할 수 있음.

1.2.3 오류, 결함, 장애를 구별하기

💡 오류

• 만드는 사람의 실수로 인해 발생.
• 오류 발생 원인은 약 7가지가 있음.
  1) 시간적인 압박
  2) 사람의 실수
  3) 경험 및 기술이 부족한 프로젝트 참여자
  4) 요구사항과 설계 등에 대한 프로젝트 참여자 간의 의사소통 문제
  5) 코드, 설계, 아키텍처의 복잡성, 해결해야 하는 근본 문제, 사용 기술의 복잡도
  6) 시스템 내/외부 인터페이스에 대한 이해 부족
  7) 새롭고 익숙하지 않은 기술

💡 결함

• 명세, 모델, 코드 등의 요인으로 인해 발생.
• 코드의 결함이 실행되면 장애를 일으킬 수 있지만 반드시 그런 것은 아님.

💡 장애

• 환경, 사용자, 제품 등의 환경적 요인으로 인해 발생.
• 테스트 결과가 기대한 것과 다르다고 해서 무조건 장애가 있다고 볼 수는 없음. (거짓 양성 or 거짓 음성일 수도 있음.)

1.2.4 결함의 근본 원인과 발생 영향을 구별하기

💡 결함의 근본 원인과 결과

• 해당 결함을 만들어낸 최초의 행동, 조건을 말함.
• 이 근본 원인을 기반으로 이루어지는 프로세스 개선은 이후 발생하는 결함 수를 상당 부분 줄여줌.

1.3 테스팅의 7가지 원리

1.3.1 테스팅의 7가지 원리 설명하기

1. 테스팅은 결함이 존재함을 밝히는 활동이지, 결함이 없음을 밝히는 활동이 아님.
2. 완벽한 테스팅은 불가능함.
3. 조기 테스팅 으로 시간과 비용을 절약할 수 있음.
4. 결함은 집중됨. 즉, 결함이 특정 부분에 집중되어 발생한다는 의미임.
5. 살충제 패러독스 에 유의하라. 즉, 새로운 결함을 발견하기 위해서는 기존 테스트와 테스트 데이터를 바꾸고 새로운 테스트를 작성할 필요가 있음.
6. 테스팅은 정황에 의존적임.
7. 오류 부재는 궤변임. 즉, 모든 가능한 테스트를 실행하고 존재하는 모든 결함을 발견하는 것은 사실상 불가능하다는 의미.

1.4 테스트 프로세스

1.4.1 정황이 테스트 프로세스에 미치는 영향

• 테스트 프로세스 전반에 걸쳐 테스트를 계획, 설계, 실행 및 관리하는 데 필수적인 정보를 제공

1.4.2 테스트 프로세스의 테스트 활동과 연관된 작업에 대해 설명하기

💡 테스트 계획

• 테스팅의 목적, 정황으로 인한 제약 사항을 고려해 테스트 목적을 달성하기 위해 필요한 접근법을 정의하는 활동.
  • 적합한 테스트 기법과 작업
  • 정해진 출시 일정 전에 완료하기 위한 테스트 일정 수립.
• 테스트 계획은 모니터링과 제어활동의 피드백을 기반으로 수정될 수 있음.
  • 테스트 계획은 시간이 지나면서 업데이트 될 수 있음.

💡 테스트 모니터링과 제어

테스트 모니터링 : 테스트 계획에 정의된 테스트 모니터링 매트릭을 활용해 실제 진행상황을 테스트 계획과 지속적으로 비교하는 활동.
테스트 제어 : 테스트 계획의 목적 달성을 위해 필요한 행동을 수행하는 것.

💡 테스트 분석

• 테스트 베이시스를 분석하여 테스트 컨디션을 식별 하는 활동.
  • 무엇을 테스트할지를 결정하는 것.
• 테스트 베이시스 평가
• 테스트 베이시스와 테스트 항목을 평가해서 결함 식별
• 테스트 할 기능과 기능 세트 식별
• 테스트 컨디션의 정의 및 우선순위 선정
• 테스트 베이시스의 개별 요소와 연관된 테스트 컨디션 간의 양방향 추적성 포착

💡 테스트 설계

• 테스트 컨디션을 기반으로 상위 수준 테스트 케이스, 상위 수준 테스트 케이스 세트, 기타 테스트 웨어를 생성.
• 테스트 케이스와 테스트 케이스 세트 설계 및 우선순위 설정
• 테스트 컨디션과 테스트 케이스에 필요한 테스트 데이터 식별
• 테스트 환경 설계와 필요한 인프라 및 도구 식별
• 테스트 베이시스, 테스트 컨디션, 테스트 케이스 간의 양방향 추적성 설정

💡 테스트 구현

• 테스트를 실행하기 위해 필요한 모든 것이 갖춰져 있는가?에 대해 답하는 활동.
• 테스트 프로시저의 개발과 우선순위 선정, 자동 테스트 스크립트 생성

💡 테스트 실행

• 테스트 항목, 테스트 대상, 테스트 도구, 테스트웨어 등의 고유번호(ID)와 버전 기록
• 테스트를 수동으로 혹은 테스트 실행 도구를 활용해서 실행
• 기대결과와 실제 결과 비교
• 이상 현상을 분석해 원인 파악

💡 테스트 완료

• 완료한 테스트 활동에서 데이터를 수집해서 경험, 테스트웨어, 기타 관련 정보를 축척하는 행동.
• 모든 결함 보고 처리를 완료했는지, 테스트 실행 후 해결되지 않은 모든 결함에 대해 수정 요청서 또는 프로젝트 백로그 항목을 생성했는지 확인.

1.4.3 테스트 프로세스를 지원하는 작업 산출물 구별하기

💡 프로세스: 테스트 계획

• 산출물 : 하나 이상의 테스트 계획

💡 프로세스: 테스트 모니터링과 제어

• 산출물 : 테스트 진행 현황 보고서, 테스트 요약 보고서 등

💡 프로세스: 테스트 분석

• 산출물 : 테스트 컨디션, 테스트 차터

💡 프로세스: 테스트 설계

• 산출물 : (상위 수준) 테스트 케이스, 테스트 케이스 세트, 테스트 데이터, 테스트 환경 요구사항

💡 프로세스: 테스트 구현

• 산출물 : 테스트 프로시저 및 프로시저 배열, 테스트 스위트, 테스트 실행 일정, 테스트 도구 및 도구로 생성되는 작업 산출물

💡 프로세스: 테스트 실행

• 산출물 : 개별 테스트 케이스 or 테스트 프로시저 상태에 대한 문서, 결함 보고서, 테스팅에 사용한 테스트 항목, 대상, 도구, 테스트웨어 등에 대한 문서

💡 프로세스: 테스트 완료

• 산출물 : 테스트 요약 보고서, 차후 프로젝트 반복주기 개선을 위한 액션 아이템, 수정 요청서 or 제품 백로그 항목, 완성된 테스트웨어

1.4.4 테스트 베이시스와 테스트 작업 산출물 간의 추적성을 유지하는 것이 어떻게 도움되는지 설명하기

1. 수정으로 인한 영향 평가 가능
2. 테스팅에 대한 검사 가능
3. IT 통제 조건을 충족할 수 있게 함.
4. 테스트 베이시스 개별 요소의 상태에 대한 정보를 포함함으로써 테스트 진행상황 보고서와 테스트 요약 보고서를 좀 더 쉽게 이해할 수 있음
5. 테스팅의 기술적인 내용을 이해관계자가 이해할 수 있는 형태로 전달
6. 비즈니스 목표 대비 제품 품질, 프로세스 역량, 프로젝트 진행 상황 등을 평가할 수 있는 정보 제공
7. 테스트 커버리지 평가

1.5 테스팅의 심리학

1.5.1 테스팅의 성공에 영향을 주는 심리 요인 식별하기

1. 다툼보다는 협력으로 시작
   • 더 나은 품질의 시스템을 개발한다는 공통 목표를 모두 함께 인식
2. 테스팅의 이점을 강조
3. 테스트 결과와 기타 발견 사항을 중립적이면서 사실에 기반을 둔 방법으로 전달
   • 사람을 비판 X
4. 상대방이 어떤 느낌을 받을지, 또 해당 정보에 대해 부정적으로 반응하는 이유가 뭔지를 이해하려고 노력
5. 상대방이 전달받은 내용을 이해했는지, 또 반대로 상대방이 하고자 하는 말을 제대로 이해했는지 확인

1.5.2 테스트 활동에 필요한 사고방식과 개발 활동에 필요한 사고방식을 구별하기

💡 테스트 활동에 필요한 사고방식

1. 테스팅의 목적은 제품에 대한 Validation, Verification, Release 전 결함 발견 등 매우 다양함.
2. 호기심, 전문적 비평 능력, 비판적 시각, 세밀한 것에 주목하는 태도, 긍정적 의사소통과 관계 수립에 대한 동기 등의 사고방식 필요
3. 독립적인 테스터는 저자와는 다른 확증 편향을 가지기 때문에 작업 산출물 작성자와는 다른 관점으로 결함 발견 효과를 높일 수 있음.

💡 개발자 활동에 필요한 사고방식

1. 개발의 일차적인 목표는 제품을 설계 하고 구축 하는 것.
2. 성공적인 개발자는 해결책을 설계하고 구축하는 데 뿐만 아니라 그런 해결책에 무슨 문제가 있는지에 대해서도 관심을 가져야함.
3. 자신이 한 일에서 실수를 발견하기 힘들게 하는 확증 편향을 갖지 않도록 노력해야함.