2024-10-16 QA TIL

테스팅이란?

• 일반적인 테스트 목적을 식별할 수 있다.
  • 요구사항, 사용자 스토리, 설계, 소스 코드 등 작업 산출물 평가 
  • 장애 유발 및 결함 식별 
  • 테스트 대상에 필요한 커버리지 보장 
  • 소프트웨어 품질 부족으로 인한 리스크 수준 완화 
  • 정의된 요구사항의 충족 여부를 확인하는 베리피케이션 
  • 테스트 대상의 계약, 법률, 규제 요구사항 준수 여부를 확인하는 베리피케이션 
  • 이해관계자가 정보에 입각한 결정을 내리는데 필요한 정보 제공 
  • 테스트 대상의 품질에 대한 자신감 획득
  • 테스트 대상의 완성 여부와 이해관계자의 기대 충족 여부를 확인하는 밸리데이션
• 테스팅과 디버깅을 구별할 수 있다
  • 테스팅은 소프트웨어 결함으로 인한 장애나 결함을 직접 식별한다. 디버깅후 확인 테스팅을 다시한다.
  • 디버깅은 테스팅에서 나온 결함의 원인을 찾고 분석하고 제거 한다.
    1. 장애 재현
    2. 분석
    3. 원인 해결
• 테스팅이 필요한 이유를 예를 들어 설명할 수 있다
  • 정해진 범위, 시간, 품질, 예산 내에서 합의된 목표를 달성하는 데 도움을 준다.
  • 결함을 식별하는 비용 효율적인 방법
• 테스팅과 품질 보증의 관계를 상기할 수 있다
  • 테스팅은 품질보증에서 품질제어활동에 속하며, 적합한 품질 달성을 위해 하는 주요 활동입니다.
    테스트 결과를 통해 품질 보증과 품질 제어 모두에 사용이 되며 결함을 수정하고 품질보증의
    피드백으로 사용이 됩니다.
• 근본 원인, 오류, 결함, 장애를 구별할 수 있다
  • 오류 : 사람의 실수로 인하여 발생을 하며, 원인으로 시간적 압박, 작업 산출물의 복잡성, 프로세스, 인프라, 상호작용 등의 이유로 오류를 범할 수 있습니다.
  • 결함 : 요구사항의 명세서나 테스트 스크립트 문서, 소스 코드, 빌드 파일과 같은 지원 산출물에서 나올 수 있으며,
    수행되어야 할 부분이 안되거나 안되어야 할 부분이 수행 되는 문제를 결함으로 표기함
  • 장애 : 방사선이나 전자기장으로 인한 펌웨어 결함 때문에 발생하는 문제 처럼 환경 조건으로 발생하는 것
  • 근본 원인 : 문제 발생의 근본적인 이유를 말한다. 근본 원인 분석 및 처리 하면 유사한 장애나 결함을 예방하거나 빈도를 줄일 수 있다.
• 테스팅의 7 가지 원리를 설명할 수 있다
  1. 테스팅은 결함의 존재를 밝히는 활동이지, 결함이 없음을 증명하지는 않는다.
  2. 완벽한 테스팅은 불가능하다.
  3. 조기 테스팅으로 시간과 비용을 절약할 수 있다.
  4. 결함은 집중된다.
  5. 테스트 효과는 줄어든다.
  6. 테스팅은 정황에 의존적이다.
  7. 결함-부재는 궤변이다.
• 다양한 테스트 활동과 업무를 요약할 수 있다
  • 테스트 활동과 업무는 반복적 또는 병렬적으로 구현이 되는 경우가 많습니다.
  • 테스트 계획 : 목적을 정의 목적을 달성할 수 있도록 접근
  • 테스트 모니터링과 제어 : 지속적으로 활동을 점검, 실제상황과 비교 활동
  • 테스트 분석 : 테스트 베이시스를 분석해 테스트 가능 식별 컨디션 정의
  • 테스트 설계 : 테스트 데이터 요구사항 정의, 테스트 환경 설계, 기타 필요 인프라 설정
  • 테스트 구현 : 테스트에 필요한 테스터웨어 구비
  • 테스트 실행 : 테스트 일정에 따라 테스트를 수행하는 것
  • 테스트 완료 : 결함 요청서 또는 백로그 항목을 만들고 완료 보고서를 전달
• 정황이 테스트 프로세스에 미치는 영향을 설명할 수 있다
  • 테스트는 단독으로 수행되지 않는다. 
  • 이해관계자, 팀원, 비지니스 도메인, 기술적 요인, 프로젝트 제약 조건, 조직적 요인, 소프트웨어 개발수명주기, 도구에 영향을 미치며 이러한 요소는 테스트 전략, 적용된 테스트 기법, 테스트 자동화 수준, 필요 커버리지 수준, 테스트 문서 상세화 수준, 보고 등 많은 테스트 관련 문제에 영향을 미친다.
• 테스트 활동을 지원하는 테스트웨어를 구분할 수 있다
  • 각 테스트 별 산출물
    • 계획 작업 : 계획, 일정, 리스크, 시작, 완료 조건
    • 모니터링과 제어 작업  : 진행 상황 보고서, 제어 지침 문서, 리스크 정보
    • 분석 작업  : 컨디션, 베이시스의 결함 보고서
    • 설계 작업 : 테스트 케이스, 차터, 커버리지 항목, 데이터 요구사항, 환경 요구사항
    • 구현 작업 : 테스트 절차, 자동 테스트 스크립트, 스위트, 데이터, 실행 일정, 환경 요소, 드라이버, 시뮬레이터, 서비스 가상화
    • 실행 작업 : 테스트 로그, 결함 보고서
    • 완료 작업 : 완료 보고서, 향후 계획서, 문서 교훈, 변경 요청서
• 추적성을 유지하는 것의 가치를 설명할 수 있다
  • 좋은 추적성은 커버리지 평가 외에도 변경사항의 영향을 파악할 수 있게 하고, 테스트 감사를 용이하게 하며, It운영 및 관리 기준을 충족하는 데 도움이 된다.
  • 보고서를 더 쉽게 이해 할 수 있다.
  • 이해관계자에게 쉽게 전달 할 수 있다.
• 테스팅에 참여하는 다양한 역할을 비교할 수 있다
  • 테스트 관리 역할 : 테스트 프로세스, 책임, 모티터링, 제어, 헙업 관리에 초점
  • 테스팅 역할 : 공학적인 측면의 책임, 분석, 설계, 구형, 실행에 초점
• 테스팅에 필요한 보편적인 기술의 예를 제시할 수 있다
  • 테스팅 지식
  • 철저함, 신중함, 호기심, 주의력, 체계적인 접근
  • 우수한 의사소통, 경청, 팀플레이
  • 분석적 사고, 비판적 사고, 창의성
  • 기술 지식
  • 도메인 지식
• 전체 팀 접근법의 장점을 상기할 수 있다
  • 1. 더 높은 품질의 소프트웨어: 모든 팀원이 소프트웨어 품질에 기여하기 때문에 결함을 일찍 발견하고 수정할 수 있으며, 최종 제품의 품질이 더 좋아집니다.
    2. 커뮤니케이션 개선: 개발자, 테스터, 비즈니스 분석가 간의 협력이 강화되면 의사소통 문제가 줄어들어, 요구 사항에 대한 오해나 결함이 발생할 가능성이 낮아집니다.
    3. 문제의 조기 발견: 개발 초기 단계부터 테스트와 피드백을 주고받음으로써 더 일찍 문제를 발견할 수 있습니다. 이를 통해 수정 비용도 줄어듭니다.
    4. 책임 분담: 품질에 대한 책임이 팀 전반에 분배되어, 특정 개인이나 팀에 모든 부담이 집중되지 않습니다.
    5. 유연성과 민첩성: 팀 전체가 지속적으로 변화하는 요구사항과 문제를 해결하기 위해 협력하므로, 유연한 대응이 가능해집니다.
    이 접근법은 특히 애자일(Agile) 방법론에서 자주 사용되며, 빠른 피드백 루프와 협업을 통해 품질을 향상시키는 데 효과적입니다.
• 독립적 테스팅의 장단점을 구분할 수 있다
  • 장점 : 배경, 기술적 관점, 독립적인 테스터가 개발자와 다른 유형의 장애와 결함을 식별할 가능성이 높다.
  • 단점 : 독립적인 테스터는 개발팀과 차단되어 협업과 의사소통이 어려울 수 있으며 적대적 관계가 될 가능성이 있다.
• 전체 팀 접근법 vs 독립적 테스팅:
  • 전체 팀 접근법은 팀 전체가 품질에 기여하는 방식으로 빠른 피드백과 협력을 강조하지만, 때로는 팀 내 편향이 문제를 발견하기 어렵게 할 수 있습니다.
  • 독립적 테스팅은 보다 객관적이고 전문적인 관점에서 소프트웨어 품질을 평가할 수 있지만, 비용 및 커뮤니케이션 측면에서 단점이 존재할 수 있습니다.