자동화의 성장과 함께 자동화 테스트에서 기술 부채 문제를 처음 인식하게 되었습니다. 테스트의 수가 수백 또는 수천 개에 이르렀을 때, 테스트 지원이 종종 개발 비용보다 더 비쌌고, 아키텍처 오류가 증가했습니다.
자동화 초기에는 패턴이나 표준 없이, 이후 리팩토링 없이 신속하게 테스트가 작성되었습니다. 그 결과, 자동화 테스트 리포지토리는 낙후되고 애플리케이션 변화로 인해 깨지며, 지원에 더 많은 노력을 요구하게 됩니다.
핵심 특성:
코드를 테스트하는 높은 비율이 기술 부채가 없다는 지표가 됩니까?
아니요, 형식적인 코드 커버리지가 테스트 베이스의 품질과 생존 가능성을 보장하지는 않습니다: 오래되거나 "불필요한" 시험이 있을 수 있습니다.
자동화 테스트 템플릿을 한 번 작성하는 것으로 기술 부채를 제외할 수 있습니까?
아니요, 인프라와 패턴은 프로젝트가 성장함에 따라 항상 검토 및 발전을 요구합니다.
자동화 테스트가 잘 구조화되었다면 수동 테스트 없이도 완전히 대체할 수 있나요?
아니요, 항상 수동으로 smoke/regression/niche 테스트가 필요하며, 자동화 테스트는 안정적인 기능의 정기적인 "모니터링"을 위해 필요합니다.
자동화 테스트가 리뷰 없이 작성되었고, 구조가 프로젝트 진행 중 변경되며 일부 테스트는 더 이상 유효하지 않게 되어 — 40%의 테스트가 애플리케이션 변경으로 인해 실패했습니다.
장점:
단점:
팀에서는 매 2주마다 자동화 테스트에 대한 리뷰 및 리팩토링이 이루어지며, 아키텍처는 승인된 표준에 따라 유지되고, 테스트는 현재의 사용자 스토리와 밀접하게 관련되어 있습니다.
장점:
단점: