중요하지 않은 작업에 엔드-투-엔드 및 통합 테스트가 가치가 있습니까?

엔드-투-엔드 및 통합 테스트 비용이 많이 드는 것으로 잘 알려져 있습니다. 물론 우리가 사람들이 죽을 수있는 응용 프로그램을 개발하면 문제가 발생할 경우 가치있는 투자입니다. 그러나 오류가 세계에서 끝나지 않는 응용 프로그램에서는 E2E 테스트 및 통합 테스트를 모두 건너 뛰고 문제가 발생할 경우 백업 계획을 작성하는 것이 더 저렴하지 않습니까? 사용자 유형에 대한 수동 테스트 + 단위 테스트 + 정적으로 유형이 지정된 언어를 사용하는 것과 비슷합니까?

예를 들어, 웹 상점에서 주문을 잃어버린 경우 대신 무료로 항목을 보낼 수 있고 다른 항목은 사과 할 수 있습니다. 최종 사용자는 이런 방식으로 더 행복해질 수 있으며 회사는 전체적으로 비용을 절약합니다.

내 질문은 일반적으로 통합 테스트 및 E2E 테스트 비용과 비용이 얼마나 듭니까? 이에 대한 위험 / 비용 계산 방법이 있습니까?

E2E 및 통합 테스트를 구현하든 아니든 상관없이 백업 계획이 필요합니다 . 시스템이 테스트 되었기 때문에 버그가 없을 것으로 예상하지 마십시오.

따라서 비용 산정에서는 E2E 테스트 구현 비용과 장애 발생시 백업 계획 예상 비용을 비교하지 않고 다음을 비교합니다.

• E2E 테스트를 수동으로 수행하기위한 비용 (새 릴리스 전에 여러 번)

vs.

• 자동화 된 E2E 테스트 구축 및 유지 비용

이러한 E2E 테스트를 여러 번 사용할 수있는 경우 일반적으로 비용이 손익 분기점에 도달하는 많은 테스트가 수행됩니다. 수동으로 수행 할 E2E 테스트와 자동화 할 사전 계획을 세울 때 적용해야하는 메트릭이어야합니다.

ROI가 즉각적으로 분명한 경우 쉽게 구현할 수있는 E2E 테스트가있을 수 있지만, 개발 및 유지 관리 비용이 몇 년에 걸쳐 수동으로 수행하는 것보다 비용이 많이 드는 E2E 테스트도 있습니다.

아마도 직관적으로 반박 할 수도 있습니다. 자동화 된 테스트는 실제로 테스트 시간을 단축하고 개발 시간을 단축 할 수 있습니다. 이기는 승리입니다.

아이디어는 테스트가 여러 수준에 기여한다는 것입니다

1. 엄격한 요구 사항 수집 및 사양

   이것은 개발 속도에 큰 영향을 미칩니다. 더 자세한 정보를 요구하지 않고, 오해, 불필요한 기능 등을 요구하지 않습니다.

2. 기능이 완료된 시점을 개발자가 알고 있음

   대부분의 테스트는 테스터가 완성 된 제품을 확인하는 것이 아니라 코드를 작성하는 동안 개발자가 수행합니다. 이 테스트를 자동화하면이 워크로드가 줄어 듭니다.

3. 새로운 기능으로 인한 버그가 즉시 감지되었습니다.

   스프린트 비용을 쉽게 낼 수 있으며 탐지되지 않은 경우 전체 기능을 다시 작성해야합니다.

4. 빠른 릴리스주기

   즉, 비행 중 코드가 적어 병합이 적고 개발자의 작업이 적고 복잡성이 줄어 듭니다.

특히 테스트 프레임 워크를 설정 한 경우 이러한 테스트를 작성하는 데 소요되는 시간은 이러한 효율성을 높이는 것보다 짧습니다.

또한 수동 테스트 시간을 절약하고 결국 더 나은 제품을 얻을 수 있습니다.

내 대답? 아마 아닐 수도 있습니다.

EOE 테스트는 매우 간단 할 때 좋습니다. 기본 시나리오를 다룰 계획이라면 EOE 테스트를 통해 이점을 얻을 수 있습니다. 그러나 실제로 복잡하고 규모가 큰 애플리케이션 (미션 크리티컬이든 아니든)이있는 경우이 EOE 테스트는 유지 관리 비용이 많이 들며 가치가 있는지 평가하려면 시나리오를 알아야합니다.

몇 년 전 Google 테스팅 블로그에서이 주제에 대해 논의했습니다. 저자 만 동의 할 수 있습니다. 좋은 테스트를 할 필요가 빠르고 , 신뢰성 및 분리 실패 의 EOE 테스트를 당신에게 제공 할 수없는 것을 특징으로한다.

많은 시나리오를 다루는 12 시간 이상의 엔드-투-엔드 테스트 가있는 응용 프로그램에서 작업했습니다 . 결국이 테스트를 다른 컴퓨터에 배포하여 테스트 시작, 실행 및 종료를 제어하고 결과를 수집 및 병합했습니다. 테스트 된 응용 프로그램은 단일 응용 프로그램 (테스트하기 쉽고 실행하기 쉬운 것)이었으며 테스트를 유지하기가 악몽이었습니다.

대부분의 시간 동안 결과에서 버그를 잡는 대신 테스트를 유지 관리했습니다. 엔드-투-엔드 테스트에서 버그의 근원을 발견하는 데 많은 시간이 걸립니다. 또한 많은 "거짓 부정적"테스트를 처리하고 문제를 이해하고 해결해야 할 시간이 거의 없었습니다. Java 애플릿로드 문제, 페이지에없는 예상 요소 (자동화 속도에 대한 다른 문제), 쿼리 코드 유지 데이터베이스 메모리 테스트에서 사용됩니다 (원래 쿼리는 데이터베이스 특정 코드를 사용하기 때문에).

이 모든 것들을 유지하고 운영하기 위해서는 사람들이 필요합니다. 결국 우리는 일부 EOE 테스트를 삭제하고 많은 단위 / 통합 테스트로 대체하기 시작했습니다.

따라서 보수적 인 조언은 Google의 테스트 피라미드를 사용하는 것입니다.

좋은 첫 번째 추측으로 Google은 70/20/10 분할 (70 % 단위 테스트, 20 % 통합 테스트 및 10 % 엔드 투 엔드 테스트)을 제안합니다. 정확한 혼합은 팀마다 다르지만 일반적으로 피라미드 모양을 유지해야합니다.

내 경험상 E2E 테스트는 앱의 중요도에 관계없이 항상 신중합니다. 나는 항상 최악의 시나리오에 대해 생각합니다. 만약 당신이 배 모양이라면, 당신은 경영진 앞에 서서 당신의 접근을 정당화합니까? 그렇지 않은 경우 접근 방식을 변경해야합니다. 많은 조직이 테스트에 할당되는 중요성과 리소스를 최소화하지만 문제가 발생했을 때 모든 사람이 책임을 져야 할 사람을 찾고 있으며 테스트를 제한하거나 해당 조언을 ​​제공하기로 결정한 경우 해고를 당할 수 있습니다. 선.

소프트웨어 개발은 ​​종종 조직 정치를 주시해야합니다.

엔드-투-엔드 및 통합 테스트는 비용이 많이 드는 것으로 잘 알려져 있습니다. "

나는이 주장에 동의하지 않는다고 생각한다.

첫째, E2E 테스트는 최종 사용자에게 중요한 것이며 복잡한 시스템을 테스트하기위한 가장 시간 효율적이고 가장 저렴한 옵션이 될 수 있습니다. 예를 들어, 누군가가 자동차를 구매할 때 대부분의 사람들은 자동차를 여러 조각으로 끌어 당기지 않고, 탄수화물, 기어 박스, 바퀴를 개별적으로 테스트하기 시작하지 않습니다. 대신 테스트 드라이브로 사용합니다.

둘째, 툴링 측면에서 E2E는 제품의 내부 발전 속도를 늦추지 않고 더 오래 지속됩니다. 당신이 그것에 대해 생각하면, 대부분의 제품의 실제 기능 표면은 그다지 크게 변하지 않지만 내부적으로 모든 종류의 개발에 영향을받을 수 있습니다. 결과적으로 테스트 툴링이 시작되고 실행되면 일반적으로 매우 오래 지속됩니다. 예를 들어, 우리가 자동차 비유로 돌아 가면. 동일한 "드라이브를 위해 가져 가라"테스트 사례는 Tesla에서와 마찬가지로 Ford Model T에서도 거의 작동합니다. 롤링 도로, 풍동 터널, 누출 테스트 설정 등에 대한 투자와 마찬가지로 내부 구성 요소 테스트 중 수명에 걸쳐 얼마나 많은 ROI를 달성 했습니까?

E2E 테스트는 초기 설정에 있지만 모든 것을 시도하고 테스트하는 데 사용되는 경우 더 비싸거나 부적절한 경향이 있습니다. 실제로이 함정을 피하는 가장 좋은 방법은 다음과 같은 것들의 테스트를 자동화하는 우선 순위에 있다고 생각합니다.

1. 자동화하기 쉽고 계속 유지하기 위해 많은 유지 보수가 필요하지 않습니다.
2. 일관되고 적절한 수동 테스트 프로세스를 적용하는 데 가장 많은 시간을 소비하십시오.
3. 제품이 파손 된 상태로 제품을 출시하면 자신이나 상사가 바보처럼 보일 위험이 있습니다.

귀하가 적절하다고 생각하는 E2E를 포함한 모든 형태의 테스트를 사용하십시오. 그래도 그에 집중하십시오.

버그가 단일 주문에만 영향을 미치는 최상의 시나리오 비용과 통합 테스트 비용을 실제로 비교할 수는 없습니다 . 논리적 버그는 많은 주문에 영향을 미칠 수 있습니다. 버그가 발생하면 결제가 이루어지지 않는다는 의미입니다. 이는 모든 비즈니스에 치명적인 영향을 줄 수 있습니다.

E2E 테스팅의 부족으로 인해 실제 생산에서 발생할 수 있는 최악의 버그 가 무엇인지 물어보아야합니다 . 머피의 법칙을 기억하십시오.

이 질문은 엔터프라이즈 웹 응용 프로그램에 관한 것이라고 가정합니다.

중간 정도의 중요 사항에 대한 나의 추천 :

• 백엔드 API에 대해 자동 테스트를 수행하여 백엔드가 예상대로 작동하는지 확인하십시오. 이 테스트는 API를 구현하는 동안 개발자가 작성해야합니다.
• 자동화 된 UI 테스트, 즉 프런트 엔드 테스트는 수동으로 수행하지 않아도됩니다.

대부분의 테스트는 API 수준 또는 구성 요소 수준에서 이루어져야한다고 생각합니다. 내부 기능 만 실행하는 단위 테스트는 신경 쓰지 않습니다.