- 작성 중
QA 하는 일
-
QA 프로세스 및 표준 개발
-
테스트(버그 문제 식별, 개발 목표와 사용자 요구사항을 충족하는지)
-
자동화/문서화(반복 테스트를 자동화하고 문제 세부사항을 문서화)
-
보안 테스트
-
규제 준수 여부 확인
블랙 박스 테스트 vs 화이트 박스 테스트 비교
블랙 박스 테스트
- 시스템 내부 동작 원리에 대한 지식 없이 테스트
- 단순하고 아키텍처에 대한 지식이 필요x
- 사용자 관점의 사용성에만 집중
- 에러의 설명을 개발자가 이해하지 못한 경우 반복된 에러 발생 우려
- 종류
- 동등 분할(입력에는 출력이 정확히 나오는지 확인)
- 경계값 분석(최댓값, 최솟값을 이용해서 확인)
- 도메인 테스트(상관관계가 존재하는 경우 영역을 분할하고 테스트 도출)
- 페어와이즈 조합 테스트
- 상태 전이 테스트
- 결정 테이블
블랙 박스 테스트를 위해 만들어 본 column
- 테스트 내용
- 앱 버전
- 번호
- 페이지
- 로그인 권한(비로그인, 로그인, 권한)
- 테스트 항목(상태)
- 테스트 환경(어떠한 상태에서 나오는 테스트인지)
- 예상 결과
- 테스트 확인
- 등록 기간
- 테스트 기기(iOS,Android,Pad,Web 등)
- 테스트 서버(prod, dev, test 등)
- 배포 이후 여부(배포된 기능인지 여부)
- 실제 결과
- 테스트 결과 부연 설명
- 스크린 샷
- 담당자
- 완료 여부
-
테스트의 자동화까지 구현을 기획했지만 앱 환경에서 자동화가 어렵기도 했고 시간이 적었습니다.
-
하지만, 정확한 테스트 확인 사안 버전 등 앱에 특화된 QA를 만드는 것에 집중했습니다.
-
페이지마다 모든 것을 꼼꼼하게 작성하고 테스트 하면서 테스트 필요 요소를 추가하기도 했습니다.
-
그 결과, 꼼꼼한 테스트를 통해 잘못된 버전을 배포하는 일, 테스트 기간을 40% 줄일 수 있었고
- 테스트 결과를 “80%”처럼 정확하게 설명할 수 있게 되었습니다.
화이트 박스 테스트
- 숨겨진 에러를 찾는 코드
- 내부 정확한 동작 원리를 이해하고 테스트
- 악의적인 조작에 취약한 부분을 식별해 보안 개선에 도움
- 개발자와 테스터간 긴밀한 참여 필요
- 비용 소요
화이트 박스 테스트를 위해 만들어 본 column
- 1
- 작성자
- 등록일
- 2
- 1차 이슈 담당
- 담당자
- 3
- 2차 이슈 할당
- 담당자
- 4
- 중요도
- 페이지(또는 발생위치)
- 5
- URL
- 테스트 브라우저
- 6
- 발생상황
- 기대효과
- 마크업/개발 코멘트
- 처리 현황
-
Jira를 통해 QA 결과를 알려주는 것보다 조금 더 명확하게 이해할 수 있습니다.
- Jira와 QA 문서를 동시에 병행했을때 일자와 업무 분장이 명확했습니다.
결과
-
QA가 점점 AI나 자동화 도구로 자동화되고 있지만 아직은 직관적이지 못하다 여겼습니다.
-
개발자가 충분히 할수 있지 않나라고 했을때, 놓치고 있는 부분이 항상 존재한다고 여겼습니다.
-
위와 같은 문서로 필요한 테스트를 정리하고, 테스트 코드를 작성하는 것
-
추가로 자동화시키는 것을 합친다면 개발 속도는 더욱 가속화 됩니다.