Web Guide자동화 테스트품질 관리회귀 검증
자동화 테스트 도입 판단
하나를 고치면 다른 데가 깨집니다.
수정할 때마다 전체를 사람이 확인할 수는 없습니다.
01언제 필요한가
규모와 수정 빈도가 기준입니다. 거의 바뀌지 않는 사이트에는 과합니다.
도입할 만한 경우
수정이 잦음 · 기능이 많고 복잡 · 결제와 예약 등 중요 기능 · 여러 명이 개발 · 장기 운영
불필요한 경우
소개 사이트 · 연 1~2회 수정 · 기능이 단순 · 초기 비용 부담이 큰 경우
02어디부터 적용할까
전부 자동화하려 하면 실패합니다. 깨지면 가장 치명적인 것부터 시작하세요.
1
결제 흐름
가장 먼저 자동화할 대상입니다.
2
로그인과 가입
막히면 모든 것이 멈춥니다.
3
주문과 예약
핵심 매출 경로입니다.
4
문의 접수
조용히 실패하면 손실이 큽니다.
5
자주 깨지는 곳
과거에 문제가 반복된 부분.
03비용과 효과
테스트도 코드입니다. 만들고 유지하는 비용이 듭니다.
초기 구축테스트 작성에 시간이 듭니다.
유지 비용화면이 바뀌면 테스트도 고쳐야 합니다.
실행 환경자동 실행 환경을 준비해야 합니다.
효과수정할 때마다 전체 확인이 자동으로 됩니다.
회수 시점수정이 잦을수록 빨리 회수됩니다.
심리적 효과고치는 것을 두려워하지 않게 됩니다.
04사람이 해야 할 것
자동화가 모든 것을 대신하지는 못합니다. 사람이 봐야 할 영역이 있습니다.
점검 항목
디자인 확인
보기 좋은지는 사람이 판단합니다.
사용성
쓰기 편한지는 자동으로 알 수 없습니다.
내용 검수
문구와 정보의 정확성.
새 기능
처음 만든 기능은 사람이 먼저 확인합니다.
실제 결제
실환경 결제는 사람이 최종 확인합니다.
역할 분담
반복은 자동으로, 판단은 사람이.
CHECK POINT
□ 수정 빈도를 기준으로 필요성을 판단했는가
□ 가장 중요한 기능부터 적용하는가
□ 테스트 유지 비용을 고려했는가
□ 자동 실행 환경이 준비되어 있는가
□ 테스트 실패 시 알림이 오는가
□ 사람이 확인할 영역을 구분했는가
□ 검수 체크리스트와 중복되지 않는가
#자동화 테스트#품질 관리#회귀 검증#결제 테스트#유지보수#배포#개발 프로세스#홈페이지 개발#웹비스타#홈페이지 제작