맨날 까먹는다, 테스트 유형(Type of Testing)

QA는 기획/논리적 오류 사전 검증, 사업 운영에 대한 타당성 검증, 협업 과정 중 프로세스 개선 제시 활동, 디자인 리뷰, 보안, 테스트를 통한 결함 도출 및 관리 등 협업 부서의 이해가 있다는 전제하에 품질을 높이기 위해 정말 다양한 업무 영역에서 역량을 펼칠 수 있다.

경험이 부족한 상태에서 어떠한 역량을 쌓는게 좋을까 고민하였을 때 무엇보다 테스팅 활동 자체의 퀄리티를 먼저 높이는 것이 좋겠다고 생각했고, 테스트 대상의 도메인 이해도, 프로젝트 상황, 프로세스 상 단계에서 어떤 테스팅을 수행할 지 판단하고 적합한 테스팅을 설계 및 수행 능력을 높이고자 기본 지식을 정리하였다.

---

 

Testing 타입은 100+가 존재한다. Testing cycle을 돌리는데 있어 공통적인 타입을 정리하여 기법 및 전략을 찾는 키워드를 찾는 목적으로 사용할 예정이다. 또한, 타입에 따른 방법론 및 전략은 별도의 글로 작성할 예정이다.

객관적인 정보를 위주로 작성하려고 노력했으나, 개인적인 의견을 작성하는 경우도 있음😉

• Ad-hoc testing

어떠한 계획이나 사전에 정의된 문서 없이 테스터(anyone)가 비공식적으로 자의적/임의적으로 하는 활동이다. 테스터의 경험, 비즈니스 이해도에 의하여 application의 flow나 random하게 수행하며, 정의된 TC보다 크리티컬 혹은 마이너한 버그를 발견할 수 있어 정식 테스팅 수행 전후, 소규모, 시간/인원이 적은 프로젝트에서 사용할 수 있다.

 

• Happy path testing

아무것도 잘못되지 않는 사용자 시나리오(사람의 실수, 의도되지 않은 행동)대로 수행하는 것을 의미한다. 많은 개발자들이 이런 테스팅을 범하곤 하는데, 이를 위해 TDD/BDD 개발을 하기도 하며, Unhappy path를 찾기 위해 'Fifty Quick Ideas To Improve Your Tests.pdf'에서 감정에 기반한 테스팅 방법이 제시되었다.

 

• Heuristic testing

휴리스틱이란 어림짐작으로 느낌표 모양의 아이콘을 보았을 때 '경고이지 않을까' 라고 생각하는 것처럼 제한된 정보와 시간상 제약 등 현실적 상황에서 체계적이고 합리적으로 판단하기 보다는 즉시적이고 바로 실현 가능한 결정을 내리는 것을 휴리스틱이라 칭한다. 기준점과 조정/가용성/대표성/감정 휴리스틱 등 다양한 종류가 있다.

 

휴리스틱 테스팅은 주로 사용성에 대한 문제를 찾기 위해 전문가에 의해 이론과 경험을 근거로 일련의 규칙을 만들고 평가 대상이 그 규칙을 얼마나 잘 지키고 있는가를 확인한다. 설계 프로세스 모든 단계에서 수행할 수 있으며, 무엇을 평가하느냐에 따라 매우 빠르게 결과를 얻을 수 있다. Jakob Nielsen에 따르면 평가자가 많을 수록 효율이 올라가며 10원칙을 제시한다. *링크참고https://m.post.naver.com/viewer/postView.nhn?volumeNo=31349003&memberNo=2647347

하지만 평가자의 경험과 역량이 좋을 때 효과적이고, 항목을 통과했다고 오류가 없다고 객관화를 범하기 쉽다.

 

• Unit testing

전형적으로 내부적인 코드와 설계를 알고 있는 개발자가 진행하며 함수 및 클래스 단위의 코드를 검증한다. 이를 위해 유닛 테스트 코드를 작성하는 것이 일반적이며 유닛 테스트 코드를 작성함으로써 해당 테스트 단위(메소드)와 더불어 오래된 코드, 디펜던시가 있는 다른(남이 짠) 코드를 검사하는 역할을 하기도 한다. 이를 통해 프로그램 안정성, 문제 발생 시 빠른 원인 파악, 개발 스타일 및 컨벤션 공유, 리팩토링 가능, 자신감 뿜뿜 할 수 있다.

하지만 처음 작성하는 경우 케이스를 모르거나 테스트 코드 작성에 시간이 소요되지만, 단점보다는 장점이 많기 때문에 꼭 알아야 한다고 생각한다.

 

• Integration testing

각기 다른 모듈을 통합하는 단계에서 수행하며 인터페이스, OS, Files system, h/w 등 상호 연동하는 동작을 테스트 한다. 환경을 고려하여 영향 있는 요인으로 인해 복잡하다.

 

• Incremental integration testing

모듈과 통합 테스트를 섞은 bottom-up 접근법이다. 기능이 추가되어 지속적인 테스팅이 필요할 때 모듈 간 통합하여 테스팅 한다.

 

• Regression testing

기능 추가 혹은 오류 수정으로 인해 새로 유입된 오류가 있는지, 이전에 수정됐던 오류가 다시 발생하는 지 확인하는 목적을 가진다. 디펜던시가 있는 모듈에 사이드 이펙트가 발생하는 경우는 흔하며 반복적인 성향이 강해 사람의 직관이 필요하지 않는 케이스는 자동화를 많이 사용한다.

 

• Cursory testing

개발자가 TC없이 주요한 단위 혹은 시스템 모듈을 즉흥적으로 테스트한다. Sanity testing 이전에 수행한다.

 

• Sanity testing

개발팀/개발자가 안정된 빌드에서 새 기능의 오류가 없는지 확인한다. 본격적인 테스트에 앞서 테스트 용이성을 판단하기 위한 목적으로 수행한다. 리그레이션 테스팅의 하위 집합이다.

 

• Smoke testing

본격적인 테스트 수행에 앞서 전문 테스트팀에서 테스트 대상이나 제품 빌드의 안정성/합리성을 확인한다. 인수 테스트의 하위 집합이다. 일반적으로 개발팀에서 Cursory→Sanity testing 테스트팀 Smoke testing이 진행된다.

 

• System testing

정해진 요구사항 및 규격서에 기반하여 이를 만족하는지 통합된 모듈 전체 시스템을 테스트한다. 이때 작동 시간, 처리 능력, 부하 등 비기능적 요소도 점검하며 Black box 레벨로 최대한 실환경과 유사하게 만들어서 수행한다.

 

• Alpha/Beta(A/B) testing

두 테스트는 고객 검증 단계에서 출시하기 전 테스트가 이뤄지며, 알파 테스트는 보통 보안 유지 목적 때문에 자사 타부서 혹은 밀접한 외부 관계사는 참여하지 않는다. 알파 테스트를 거친 후 선별된 잠재 고객에게 베타 테스트를 진행한다. 이는 고객의 니즈를 짐작하지 않고 반응을 얻고 개선시키는 데 의미가 크다. A/B 테스팅은 악조건의 실환경에 진행하지만 주요 항목을 위주로 테스트하기 때문에 추가적으로 필드 테스팅을 통해 하드웨어가 포함된 (전자제품) 제품의 경우 다양한 신뢰성 테스트를 진행한다.

 

• Interface testing

API, 웹 등 요소 간의 통신을 제어하는 데 사용되며 주로 json,xml 형식의 rest/soap를 수행할 수 있다. 단위, 기능, 부하, 보안, 런타임 오류 감지, 워크 플로, 개별(과금,재고 등) 시스템 테스트와 같은 사례가 포함된다.

 

• Performance testing

테스트 타겟의 성능 요구사항을 만족하는 지 확인하며, Load/Stress/Spike/Stability/Soak/recovery/Volume/Resilience/Failure 등 종류가 있다. 성능 테스트 시에는 예상 사용자 수, 허용가능한 성능, 시정 조치 계획을 이해하고 평가할 수 있어야 한다. 설계자는 실제 상황과 비슷한 '상황 설정', '구현', '결과에 따른' 분석을 명확히 할 수 있어야 한다.

 

• Load testing

성능을 벤치마크하기 위한 테스트로 일반적인 부하를 가하여 테스팅한다. 부하를 순차적으로 증가시켰을 때 응답시간, CPU, 메모리 자원의 수치 증가를 보고 비정상적인 상태가 되는 임계점을 찾는다. 임계점을 높이기 위해 튜닝과 테스트를 반복하여 성능 향상하며 신뢰성을 검증을 목적으로 한다.

 

• Stress testing

충분한 자원 및 리소스를 갖추지 않은 상태에서 임계값 이상의 요청을 지속적으로 보내 어떻게 반응하는지, 복구가 되는지 확인한다. 성능/부하/스트레스 테스트를 통해 하드웨어 인터럽트, 메모리 런타임 에러, 데드락, 멀티스레딩 문제를 식별할 수도 있다.

 

• Spike testing

순간적으로 사용자 수가 몰렸을 때 상태를 확인하기 위해 순차적으로 사용자 수를 증가시켜 확인한다.

 

• Volume testing

처리해야 할 많은 양의 데이터에 따른 병목 구간, 데이터 손실 여부, 자원, 처리 속도를 확인한다.

 

• Security testing

해킹 기법을 이용한 시스템 침투 테스트. 멜웨어, 바이러스, 권한 획득 등을 이용하여 보안성을 확인한다. 보안툴을 이용하기도 하며, 매년 발표되는 위협 OWASP의 항목을 점검해볼 수 있다.

 

• Compatibility testing

os/제조사/해상도/cpu/ram/네트워크 등 환경에서 주요 기능 동작 여부를 확인한다. 하지만 시간, 인력 한계때문에 전체를 다하기는 현실적으로 어렵고 가장 의심되는, 중요한 환경에서 테스팅을 하게된다.

 

• Install testing

SW가 정상적으로 목적 경로에 설치되는 지 확인하고 레지스트리의 변경, 제거가 수행되는지까지 확인한다. 이때 버전 체크, 필요 메모리 공간, 설치 중 중단 시도를 고려한다.

 

• Recovery testing

중단이 발생하면 큰 비용으로 돌아오기 때문에 오류로 인해 소프트웨어가 복구가 이뤄지는 지, 복구 소요 시간, 추가 작업 수행 가능 여부 등을 확인한다. 복구가 필요한 상황은 일반적으로 네트워크, 정전, 외부와 통신, 물리적 조건 등이 있다.

 

• Reliability testing

일정 기간 동안 고장 없이 환경(온/습도, 전압, 전파,낙뢰, 진동) 등과 같은 조건 하에서 동작이 지속됨을 확인한다. 주로 환경 시험과 수명 시험을 테스팅 한다. 고장에 대한 저항성, 오랜 기간 동안 수행될 확률, 참사없이 곱게 고장날 능력을 의미하기도 한다.

 

• Usability testing

사용자에게 할 일을 주고 사용자 모습을 관찰한 뒤 질문을 던져 행동의 이유를 파악한다. 초기에 쉽고, 누구나 할 수 있고, 셀프 평가도 가능한 점에서 개발을 효율화 할 수 있다.

 

• Compliance testing

비기능 테스팅으로, 릴리스 되기 전 테스트 대상이 정의된 내부/외부적 조직의 기준을 부합하는지 한다. 표준 절차 가이드 라인 충족 여부, 문서의 완전성 및 타당성, 개발 방법론 등 을 확인한다. 이를 위해서 관리자에 의해 잘 이해하고 문서화해야 한다.

 

• Localization testing

테스트 대상이 특정 언어, 나라의 문화에서 적합한지 확인한다. 컨텐츠, UI를 중점으로 보며 이외에도 시간, 돈, 문서를 검증한다. 해당 지역의 언어 전문가, DBCS(double byte code set) 차이, 지역 간의 시간 차이로 어려움이 생길 수 있다.

 

 

 

---

1. 마 치 며

틈틈이 개념과 예제, 어떨 때 사용하면 좋을 지 고민하다보니 내용이 많아져서 이만 줄이고

white box와 같은 종류는 다음 편에 이어서 계속!

---