답변.

회귀 수동 테스트는 코드 변경 후 시스템의 이미 테스트된 기능을 다시 확인하여 이러한 변경이 제품의 안정적인 부분에 새로운 결함을 초래하지 않았는지 확인하는 프로세스입니다.

질문 배경: 소프트웨어 라이프사이클의 초기 단계에서 테스터는 새로운 기능 테스트에 집중하는 경향이 있습니다. 시간이 지남에 따라 시스템은 변경 사항으로 인해 예기치 않은 회귀의 위험이 증가합니다. 많은 소프트웨어 역사에서 버그는 "고장" 난 이전에 작동하던 것을 수정한 후 발생 했으므로 회귀 테스트는 점점 필수적인 관행이 되었습니다.

문제: 주요 딜레마는 지속적인 변경에 대한 피드백을 효율적으로 그리고 짧은 시간 안에 최대한 많은 기능을 재검토하는 것입니다. 무질서하거나 비체계적으로 접근하면 중요한 결함을 놓치거나 마감 기한을 맞추지 못하거나 팀이 과중하게 되며 때로는 검토가 형식적으로 변할 수 있습니다.

해결책: 효율적인 회귀 테스트 조직을 위해 필요합니다:

핵심 기능에 대한 안정적이고 유지 관리되는 테스트 케이스 또는 체크리스트 세트를 보유하십시오;
수정을 할 때마다 이러한 세트를 정기적으로 업데이트하십시오;
가능하면 루틴을 자동화하고, 수동 테스트에는 중요한 또는 비표준 시나리오만 선택하십시오;
비즈니스 위험과 변경 빈도에 따라 검토할 기능의 우선 순위를 협의하십시오.

주요 특징:

회귀 테스트는 명백한 버그뿐만 아니라 모듈 간의 상호작용과 관련된 숨겨진 오류 체인도 식별합니다.
테스트 케이스 세트를 정기적으로 검토하고 우선 순위를 매기는 것이 중요합니다.
최적의 전략은 가능할 때 수동 검토와 자동화를 결합하는 것입니다.

함정 질문.

회귀 테스트는 모든 변경 후에 시작하는 것이 가장 좋습니까, 아니면 변경을 도입하는 동시에 진행하는 것이 좋습니까?

많은 사람들이 회귀는 모든 변경이 완료된 후에만 수행된다고 잘못 생각합니다. 사실 변경사항을 도입할 때마다 부분적으로 계획하고 수행하는 것이 더 빠르게 критических 실패에 대응할 수 있는 올바른 방법입니다.

회귀 테스트 케이스를 한 번 작성하는 것으로 충분하고 더 이상 업데이트를 하지 않아도 됩니까?

아니요, 회귀용 테스트 케이스는 지속적으로 업데이트해야 합니다: 비즈니스 로직 또는 인터페이스가 변경되면 테스트 시스템은 제품에 따라 변경되어야 합니다.

스모크 테스트는 회귀의 일부입니까?

아니요, 스모크 테스트는 빌드 후 명백한 실패를 신속하게 차단하는 것이고, 회귀 테스트는 더 넓은 기능을 다루고 깊이 있는 문제를 찾습니다.

전형적인 실수 및 안티 패턴

구식 테스트 케이스로 인해 테스트가 쓸모없는 형식적인 것이 됩니다.
눈에 잘 띄지 않지만 중요한 시나리오를 무시합니다.
명확한 우선 순위가 없으며 핵심 기능과 중요하지 않은 기능에 동일한 주의를 기울입니다.

사례

부정적인 사례

팀이 릴리스를 수행하고 테스터가 구식 테스트 케이스 목록에 따라 기능을 형식적으로 검사하며, 마지막 API 수정 사항을 알지 못합니다. 이전의 버그가 수정되었지만 시스템의 다른 부분에서 누군가가 시작하기 전까지 발견하지 못한 중요한 결함이 발생합니다.

장점:

테스트 케이스 작업에서 시간 절약.

단점:

중요한 회귀를 놓칠 위험이 큽니다.
테스트의 품질에 대한 신뢰가 줄어듭니다.

긍정적인 사례

릴리스 전에 테스터들은 회귀 체크리스트를 업데이트하고 분석가와 최신 위험 영역에 대해 논의하며, 실제 시나리오 기반으로 테스트의 우선 순위를 매기고 핵심 흐름에 대한 수동 회귀 테스트를 수행했습니다.