테스팅이란 무엇인가?
- 테스팅은 단지 소프트웨어를 실행하고 결과를 확인하는 테스트 수행에 국한되지 않는다.
- 소프트웨어 테스팅이란, 다양한 활동을 포함하는 프로세스이며, 테스트 실행은 그 많은 활동 중 하나일 뿐이다.
- 테스트 프로세스는 테스트 계획, 분석, 설계, 테스트 구현, 테스트 진행 상황 킻 결과 보고, 테스트 대상 품질 평가 등 만흔 활동을 포함한다.
테스팅의 일반적인 목적
- 요구사항, 사용자 스토리, 설계, 소스 코드 등과 같은 작업 산출물 평가에 의한 결함 예방
- 명시된 모든 요구사항이 충족됐는지 검증
- 테스트 대상의 완성 여부 확인과 사용자와 기타 이해관계자의 기대치대로 동작하는지 확인
- 테스트 대상의 품질 수준에 대한 자신감 획득
- 장애 및 결함 발견과 이에 따른 부적절한 소프트웨어 품질의 리스크 레벨 감소
- 이해관계자가 테스트 대상의 품질 수준을 결정하는 데 필요한 충분한 정보 제공ㅇ
- 계약/법률/규제 요구사항이나 표준의 준수 및 테스트 대상이 이러한 요구사항이나 표준을 준수하는지 확인
- 컴포넌트 테스팅
- 내재되어 있는 결함을 최대한 조기에 가능한 많이 식별하고 수정하기
- 코드 커버리지를 높이기
- 인수 테스팅
- 하나의 시스템이 기대한대로 동작하는지, 요구사항을 충족하는지 확인
- 특정 시점에 시스템을 배포하는 것에 대한 리스크 정보를 이해관계자에게 제공하는 것
테스팅과 디버깅의 차이
- 테스트 : 소프트웨어 결함으로 인한 장애를 찾아낼 수 있다.
- 테스터는 초기 테스트와 마지막 확인 테스트를 담당
- 디버깅: 그런 장애의 원인을 찾고 분석해서 수정하는 개발 활동
- 개발자는 디버깅 관련 컴포넌트 및 컴포넌트 통합 테스팅(지속적 통합)수행
- 이후 확인 테스팅에서 결함을 제대로 수정했는지 확인
- 애자일 및 기타 소프트웨어 생명주기 모델에서는 테스터가 디버깅과 컴포넌트 테스팅에 관여하기도 한다.
테스팅이 왜 필요한가?
성공을 위한 테스팅의 기여
- 적절한 테스트 기법을, 적절한 테스트 전문성으로, 적절한 테스트 레벨과 개발 생명주기 단계에 적용하면 소프트웨어와 시스템이 문제(결함으로 인한 장애, 이해관계자의 요구사항 불충족 등)를 안고 배포되는 경우를 줄일 수 있다.
예시
- 테스터를 요구사항 리뷰 혹은 사용자 스토리 개선에 참여시키면 해당 작업 산출물에서 결함을 발견할 수 있다.
- 시스템을 설계하는 동안 테스터가 시스템 설계자와 적극적으로 협업 -> 설계와 테스트 방향에 대한 이해도 상승 -> 기능 설계에 결함이 유입되는 리스크가 줄어들고, 필요한 테스틀 조금 더 일찍 알 수 있다.
- 코드 개발 시 테스터와 시스템 설계자가 적극적으로 협업 -> 코드와 테스트 방향에 대한 이해도 상승 -> 코드와 테스트에서의 결함 발생 리스크 감소
- 테스터가 릴리즈 전에 소프트웨어 확인 및 검증 -> 놓칠 수 있는 장애 발견, 결함을 제거하는데 도움을 줄 수 있다. 이해관계자의 필요와 요구사항 충족도 증가.
품질 보증과 테스팅
품질보증과 테스팅은 포괄적인 개념인 품질 관리 Quality Management에 속한다.
- 품질관리: 품질 측면에서 조직이 나아가야 하는 방향을 제시하고 제어하는 모든 활동이 포함된다.
QA Quality Assurance
- 품질 보증
- 적절한 품질 수준을 달성했는지 확신을 얻기 위해 적절한 프로세스를 준수하도록 하는 것에 초점을 두고 있다.
- QA 프로세스를 바탕으로 생성되는 작업 산출물의 품질은 더 월등한 경우가 많다.
- 높은 작업 산출물 품질은 결함 예방에 도움이 된다.
- 근본 원인 분석(결함 원인을 찾아 제거하기 위함), 회고 회의의 결과를 적절하게 적용해서 프로세스를 개선하는 것은 효과적인 품질 보증에 중요하다.
- 전반적인 프로세스의 올바른 수행 여부에 관심을 가진다 -> 올바른 테스팅 적용에도 관심을 가진다.
Testing
- 테스트 활동은 소프트웨거 개발 및 유지보수 프로세스의 일부다.
오류Errors, 결함Defects, 장애Failures
오류
- 결함(버그)를 발생시키는 오류(실수)를 만들 수 있는데, 특정 작업에 결함을 만드는 오류(원인)은 다른 작업에도 결함을 만들 수 있다.
- 예를 들어, 요구사항을 도출하면서 범해진 요구 -> 요구사항 결함 -> 프로그램 작성 시 오류를 일으킴 -> 코드 결함의 원인이 된다.
결함
- 코드의 결함이 실행되면 장애를 일으킬 수 있다(반드시 장애를 일으키는 것은 아니다)
- 결함 중 일부는 발생 가능성이 없거나 매우 낮아서 특수한 입력이나 사전조건이 충족되어야 장애를 유발
대표적인 오류 발생 원인
- 시간적인 압박
- 사람의 실수
- 경험이 적거나 기술이 부족한 프로젝트 참여자
- 요구사하과 설계 등에 대한 프로젝트 참여자 간의 의사소통 문제
- 코드, 설계, 아키텍처의 복잡성, 해결해야하는 근본 문제, 사용하는 기술의 복잡도
- 시스템 내/외부 인터페이스에 대한 이해 부족, 특히 내/외부 인터페이스 수가 많은 경우
- 새롭고 익숙하지 않은 기술
장애
- 장애는 코드 결함뿐만 아니라 환경ㅇ 조건으로 인해 발생할 수 있다.
- 방사능, 전자기정, 환경오염 등은 펌웨어 결함의 원인이 되거나 하드웨어 상태를 변화시켜 소프트웨어 실행에 영향을 줄 수 있다.
- 테스트 결과가 기대한 것과 다르다고 무조건 장애가 있다고 볼 수 없음
- 다양한 이유로 거짓양성(false positive: 결함으로 보고됐지만 실제 결함이 아닌 경우) 발생 가능성
- 테스트 실행 방식의 오류, 테스트 데이터, 테스트 환경, 기타 테스트웨어에 결함이 있는 경우 등의 이유에 의함
- 비슷한 오류나 결함이 거짓음성(false negative: 테스트가 발견했어야 할 결함을 발견하지 못하는 경우)의 원인이 되는 반대의 경우도 있다.
- 다양한 이유로 거짓양성(false positive: 결함으로 보고됐지만 실제 결함이 아닌 경우) 발생 가능성
결함Defects, 근본 원인Root Causes, 결과Effects
- 결함의 근본 원인: 해당 결하믈 만들어낸 최초의 행동이나 조건
- 결함 분석 -> 근본 원인 찾기 -> 차후 유사한 결함의 발생 가능성을 낮춤
- 이를 기반으로 이루어지는 프로세스 개선은 이후 발생하는 결함 수를 상당 부분 줄여준다.
