소프트웨어 테스트에 RPA 활용: 전략적 접근이 필요한 이유

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

때때로 내 뉴스 피드에 "인생 꿀팁 Top 10" 같은 기사가 뜨곤 합니다. 평범한 가정용품을 예상치 못한 방식으로 사용해 삶을 개선하는 팁과 요령들 — "...7번 팁은 당신의 마음을 날려버릴 겁니다!!!"

인정하건대, 저는 이 클릭베이트에 낚여 열곤 했습니다. 솔직히 때때로 즐겁게 놀랐습니다. 예를 들어, 캔 따개로 성가신 플라스틱 블리스터 팩을 자르거나, 화장지 심으로 포장지가 풀리지 않게 할 수 있다는 걸 누가 알았겠습니까?

위 두 '꿀팁'을 시도해봤는데요? "그럭저럭" 작동했습니다... 잠시 동안. 캔 따개는 플라스틱이 융착된 이음새를 잘랐지만, 포장 길이 전체를 자르지는 못했습니다. 화장지 심은 잠시 포장지를 잡았지만, 결국 골판지가 약해지고 포장지가 풀렸습니다. 놀랍게도, 플라스틱 블리스터 팩에는 가위, 포장지에는 작은 테이프 조각을 쓰는 것이 훨씬, 훨씬 더 잘 작동했습니다.

아주 유사하게, 많은 조직이 이제 소프트웨어 테스트 자동화를 위해 RPA 사용을 고려하고 있습니다: 일종의 소프트웨어 테스트용 '기술 꿀팁(tech hack)'. 그러나 화장지 심이 내 포장지 풀림을 막는 지속 가능한 해결책이 아니었듯, RPA는 소프트웨어 테스트 자동화를 위한 지속 가능한 해결책이 아닙니다... 그리고 RPA 도구를 소프트웨어 테스트 자동화 작업에 지속 가능하게 만들기 위해 필요한 수정은, 글쎄요, 꿀팁(핵)일 것입니다.

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

그러나 성공적이고 지속 가능한 테스트 자동화는 애플리케이션 경로를 클릭하는 능력 이상이 필요하다는 것을 인식하는 것이 중요합니다. 업계 평균 테스트 자동화율 <20%라는 암울한 수준을 넘어서려면, 팀은 효과적인 자동화 테스트 스위트를 구축하고 안정화할 수 있어야 합니다. RPA 도구는 일반적으로 이를 가능하게 설계되지 않았습니다. 그 결과, 필요한 테스트 데이터와 테스트 환경을 기다리는 지연, 자동화 이니셔티브에 대한 신뢰를 떨어뜨리는 일관성 없는 결과, 상당한 리소스를 소비하지만 명확하고 실행 가능한 피드백을 제공하지 않는 '부풀린(bloated)' 테스트 스위트 같은 테스트 자동화 장애물에 부딪히게 됩니다.

가트너(Gartner)의 다음 정의를 비교해 RPA 도구와 테스트 자동화 도구의 범위 차이를 빠르게 살펴보세요:

RPA 도구: "구조화된 데이터에서 '만약, 그러면, 아니면' 문을 수행하며, 일반적으로 사용자 인터페이스(UI) 상호작용 조합이나 API 연결을 통해 클라이언트 서버, 메인프레임, HTML 코드를 구동합니다. RPA 도구는 RPA 도구 언어로 프로세스를 매핑해 소프트웨어 '로봇'이 따르게 하며, 제어 대시보드에 의해 런타임이 할당되어 스크립트를 실행합니다."

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

다음 핵심 차이점을 고려하면 이러한 추가 테스트 기능의 필요성이 명확해집니다:

• 프로덕션 환경에서 작업 시퀀스를 자동화해 명확히 정의된 프로세스 경로를 성공적으로 실행해 작업을 더 빠르게 완료하는 것, 그리고
• 테스트 환경에서 현실적인 비즈니스 프로세스를 자동화해 애플리케이션이 어디에서 실패하는지 확인해 애플리케이션이 릴리스하기에 너무 위험한지 정보에 입각한 결정을 내리는 것

이 차이점이 소프트웨어 테스트에 의미하는 것

• 자동화는 일반적으로 불완전하고 진화하며 제약이 있는 테스트 환경에서 실행되어야 함
• 상태 기반, 보안, 규정 준수 테스트 데이터 관리가 큰 과제가 됨
• 효과적인 테스트 케이스 설계가 성공의 필수 요소
• 실패는 비즈니스 리스크에 대한 통찰을 제공해야 함

더 구체적인 용어로, 온라인 여행 서비스 테스트 예를 들어보겠습니다. 사용자가 선불 호텔 예약을 연장하는 기능을 확인하고 싶다고 가정합니다. 먼저, 애플리케이션 로직을 철저히 검증하는 데 몇 개의 테스트가 필요한지, 각 테스트에 어떤 데이터 조합이 필요한지 결정해야 합니다.

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

다음으로, 연결된 호텔 예약 시스템(방 있음/없음), 신용카드(거래 승인/거절) 등에서 필요한 범위의 응답을 호출하는 방법이 필요합니다. — 하지만 실제로 객실을 예약하거나 신용카드를 청구하지 않고.

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

완전한 프로세스를 자동화한 후, 다양한 체크포인트에서 여러 검증을 구성해야 합니다. 적절한 세부 사항이 적절한 메시지 형식으로 호텔에 전송되었나? 예약이 사용자 데이터베이스에서 업데이트되었나? 결제 데이터가 신용카드 제공업체에 제대로 전송되었나? 계정 크레딧이 적용되었나? 예약을 연장할 수 없을 때 사용자가 적절한 메시지를 받았나? 신용카드가 거절되면? 신용카드가 거절되면 시스템이 실제로 지불하지 않은 추가 박수를 더하는 대신 원래 예약 길이로 되돌렸나?

이제 회사가 모든 선불 예약에 10달러 변경 수수료를 추가하기로 결정했다고 상상해보세요. 이 새로운 요구사항을 기존 자동화 테스트에 쉽게 반영할 수 있을까요? 아니면 모든 테스트를 실질적으로 재작업해야 할까요?

이 단순한 예조차도 RPA 도구가 해결하도록 설계되지 않은 소프트웨어 테스트의 많은 복잡성을 드러냅니다. RPA 도구는 시퀀스 내 특정 작업을 자동화하도록 구축되었습니다. 소프트웨어 테스트 자동화 도구는 더 넓은 작업 시퀀스의 회복탄력성을 측정하도록 설계되었습니다. 직설적으로 말하면: RPA 도구는 프로세스를 작동하게 만드는 아키텍처입니다. 하지만 소프트웨어 테스트에는 프로세스가 어떻게 깨질 수 있는지 판단하는 데 도움이 되는 도구가 필요합니다.

비효율적인 소프트웨어 테스트 자동화는 릴리스를 지연시키면서 엄청난 양의 리소스를 소비하는 것으로 악명이 높습니다. CIO들이 고객 경험을 더 빠른 소프트웨어 제공으로 개선하는 디지털 트랜스포메이션 이니셔티브에 점점 더 많이 투자함에 따라, 소프트웨어 테스트를 소홀히 하는 것은 역효과를 낳습니다. 올바른 도구를 선택하면 가속화된 제공, 비즈니스 리스크 감소, 혁신에 전념할 더 많은 리소스 측면에서 크게 보상받을 것입니다.

웨인 아리올라(Wayne Ariola)는 저자이자 DevOps 및 앱 개발 공간에서 잘 알려진 기조 연설자입니다.