언제 테스트를 중단합니까?
https://stackoverflow.com/questions/32229
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
실무에서 애플리케이션 테스트를 중단하고 프로덕션으로 이동할 때가 된시기를 알기 위해 어떤 조치를 사용하십니까?
해결책
내 조직의 프로젝트에서 일반적으로 사용하는 측정은 다음과 같습니다.
- 심각도 1 (스토퍼 표시) 문제 없음
- 심각도 2 (주요 기능 장애) 문제 없음
- 허용되는 심각도 3 (사소한 기능) 문제 수
"허용되는 숫자"는 응용 프로그램의 크기 등에 따라 당연히 매우 칙칙한 숫자입니다.
이러한 전제 조건이 충족되면 모든 이해 관계자들 (QA 책임자, 개발 책임자, 앱 지원 책임자 등)이 회의를 갖고 미해결 문제 목록을 검토하고 합의가 있는지 확인합니다. 미해결 문제에 할당 된 심각도. 미해결 Sev 1 및 Sev 2 문제가 없음을 확인하면 각 이해 관계자로부터 "Go / No Go"전화를받습니다. 모두가 "Go"라고 말하면 Production으로 이동하는 것이 편합니다. 적어도 한 명의 이해 관계자가 "No Go"라고 말하면 "No Go"의 이유를 조사하고 필요한 경우 그 뒤에있는 문제를 해결하기위한 조치를 취합니다.
작은 프로젝트에서는 프로세스가 더 능률적 일 수 있으며, 1 인 작업 인 경우 사전 조건 세트가 훨씬 더 간단 할 수 있습니다. 버그-거기에 두자! ". 응용 프로그램에서 제공하는 이점이 버그의 성가신 문제를 무시하는 한, 특히 "일찍 자주 릴리스"지침을 따르는 경우 유용 할 수 있습니다.
다른 팁
첫째, 테스트를 중단하지 마십시오. 귀하 가 테스트를 마치고 릴리스하면 사용자가 대신 테스트를한다는 의미입니다.
둘째, 포괄적 인 테스트 스크립트가 허용 가능한 수준의 실패와 함께 통과하면 다음 단계로 넘어갈 준비가 된 것입니다.
마지막으로 이것은 귀하의 경우에 매우 구체적입니다.일부 프로젝트에서는 사소한 변경 사항이 적용되기 전에 많은 사람들이 시스템을 해킹하는 3 주 베타 테스트 기간이 있습니다.다른 영역 (덜 중요하지 않음)에서는 다른 개발자의 고개만으로 작은 변경 사항을 제거 할 수 있습니다.
항상 시도하고 싶었던 흥미로운 테스트 방법 중 하나는 '오류 시드'입니다. 아이디어는 다른 범주에 속하는 시스템에 의도적 인 버그를 삽입하는 사람이 있다는 것입니다.
예 :
- 화장품, 맞춤법 오류 등
- 심각하지 않은 오류
- 중대한 오류 및 충돌
- 데이터 문제. 오류는 발생하지 않지만 결과에 더 심각한 문제가 있습니다.
- 등
'시더'는 신속하게 되돌릴 수 있도록 이러한 버그를 삽입하기 위해 변경된 사항을 정확히 문서화합니다. 테스트 팀이 시드 된 버그를 발견함에 따라 실제 버그도 발견하지만 차이점을 알지 못합니다. 이론적으로 테스트 팀이 시드 된 치명적 오류의 90 %를 발견하면 실제 치명적 오류의 비례적인 수를 찾은 것입니다.
이 통계를 통해 언제 석방이 허용되는지 판단 할 수 있습니다. 물론 어떤 버그가 발견되는지 (실제 또는 시드 된) 임의의 특성으로 인해 절대적으로 완벽하지는 않지만, 얼마나 많은 버그를 공개할지 전혀 모르는 것보다 낫습니다.
직장에서 가끔 사용되는 한 가지 측정 항목은 제품의 마지막 여러 버전에 존재하는 오래되고보고되지 않은 버그를 찾기 시작할 때 충분히 테스트 한 것입니다.테스트 중에 발견 한 버그이고 고객이 불만을 제기하지 않은 상태로 수년 동안 버그가 존재했다면 안전하게 배송 할 수 있습니다.
물론 모든 수동 테스트, 자동화 된 테스트, 개발자가 제품, 베타 및 지속적인 테스트를 사용하도록 만들지 만 현재 발견되었지만보고되지 않은 버그 수를 사용하여이전 버전에서 처음 들었을 때 새로운 아이디어였습니다.
모든 주요 쇼 스토퍼가 사라 졌을 때
진심으로 사용자 수락 테스트를 수행하고 사용자가 시스템을 사용하고 시스템이 모두 잘 렸는지 확인해야합니다.이것이 실용적이지 않다면 타겟층과 유사한 일부 사용자를 대상으로 비공개 베타를 수행하세요.
시스템의 모든 버그를 실제로 찾는 것은 불가능하므로 때때로 유일한 실제 규칙은 그냥 발송 하는 것입니다.
mharen,
포괄적 인 자동화 테스트가있는 경우 모두 통과하지 않는 한 소프트웨어를 배송하는 것은 무책임한 일입니다.자동화 된 테스트는 이러한 영역이 핵심 기능이거나 과거에 발생한 버그 중 하나이며, 테스트를 통과하도록 수정할 수 있음을 의미합니다.자동화 된 테스트를 100 % 통과하지 못한 소프트웨어를 배송하는 것은 무책임합니다.
Jon,
자동 테스트를 의미하는 테스트 스크립트를 의미하지는 않았습니다.테스트 대상과 테스트 방법에 대한 단계별 목록의보다 전통적인 접근 방식을 언급했습니다.
즉, 모든 자동화 된 테스트를 통과해야한다는 데 동의하지 않습니다.그것은 모두 심각도와 우선 순위에 달려 있습니다.대규모 프로젝트에서는 개발자가 사용자가보고 한 문제를 기반으로 실패한 테스트를 작성하도록 할 수 있습니다.모든 릴리스에서 모든 버그를 수정할 수는 없으므로 일부 테스트는 통과하지 못할 수도 있습니다.
'showstopper'또는 주요 기능 버그 사이의 제품 테스트 시간을 측정하면 거의 완료되었음을 알 수 있습니다.새로운 기능이 포함 된 제품이 빠르게 유동하는 경우, 테스트 팀이보고하는 대부분의 버그가 심각한 기능 버그라는 사실을 발견하는 것이 일반적입니다.이러한 문제를 처리함에 따라 상호 작용의 부드러움과 명확성을 개선하기위한 사소한, 적합 및 마감 유형 문제가 자주 발생합니다.종합적으로 그들은 제품 품질에 큰 차이를 만들지 만 각각은 그다지 중요하지 않습니다.이러한 문제가 수정되고 테스트가 계속되면 테스터가 오류 사례와 비정상적인 사용 패턴을 입력함에 따라 버그 보고서를 계속받을 수 있습니다.이 시점에서 릴리스의 비즈니스 가치와 감지되지 않은 흥행의 위험을 확인하는시기에 따라 다릅니다.
