테스트 자동화 프로젝트를 구축하기 전에 알아야 할 5 가지 이유

이론적으로 테스트 자동화 프로그램 또는 도구는 테스터가 일을 더 쉽게 만들고 여가 시간을 제공하며 평가 범위를위한 추가 이완 담요를 제공합니다.

그리고 많은 조직이 투자 된 리소스를 반환하고 절약 할 수있는 확장 가능하고 강력하며 우수한 테스트 자동화 인프라를 구현하지 못하고 있습니다. 일부 "버려" 작성된 테스트 자동화 작업과 다른 작업은 안정적인 자동화 제품군을 얻기위한 목표를 달성하기 위해 지속적으로 노력했습니다.

수년에 걸쳐 자동화 작업을 수행하려는 많은 회사를 관찰했으며, 약속 된 것을 제공하거나 목표로 설정하지 못해 폐기 된 서면 프로젝트, 프레임 워크 전환 및 관리자 해고를 목격했습니다.

실패에는 많은 이유가 있지만 자동화는 장기적으로 완벽하게 이해되지만보기보다 훨씬 더 어렵다는 것을 이해해야합니다.

다음은 테스트 자동화 프로젝트 구축을 시작하기 전에 알아야 할 몇 가지 이유입니다.

분석 및 질문 : 테스트 자동화 작업은 다른 응용 프로그램 프로젝트와 같은 작업이며 하나처럼 취급되어야합니다. 소프트웨어 프로젝트 계획을 어떻게 처리 하시겠습니까? 테스트 자동화 프로젝트 구현에 대해 생각할 때이 아이디어를 사용하십시오. 누구를 선택 하시겠습니까? 누가 생산 된 제품을 사용합니까? 작업에 가장 적합한 언어 또는 프레임 워크는 무엇입니까? 도전과 지침을 이해하고 엿볼 수 있습니까? 혼자서 아무것도 모르는 아키텍처를 구성 하시겠습니까? 아니면 자문가를 불러 몇 가지 생각을 해보시겠습니까?

이 모든 질문은 코드 한 줄을 작성하거나 심지어 상황을 테스트하기 전에 스스로에게 물어보아야 할 빙산의 일각 일뿐입니다.

불충분 한 기술 : 질문 하나하겠습니다. 검색 가능한 훌륭한 코드를 작성하는 방법을 이해하지 못하는 사람 또는 경험이없는 프로그래머에게 앱 디자인 스타일을 지정하고 처음부터 작성하는 방법을 이해하지 못하도록 허용 하시겠습니까? 대답은 '아니오'라고 생각합니다. 그렇다면 왜 그렇게 많은 기업들이 경험과 기술없이 누군가 평가 자동화 인프라를 통해 품질을 구현할 수 있다고 생각합니까? 전담 직원이 경험과 지식이없고 고용 할 사람을 고용 할 계획이 없다면 코드없는 자동화 도구 사용에 대해 생각해야합니다.

비현실적인 기대치 / 접근법 : 하나를 두 부분으로 나누겠습니다. 첫 번째는 테스트 자동화의 ROI (투자 수익)에 대한 잘못된 이해이고 두 번째 구성 요소는 시간당 비현실적인 기대 프레임 워크입니다. 당신이 만든 것만 큼 좋은 직업이 있으며, 시간을 투자하지 않고는 무언가를 기대할 수 없습니다. 나는 QA 엔지니어에게 잠복 인프라를 구성하기 위해 매주 6 시간을 확보했다고 말했습니다. 그가 6 시간을 달성하기를 기대해야합니까?

이 작업을 수행하려면 문의해야합니다.

• 테스트 자동화와 함께 달성하고자하는 목표는 정확히 무엇입니까?
• 노력 / 시간에 대한 환상적인 가치로 간주되는 것은 무엇입니까?
• 성취 기준은 무엇입니까?
• 그것을 실현하기 위해 얼마나 많은 시간 / 돈을 사용할 준비가되어 있습니까?

자동화는 "시작 및 삭제" 할당이 아닙니다. 유지 관리, 그룹 노력 및 발전이 필요한 지속적인 프로세스임을 인정하고 싶습니다.

슬프게도 일부 회사는 QA 엔지니어에게 비밀 작업을 제공하는 것이 작업자를 보호하거나 그의 주간 루틴에 "향신료"를 추가하는 유일한 방법으로 인식하고 있음을 인정해야합니다. 오해하지 마세요. 저는 우리가 노동자들을 보존하거나 그들에게 배우고 발전 할 시간을 제공해서는 안된다고 말하는 것이 아닙니다. 저는 그것이 노동자에게 현실적이고 투명한 기대치와 일치해야한다고 말하는 것입니다. .

불충분 한 계획 : 환상적인 자동화 프로젝트는 포괄적 인 기술 스타일로 발전 할 높은 수준의 계획과 계획으로 시작해야합니다. "하나의 크기에 모두 적합"전략조차도 성공에 치명적일 수 있습니다. 단일 회사에서 훌륭하게 효과가 있었다고해서 반드시 당신을 위해 일할 것이라는 의미는 아닙니다. 이 발표는 악기 선택에 대해 사실 일 수 있습니다. 실제로 해당 기술을 사용할 필요가 없을 때마다 화제의 단어가됩니다. 이것은 주목해야 할 매우 중요합니다. 이러한 도구가 제공 할 수있는 대안 및 이점 / 대안을 고려하지 않고도 높은 가격 대비 가치를 제공 할 수있는 많은 오픈 소스 및 상용 도구가 있습니다. 귀하의 요구에 맞는 도구를 선택하십시오. 여기 내 2 센트가 있습니다. 많은 시간을 낭비하는 것보다 솔루션에 비용을 지불하는 것이 훨씬 낫습니다 (프로그램의 비용 태그보다 훨씬 더 비싸게 될 것입니다).

이제 설계를 계획하는 방법에 대해 계속 논의하면서 포괄적 인 기술 아키텍처와 비즈니스 요구 사항에 대해 생각해야합니다. 다음은 고려해야 할 몇 가지 측면입니다.

• 사람들이 조사 할 작업, 모듈, 비즈니스 흐름을 상상해보십시오.
• 각 실행 단계에 대해 계획된 정책은 무엇입니까? (Sanity, Regression, CI / CD 전용 패키지?)
• 주요 공유 / 공통 / 반복 흐름 / 기능은 무엇입니까?
• 간단한 독립형 아티팩트에 대한 모든 테스트를 어떻게 계획합니까? (SetUp 및 TearDown, 생성 된 평가 데이터 대신 외부 데이터에 대한 종속성, 각 테스트, 스위트 클래스 전에 실행해야하는 것은 무엇입니까?)
• 한 평가가 동시성으로 실행되는 경우 다른 평가가 "중단"되는 것을 어떻게 방지합니까?
• 확장 가능하고 깨끗하며 적절한 분위기를 어떻게 만들 수 있습니까? (모의 서버, 데이터베이스 케이스, 정리 스크립트, 브라우저 기본 설정, 그리드 / 서버 구성, 설정 및 정리, 가상 환경 또는 도커 컨테이너).
• 우리가 사용한다면 정확히 무엇을 빌드할까요?
• 종속성을 정확히 어떻게 관리 할 수 있습니까?
• 우리 프로젝트는 어디에 저장됩니까?
• 얼마나 많은 엔지니어가 프로젝트에서 작업하고 있으며 변형 관리를 관리하는 방법은 무엇입니까?
• 빌드를 수행하는 데 가장 적합한 CI 도구는 무엇입니까?
• CI / CD 워크 플로를 구현 하시겠습니까?
• 자신의 실행 플랫폼을 설계하는 데 사용할 수있는 테스트와 리소스를 어디에서 실행 하시겠습니까? (클라우드 솔루션 허가를 구매하기위한 자금을 제공 받았습니까? 자체 Selenium 서버 인프라를 구축하기위한 도구 또는 지원이 있습니까?)
• 정확히 어떤 종류의 테스트가 곧 자동으로 이루어 지나요? (API, 시각적 개념, 서버 프로세스, 웹 / UI 자동화, 모바일-Android / IOS).
• 추가 평가가 필요한 대규모 데이터 수집, 긴 흐름, 복잡한 프로세스, 통합이 있습니까?
• GUI를 통해 무엇을 테스트해야하며 API를 통해 확인하는 것이 더 안전 할 수 있습니까?
• 근본 원인 평가 및 디버깅을 더 간단하게 만들기 위해 정확히 어떤 로그,보고 메커니즘, 핸들러 및 리스너를 구현해야합니까? (하루에 결과를 이해하는 데 헌신한다면 1 시간 자동화 제품군은 무엇입니까?)
• 실행이 제공해야하는 메트릭 / 보고서 / 출력은 무엇입니까?
• 우리가 정말로 원하는 통합은 정확히 무엇입니까? (보고 프로그램, ALM 도구, 버그 추적기, 평가 관리 프로그램).
• 누가 인프라를 구성 할 수 있으며 누가 테스트를 구현해야합니까? (둘 사이에 분기가있을 수도 있습니까?)
• 자동화 엔지니어에게 자동화되어야하는 비즈니스 흐름 / 테스트 사례 / 비즈니스 로직을 제공 할 책임이있는 사람은 누구입니까?
• 향후 목표를 결정하기 위해 정의 된 POC (개념 증명) 단계가 있습니까?

간단히 말해서 질문 중 일부에 불과합니다. 여기서 빼내야 할 것은

적절한 도구 옵션, 우수한 계획 / 설계는 실패와 성공의 차이를 만들어 낼 수 있습니다.

모든 것을 자동화하기 : 주목해야 할 중요한 점은 무엇을 자동으로 할 수 있거나해야하는 것이 아니라는 것입니다. 때때로 인식이나 잘못된 관리 결정이 있으면 테스터의 머리에 오는 모든 것을 자동화하거나 테스트 케이스를 맹목적으로 스크립트로 변환합니다. 우선, 모든 평가가 자동화에 적합한 것은 아닙니다. 둘째, 테스트 케이스 자체는 작업에 적합하지 않습니다. 이것은 유지할 수없는 자동 테스트의 묶음으로 끝납니다. 슬프게도 대부분의 경우 우리가 작성한 많은 작업을 표시하게 될 것입니다. 회사가 때때로 동일한 비즈니스 로직을 확인하는 수만 개의 테스트 인스턴스를 자동화 팀을 유지 관리 할 자금이없는 경우 자동화에 추가 가치가 없습니다.

또한 모든 자동화 빌드를 유지하는 데 필요한 사항에 대한 명확한 계획을 만들어야합니다. 회귀에는 무엇이 포함됩니까? 우리의 이성이란 무엇입니까? CI / CD 파이프 라인에 들어갈만큼 안전하고 신뢰할 수있는 것은 무엇입니까?

테스트 자동화 는 적절한 가치를 제공하기위한 견고한 계획, 이해, 헌신 및 헌신이 필요합니다.

기술 부족 / 적절한 교육, 잘못된 도구 선택, 불충분 한 리소스, 적절한 준비 부족, 비현실적인 기대 등이 모두 프로젝트를 실패하게 만들 수 있습니다.

이 보고서가 긍정적 인 영향을 미치고 여러분 중 일부가 생산적인 사고 방식을 따르는 데 도움이되기를 바랍니다.