더 나은 애자일 테스트로 가는 길

Capgemini에서 만든 연례 세계 품질 보고서에 따르면 설문 응답자의 42%는 테스트를 애자일 개발에 적용하는 데 있어 "전문적인 테스트 전문성 부족"을 문제로 꼽았습니다. 애자일의 출현으로 소프트웨어 개발의 반복 속도가 빨라지긴 했지만 어떤 경우에는 품질이 희생되기도 했습니다.

치열한 경쟁으로 인해 팀은 지속적으로 신제품 업데이트를 제공해야 하지만 테스트에 대한 관심 감소를 비롯한 자체 비용이 발생하기도 합니다. Rob Mason과 같은 일부는 더 나아가 Agile이 소프트웨어 테스트를 죽이고 있다고 주장합니다. 최근 페이스북은 품질 희생의 유혹을 해소하기 위해 모토를 '빨리 움직여서 깨기'에서 '안정적인 인프라로 빠르게 움직이기'로 바꿨다.

그렇다면 테스트를 애자일 소프트웨어 개발의 새로운 세계에 더 잘 통합하려면 어떻게 해야 할까요? 애자일 테스트.

기존의 테스트는 상당히 번거롭고 많은 문서에 의존합니다. 애자일 테스팅은 애자일 소프트웨어 개발 원칙을 모방하는 테스팅 프로세스에 대한 접근 방식으로 다음을 수행합니다.

• 테스트는 훨씬 더 자주 수행됩니다.
• 테스트는 문서에 덜 의존하고 팀 구성원 협업에 더 많이 의존합니다.
• 일부 테스트 활동은 테스터뿐만 아니라 개발자도 수행합니다.

지난 7년 동안 저는 많은 팀을 애자일 테스트로 전환했고 테스터와 협력하여 프로세스가 새로운 방법론에 맞도록 도왔습니다. 이 기사에서는 더 나은 애자일 테스트를 수행하는 과정에서 배운 가장 영향력 있는 몇 가지 팁을 공유합니다. Agile 사례 내에서 속도와 품질 사이에 마찰이 있는 것은 자연스러운 일이지만 이 기사에서는 민첩성을 손상시키지 않으면서 테스트 품질을 높이는 데 사용할 수 있는 몇 가지 기술을 다룰 것입니다. 여기에 설명된 대부분의 제안은 팀의 참여가 필요하므로 개발자와 테스터가 모두 계획에 참여하는 것이 좋습니다.

릴리스 테스트 주기 프로세스 공식화

테스트의 한 가지 문제는 릴리스 테스트 주기가 없거나 릴리스 일정이 없거나 불규칙한 테스트 요청이 있다는 것입니다. 주문형 테스트 요청은 특히 테스터가 여러 프로젝트를 처리하는 경우 QA 프로세스를 어렵게 만듭니다.

많은 팀은 각 스프린트 후에 단일 빌드만 수행하므로 Agile 프로젝트에 적합하지 않습니다. 일주일에 한 번 릴리스로 이동하는 것이 도움이 될 수 있으며 점차적으로 매주 여러 빌드로 전환됩니다. 이상적으로는 개발 빌드와 테스트가 매일 이루어져야 합니다. 즉, 개발자가 매일 리포지토리에 코드를 푸시하고 빌드가 특정 시간에 실행되도록 예약됩니다. 한 단계 더 나아가 개발자는 주문형 새 코드를 배포할 수 있습니다. 이를 구현하기 위해 팀은 CI/CD(지속적 통합 및 지속적 배포) 프로세스를 사용할 수 있습니다. CI/CD는 주요 릴리스 당일 빌드 실패 가능성을 제한합니다.

CI/CD와 테스트 자동화가 결합되면 중요한 버그를 조기에 감지할 수 있으므로 개발자는 예정된 클라이언트 릴리스 전에 중요한 버그를 수정할 수 있는 충분한 시간을 가질 수 있습니다. 애자일의 원칙 중 하나는 작동하는 소프트웨어가 진행 상황의 주요 척도라는 것입니다. 이러한 맥락에서 공식화된 릴리스 주기는 테스트 프로세스를 보다 민첩하게 만듭니다.

배포 도구로 테스터의 역량 강화

테스트의 일반적인 마찰 지점 중 하나는 코드를 스테이징 환경에 배포하는 것입니다. 이 프로세스는 팀이 영향을 미칠 수 없는 기술 인프라에 따라 다릅니다. 그러나 유연성이 있다면 테스터나 프로젝트 관리자와 같은 비기술적인 사람들이 스스로 테스트하기 위해 업데이트된 코드베이스를 배포할 수 있는 도구를 만들 수 있습니다.

예를 들어, 우리 팀 중 한 곳에서는 버전 제어에 Git을 사용하고 커뮤니케이션에 Slack을 사용했습니다. 개발자는 Git, 배포 스크립트 및 하나의 가상 머신에 액세스할 수 있는 Slackbot을 만들었습니다. 테스터는 GitHub 또는 Jira에서 얻은 브랜치 이름으로 봇을 ping하고 스테이징 환경에 배포할 수 있었습니다.

이 설정은 테스터가 개발자에게 테스트를 위해 분기를 배포하도록 요청해야 할 때 통신 낭비와 지속적인 중단을 줄이는 동시에 개발자에게 많은 시간을 제공했습니다.

TDD 및 ATDD 실험

테스트 주도 개발(TDD)은 품질에 중점을 둔 소프트웨어 개발 프로세스 유형입니다. 전통적으로 개발자는 코드를 작성한 다음 누군가가 코드를 테스트하고 버그가 발견되면 보고합니다. TDD에서 개발자는 사용자 스토리를 완성하는 코드를 작성하기 전에 먼저 단위 테스트를 작성합니다. 개발자가 테스트를 통과하기 위해 최소한의 코드를 작성할 때까지 테스트는 처음에 실패합니다. 그 후, 코드는 팀의 품질 요구 사항을 충족하도록 리팩토링됩니다.

수락 테스트 주도 개발(ATDD)은 TDD와 유사한 논리를 따르지만 이름에서 알 수 있듯이 수락 테스트에 중점을 둡니다. 이 경우 승인 테스트는 개발자, 테스터 및 요청자(클라이언트, 제품 소유자, 비즈니스 분석가 등)와 공동으로 개발 전에 생성됩니다. 이 테스트는 팀의 모든 사람이 코드를 작성하기 전에 클라이언트의 요구 사항을 이해하는 데 도움이 됩니다.

TDD 및 ATDD와 같은 기술은 테스트 절차를 개발 수명 주기의 초기 단계로 이동하여 테스트를 보다 민첩하게 만듭니다. 초기에 테스트 시나리오를 작성할 때 개발자는 요구 사항을 정말 잘 이해해야 합니다. 이는 불필요한 코드 생성을 최소화하고 개발 주기 초기에 제품 불확실성을 해결합니다. 제품에 대한 질문이나 갈등이 후기 단계에서만 드러나면 개발 시간과 비용이 늘어납니다.

작업 카드 이동을 추적하여 비효율성 발견

우리 팀 중 하나에는 특히 작은 기능으로 매우 빠른 개발자가 있었습니다. 그는 코드 리뷰 중에 많은 코멘트를 받았지만 우리 스크럼 마스터와 나는 경험 부족으로 그것을 썼습니다. 그러나 그가 더 복잡한 기능을 코딩하기 시작하면서 문제가 더 분명해졌습니다. 그는 코드가 완전히 준비되기 전에 테스트에 코드를 전달하는 패턴을 개발했습니다. 이 패턴은 일반적으로 개발 프로세스에 투명성이 부족할 때 발생합니다. 예를 들어, 다른 사람들이 주어진 작업에 얼마나 많은 시간을 소비하는지 명확하지 않습니다.

때때로 개발자는 가능한 한 빨리 기능을 제공하고 품질을 테스터에게 "아웃소싱"하기 위해 작업을 서두릅니다. 이러한 설정은 병목 현상을 스프린트 아래로 더 이동시킵니다. 품질 보증(QA)은 팀이 가지고 있는 가장 중요한 안전망이지만 QA의 존재는 개발자에게 품질 고려 사항을 생략할 수 있는 능력을 제공한다는 것을 의미할 수 있습니다.

많은 최신 프로젝트 관리 도구에는 스크럼 또는 칸반 보드에서 작업 카드의 이동을 추적하는 기능이 있습니다. 우리의 경우 Jira를 사용하여 해당 개발자의 작업에 어떤 일이 발생했는지 분석하고 팀의 다른 개발자와 비교했습니다. 우리는 다음을 발견했습니다.

• 그의 작업은 우리 보드의 테스트 열에서 거의 두 배의 시간을 보냈습니다.
• 그의 작업은 두 번째 또는 세 번째 수정 라운드를 위해 훨씬 더 자주 QA에서 반환됩니다.

따라서 테스터는 작업에 더 많은 시간을 할애하는 것 외에도 여러 번 수행해야 했습니다. 불투명한 프로세스로 인해 개발자가 정말 빠른 것처럼 보였습니다. 그러나 우리가 테스트 시간을 고려할 때 그것은 거짓으로 판명되었습니다. 사용자 스토리를 앞뒤로 옮기는 것은 분명히 린 접근 방식이 아닙니다.

이를 해결하기 위해 이 개발자와 솔직한 토론을 시작했습니다. 우리의 경우 그는 자신의 작업 패턴이 얼마나 해로운지 알지 못했습니다. 품질 요구 사항은 낮고 테스터 풀은 더 많았던 이전 회사에서 일하는 데 익숙해진 방법이었습니다. 우리의 대화와 스크럼 마스터와의 몇 번의 프로그래밍 세션의 도움으로 그는 점진적으로 더 높은 품질의 개발 접근 방식으로 전환했습니다. 그의 빠른 코딩 능력으로 인해 그는 여전히 높은 성과를 거두었지만 QA 프로세스의 "낭비"가 제거되어 전체 테스트 프로세스가 훨씬 더 민첩해졌습니다.

QA 팀 스킬셋에 테스트 자동화 추가

비 Agile 프로젝트의 테스트에는 테스트 분석, 테스트 설계 및 테스트 실행과 같은 활동이 포함됩니다. 이러한 활동은 순차적이며 광범위한 문서가 필요합니다. 회사가 애자일로 전환할 때 대부분의 경우 전환은 테스터보다는 개발자에게 집중됩니다. 그들은 광범위한 문서 작성(기존 테스트의 기둥)을 중단하지만 수동 테스트를 계속 수행합니다. 그러나 수동 테스트는 느리고 일반적으로 Agile의 빠른 피드백 루프에 대처할 수 없습니다.

테스트 자동화는 이 문제에 대한 인기 있는 솔루션입니다. 개발자와 테스터가 다른 작업에 집중하는 동안 테스트 코드를 백그라운드에서 실행할 수 있으므로 자동화된 테스트를 사용하면 새롭고 작은 기능을 훨씬 쉽게 테스트할 수 있습니다. 또한 테스트가 자동으로 실행되기 때문에 수동 테스트 노력에 비해 테스트 범위가 훨씬 더 커질 수 있습니다.

자동화된 테스트는 테스트 중인 코드베이스와 유사한 소프트웨어 코드 조각입니다. 이것은 자동화된 테스트를 작성하는 사람들이 성공하기 위해서는 기술적 능력이 필요하다는 것을 의미합니다. 여러 팀에서 자동화된 테스트를 구현하는 방법에는 다양한 변형이 있습니다. 때때로 개발자 자신이 테스터의 역할을 맡아 모든 새로운 기능으로 테스트 코드베이스를 늘립니다. 다른 팀에서는 수동 테스터가 테스트 자동화 도구 사용 방법을 배우거나 숙련된 기술 테스터를 고용하여 테스트 프로세스를 자동화합니다. 팀이 어떤 경로를 택하든 자동화는 훨씬 더 민첩한 테스트로 이어집니다.

테스트 우선 순위 관리

비 Agile 소프트웨어 개발의 경우 테스터는 일반적으로 프로젝트별로 할당됩니다. 그러나 Agile 및 Scrum의 출현으로 동일한 QA 전문가가 여러 프로젝트에서 작업하는 것이 일반적이 되었습니다. 테스터가 한 팀의 릴리스 테스트를 다른 팀의 스프린트 계획 세션보다 우선시할 때 이 중복되는 책임은 일정에 충돌을 일으키고 테스터가 중요한 행사를 놓칠 수 있습니다.

테스터가 때때로 여러 프로젝트에서 작업하는 이유는 분명합니다. 정규직 역할을 채우기 위해 테스팅을 위한 작업의 지속적인 흐름이 거의 없기 때문입니다. 따라서 이해 관계자가 팀에 전용 테스트 리소스를 할당하도록 설득하기 어려울 수 있습니다. 그러나 테스터가 테스트 활동에 참여하지 않을 때 다운타임을 채우기 위해 수행할 수 있는 몇 가지 합리적인 작업이 있습니다.

클라이언트 지원

한 가지 가능한 설정은 테스터가 스프린트 중단 시간을 클라이언트 지원 팀을 돕는 데 사용하도록 하는 것입니다. 테스터는 클라이언트가 가지고 있는 문제에 지속적으로 직면함으로써 사용자 경험과 개선 방법을 더 잘 이해하게 됩니다. 그들은 계획 세션 동안 토론에 기여할 수 있습니다. 또한, 클라이언트가 실제로 소프트웨어를 사용하는 방법에 더 익숙해지기 때문에 테스트 활동 중에 더 주의를 기울입니다.

제품 관리

테스터 우선 순위를 관리하는 또 다른 기술은 본질적으로 수동 테스트를 수행하는 하위 제품 관리자로 만드는 것입니다. 이것은 또한 주니어 제품 관리자가 사용자 스토리에 대한 요구 사항을 만드는 데 많은 시간을 할애하고 대부분의 작업에 대한 친밀한 지식을 가지고 있기 때문에 테스터의 근무 외 시간을 채우기 위한 실행 가능한 솔루션입니다.

테스트 자동화

이전에 논의한 바와 같이 수동 테스트는 종종 자동화보다 열등합니다. 이러한 맥락에서 자동화에 대한 추진은 테스터가 팀에 전적으로 관심을 기울이고 여가 시간에 학습하여 Selenium과 같은 테스트 자동화 도구를 사용하도록 하는 것과 결합될 수 있습니다.

요약: 품질 애자일 테스트

테스트를 보다 민첩하게 만드는 것은 많은 소프트웨어 개발 팀이 현재 직면하고 있는 불가피한 일입니다. 그러나 "가능한 한 빨리 테스트하라"는 사고방식을 채택하여 품질이 타협되어서는 안 됩니다. 애자일 전환에는 애자일 테스트로의 전환이 포함되어야 하며 이를 달성하는 몇 가지 방법이 있습니다.

• 릴리스 테스트 주기 프로세스를 공식화합니다.
• 배포 도구로 테스터의 역량을 강화하십시오.
• 테스트 주도 개발과 수용 테스트 주도 개발을 실험해보세요.
• 작업 카드 이동을 추적하여 비효율성을 발견합니다.
• QA 팀 스킬셋에 테스트 자동화를 추가합니다.
• 테스터 우선순위를 관리합니다.

매년 소프트웨어가 향상되고 사용자의 기대치가 높아집니다. 또한 고객이 Google, Apple 및 Facebook과 같은 최고 소프트웨어 브랜드의 고품질 제품에 익숙해짐에 따라 이러한 기대는 다른 소프트웨어 제품에도 전달됩니다. 따라서 품질에 대한 강조는 앞으로 더욱 중요해질 것입니다. 이러한 테스트 및 전반적인 개발 프로세스 개선은 테스트를 보다 민첩하게 만들고 높은 수준의 제품 품질을 보장할 수 있습니다.