답변.

기존 프로젝트에 자동화 테스트를 도입하는 것은 복잡하고 다단계의 작업입니다.

사안의 역사: 수동 테스트가 오랜 기간 동안 수행된 조직에서는 프로세스, 문서 및 코드 아키텍처가 항상 자동화 요구사항에 부합하지 않습니다. 테스터는 자동화 도구를 다루지 못하고, 테스트 및 애플리케이션 아키텍처는 자동 테스트의 빠른 실행을 지원하지 않을 수 있습니다.

문제: 도입의 주요 어려움은 다음과 같습니다:

자동화 문화의 부재: 경험, 도구 및 프로세스가 없습니다.
레거시 코드의 복잡성: 테스트 통합의 어려움, 테스트 가능한 인터페이스 및 안정적인 요소 구조의 부재.
우선순위 기준의 부재: 무엇을 먼저 자동화해야 하며, 어디서 가장 큰 효과를 얻을 수 있을까요?

해결책: 팀은 다음 단계를 거쳐야 합니다:

준비 상태 평가: 시간 절약을 가져올 수 있는 가장 중요한 반복 수동 테스트를 식별합니다.
파일럿: 작은 시스템 블록을 선택하고 가설을 빠르게 검증하기 위해 파일럿 자동 테스트 세트를 구현합니다.
점진적 도입: 파일럿의 성공에 따라 자동화 테스트의 범위를 확장하고, 팀을 자동화 교육을 병행합니다.

주요 특징:

자동화는 회귀 및 "스모크" 테스트로 시작하는 것이 유리합니다.
자동 테스트를 기존 개발 프로세스에 통합하는 것이 중요합니다(예: 풀 리퀘스트 시 실행).
커뮤니케이션을 고려해야 하며, 자동화의 이점과 한계를 비즈니스 및 테스터들에게 설명해야 합니다.

트릭 질문.

자동화 테스트가 수동 테스트를 완전히 대체할 수 있습니까?

아니요. 비록 자동화 테스트의 적용 범위가 높더라도, 이들은 반복적이고 결정론적인 시나리오에만 적용됩니다. 발견할 수 없는 사용성 버그, 탐색 문제, 디자인 결함 및 비정형 "인간" 버그는 일반적으로 수동으로 잡힙니다.

모든 테스트 케이스를 예외 없이 자동화해야 합니까?

아니요. 모든 테스트 케이스를 자동화하는 것은 정당하지 않을 수 있습니다: 낮은 빈도의 테스트나 복잡한 시나리오는 비용이 많이 들고 낮은 수익률로 인해 수동 테스트로 두는 것이 좋습니다.

테스터는 성공적인 자동화를 위해 꼭 프로그래머여야 합니까?

아니요, 하지만 기본적인 프로그래밍 수준은 바람직합니다. 팀은 일반적으로 경험 많은 테스터와 자동화 아키텍트, 자동화 제작자는 개발자로 구성됩니다.

일반적인 오류 및 안티 패턴

우선순위를 정하지 않고 즉시 모든 것을 자동화하려는 시도.
수동 테스터와 자동화 제작자 간의 의사소통 부족.
프로젝트에 적합하지 않은 "유명한" 도구 선택.
자동 테스트의 유지보수 및 актуализация 프로세스의 부재: "실행하고 잊어버리기".

실제 사례

부정적 사례

회사는 우선 순위를 논의하지 않고 별도의 팀을 구성하지 않고 모든 수동 테스트를 동시에 자동화하겠다고 결정했습니다. 멋진 도구를 구매했으나, 필요한 브라우저의 일부를 지원하지 않았습니다. 결국 3개월 후 반의 테스트가 작동하지 않게 되었습니다.

장점:

빠른 초기 도입, 팀의 열정.

단점:

막대한 비용, 빠른 실망, 교육 비용, 실제로 필요한 시나리오의 낮은 적용 범위.

긍정적 사례

팀은 가장 자주 발생하는 10개의 회귀 시나리오를 수동으로 선택했습니다. Python(Selenium)으로 자동화 교육을 실시하고 CI에 테스트를 추가했습니다. 6개월 후 70%의 회귀 검사가 자동으로 실행되었고, 수동 테스터는 창의적인 작업에 집중했습니다.