소프트웨어 테스트에 RPA 사용:"기술 해킹"?

비효율적인 소프트웨어 테스트 자동화는 엄청난 양의 리소스를 소비하면서 릴리스를 지연시키는 것으로 유명합니다.

종종 내 뉴스 피드에는 "10대 생활 꿀팁"을 제공하는 기사가 있습니다. 다음은 평범한 가정용품을 사용하여 삶을 개선하는 예상치 못한 방법에 대한 팁과 트릭입니다. "...그리고 팁 번호 7은 당신의 마음을 사로잡을 것입니다!!!"

분명히, 나는 이 클릭 미끼를 여는 데 빨려 들었습니다. 솔직히 기분 좋게 놀랠 때가 있다. 예를 들어, 성가신 플라스틱 블리스터 팩을 캔따개로 자르거나 화장지 롤을 사용하여 포장지가 풀리지 않도록 할 수 있다는 것을 누가 알았겠습니까?

나는 위의 두 가지 "해킹"을 시도했고 무엇을 추측합니까? 그들은 "약간" 일했습니다… 잠시 동안. 깡통따개는 플라스틱이 융합된 이음새를 잘랐지만 포장 길이를 자르지 못했습니다. 휴지는 잠시 동안 포장지를 붙들고 있었지만 결국 판지가 약해지고 포장지가 풀렸습니다. 당연히 플라스틱 블리스터 팩에 가위를 사용하고 포장지에 작은 테이프를 사용하는 것이 훨씬 더 효과적이었습니다.

매우 유사한 맥락에서 많은 조직이 이제 RPA를 사용하여 소프트웨어 테스트를 자동화하는 것을 고려하고 있습니다. 일종의 소프트웨어 테스트를 위한 "기술 해킹"입니다. 그러나 화장지 롤이 포장지가 펴지지 않도록 하는 지속 가능한 솔루션을 제시하지 않은 것처럼 RPA는 소프트웨어 테스트 자동화를 위한 지속 가능한 솔루션이 아니며 소프트웨어 테스트 작업을 위해 RPA 도구를 지속 가능하게 만드는 데 필요한 수정 사항 자동화는 해킹이 될 것입니다.

조직에 이미 RPA 도구가 있고 테스트 자동화를 시작하려는 경우 RPA 도구가 논리적인 선택처럼 보일 수 있습니다. 일반적으로 몇 가지 기본적인 테스트 시나리오(예:새 사용자 생성 및 트랜잭션 완료)를 자동화하고, 유효성 검사를 추가하고, 테스트 자동화로 가는 길에 있다고 믿는 것은 비교적 쉽습니다.

그러나 성공적이고 지속 가능한 테스트 자동화에는 애플리케이션 경로를 클릭하는 기능 이상의 것이 필요하다는 점을 인식하는 것이 중요합니다. 암울한 업계 평균 테스트 자동화 비율인 <20%를 초과하기 위해 팀은 효과적인 자동화 테스트 제품군을 구성하고 안정화할 수 있어야 합니다. RPA 도구는 일반적으로 이를 가능하게 하도록 설계되지 않았습니다. 결과적으로 필요한 테스트 데이터 및 테스트 환경을 기다리는 지연, 자동화 이니셔티브에 대한 신뢰를 약화시키는 일관되지 않은 결과, 상당한 리소스를 소비하지만 명확하게 제공하지 않는 "비대해진" 테스트 제품군과 같은 테스트 자동화 장애물에 부딪히게 됩니다. 실행 가능한 피드백.

RPA 도구와 테스트 자동화 도구 간의 범위 차이에 대한 간략한 개요를 보려면 Gartner의 다음 정의를 비교하십시오.

RPA 도구는 "일반적으로 UI(사용자 인터페이스) 상호 작용의 조합을 사용하거나 API에 연결하여 클라이언트 서버, 메인프레임 또는 HTML 코드를 구동함으로써 구조화된 데이터에 대해 'if, then, else' 문을 수행합니다. RPA 도구는 소프트웨어 "로봇"이 따르도록 RPA 도구 언어로 프로세스를 매핑하여 작동하며 런타임은 제어 대시보드에서 스크립트를 실행하도록 할당됩니다."

테스트 자동화 도구는 “조직이 자동화된 기능 테스트를 설계, 개발, 유지 관리, 관리, 실행 및 분석할 수 있도록 지원합니다. … 소프트웨어 개발 수명 주기(SDLC) 전반에 걸쳐 제품과 기능의 폭과 깊이를 제공합니다. 여기에는 테스트 설계 및 개발이 포함됩니다. 테스트 케이스 유지 및 재사용; 및 테스트 관리, 테스트 데이터 관리, 자동화된 테스트 및 통합, 지속적인 테스트 지원에 중점을 둡니다."

이러한 추가 테스트 기능의 필요성은 다음과 같은 몇 가지 핵심 차이점을 고려할 때 명확해집니다.

• 생산 환경에서 일련의 작업을 자동화하여 프로세스를 통해 명확하게 정의된 경로를 성공적으로 실행하여 작업을 더 빨리 완료할 수 있습니다.
• 실제 비즈니스 프로세스를 자동화합니다. 애플리케이션이 릴리스하기에 너무 위험한지 여부에 대해 정보에 입각한 결정을 내릴 수 있도록 애플리케이션이 실패하는 위치를 확인하기 위한 테스트 환경

소프트웨어 테스트에서 이러한 차이점은 무엇을 의미합니까?

• 자동화는 일반적으로 불완전하고 진화하며 제한적인 테스트 환경에서 실행되어야 합니다.
• 상태 저장, 보안, 규정 준수 테스트 데이터를 관리하는 것은 큰 도전이 됩니다.
• 효과적인 테스트 케이스 설계는 성공에 필수적입니다.
• 실패는 비즈니스 위험에 대한 통찰력을 제공해야 합니다.

좀 더 구체적으로 설명하자면, 온라인 여행 서비스를 테스트하는 예를 생각해보자. 사용자가 선불 호텔 예약을 연장할 수 있는 기능을 확인하려고 한다고 가정합니다. 먼저 애플리케이션 로직을 철저히 실행하기 위해 얼마나 많은 테스트가 필요한지, 그리고 각각 어떤 데이터 조합을 사용해야 하는지를 결정해야 합니다.

그런 다음 테스트 시나리오를 실행할 수 있는 상태로 애플리케이션을 설정하는 데 필요한 모든 데이터를 획득하고 프로비저닝해야 합니다. 이 경우 미래의 특정 날짜에 대한 기존 선불 예약이 있는 기존 사용자 계정이 (최소한) 필요하며 GDPR과 같은 개인 정보 보호 규정으로 인해 실제 프로덕션 데이터를 사용할 수 없습니다.

다음으로 연결된 호텔 예약 시스템(객실 사용 가능/사용 불가), 신용 카드(거래 승인/거부) 등에서 필요한 범위의 응답을 호출하는 방법이 필요하지만 실제로 객실을 예약하거나 요금을 청구하지 않습니다. 신용카드.

물론 프로세스를 자동화해야 합니다. 여기에는 로그인, 기존 예약 검색, 수정 의사 표시, 확장 기간 지정이 포함됩니다.

전체 프로세스가 자동화되면 다양한 체크포인트에서 여러 검증을 구성해야 합니다. 적절한 세부 정보가 적절한 메시지 형식으로 호텔에 전송되었습니까? 사용자 데이터베이스에서 예약이 업데이트되었습니까? 결제 데이터가 신용 카드 제공업체에 제대로 전송되었습니까? 계정 크레딧이 적용되었습니까? 예약을 연장할 수 없는 경우 사용자가 적절한 메시지를 받았습니까? 신용카드가 거부된 경우는 어떻게 됩니까? 신용 카드가 거부된 경우 실제로 지불되지 않은 숙박을 추가하지 않고 시스템이 원래 예약 기간으로 되돌아갔습니까?

이제 회사에서 모든 선불 예약에 대해 $10의 변경 수수료를 추가하기로 결정했다고 상상해 보십시오. 이 새로운 요구 사항을 기존의 자동화된 테스트에 쉽게 적용할 수 있습니까? 아니면 이 사소한 변경 사항을 수용하기 위해 모든 테스트를 상당히 재작업해야 합니까?

이 간단한 예에서도 RPA 도구가 해결하도록 설계되지 않은 많은 소프트웨어 테스트 복잡성 중 일부를 노출합니다. RPA 도구는 시퀀스 내에서 특정 작업을 자동화하도록 구축되었습니다. 소프트웨어 테스트 자동화 도구는 광범위한 작업 시퀀스의 탄력성을 측정하도록 설계되었습니다. 직설적으로 말하자면, RPA 도구는 프로세스가 작동하도록 설계되었습니다. 그러나 소프트웨어 테스트를 위해서는 프로세스가 중단될 수 있는 방법을 결정하는 데 도움이 되는 도구가 필요합니다.

비효율적인 소프트웨어 테스트 자동화는 엄청난 양의 리소스를 소비하면서 릴리스를 지연시키는 것으로 악명이 높습니다. CIO가 더 빠른 소프트웨어 제공을 통해 고객 경험을 개선하는 디지털 혁신 이니셔티브에 점점 더 많은 투자를 함에 따라 소프트웨어 테스트를 생략하는 것은 비생산적입니다. 작업에 적합한 도구를 선택하면 제공 가속화, 비즈니스 위험 감소, 혁신에 전념할 더 많은 리소스 측면에서 상당한 성과를 거둘 수 있습니다.

Wayne Ariola는 IT 리더를 위한 지속적인 테스트의 저자이자 DevOps 및 App Dev 분야의 유명한 기조 연설자입니다.