다른 시스템의 품질 보증 (QA)을 위해 완전히 중복 된 시스템을 만드는 것이 좋지 않습니까?

직장에서 우리는 매우 복잡한 시스템을 가지고 있습니다. 이 시스템을 System_A라고하겠습니다. Google의 품질 관리팀에서 System_A를 테스트하기 위해이 시스템을 System_B라고하는 다른 시스템을 만들었습니다.

System_B가 사용되는 방식은 다음과 같습니다. IN (System_B 자체를 사용하여) 입력을 생성하고 이러한 입력을 System_B를 통해 다시 처리하고 출력 O_B를 생성합니다. 따라서 프로세스는 다음과 같습니다.

System_B(IN) -> O_B.

그런 다음 System_A에서 자체 출력 O_A를 생성하기 위해 동일한 작업을 수행합니다.

System_A(IN) -> O_A.

언제든지 O_B는 예상 출력이고 O_A는 관찰 / 실제 출력이라고 가정합니다. O_B가 "골드"소스 (진실)임을 암시합니다. 그러나 우리는 문제의 조합에 부딪쳤다.

• O_A가 틀렸어 O_B가 맞아
• O_A가 맞아 O_B가 맞아
• O_A가 잘못되었습니다. O_B가 잘못되었습니다.
• O_A가 맞아 O_B가 틀렸다

O_B가 항상 옳다고 가정하면 무엇이 옳은지를 결정합니까 (또는 예상되는 것)? 글쎄, O_B는 때로는 인간 검사 및 분석에 잘못 (또는 종종) 잘못되었습니다. 이 프로세스를 사용하여 품질 보증을 통과하면 실제 사용자가 불만을 제기하고 결국 O_B가 잘못되었다는 사실로 되돌아갑니다.

문제는 이것입니다 : 실제 시스템을 테스트하기 위해 "테스트 시스템"을 만드는 것은 나쁜 습관입니까?

• 미끄러운 경사면은 어떻습니까? 그렇다면 "테스트 시스템"을 테스트하기 위해 또 다른 시스템이 필요하다고 주장 할 수 없습니까?
• 개발자는 이제 System_B의 복잡성이 System_A보다 큰 최소 2 개의 코드 기반을 학습해야하므로 비용이 엄청나게 엄청나게 비쌉니다. System_B가 조직에 얼마나 좋은지 나쁜지 어떻게 정량화 할 수 있습니까?
• System_B를 생성 한 최초의 "압착"이유 중 하나는 테스트를 "자동화"하는 것이 었습니다. System_B는 입력을 생성하여 자체적으로 출력을 생성하는 프로세스를 부트 스트랩하기 때문에 완전히 자동화 된 것을 매우 자랑스럽게 생각합니다. 그러나 우리는 양을 정할 수없는 방식으로 더 많은 피해를 입히고 더 많은 복잡성을 도입했다고 생각합니다. QA의 업무가 완전히 자동화됩니까? 병렬 시스템을 만들기에 충분한 이유가 있습니까?
• 우리가 모두 System_B가 잘못되었다는 것을 알고 있지만 내 진짜 관심사는 이것입니다. System_B가 입력을 처리하는 데 능숙하고 출력이 금 소스라면 System_A를 System_B로 바꾸지 않겠습니까? 이를 위해 직장에서 아무도 만족스러운 대응을 할 수 없습니다.

이 문제에 대한 모든 지침을 부탁드립니다.

• O_A가 틀렸어 O_B가 맞아

수정 A

• O_A가 맞아 O_B가 틀렸다

수정 B

• O_A가 맞아 O_B가 맞아

바라건대, 그들은 또한 동의합니다.

• O_A가 잘못되었습니다. O_B가 잘못되었습니다.

잘만되면, 그들은 동의하지 않기 때문에 당신은 그것에 대해 무언가를해야한다는 것을 알게 될 것입니다.

어떤 프로세스도 모든 것을 잡을 수는 없습니다. 물론 코드를 두 배로 늘 렸지만 O (2n)의 2와 같다고 생각하십시오. 통합 테스트까지 자동화 된 QA는 훌륭합니다. 수동 테스트는 inovation에 대한 드래그입니다. 특히 전체 테스트가 필요한 교차 절단 변경의 경우. 또한 다른 프로그래머가 동일한 것을 구현하게되므로 경쟁하게 할 수 있습니다.

다른 버그가 발생할 확률을 높이는 것은 다른 사람들이어야합니다. 시스템 A에서 대처하여 시스템 B를 작성하는 것은 권장하지 않습니다. 기존 O_A 사본을 새 사본과 비교하여 저장하면 동일한 결과를 얻을 수 있습니다.

문제는 이것입니다 : 실제 시스템을 테스트하기 위해 "테스트 시스템"을 만드는 것은 나쁜 습관입니까?

그렇다면 모든 테스트가 잘못되었습니다.

• 미끄러운 경사면은 어떻습니까? 그렇다면 "테스트 시스템"을 테스트하기 위해 또 다른 시스템이 필요하다고 주장 할 수 없습니까?

예, 우리는 그것을 주장 할 수 있습니다. 이 세 번째 시스템 인 system_A를 호출합니다. :피

• 개발자는 이제 System_B의 복잡성이 System_A보다 큰 최소 2 개의 코드 기반을 학습해야하므로 비용이 엄청나게 엄청나게 비쌉니다. System_B가 조직에 얼마나 좋은지 나쁜지 어떻게 정량화 할 수 있습니까?

너프 건으로 놀아 주도록 우리를 지불하는 행복한 고객 수. 수동 테스트 비용을 절감했습니다. 버그가 발견 될 때마다 유용성이 입증 될 무언가를 만들었습니다. 초기에 발견 된 버그는 늦게보고 된 버그보다 훨씬 저렴합니다.

• System_B를 생성 한 최초의 "압착"이유 중 하나는 테스트를 "자동화"하는 것이 었습니다. System_B는 입력을 생성하여 자체적으로 출력을 생성하는 프로세스를 부트 스트랩하기 때문에 완전히 자동화 된 것을 매우 자랑스럽게 생각합니다. 그러나 우리는 양을 정할 수없는 방식으로 더 많은 피해를 입히고 더 많은 복잡성을 도입했다고 생각합니다. QA의 업무가 완전히 자동화됩니까? 병렬 시스템을 만들기에 충분한 이유가 있습니까?

System_B의 복잡성은 System_A와 훌륭하게 격리되어 있습니다. System_B가 존재하므로 System_A에 기능을 추가하는 것이 어렵지 않습니다. System_B가 빠르게 진행할 수 있다는 확신을주기 때문에 실제로 더 쉽습니다.

• 우리가 모두 System_B가 잘못되었다는 것을 알고 있지만 내 진짜 관심사는 이것입니다. System_B가 입력을 처리하는 데 능숙하고 출력이 금 소스라면 System_A를 System_B로 바꾸지 않겠습니까? 이를 위해 직장에서 아무도 만족스러운 대응을 할 수 없습니다.

오타입니까? System_B는 종종 잘못되었으므로 System_A를 대체하는 데 사용하려는 최고의 표준입니까?

System_A가 종종 잘못되었다는 것을 의미한다고 가정합니다. 어떤 것이 가장 자주 잘못되었는지는 중요하지 않습니다. 어느 쪽이 잘못 되든지 작업이 필요한 것입니다. 이 시스템은 옳고 그름을 결정하지 않으며 개발자는 결정합니다. 시험은 무엇인가가 옳지 않다는 의견의 불일치를 만들어내는 것입니다. 개발자들은 그것이 무엇인지 알아냅니다. 여기서 생산되는 금본위 제는 없습니다. 동의 또는 불일치 만 있습니다. 의견 불일치에는 작업을 수행해야합니다. 그 일의 일부는 어디를 알아내는 것입니다.

실제로 고객이 사용하는 시스템이있는 경우 버그 수정 및 새로운 기능을 확인하기 위해 QA 시스템을 갖추어야합니다. 품질 관점에서 볼 때 프로덕션 시스템의 복제본은 가능한 한 근접해야합니다. 이렇게하면 프로덕션 시스템과 해당 QA 시스템이 동일한 지 확인하면 한 시스템에서 작동하는 시스템이 다른 시스템에서 작동해야합니다. 그렇지 않은 경우 시스템이 동일하지 않고 입력이 동일하지 않거나 출력이 잘못 해석 된 것입니다.

시스템이 미션 크리티컬하고 연중 무휴 24 시간 사용할 수 있어야하는 경우에는 두 배가됩니다. 그런 다음 프로덕션 시스템의 다운 타임을 최소화해야하므로 QA 시스템을 갖추지 못한 사치에는 아무런 도움이되지 않습니다. 24/7 시스템 인 경우 프로덕션 시스템의 정확한 복제본은 매우 강력하게 권장됩니다.

이 접근법의 명백한 단점은 비용입니다. 하드웨어 비용을 두 배로 늘리고 배포 및 유지 관리 비용을 높입니다. 또한 프로덕션 시스템에서 QA로 데이터를 지속적으로 복제해야 시스템에서 작업하는 데이터의 차이로 인해 다른 결과가 발생할 가능성을 최소화 할 수 있습니다.

일부 균형은 일반적으로 생산 시스템에 비해 QA 시스템의 일부 구성 요소를 축소하여 대부분의 기능을 올바르게 테스트 할 수 있습니다. 이들은 일반적으로 중복 서버, 서버 크기 또는 워크 스테이션 수입니다. 그러나 약간의 버그가 항상 축소 된 부분에서 정확하게 발견된다는 것이 나의 경험입니다. 그런 다음 프로덕션 시스템에서 허용되는 중단 시간을 최소화하면서 문제를 재현하고 수정을 구현하는 것은 악몽입니다.

시스템을 테스트 할 때마다 예상 결과가 무엇인지 알아야합니다.

시스템 이이 예상 결과를 생성하도록하는 데의 문제는 분명히 '시스템을 어떻게 테스트합니까?'입니다.

그럼에도 불구하고 사람들이 스프레드 시트를 사용하여 예상되는 결과를 생성하는 것을 보는 것은 일반적이지 않습니다.

하루가 끝나면 시스템 요구 사항을 해석하고 수동으로 예상 결과를 생성하기 위해서는 사람이 필요합니다. 시스템이 있고 차이점 만 확인하면 테스트를 건너 뜁니다.