지난 1 년 동안 팀을 출시 초기 릴리스의 개발 모드 (AKA : Agile이 아닌 Rapid Application Development)로 이끌었습니다. 빌드를 닫는 방법에 대한 자세한 내용은 다음 답변을 참조하십시오.
RAD 환경에서 릴리스 품질을 향상시키는 간단한 방법

우리가 RAD를 채택했을 때, 사람들은 상당히 독립적이었고 그들은 단위 테스트를 먼저하고있었습니다. 통합 테스트는 프로세스 후반에 훨씬 많이 발생했습니다. 많은 공식적인 시행 없이는 자연스러운 과정이었습니다. 이제 상황이 상당히 다릅니다.

1. 전체 플랫폼은 핫스팟없이 클라이언트 측에서 작동하는 기존 빌드 / 릴리스와 잘 통합되어 있습니다.

2. 새로운 기능 요구 사항이 계속 나타나고 갈수록 점진적으로 요구합니다.

3. 독립적 인 개발 그룹이 프로세스를 올바르게 따르고 있지만 복잡하고 명백하지 않은 상황으로 인해 주요 장애가 발생했기 때문에 시스템의 전반적인 역학이 매우 중요합니다.

4. 시스템의 많은 부분에는 새로운 알고리즘과 연구 입력이 포함되어 있으므로 잘 정의 된 소프트웨어의 기능 테스트와 같은 문제 (및 테스트 메커니즘)가 항상 정확하게 예측되는 것은 아닙니다.

최근에는 프로세스 개선이 필요한지 확인하기 위해 전반적인 전반적인 그림을 얻으려고했습니다. 팀과 함께 앉았을 때 많은 사람들이 “우리는 더 이상 단위 테스트를하지 않습니다!” 다른 사람들은 우리가 지금부터 시작해서는 안된다고 생각했지만 그것이 효과적이지 않을 것입니다.

단위 테스트는 비교적 성숙한 시스템에서 유용합니까? 최소한 장치의 성숙도에 따라 테스트 범위를 측정해야합니까? 단위 테스트로 개발 속도가 느려 집니까? 다른 방법으로 단위 테스트를 평가해야합니까?

릴리스 초기 릴리스 환경에서 성숙한 플랫폼에 대한 테스트의 모범 사례는 무엇입니까?

답변