자동화된 소프트웨어 테스트

Why is testing automation important to continuous delivery?

CD(지속적 제공)는 고객에게 새 코드 릴리스를 최대한 빠르게 제공하는 것을 중요시합니다. 자동화된 테스트는 그 목표를 달성하는 데 있어서 매우 중요합니다. 제공 프로세스 내에 시간이 많이 걸리는 수동 단계가 있으면 사용자에게 제공을 자동화할 수 없습니다.

CD는 더 큰 배포 파이프라인의 일부입니다. CD는 CI(지속적 통합)의 후속 도구이며 CI에 종속되기도 합니다. 새로운 코드 변경 사항에 대해 자동화된 테스트를 실행하고 해당 변경으로 인해 기존 기능이 손상되거나 새로운 버그가 발생하지 않는지 확인할 책임은 전적으로 CI에 있습니다. CD는 지속적 통합 단계가 자동화된 테스트 계획을 통과하면 트리거됩니다.

자동화된 테스트, CI 및 CD 간의 관계는 빠른 속도의 소프트웨어 팀에 많은 이점을 가져다 줍니다. 자동화된 테스트는 새로운 커밋으로 인해 버그가 발생하지 않도록 하여 개발의 모든 단계에서 품질을 보장하므로 소프트웨어는 항상 배포할 준비가 된 상태로 유지됩니다.

1. 엔드투엔드 테스트

구현해야 할 가장 가치 있는 테스트는 틀림없이 엔드투엔드(E2E) 테스트입니다. E2E 테스트는 소프트웨어 제품의 전체 스택에서 사용자 수준 경험을 시뮬레이션합니다. E2E 테스트 계획은 일반적으로 “사용자가 로그인할 수 있음” “사용자가 입금할 수 있음” “사용자가 이메일 설정을 변경할 수 있음”과 같은 사용자 수준의 사례를 다룹니다. 이 테스트는 새 커밋이 푸시되더라도 실제 사용자가 원활하게 버그 없는 경험을 하고 있다는 확신을 주기 때문에 구현하는 것이 아주 중요합니다.

E2E 테스트 도구는 사용자 작업을 캡처하고 재현하므로 E2E 테스트 계획은 주요 사용자 경험 흐름의 기록이 됩니다. 소프트웨어 제품에 자동화된 테스트 커버리지가 없는 경우 가장 중요한 비즈니스 흐름에 대한 E2E 테스트를 구현하면 최대한의 가치를 얻을 수 있습니다. E2E 테스트는 사용자 흐름 시퀀스를 캡처하고 기록하는 데 초기 비용이 많이 들 수 있습니다. 소프트웨어 제품이 매일 빠르게 릴리스되지 않는다면 팀이 직접 E2E 테스트 계획을 수동으로 실행하는 것이 더 경제적일 수 있습니다.

2. 단위 테스트

이름에서 알 수 있듯이 단위 테스트는 개별 코드 단위를 다룹니다. 코드 단위는 함수 정의로 측정하는 것이 가장 좋습니다. 단위 테스트는 개별 함수를 테스트합니다. 단위 테스트를 통해 함수에 대한 예상 입력이 예상 출력과 일치하는지 확인할 수 있습니다. 민감한 계산이 있는 코드(금융, 의료 또는 항공우주와 관련될 수 있음)의 테스트에 가장 적합한 것은 단위 테스트입니다. 단위 테스트는 저렴하고 구현이 빠르며 투자 대비 효과가 높습니다.

3. 통합 테스트

코드의 한 단위가 타사 서비스에 외부 호출을 하는 경우가 많습니다. 테스트 중인 기본 코드베이스는 해당 타사 유틸리티의 코드에 액세스할 수 없습니다. 통합 테스트는 이러한 타사 종속성을 모방하고 종속성과 인터페이스하는 코드가 예상대로 동작하는지 확인합니다.

통합 테스트는 작성 방식과 도구 측면에서 단위 테스트와 비슷합니다. 통합 테스트는 E2E 테스트에 대한 비용이 낮은 대안이 될 수 있지만 단위 테스트와 E2E의 조합을 이미 실행하고 있다면 투자 대비 효과에 대해서는 논쟁의 여지가 있습니다.

4. 성능 테스트

소프트웨어 개발의 맥락에서 '성능'은 소프트웨어 프로젝트가 반응하는 속도와 반응성을 설명하는 데 사용됩니다. 성능 메트릭의 예로는 '페이지 로드 시간', '최초 렌더링 시간', '검색 결과 응답 시간'이 있습니다. 성능 테스트는 이러한 예시 사례에 대한 측정값과 어설션을 만듭니다. 자동화된 성능 테스트는 이러한 메트릭 전반에 걸쳐 테스트 케이스를 실행한 다음 회귀나 속도 저하가 발생하면 팀에 알립니다.

어떤 유형의 소프트웨어 테스트를 수동으로 실행해야 합니까?

자동화할 수 있는 모든 테스트는 분명히 자동화해야 하며 생산성과 인건비 면에서 엄청난 이득을 줍니다. 하지만 자동화된 테스트 스위트를 개발하는 것의 ROI가 수동 테스트 실행에 비해 그만한 가치가 없을 때도 있습니다.

1. 예비 테스트

자동 테스트는 스크립트로 작성되며 일련의 단계에 따라 동작을 검증합니다. 예비 테스트는 더 무작위적이고 스크립트 없는 시퀀스를 시도하여 버그나 예상치 못한 동작을 찾아냅니다. 소프트웨어 예비 테스트 스위트를 구축할 수 있는 소프트웨어 도구도 있지만 아직 완전히 성숙되지 않았으며 널리 채택되지 않았습니다. 수동 QA 테스터를 할당하고 담당자의 창의력을 발휘하여 소프트웨어 제품의 버그를 찾는 것이 훨씬 더 효율적일 수 있습니다.

2. 시각적 회귀 테스트

소프트웨어 UI에 시각적 디자인 결함이 생기면 시각적 회귀가 발생합니다. UI 요소의 위치, 글꼴, 색상 등이 잘못된 것일 수 있습니다. 예비 테스트와 마찬가지로 이러한 회귀를 포착하는 자동화된 테스트를 작성하는 도구가 있습니다. 이러한 도구는 소프트웨어 제품의 다양한 상태에 대한 스크린샷을 캡처한 다음 OCR을 사용하여 예상 결과와 비교합니다. 이러한 테스트는 개발하는 데 비용이 많이 들며 도구가 널리 채택되어 있지 않습니다. 눈으로 직접 보고 시각적 문제가 있는지 수동으로 확인하는 것이 훨씬 더 효과적일 수 있습니다.

3. DevOps 팀을 위한 테스트 자동화 프레임워크 구축

자동화된 테스트의 모든 것을 아우르는 솔루션은 없습니다. 팀을 위한 자동화된 테스트 솔루션을 계획할 때 고려해야 할 몇 가지 주요 사항이 있습니다.

4. 릴리스 빈도

매달 또는 매주와 같이 고정된 간격으로 릴리스되는 소프트웨어 제품의 경우 수동 테스트가 더 적합할 수 있습니다. CI 및 CD는 자동화된 테스트에 종속되기 때문에 더 빠르게 릴리스되는 소프트웨어 제품은 자동화된 테스트의 효과를 크게 볼 것입니다.

5. 사용할 수 있는 도구 및 에코시스템

각 프로그래밍 언어에는 보완 도구와 유틸리티로 구성된 자체 에코시스템이 있습니다. 자동화된 테스트 패턴 유형에는 특정 프로그래밍 언어 에코시스템에서 사용할 수도 있고 사용하지 못할 수도 있는 고유한 도구 집합이 있습니다. 자동화된 테스트 패턴을 성공적으로 구현하려면 언어와 도구 지원이 함께 있어야 합니다.

6. 제품 시장 적합성 및 코드베이스 성숙도

팀이 대상 고객이나 비즈니스 모델이 아직 입증되지 않은 신제품을 만드는 중이라면 자동화된 테스트에 투자하는 것은 합리적이지 않을 수 있습니다. 자동화된 테스트는 예상치 못한 코드 회귀를 제한하는 보험 메커니즘 역할을 합니다. 팀이 빠른 속도로 진행하고 있는 경우 코드가 급격하고 빠르게 변경될 때 자동화된 테스트를 업데이트하고 유지 관리하는 데 엄청난 비용이 들 수 있습니다.

자동화된 테스트를 CD 파이프라인의 일부로 만드세요

자동 테스트는 최신 표준 소프트웨어 개발 방식입니다. 최고의 팀과 회사는 자동 테스트를 사용합니다. CI/CD는 자동 테스트에 종속되며 최고의 팀이 믿을 수 있고 강력한 소프트웨어를 고객에게 제공하는 데 매우 중요합니다.

Atlassian의 Open DevOps는 사용자가 즐겨 사용하는 도구로 CD 기반 개발 파이프라인을 구축할 수 있는 개방형 도구 체인 플랫폼을 제공합니다. DevOps 테스트 자습서를 통해 Atlassian 도구 및 타사 도구가 워크플로에 테스트를 통합하는 방법을 알아보세요.