테스팅의 목적
- 요구사항, 사용자 스토리, 설계, 소스 코드 등과 같은 작업 산출물 평가에 의한 결함 예방
- 명시된 모든 요구사항이 충족됐는지 검증
- 테스트 대상의 완성 여부 확인과 사용자와 기타 이해관계자의 기대치 대로 동작하는지의 확인
- 테스트 대상의 품질 수준에 대한 자신감 획득
- 부적절한 소프트웨어 품질의 리스크 레벨 감소로 장애와 결함을 발견
- 이해관계자가 테스트 대상의 품질 수준을 결정하는 데 필요한 충분한 정보 제공
- 계약 / 법률 / 규제 요구사항이나 표준의 준수 및 테스트 대상이 이러한 요구사항이나 표준을 준수하는지 확인
테스트 활동과 작업
- 테스트 계획
- 테스트 모니터링과 제어
- 테스트 분석
- 테스트 설계
- 테스트 구현
- 테스트 실행
- 테스트 완료
테스트 베이시스와 테스트 작업 산출물 간의 추적성의 장점
- 수정으로 인한 영향 평가를 가능하게 한다.
- 테스팅에 대한 감사를 가능하게 한다.
- IT 통제조건을 충족할 수 있게 한다.
- 테스트 베이시스 개별 요소의 상태에 대한 정보를 포함함으로써 테스트 진행 상황 보고서와 테스트 요약 보고서를 좀 더 쉽게 이해할 수 있게 한다.
- 테스팅의 기술적인 내용을 이해관계자가 이해할 수 있는 형태로 전달한다.
- 비즈니스 목표 대비 제품 품질, 프로세스 역량, 프로젝트 진행 상황 등을 평가할 수 있는 정보를 제공한다.
반복적 개발의 예
- 래셔널 통합 프로세스 : 각 반복주기가 상당히 긴 경우가 많으며 따라서 기능 증분도 상당히 큼
- 스크럼 : 각 반복주기가 짧은 성향을 가지며 따라서 기능 증분도 작음
- 칸반 : 반복주기 기간이 고정된 경우와 고정되지 않은 경우가 있으며, 각 반복주기는 완료 후 하나의 개선 사항이나 기능을 전달하거나 몇 개의 기능을 묶어 한 번에 전달할 수도 있음
- 나선형 : 실험적인 증분을 생성, 일부는 차후 개발 과정에서 상당 부분 수정되거나 심한 경우 폐기되기도 함
유지보수가 필요한 상황
- 개선을 위한 변경, 계획된 확장, 수정 혹은 긴급 변경, 운영 환경 변경, 상용 소프트웨어 업그레이드, 결함 및 취약성을 위한 패치 등
- 이관을 위한 변경, 하나의 플랫폼에서 다른 플랫폼으로 이관할 때, 변경된 소프트웨어뿐만 아니라 신규 환경에 대한 운영 테스트가 필요할 수 있거나 또는 유지보수하고 있는 시스템에 이관하는 다른 애플리케이션의 데이터를 위한 데이터 전환 테스트 등
- 단종, 애플리케이션의 수명이 다할 때 등, 애플리케이션이나 시스템이 단종될 때 데이터 이관이나 장시간의 데이터 유지가 필요하면 보관처리에 대한 테스팅이 필요할 수 있다.
- 장시간의 보관이 필요한 경우 차후 복원/회수 절차에 대한 테스팅이 필요할 수 있다.
- 여전히 서비스하고 있는 기능이 있다면, 해당 기능이 정상 동작할거라는 확신을 얻기 위한 리그레션 테스팅이 필요할 수 있다.
정적 테스팅으로 검토할 수 있는 작업 산출물
- 비즈니스 요구사항, 기능 요구사항, 보안 요구사항과 같은 명세
- 에픽, 사용자 스토리, 인수 기준
- 아키텍처 및 설계 명세
- 코드
- 테스트 계획, 테스트 케이스, 테스트 프로시저, 자동화 테스트 스크립트와 같은 테스트웨어
- 사용자 가이드
- 웹 페이지
- 계약, 프로젝트 계획, 일정, 예산 기획
- 형상 및 인프라 셋업
- 액티비티 다이어그램과 같은 모델 기반 테스팅에 사용되는 모델
동적 테스팅에 비해 쉽고 비용도 적은 정적 테스팅의 일반적 결함 유형
- 요구사항 결함 (ex. 불일치, 모호함, 모순, 누락, 부정확, 중복 등)
- 설계 결함 (ex. 비효율적인 알고리즘이나 데이터베이스 구조, 높은 결합도, 낮은 응집도 등)
- 코딩 결함 (ex. 정의되지 않은 값이 있는 변수, 선언했으나 사용하지 않는 변수, 도달할 수 없는 코드, 중복 코드 등)
- 표준과의 차이 (ex. 코딩 표준 미준수 등)
- 잘못된 인타페이스 명세 (ex. 호출하는 시스템과 호출되는 시스템이 서로 다른 측정 단위 사용)
- 보안 취약점 (ex. 버퍼 오버플로우에 대한 취약성)
- 테스트 베이시스 추적성이나 불충분한 커버리지 또는 부정확성 (ex. 특정 인수 조건에 대한 테스트 누락)
리뷰의 단계
- 계획
- 리뷰 착수
- 개별 리뷰
- 이슈 논의 및 분석
- 수정 및 보고
공식 리뷰에서의 역할
- 저자
- 관리자
- 촉진자
- 리뷰 리더
- 검토자
- 서기
리뷰 유형
- 비공식 리뷰 : 잠재적 결함 발견
- 워크쓰루 : 결함 발견, 소프트웨어 제품 개선, 다른 구현 방법 고려, 표준이나 규정 준수 평가
- 기술 리뷰 : 합의 도출, 잠재적 결함 발견
- 인스펙션 : 잠재적 결함 발견, 작업 산출물의 품질 평가 및 자신감 획득, 저자 학습과 근본 원인 분석을 통한 유사 결함의 발생 예방
리뷰 기법 적용
1. 애드혹 : 검토자에게 리뷰 수행 방법에 대한 안내가 거의 또는 전혀 제공되지 않고 검토자는 대부분의 경우 작업 산출물을 순차적으로 읽으면서 이슈를 식별하고 기록한다. 애드혹 리뷰는 특별한 준비 없이 일반적으로 사용되는 기법이다. 이 기법은 검토자의 능력에 크게 의존하며, 여러 검토자가 동일한 문제를 보고할 수 있다.
2. 체크리스트 기반 : 검토자는 리뷰 시작 시점에 배포된 체크리스트를 기반으로 이슈를 식별한다. 리뷰 체크리스트는 잠재 결함을 식별하기 위해 경험에서 도출한 일련의 질문으로 구성된다. 체크리스트는 리뷰 대상 작업 산출물 유형별로 작성해야 하며 이전 리뷰에서 누락된 이슈 유형을 다루기 위해 주기적으로 개선할 필요가 있다. 체크리스트 기반 기법의 주요 장점은 일반적인 결함 유형에 대한 체계적인 커버리지를 갖는다는 점이다. 개별 리뷰를 수행할 때 검토자는 체크리스트를 단순히 실행하는 것 뿐만 아니라, 체크리스트로 식별할 수 없는 결함도 찾기 위해 특별한 주의를 기울여야 한다.
3. 시나리오 및 드라이 런 : 시나리오 기반 리뷰에서 검토자는 작업 산출물을 어떻게 검토할지에 대한 구조화된 지침을 제공받는다. 시나리오 기반 리뷰는 작업 산출물의 예상되는 용도를 기반으로 작업 산출물에 대해 드라이런을 수행할 수 있도록 검토자를 지원한다. 이러한 시나리오는 검토자에게 단순한 체크리스트 항목보다 특정 결함 유형을 식별하는 방법에 대한 좀 더 나은 지침을 제공한다. 체크리스트 기반 리뷰와 마찬가지로, 다른 결함 유형을 발견하기 위해 검토자는 기록된 시나리오에만 너무 얽매이지 않아야 한다.
4. 관점 기반 : 관점 기반 읽기)는 역할 기반 리뷰와 마찬가지로 검토자가 개별 리뷰 중 다양한 이해관계자의 관점을 사용하게 된다. 일반적으로 사용되는 이해관계자 관점에는 최종 사용자, 영업, 설계자, 테스터, 운영자 등이 있다. 서로 다른 이해관계자 관점을 사용하면, 검토자 간에 중복되는 이슈가 줄어들고 개별리뷰가 좀 더 깊이 있게 진행된다. 또한, 관점 기반 읽기에서는 검토자가 리뷰 대상 작업 산출물로부터 이해관계자의 관점을 기반으로 하는 산출물을 작성해야 한다. 예를 들어, 테스터가 필요한 모든 정보가 존재하는지 확인하기 위해 요구사항 명세에 대한 관점 기반 읽기를 수행하면서 인수 테스트 초안을 작성을 시도할 수 있다. 또한 관점 기반 읽기에서는 체크리스트도 활용한다.
5. 역할 기반 : 역할 기반 리뷰는 검토자가 작업 산출물을 개별 이해관계자 역할의 관점에서 평가하는 기법이다. 일반적인 역할에는 특정 최종 사용자 유형(경험 많은, 경험 적은, 노인, 아동 등)과 조직 내 특정 역할(사용자 관리자, 시스템 관리자, 성능 테스터 등)이 있다. 역할이 비슷하기 때문에 같은 원칙이 관점 기반 읽기에도 적용된다.
'테스팅' 카테고리의 다른 글
| ISTQB CTFL 실라바스2 (0) | 2024.03.22 |
|---|---|
| 애플리케이션 테스트 관리 (2) | 2024.03.22 |