메뉴

애자일 세계에서 효율적인 테스트 자동화를 구현하는 방법

how implement efficient test automation agile world

문제를 제거하기 위해 도구를 사용해보십시오

Agile의 자동화는 매우 중요합니다.

모든 Sprint에 추가되고 제공되는 많은 기능에 대해 생각해보십시오. 새로 추가 된 기능이 기존 기능에 영향을 미치지 않도록하는 방법이 있어야합니다.

스프린트 기간이 짧기 때문에 스프린트 끝에서 제품이 증가 할 때마다 전체 슈트를 실행하는 것은 사실상 불가능합니다. 자동화 된 테스트 슈트를 갖는 것이 여기서 더 큰 역할을 할 것입니다.

그러나 자동화를 도입하고 성숙시키는 데는 확실히 시간이 걸립니다. 자동화 활동을 계획하고 설계하는 데 초기 투자를 수행하면 장기적으로는 확실히 성과가있을 것입니다.

애자일 테스팅 고급 시리즈의이 3 부에서는 프로젝트에 자동화를 도입 할 때 내 경험을 바탕으로 고려할 몇 가지 지침을 인용하려고합니다.

또한 읽기 1 부 과 2 부 먼저 주제를 더 잘 이해해야합니다.

학습 내용 :

Agile에서 무엇을 자동화해야합니까?

프로젝트에 자동화를 도입 할 계획이있을 때마다 우리 대부분은 즉시 'Smoke Tests suit'또는 'regression test suit'를 최고로 선택합니다. 자동화 후보 . 물론 그렇습니다.하지만 자동화 테스트 피라미드를 생각할 때 우리가 말하는 피라미드의 최상위 계층에 불과하다는 결론을 내릴 수 있습니다.

위의 레이어 외에도 우리는 여전히 서비스 계층 그리고 단위 레이어 더 중요합니다.

안드로이드를위한 최고의 무료 음악 다운로더 앱

그렇다면 Smoke 테스트 및 회귀 테스트 외에 어떤 테스트가 자동화에 적합한 후보가 될 수 있습니까?

# 1) 빌드 및 배포

기존 환경에서는 매주, 격주 또는 매월 일 수있는 미리 정의 된 빌드가 있습니다. 그 이유 중 하나는 이러한 배포에 시간이 걸리기 때문입니다. 이 접근 방식의 문제점은 미리 정의 된 날짜를 기다려 버그를 수정하거나 새로운 기능을 구현해야하기 때문에 지연이 발생한다는 것입니다.

두 번째 이유는 테스터가 테스트를 마치고 버그와 결함을 발견 할 때까지 프로그래머가 다른 구현 부분으로 옮겨 가고 이전 애플리케이션의 버그를 해결하는 데 관심이 줄어 들었습니다. 이 접근 방식은 또한 프로덕션에서 기능을 사용할 수 있도록하는 시간을 지연시킵니다.

빌드 및 배포는 반복적이고 때로는 지루한 엔티티입니다. 또한 빌드를 배포하는 데 몇 시간이 걸릴 수 있으며 이로 인해 테스트가 지연되고 결국 피드백이 지연됩니다. 반복적 인 작업이기 때문에 배포는 자동화를위한 좋은 후보가됩니다.

또한 읽으십시오=> 릴리스 및 배포 관리 프로세스

자동화 된 빌드 배포의 몇 가지 이점은 다음과 같습니다.

  • 배포 실수의 가능성 없음 (잘못된 파일 복사 또는 파일을 잘못된 위치에 복사하는 것과 같은 인적 오류를 피할 수 있음)
  • 버그 / 기능은 수정되는 즉시 테스트 할 수 있습니다.
  • 테스터는 테스트에 더 많은 시간을 할애합니다.
  • 이 기능은 짧은 시간에 프로덕션으로 이동할 준비가되었습니다.
  • 빠른 피드백

# 2) 단위 테스트 / 구성 요소 테스트

나는 이미 사용하여 단위 계층을 자동화하는 중요성에 대해 이야기했습니다. 지난 튜토리얼의 TDD 접근 방식 .

이것은 피라미드의 가장 낮은 층을 형성하므로 기초와 모든 기초는 견고해야합니다. 개발 팀은 대부분의 테스트를이 계층에 수용하기 위해 협력하고 협력해야합니다.

# 3) API / 웹 서비스 테스트

웹 서비스는 두 응용 프로그램이 기본 아키텍처 또는 기술을 방해하지 않고 요청 및 응답 측면에서 데이터 또는 정보를 교환하는 매체입니다. 더 간단하게 말하면, 요청을 제공하고 응답을 검증하는 것은 웹 서비스 테스트에서 일반적으로 수행하는 작업입니다.

웹 서비스 테스트 이러한 웹 서비스 메서드를 호출하는 프로그램을 작성하고 반환되는 값의 유효성을 검사해야합니다. 다양한 순열과 조합에 대해 서비스를 테스트 할 수도 있습니다. Excel 시트에 모든 테스트 데이터가 있으면 프로그램이 데이터를 읽고 테스트 데이터를 매개 변수로 전달하여 테스트 가능한 서비스를 호출하고 결과를 검증 할 수 있습니다.

이 특정 테스트는 피라미드 중간층의 일부입니다. 대부분의 기능 테스트는이 계층으로 푸시 될 수 있습니다. 이 계층에서 발생하는 결함을 해결하면 쉽게 수정할 수 있으며 UI를 사용할 수있을 때까지 연기되지 않습니다.

# 4) GUI 뒤에서 테스트

GUI 뒤에서 테스트를 자동화하는 것은 실제 GUI를 자동화하는 것보다 비교적 쉽습니다. 또 다른 장점은 UI 변경에 관계없이 기능이 그대로 유지된다는 것입니다. 일부 UI 요소가 변경 되더라도 기능의 기능은 변경되지 않습니다. 이 기술은 주로 비즈니스 논리 및 규칙에 중점을 둡니다.

테스트 케이스는 대부분 표 형식이나 스프레드 시트로 작성되며, 이러한 테이블의 입력을 받아들이고 결과를 반환하는 픽스처 / 코드 조각이 작성됩니다. 결과는 즉시 생성되며 비 기술적 이해 관계자가 이러한 테스트를 실행하고 예상 결과를 얻을 수있는 훌륭한 플랫폼을 제공합니다. 이 기술을 달성하는 데 사용되는 도구 중 하나는 적합 .

# 5) 비 기능 테스트

이 비 기능 테스트 기술 기본적으로 부하, 성능 및 스트레스 테스트가 포함됩니다. 이러한 테스트를 자동화하는 데 사용할 수있는 다양한 도구가 시장에 나와 있습니다.

# 6) 데이터 비교

대부분의 테스트에서는 텍스트 파일, CSV 또는 Excel 파일을 포함한 데이터 파일을 비교해야합니다.

미국의 무료 이메일 제공 업체 목록
  • 이러한 파일은 데이터 유효성 검사를위한 기준과 비교할 수 있습니다.
  • 비교는 동일한 데이터이지만 다른 형식 일 수 있습니다. 이것은 기본적으로 두 개의 다른 소스에서 생성 된 두 개의 동일한 파일이있을 때 발생합니다.

이러한 비교는 반복적 일 수 있으므로 자동화됩니다.

# 7) 검색

많은 파일에서 특정 엔티티를 검색하는 것도 지루할 수 있으며 반복적 인 작업 인 경우 하나님이 우리를 도와 주 십니다. 한 가지 예는 로그 파일을 검색하는 것입니다. 이것이 또한 자동화에 대해 생각해야하는 것보다 지루하고 반복적 인 작업이라면.

# 8) 반복적 인 작업

반복적 인 경우 최종 사용자와 상호 작용하거나 스토리를 작성하여 시작하는 모든 작업은 자동화에서 고려되어야합니다. 자동화를 수행한다고해서 정교한 도구 / 기술이 포함되어야하는 것은 아니라는 점을 이해해야합니다. 목적을 해결하기 위해 간단한 VB 매크로 또는 Javascript가있는 Java 프로그램 일 수 있습니다.

어디서 시작하나요?

자동화를 시작할 위치를 알려주는 글 머리 기호 나 단계별 가이드가 없습니다. 팀을 위해 자동화를 시작하려면 자동화하려는 측면 또는 자동화의 궁극적 인 목표가 무엇인지 브레인 스토밍하고 깊이있는 생각을 적용해야합니다.

다음으로 시작할 수 있습니다.

  • 반복적 인 작업 식별,
  • 응용 프로그램의 고통 영역 식별
  • 테스트 과제 식별

투어 프로젝트 / 팀에 자동화가 없다면 단위 테스트를 먼저 대상으로 할 수있는 다 계층 접근 방식을 사용하여 자동화 할 수 있습니다. 이것은 당신에게 가장 높은 ROI를 줄 것입니다.

동시에 테스터는 연기 테스트 슈트 작업을 시작한 다음 회귀 작업을 시작할 수 있습니다. 팀이 기술을 습득하고 편안함을 느끼면 점차적으로 다른 반복 작업을 자동화하는쪽으로 이동합니다.

요구 사항을 평가하지 않고 새 도구를 직접 구입하지 마십시오. 앞서 말했듯이 간단한 프로그램이나 매크로를 사용하면 일부 반복 작업을 자동화하려는 목적을 해결할 수 있습니다. 따라서 도구를 구매하기 전에 POC 수행 그 도구가 사용하기에 효과적인지 평가합니다.

자동화를위한 올바른 테스트 케이스를 선택하는 방법에 대한 자세한 내용과 다음 기사에서 자동화 작업 예측에 대한 통찰력을 제공 한이 문서를 살펴보십시오. 자동화 테스트 프로세스 문제에 대한 수동 과 셀레늄 자동화 프로젝트의 평가를 테스트합니다.

자동화 및 도구의 범위가 확정되면 다음은 프레임 워크를 설계하는 것입니다.

Agile에서는 프레임 워크가 진화했습니다. 전체 프레임 워크를 먼저 디자인 한 다음 구현하는 것을 목표로하지 마십시오. MVP (최소 실행 가능 제품)를 위해 설계 및 구현 한 다음 더 많은 기능을 포함하도록 기존 프레임 워크를 향상시킵니다. 또한 자동화 제품군을 견고하게하려면 좋은 코딩 및 개발 사례를 적용해야합니다.

몇 가지 모범 사례

  • 한 번에 100 % 자동화를 목표로하지 마십시오. 작게 시작하십시오. 진화하는 과정임을 기억하세요
  • 소프트웨어 개발을 위해 따르는 것과 동일한 Agile 관행을 따르십시오. 자동화에는 적절한 계획과 설계도 필요합니다. 자동화 할 때 기술 부채를 늘리고 싶지 않을 것입니다.
  • 테스트 자동화 백 로그를 생성합니다. 이 백로 그는 새로운 기능 구현에서 기존 기능 향상에 이르기까지 다양합니다. 식별 된 항목에 스토리 포인트를 부여하고 그에 따라 할당합니다. 이러한 백 로그 항목을 Sprint로 가져와 Kanban 보드를 사용하여 추적합니다.
  • 자동화 스토리에 대한 허용 기준을 작성하십시오. 이러한 허용 기준에는 다음이 포함될 수 있습니다.
    • CI와 테스트 스위트 통합
    • 슈트를 중앙 위치로 포팅
    • 이메일을 통해 결과 보내기
    • 테스트 실패시 오류 로그 파일 전송 제공
    • 기타 기준….
  • 새 도구를 평가하는 데 너무 많은 시간을 소비하지 마십시오. 새 도구에서 원하는 모든 것에 대한 우선 순위가 지정된 체크리스트를 만들고이를 평가할 타임 라인을 결정할 수 있습니다. 정해진 시간 내에 결과가 나오지 않으면 다음으로 넘어 가세요
  • 무엇을 자동화할지 현명하게 결정하십시오. 모든 자동화가 효과적이지 않고 긍정적 인 ROI를 제공합니다. 자동화를 위해 자동화하지 마십시오.
  • 적절한 개발 환경을 사용하십시오. 지역에 코드를 보관하지 마십시오. 코드를 보관할 리포지토리를 확보하고 하루가 끝날 때 코드를 확인하는 습관을 만드십시오.
  • 비슷한 방식으로 중앙 위치에서 자동화 된 테스트를 실행 해보십시오. 사람을 독립적으로 만드십시오. 팀의 모든 사람이 자신의 컴퓨터에서 스크립트를 트리거 할 수 있고 이메일을 통해 결과를 얻을 수 있어야합니다.

자동화에 적용 할 수있는 애자일 원칙은 무엇입니까?

매우 간단한 몇 가지 팁 :

  • 단순하게 유지하십시오. 필요한 것을하십시오. 자동화를 불필요하게 복잡하게 만드는 설탕 코팅 구현을 제공하는 많은 사례를 보았습니다. 필요하지 않은 것은 피합시다
  • 간단한 일을한다고해서 가장 쉬운 일을하는 것은 아닙니다. 즉, 자동화 목표를 달성하기 위해 아기 단계를 밟아야합니다. 자동화하기 위해 간단한 기능을 사용할 수 있지만 자동화 구현이 복잡한 것으로 판명 될 수 있습니다.
  • 전체 팀 접근 방식 적용 . 저는 모두가 애자일 팀의 테스터라고 믿습니다. 테스터 나 개발자에게만 자동화 작업을 제한하지 마십시오. 각 분야는 프로젝트의 자동화를 달성하기 위해 서로의 입장에서야합니다. 이 접근 방식은 구현시 발생하는 기술적 문제를 해결하는데도 효과적입니다.
  • 프레임 워크는 Agile에서 진화합니다. . 불필요하게 자동화를 복잡하게 만들 수있는 기능을 너무 많이 제공하지 마십시오.
  • 시간을내어 올바르게하십시오. 기술적 부채를 피하기 위해 시간을내어 적절하게 설계하십시오.
  • 자주 피드백 받기
  • 적절한 코딩 표준과 관행을 적용하십시오. 디자인은 단순해야하며 OOPS 개념을 적용하고 테스트를 서로 독립적으로 유지해야합니다. 테스트 슈트의 '유지 보수성'과 같은 요소 고려

Agile에서 자동화하는 동안 문제가 있습니까?

애자일 세계에서 자동화는 자신의 도전 :

  • 우리는 정말 잘 계획해야합니다. 적절한 테스트 스위트, 도구, 프레임 워크 및 접근 방식을 결정하려면 모두 적절한 전략이 필요합니다. 그러나 우리는 계획을 과도하게하지 않는 것을 기억해야합니다. MVP (최소 실행 가능 제품)를 염두에 두십시오.
  • 빠른 제공을 원하기 때문에 코드 품질 저하 : 자동화에도 기술적 부채가 있음을 기억해야합니다.
  • 대부분의 팀 팀은 '전체 팀 접근 방식'을 따르지 않고 테스터의 책임을 추가하는 테스터를 위해 자동화 된 제품군을 코딩하고 유지 관리하는 모든 책임을 맡깁니다.
  • 기능 테스트 자동화는 UI 자동화보다 어렵습니다.

이러한 모든 과제 중에서 가장 중요한 과제는 테스터의 기술을 업그레이드하는 것입니다.

팀의 자동화를 수행하고 유지하는 것은 프로그래머 (개발자)가 수행하는 프로그래밍 (개발) 활동과 거의 같습니다. 구현뿐만 아니라 자동화 된 슈트를 CI에 통합하는 것도 중요하며 테스터는 새로운 기술을 배우고 채택하며 새로운 도구와 기술을 배워야합니다.

Agile에 적합한 일부 오픈 소스 도구

  • 셀레늄 WebDriver -UI 용
  • 셀레늄 그리드 – 병렬 실행 용
  • 오이 – BDD 용
  • JMeter – 성능 테스트 용
  • 비누 – 웹 서비스 용
  • WireMock – 웹 서비스를 사용할 수 없을 때 웹 서비스 테스트.
  • Epochs-모바일 용

유명한 애자일 테스트 사분면으로 마무리하겠습니다.

애자일 테스트 사분면

사분면 1 TDD 방식으로 자동화 할 수있는 단위 및 구성 요소 테스트입니다.

2 사분면 BDD 접근 방식을 적용 할 수있는 기능 테스트에 대해 이야기합니다.

사분면 3 수동 테스트 범위가있는 유일한 사분면입니다.

4 사분면 기본적으로 일부 도구로 수행 할 수있는 테스트에 대해 이야기합니다. 이것은 부하 테스트, 스트레스 테스트, 볼륨 테스트 및 보안 테스트를 처리합니다.

결론

Smoke 테스트 및 회귀 테스트를 제외하고는 많은 자동화 범위가 있습니다. 따라서 우리는 자동화를 이러한 유형의 테스트에만 국한시키는 개념에서 벗어나야합니다. 즉, Agile에서 테스터의 기술 세트는 단순히 버그와 결함을 찾는 것 이상을 요구한다는 것을 의미합니다.

수동 테스트를위한 샘플 테스트 케이스

테스터는 더 많은 협업이 필요하고 프로그래밍 / 자동화 기술을 연마해야합니다. 점점 더 많은 테스트가 자동화되면 테스터가 더 정교하고 까다로운 작업에 참여할 수있는 더 많은 시간이 주어집니다.

저자 정보 : 이 기사는 STH 팀원 Shilpa의 글입니다. 그녀는 인터넷 광고, 투자 은행 및 통신과 같은 도메인에서 지난 10 년 이상 소프트웨어 테스트 분야에서 일하고 있습니다.

아래에 귀하의 의견과 생각을 공유하십시오.

추천 도서

^