뷰티풀 테스팅 16강 정리 - 수동 테스팅이 필요한 이유

쥐도리·2023년 3월 28일

뷰티풀 테스팅 정리

목록 보기

10/10

16장 수동 테스트의 역할 & 자동화 테스팅의 역할

수동 리그렉션 테스팅도 필요한 이유

테스팅 != 검사, 테스팅 == 조사

현업에서 수행되는 SW 테스팅과 학교에서 배우는 SW 테스팅은 다르다.

훌륭한 SW 테스팅이 무엇인지, 어떻게 해야할지는 다양한 해석이 존재한다

SW 테스팅에 있어 모든 환경에 적용 가능한 '베스트 프랙티스'는 존재하지 않다.

테스팅은 검사? 조사?
- 검사(check) : 예상 결과와 실제 결과의 일치 여부 검증
- 조사(investigate) : 테스팅 수행에 연관된 품질 검증
- 검사의 한계 : 검사는 자동화가 가능하다. 그러나 생각지 못한 결함은 발견 X
- 조사의 한계 : 조사는 자동화가 불가능하다. 그리고 제품에 따라 베스트 프랙티스가 달라진다.
  ⇒ 그래서 고품질의 테스팅은 "조사"를 목표로 두고 해야한다.

조사 테스팅 vs 검사 테스팅 예시
- 웹페이지 계산기 테스팅
  - 검사 테스팅 : 클리어 버튼 클릭 → 정상 결과 O
  - 조사 테스팅 : 클리어 버튼 클릭에 따른 메모리 누수 확인 → 30~1시간 이후 오류 발생 예상

수학자의 증명 방식을 추구하자

수학자와 개발자의 차이
- 수학자 : 문제 해결에 정확한 개념 및 명확한 논리 구조를 가진 증명 제시
- 개발자 : 문제 해결에 대부분 해결 가능토록 조건문 설계 + 결함 발견시 새로운 조건문 추가로 해결
테스팅이 갖춰야할 특성 : 아름답고 단순명료할 것.

고객(사람)이 느끼는 불편함을 찾는 것이 목적임을 잊지말자.

테스팅 예제 (웹페이지 계산기)
- 2개의 숫자 입력 필드 존재
- 연산자 선택하는 드롭박스 존재
- 계산 출력하는 버튼 클릭
- 마지막 결과값 보여주는 필드 존재
자동화 작동 시나리오
- 테스트 데이터를 통한 일치여부 검증 스크립트 수행
자동화의 작동 시나리오에서 찾을 수 없는 결함 예시
- 아이콘 배경색이 투명하지 않다.
- 곱셈결과 수행 이후, 드롭 박스가 첫 번째인 "더하기"로 바뀌어 덧셈 결과처럼 보일 수 있다.
- 두 번째 입력 이후 취소 버튼이 동작하지 않는다.
- 답 출력값이 편집이 가능하다
- 연산 완료에 있어 8초나 소모된다.
- 결과 출력 이후 입력필드 값 변경 시, 0+4 = 8 처럼 보일 수 있다.
  ⇒ 사람이 느끼는 불편함을 찾지 못하는 자동화 시나리오

테스팅 프로세스
- 제품에 따른 결함 카테고리 설계
- 테스팅 업무에 "리뷰 필요", "개발 중", "QA 중", "사인오프 대기" 등 진행사항 태그 표시
- QA를 포함한 개발자, PM, 제품 관리자 등 여러 사람 만나 스토리의 규모, 세부 사항 확인
수동화 테스팅의 한계
- 여러 테스팅 시나리오에 따른 테스팅 설계 완료 & 모든 브라우저 테스팅 설계
- 개발 완료 이후 2주 마다 정기 패치 진행 시, 2주마다 모든 리그렉션 테스팅 진행?
  → 개발자보다 테스터 인원 더 필요
결론
- 테스팅에 있어 어떤 테스팅은 계속 조사해야 하는가? 어떤 테스팅은 검사로 자동화 해야 하는가?

테스팅은 검사가 아니고 조사하는 작업이다.
컴퓨터 과학자는 단순히 조건문을 처리하고 다음 조건문으로 옮겨가려 한다.
사람이 테스팅을 직접 수행하면 자동화에선 찾을 수 없었던 불편함을 바로 찾을 수 있다.(아이콘, 시각)
QA는 QA 관리자를 포함해 제품 관리자, 개발자, PM 등 여러 사람들을 만나 스토리의 규모, 세부 구현사항, 그리고 어떻게 테스트할 것인가 논의해야 한다.

Adam Goucher, ⌜뷰티풀 테스팅⌟, 지앤선, 2011

해보고, 정리하고, 돌아보자