2021.11.12

SaaS와 로우코드 애플리케이션 QA 테스트를 자동화하는 방법

Isaac Sacolick | InfoWorld
품질 보증 자동화 엔지니어는 레거시 모노리식 애플리케이션부터 마이크로서비스를 활용하는 클라우드 네이티브 애플리케이션에 이르기까지 기업 내부에서 개발된 애플리케이션을 테스트한다. 일반적인 미션 크리티컬 애플리케이션에는 코드 수준에서의 단위 테스트와 코드 리뷰, API 테스트, 자동화된 사용자 경험 테스트, 보안 테스트, 성능 테스트 등이 필요하다. 가장 모범적인 데브옵스 사례는 이런 테스트 실행을 자동화한 다음 CI/CD(지속적 통합 및 제공) 파이프라인 내에서의 지속적인 테스트를 위한 최적의 하위 집합을 선택하는 것이다.
 
ⓒ Getty Images Bank

그런데 서비스형 소프트웨어(SaaS) 플랫폼이나 시민 개발자에게 개발 권한을 주는 로우코드 개발 툴 또는 노코드 플랫폼으로 구성된 애플리케이션과 워크플로우, 통합, 데이터 시각화, 사용자 경험에는 어떻게 대처해야 할까? 과연 코드가 적게 혹은 아예 사용되지 않는다고 해서 필요에 따라 워크플로우가 기능하고 데이터 처리가 기업 요구사항에 따라 이뤄지며, 보안 구성이 회사 정책에 부합하고 성능이 사용자의 기대에 부응할까?

이 질문은 필자의 고등학교 시절 미적분학 선생님의 말씀을 떠올리게 한다. 선생님은 “단순히 추정만 하는 것은 나와 너희를 웃음거리로 만드는 일이다”라고 말했다. 이 말을 SaaS와 로우코드, 노코드의 경우에 대입하면, 테스트 계획 없이 막연히 앱이 요청한 대로 작동할 것이라고 상정할 경우 다음과 같은 문제로 이어질 수 있다.

•    이해관계자는 예상하지 못한 결과로 당혹스러운 상황 발생
•    데이터를 대중 혹은 액세스 권한이 없는 직원에게 노출시키는 보안 허점 발생
•    다른 통합 워크플로우와 고객 경험에 전파될 수 있는 데이터 문제 발생
•    애플리케이션을 많은 사용자와 더 큰 데이터 집합으로 확장할 때 성능 문제 발생
•    애플리케이션 재구축 및 해결책 개발 지시로 IT 부서 불만 발생

그렇다면 무엇을 테스트해야 할까? 기본 소스 코드에 액세스하지 않고도 이런 앱을 테스트할 수 있는 방법은 무엇일까? 특히 많은 데브옵스 조직에서 QA 엔지니어가 부족한 상황을 고려할 때 IT 부서는 테스트의 어느 부분에 우선순위를 둬야 할까?

몇몇 전문가에게서 이 질문에 대한 답을 얻었다.
 

애자일 수용 테스트의 정의 및 구현부터 시작해야 한다

런치다클리(LaunchDarkly) CTO 존 코두멀은 소프트웨어 개발이 필요한 애플리케이션뿐만 아니라 IT가 지원하는 모든 애플리케이션에 수용 테스트를 적용해야 한다는 점을 강조했다. 코두멀은 “일반적인 SaaS 모델에서 개발 부서는 릴리스 테스트 절차의 일부로 수용 테스트를 실시한다”라고 말했다.

비즈니스 및 사용자 수락 테스트를 정의하는 것은 중요한 출발점이다. 대부분의 SaaS와 로우코드/노코드 애플리케이션에는 구성이 필요하고 구현은 스크럼 또는 다른 애자일 방법론을 따를 수 있기 때문이다. 애자일 방식에는 문서화된 승인 기준이 포함된 사용자 스토리로 요구사항을 작성하는 것이 포함된다. 애자일 부서는 기업의 소규모의 기능 계약과 비기능적 요구사항과 같은 애자일 사용자 스토리를 관리해야 한다.

수용 기준을 정의하는 것은 중요한 첫 단계이다. 코딩이 필요하지 않거나 제한적인 구성만 필요한 SaaS 애플리케이션이라고 하더라도 이 단계에 따라야 한다.

하지만 IT 부서가 수용 기준을 정의하고 테스트를 자동화하는 일에 책임을 지지 않는다고 가정해보자. 이 경우 테스트의 부재로 위험이 발생하거나 사업 부서가 테스트를 맡게 된다. 2가지 경우 모두 썩 좋은 상황은 아니다. 테스트 기능을 비롯한 구현을 주도하는 업무는 IT 부서가 맡아야 한다.
 

로우코드/노코드에는 비즈니스 로직 테스트가 필요하다

로우코드/노코드 플랫폼은 추상화 계층을 제공하고 애플리케이션 개발, 지원, 개선 과정을 간소화한다. 하지만 이런 플랫폼을 사용하더라도 여전히 비즈니스 로직을 코딩하고 워크플로우를 구성해야 하며, 데이터 처리 규칙을 정의하고 액세스 역할을 선택해야 한다. 플랫폼이 작업을 간소화하지만 개발자가 부정확하게 로직을 구현하거나 로우코드/노코드 플랫폼에서 정확히 요구사항을 충족하는 방법을 아예 모를 수 있다는 위험성도 있다.

코두멀은 테스트가 2가지 부가적인 책임을 부여한다고 덧붙였다. “로우코드 솔루션 테스트는 2가지를 테스트하는 데 중점을 둔다. 하나는 로우코드 사용자가 표현하는 비즈니스 로직 테스트, 다른 하나는 로우코드 솔루션을 지탱하는 구조의 적절한 동작 테스트이다. 이 2가지 유형의 테스트로 애플리케이션이 최종 사용자의 기대에 부합해 작동하는지 확인한다”라고 말했다.

브라우저를 통해 사용자 상호작용을 포착하고 이런 흐름 테스트를 자동화하는 툴을 사용해 비즈니스 로직을 테스트할 수 있다. 기반 구조를 테스트하기 위해서는 데이터 모델, 권한, 양식, 보고서, 자동화가 표준을 충족하고 위험을 유발하지 않는지에 대한 검토가 필요할 수 있다.

모니타우르(Monitaur) CTO 앤드류 클라크는 자동화 테스트는 워크플로우와 애플리케이션의 비즈니스 프로세스 지원 방법에 초점을 맞춰야 한다면서 “SaaS 및 로우코드 애플리케이션을 테스트하는 효과적인 방법은 기본 입력 및 출력 검증을 수행하는 것이다. 시스템이 수행해야 하는 주요 이벤트 및 작업 매트릭스를 만들어 테스트 케이스를 설정해 시스템이 예상대로 동작하는지 검증해야 한다”라고 말했다.

나임(KNIME) 데이터 과학 에반젤리즘 책임자인 로사리아 실리포는 여기서 한 걸음 더 나아가 노코드/로우코드 애플리케이션도 비슷한 테스트 표준을 따라야 한다고 주장했다. 실리포는 “로우코드 애플리케이션에는 단위 테스트, 골든 테이블, 정상 종료 등 코드 기반 애플리케이션과 동일한 가이드라인을 따르는 자체 테스트 모음이 동반되어야 한다. 오류 발생 시 대응할 실패 코드가 없는 웹 서비스 또는 정상 종료가 없는 웹 애플리케이션을 구축하는 것은 코드 기반 애플리케이션과 마찬가지로 전문성이 결여된 방식이다”라고 말했다.
 

로우코드 테스트 플랫폼과 머신러닝 사용하기

로우코드/노코드를 사용한 개발이 개발 프로세스 속도를 높이고 개선 작업을 더욱 수월하게 하지만 데브옵스 부서는 여전히 테스트와 구성 검토를 수행해야 한다.

좋은 소식은 QA 엔지니어가 로우코드 테스트 플랫폼으로 테스트를 개발할 수 있다는 것이다. 소스 랩스(Sauce Labs) 산하 오토놈IQ(AutonomIQ) CEO 램 샨무갬은 “로우코드 테스트에서는 첨단 AI/ML 기법을 사용해서 테스트 스크립트를 작성하고 유지하는 과정이 기계를 통해 이뤄진다. 이를 통해 시간과 비용을 크게 절약할 수 있으며, 일반적인 개발자, 심지어 개발자가 아닌 사람도 테스트 자동화 스크립트를 생성할 수 있어 자동화 엔지니어에 대한 의존도도 낮출 수 있다. 궁극적으로 테스트 수행자는 이제 소프트웨어의 비즈니스 요구사항에 중점을 두고 사용자의 의도가 보존되는지 확인할 수 있다”라고 말했다.
 

로우코드 및 SaaS 플랫폼이 테스트를 자동화하는 방법

사용자 경험과 비즈니스 로직, 데이터 처리, SaaS 또는 로우코드 애플리케이션의 구성 테스트로 품질과 안정성, 보안을 충분히 검증할 수 있을까?

전체적인 품질은 로우코드 플랫폼 또는 SaaS 업체가 자체 기술을 어떻게 테스트하고 기반 클라우드 서비스와 인프라를 어떻게 관리하는지에 따라서도 좌우된다. 플랫폼 업체 대부분은 ISO, SOC, GDPR, PCI, FedRamp와 같은 보안 인증, 서비스 수준, 규정 준수 증명을 공개한다. 주요 업체는 릴리스 일정, 릴리스 노트, 알려진 결함, 서비스 수준 기록, 업타임 상태 확인을 위한 웹페이지 액세스도 공개한다. 하지만 아키텍처와 개발 표준, 테스트 방법에 관한 세부적인 내용을 제공하는 업체는 그렇게 많지 않다.

필자는 코베오(Coveo) 연구개발 부문 부사장인 마틴 라포트와 테스트 및 배포 방법에 관해 이야기한 적이 있다. 라포트는 “SaaS 플랫폼 구성 요소가 하루에도 여러 번 업데이트되는 세상에서 오류 비율 증가나 응답 시간 변동과 같은 변화를 감지하기 위해서는 관찰 가능성이 핵심이다. 이상 현상이 감지될 때마다 롤아웃이 중단되고 이전 정상 버전으로의 자동 롤백이 이뤄져야 한다”라고 설명했다.

이는 배포 빈도와 테스트 방식에 있어 까다로운 기준이며, SaaS 및 로우코드 플랫폼을 찾을 때 확인해야 할 사항이다. 이 정도 수준의 테스트와 함께 개발 부서의 테스트 자동화 노력이 보완되면 특히 높은 안정성이 필요한 애플리케이션의 배포 위험을 낮추는 데 도움이 된다. editor@itworld.co.kr


2021.11.12

SaaS와 로우코드 애플리케이션 QA 테스트를 자동화하는 방법

Isaac Sacolick | InfoWorld
품질 보증 자동화 엔지니어는 레거시 모노리식 애플리케이션부터 마이크로서비스를 활용하는 클라우드 네이티브 애플리케이션에 이르기까지 기업 내부에서 개발된 애플리케이션을 테스트한다. 일반적인 미션 크리티컬 애플리케이션에는 코드 수준에서의 단위 테스트와 코드 리뷰, API 테스트, 자동화된 사용자 경험 테스트, 보안 테스트, 성능 테스트 등이 필요하다. 가장 모범적인 데브옵스 사례는 이런 테스트 실행을 자동화한 다음 CI/CD(지속적 통합 및 제공) 파이프라인 내에서의 지속적인 테스트를 위한 최적의 하위 집합을 선택하는 것이다.
 
ⓒ Getty Images Bank

그런데 서비스형 소프트웨어(SaaS) 플랫폼이나 시민 개발자에게 개발 권한을 주는 로우코드 개발 툴 또는 노코드 플랫폼으로 구성된 애플리케이션과 워크플로우, 통합, 데이터 시각화, 사용자 경험에는 어떻게 대처해야 할까? 과연 코드가 적게 혹은 아예 사용되지 않는다고 해서 필요에 따라 워크플로우가 기능하고 데이터 처리가 기업 요구사항에 따라 이뤄지며, 보안 구성이 회사 정책에 부합하고 성능이 사용자의 기대에 부응할까?

이 질문은 필자의 고등학교 시절 미적분학 선생님의 말씀을 떠올리게 한다. 선생님은 “단순히 추정만 하는 것은 나와 너희를 웃음거리로 만드는 일이다”라고 말했다. 이 말을 SaaS와 로우코드, 노코드의 경우에 대입하면, 테스트 계획 없이 막연히 앱이 요청한 대로 작동할 것이라고 상정할 경우 다음과 같은 문제로 이어질 수 있다.

•    이해관계자는 예상하지 못한 결과로 당혹스러운 상황 발생
•    데이터를 대중 혹은 액세스 권한이 없는 직원에게 노출시키는 보안 허점 발생
•    다른 통합 워크플로우와 고객 경험에 전파될 수 있는 데이터 문제 발생
•    애플리케이션을 많은 사용자와 더 큰 데이터 집합으로 확장할 때 성능 문제 발생
•    애플리케이션 재구축 및 해결책 개발 지시로 IT 부서 불만 발생

그렇다면 무엇을 테스트해야 할까? 기본 소스 코드에 액세스하지 않고도 이런 앱을 테스트할 수 있는 방법은 무엇일까? 특히 많은 데브옵스 조직에서 QA 엔지니어가 부족한 상황을 고려할 때 IT 부서는 테스트의 어느 부분에 우선순위를 둬야 할까?

몇몇 전문가에게서 이 질문에 대한 답을 얻었다.
 

애자일 수용 테스트의 정의 및 구현부터 시작해야 한다

런치다클리(LaunchDarkly) CTO 존 코두멀은 소프트웨어 개발이 필요한 애플리케이션뿐만 아니라 IT가 지원하는 모든 애플리케이션에 수용 테스트를 적용해야 한다는 점을 강조했다. 코두멀은 “일반적인 SaaS 모델에서 개발 부서는 릴리스 테스트 절차의 일부로 수용 테스트를 실시한다”라고 말했다.

비즈니스 및 사용자 수락 테스트를 정의하는 것은 중요한 출발점이다. 대부분의 SaaS와 로우코드/노코드 애플리케이션에는 구성이 필요하고 구현은 스크럼 또는 다른 애자일 방법론을 따를 수 있기 때문이다. 애자일 방식에는 문서화된 승인 기준이 포함된 사용자 스토리로 요구사항을 작성하는 것이 포함된다. 애자일 부서는 기업의 소규모의 기능 계약과 비기능적 요구사항과 같은 애자일 사용자 스토리를 관리해야 한다.

수용 기준을 정의하는 것은 중요한 첫 단계이다. 코딩이 필요하지 않거나 제한적인 구성만 필요한 SaaS 애플리케이션이라고 하더라도 이 단계에 따라야 한다.

하지만 IT 부서가 수용 기준을 정의하고 테스트를 자동화하는 일에 책임을 지지 않는다고 가정해보자. 이 경우 테스트의 부재로 위험이 발생하거나 사업 부서가 테스트를 맡게 된다. 2가지 경우 모두 썩 좋은 상황은 아니다. 테스트 기능을 비롯한 구현을 주도하는 업무는 IT 부서가 맡아야 한다.
 

로우코드/노코드에는 비즈니스 로직 테스트가 필요하다

로우코드/노코드 플랫폼은 추상화 계층을 제공하고 애플리케이션 개발, 지원, 개선 과정을 간소화한다. 하지만 이런 플랫폼을 사용하더라도 여전히 비즈니스 로직을 코딩하고 워크플로우를 구성해야 하며, 데이터 처리 규칙을 정의하고 액세스 역할을 선택해야 한다. 플랫폼이 작업을 간소화하지만 개발자가 부정확하게 로직을 구현하거나 로우코드/노코드 플랫폼에서 정확히 요구사항을 충족하는 방법을 아예 모를 수 있다는 위험성도 있다.

코두멀은 테스트가 2가지 부가적인 책임을 부여한다고 덧붙였다. “로우코드 솔루션 테스트는 2가지를 테스트하는 데 중점을 둔다. 하나는 로우코드 사용자가 표현하는 비즈니스 로직 테스트, 다른 하나는 로우코드 솔루션을 지탱하는 구조의 적절한 동작 테스트이다. 이 2가지 유형의 테스트로 애플리케이션이 최종 사용자의 기대에 부합해 작동하는지 확인한다”라고 말했다.

브라우저를 통해 사용자 상호작용을 포착하고 이런 흐름 테스트를 자동화하는 툴을 사용해 비즈니스 로직을 테스트할 수 있다. 기반 구조를 테스트하기 위해서는 데이터 모델, 권한, 양식, 보고서, 자동화가 표준을 충족하고 위험을 유발하지 않는지에 대한 검토가 필요할 수 있다.

모니타우르(Monitaur) CTO 앤드류 클라크는 자동화 테스트는 워크플로우와 애플리케이션의 비즈니스 프로세스 지원 방법에 초점을 맞춰야 한다면서 “SaaS 및 로우코드 애플리케이션을 테스트하는 효과적인 방법은 기본 입력 및 출력 검증을 수행하는 것이다. 시스템이 수행해야 하는 주요 이벤트 및 작업 매트릭스를 만들어 테스트 케이스를 설정해 시스템이 예상대로 동작하는지 검증해야 한다”라고 말했다.

나임(KNIME) 데이터 과학 에반젤리즘 책임자인 로사리아 실리포는 여기서 한 걸음 더 나아가 노코드/로우코드 애플리케이션도 비슷한 테스트 표준을 따라야 한다고 주장했다. 실리포는 “로우코드 애플리케이션에는 단위 테스트, 골든 테이블, 정상 종료 등 코드 기반 애플리케이션과 동일한 가이드라인을 따르는 자체 테스트 모음이 동반되어야 한다. 오류 발생 시 대응할 실패 코드가 없는 웹 서비스 또는 정상 종료가 없는 웹 애플리케이션을 구축하는 것은 코드 기반 애플리케이션과 마찬가지로 전문성이 결여된 방식이다”라고 말했다.
 

로우코드 테스트 플랫폼과 머신러닝 사용하기

로우코드/노코드를 사용한 개발이 개발 프로세스 속도를 높이고 개선 작업을 더욱 수월하게 하지만 데브옵스 부서는 여전히 테스트와 구성 검토를 수행해야 한다.

좋은 소식은 QA 엔지니어가 로우코드 테스트 플랫폼으로 테스트를 개발할 수 있다는 것이다. 소스 랩스(Sauce Labs) 산하 오토놈IQ(AutonomIQ) CEO 램 샨무갬은 “로우코드 테스트에서는 첨단 AI/ML 기법을 사용해서 테스트 스크립트를 작성하고 유지하는 과정이 기계를 통해 이뤄진다. 이를 통해 시간과 비용을 크게 절약할 수 있으며, 일반적인 개발자, 심지어 개발자가 아닌 사람도 테스트 자동화 스크립트를 생성할 수 있어 자동화 엔지니어에 대한 의존도도 낮출 수 있다. 궁극적으로 테스트 수행자는 이제 소프트웨어의 비즈니스 요구사항에 중점을 두고 사용자의 의도가 보존되는지 확인할 수 있다”라고 말했다.
 

로우코드 및 SaaS 플랫폼이 테스트를 자동화하는 방법

사용자 경험과 비즈니스 로직, 데이터 처리, SaaS 또는 로우코드 애플리케이션의 구성 테스트로 품질과 안정성, 보안을 충분히 검증할 수 있을까?

전체적인 품질은 로우코드 플랫폼 또는 SaaS 업체가 자체 기술을 어떻게 테스트하고 기반 클라우드 서비스와 인프라를 어떻게 관리하는지에 따라서도 좌우된다. 플랫폼 업체 대부분은 ISO, SOC, GDPR, PCI, FedRamp와 같은 보안 인증, 서비스 수준, 규정 준수 증명을 공개한다. 주요 업체는 릴리스 일정, 릴리스 노트, 알려진 결함, 서비스 수준 기록, 업타임 상태 확인을 위한 웹페이지 액세스도 공개한다. 하지만 아키텍처와 개발 표준, 테스트 방법에 관한 세부적인 내용을 제공하는 업체는 그렇게 많지 않다.

필자는 코베오(Coveo) 연구개발 부문 부사장인 마틴 라포트와 테스트 및 배포 방법에 관해 이야기한 적이 있다. 라포트는 “SaaS 플랫폼 구성 요소가 하루에도 여러 번 업데이트되는 세상에서 오류 비율 증가나 응답 시간 변동과 같은 변화를 감지하기 위해서는 관찰 가능성이 핵심이다. 이상 현상이 감지될 때마다 롤아웃이 중단되고 이전 정상 버전으로의 자동 롤백이 이뤄져야 한다”라고 설명했다.

이는 배포 빈도와 테스트 방식에 있어 까다로운 기준이며, SaaS 및 로우코드 플랫폼을 찾을 때 확인해야 할 사항이다. 이 정도 수준의 테스트와 함께 개발 부서의 테스트 자동화 노력이 보완되면 특히 높은 안정성이 필요한 애플리케이션의 배포 위험을 낮추는 데 도움이 된다. editor@itworld.co.kr


X