애자일 테스트는 애자일 방법론의 원칙을 제품 테스트에 적용하여 지속적인 테스트를 모든 개발 단계에 통합합니다.
다른 어떤 개발 방법론보다도 소프트웨어 개발에 대한 애자일 접근 방식은 비즈니스가 앱 개발 프로세스에 접근하는 방식을 완전히 바꾸어 놓았습니다. 선형적 시스템에서 팀이 후속 단계를 시작하기 전에 전체 프로젝트 단계를 완료해야 하는 보다 전통적인 '워터폴' 방법론과 달리 애자일 개발은 팀이 여러 프로젝트 단계에서 동시에 작업할 수 있도록 지원합니다.
이 접근 방식의 장점으로는 시장 출시 기간 단축, 프로젝트 투명성 향상, 프로젝트 도중에 목표를 변경하거나 기타 새로운 데이터를 고려할 수 있는 유연성 등이 있으며, 애자일 접근 방식의 핵심 요소는 애자일 테스트입니다.
애자일에서는 프로젝트의 개발 단계가 완료될 때까지 테스트를 기다릴 필요가 없습니다. 그 대신 테스트가 다른 개발 작업과 함께 지속적으로 운용됩니다. 더 뛰어난 품질의 최종 제품을 얻을 수 있도록 테스트 담당자는 개발자, 경우에 따라서는 고객과도 협력합니다.
애자일 테스트와 워터폴 접근 방식을 구분하는 몇 가지 차이점이 있습니다.
위에서 설명했듯이 전통적인 소프트웨어 개발 방식에서는 개발 수명주기가 끝날 때까지 테스트가 늦춰집니다. 워터폴 방법론에서 각 프로젝트 단계는 이전 단계가 완료될 때까지 기다려야 시작할 수 있기 때문입니다. 따라서 테스트 및 통합 단계는 개발 작업이 이미 완료된 시스템 설계 및 구현 단계 이후에나 개시될 수 있습니다.
이렇게 경직된 개발 모델은 명확하게 구조화되어 있고 상대적으로 관리하기 쉽지만, 몇 가지 단점도 있습니다. 프로젝트 요구 사항이 예기치 않게 변경되거나 테스트를 통해 초기 개념적 단계에 내재한 문제가 드러난 경우, 이러한 문제가 고려되도록 적응하기가 거의 불가능할 수 있습니다. 간단히 말해서 개발 후까지 테스트가 미뤄지면 변경 사항과 소프트웨어 버그를 처리하기가 어려워지고, 비용도 많이 들며, 팀이 마감일을 지키기 힘들어질 수 있습니다. 결국 바람직하지 못한 선택을 하는 경우가 많은데, 모든 문제가 해결될 때까지 출시를 연기하거나 수준 이하의 제품을 출시하여 부정적 결과를 낳는 경우도 있습니다.
워터폴 방법론과 달리 애자일에서는 모든 개발 단계에서 테스트가 진행됩니다. 소프트웨어 코드가 업데이트될 때마다 테스트 팀이 개입하여 자동으로 해당 기능을 확인합니다. 아니면 초기 테스트를 사용하여 코드의 형태를 만들지 결정할 수 있습니다. 또한, 테스트에는 최종 사용자를 포함하는 사용성 테스트뿐만 아니라 자동화된 솔루션이 포함될 수 있습니다.
모든 단계에서 테스트를 구현한다는 점이 혼란스러워 보일 수 있지만, 실제로는 개발 내내 테스트를 통해 팀이 더 나은 최종 제품을 더 빨리 제작할 수 있습니다. 그러기 위해서는 다음과 같은 몇 가지 중요한 애자일 원칙을 준수해야 합니다.
- 지속적인 피드백
테스트 담당자는 사용자 피드백과 테스트 결과를 개발자에게 지속적으로 배포해야 합니다. - 고객 만족
긍정적인 사용자 경험을 제공하는 것이 모든 애자일 테스트 담당자의 일차적인 목표여야 합니다. - 제약 없는 커뮤니케이션
애자일에서는 의사소통이 무엇보다 중요하며, 개발자와 직접 소통함으로써 오류와 오해를 줄이고 사용자 피드백을 더욱 효과적으로 전달할 수 있습니다. - 단순성
애자일 방법론에서는 불필요한 테스트나 잘못된 작업이 수행되어서는 안 됩니다. 애자일 테스트 담당자는 필요한 모든 테스트를 수행하되, 필수적인 테스트만 수행해야 합니다. - 적응성
애자일 테스트 담당자는 프로젝트 변경 사항과 사용자 피드백을 지속적으로 확인해야 합니다. - 공동 작업
테스트 담당자는 기술보다 상호작용을 중요시하며, 사람을 위해 사람들과 직접 협력합니다. 사람에게 분명히 초점을 맞추면 사용성의 우선순위를 정하는 데 도움이 됩니다.
애자일 테스트는 애자일 개발 방법론의 필수적인 부분이기 때문에 애자일 테스트에서 제공하는 이점은 애자일의 다른 장점과 밀접하게 연관되어 있습니다. 그 이점은 다음과 같습니다.
애자일 테스트를 통해 팀은 개발 프로세스 초기에 결함을 감지하고 수정할 수 있어 버그가 출시 시점까지 해결되지 않을 확률이 줄어듭니다. 동시에 모든 개발 팀원이 테스트에 관여하므로, 각자 차별화된 기술을 활용하여 더 나은 최종 제품을 만들 수 있습니다.
전통적인 개발에서는 모든 개발 단계가 완료될 때까지 제품이 출시되지 않습니다. 안타깝게도 기술 진화의 속도가 빨라져 몇 개월 동안 개발이 늦어지면 배포 가능한 시점이 되었을 때 기능은 물론 심지어 제품 전체가 완전히 쓸모 없어질 수 있습니다. 개발 및 테스트를 전체 수명주기에 걸쳐 지속적으로 통합하면 제작이 빠르게 진행되고 현재 시장에 적합한 애플리케이션을 선보일 수 있습니다.
팀이 조립 라인처럼 운영되면 프로젝트가 테스트 단계로 넘어오기를 기다리느라 테스트 담당자가 많은 시간을 낭비하게 됩니다. 애자일 테스트는 이렇게 허비되는 시간을 없애 테스트 담당자가 개발자와 동시에 업무를 수행할 수 있습니다. 즉, 더 짧은 시간에 더 많은 작업을 완료할 수 있게 됩니다.
고객을 비롯한 다른 최종 사용자는 지금 당장 솔루션을 필요로 하며, 제품 출시를 오래 기다려야 하면 흥미를 잃게 됩니다. 애자일 테스트는 애플리케이션을 더 빠르게 제공할뿐더러 애플리케이션을 상시 개선하여 더 나은 고객 경험을 선사할 수 있습니다.
Agile 테스트가 개발 수명주기의 모든 단계에서 이루어지지만, 효과적인 Agile 테스트 전략에는 다음과 같은 4가지 단계로 구성된 자체 수명주기가 포함되어 있습니다.
흔히 '반복 제로(Iteration 0)'라고 하는 애자일 테스트의 초기 단계에서는 테스트를 진행하는 데 필요한 기초 작업을 다룹니다. 여기에는 프로젝트의 비즈니스 케이스, 범위, 경계를 설정하는 동시에 주요 요구 사항을 요약하고 위험을 식별하며 비용을 예측하는 작업이 포함됩니다. 아울러 필수 테스트 자원(인력과 도구 포함)을 식별하고 보호하는 작업도 포함됩니다.
대부분의 애자일 테스트가 이 단계에서 이루어집니다. 구성 반복은 확인 테스트 또는 조사 테스트로 분류될 수 있는 반복 테스트 작업입니다. 확인 테스트는 기능이나 제품이 해결하도록 정해진 용도를 충족하는지 확인합니다. 조사 테스트는 사용성, 통합 결함 등 제품 용도와 직접 관련이 없는 버그 또는 기타 문제를 찾습니다.
프로젝트 완수 시점이 다가오면 애자일 테스트 담당자는 완성된 소프트웨어를 전체적으로 확인해야 합니다. 여기에는 전체 시스템 테스트 및 수용 테스트가 포함되며, 이는 일반적으로 개발 도중에 이루어지는 테스트보다 훨씬 엄격합니다.
마지막으로 테스트가 완료되면 제품이 제작 단계로 넘어갈 수 있습니다.
애자일 개발에 익숙해지면서 고유한 요구 사항에 더 잘 맞는 자체 애자일 테스트 방법론 만들고 싶어 하는 조직이 많습니다. 그러나 확립된 방법론부터 시작하여 구체적인 사용 사례에 맞게 조정하는 것이 유용한 경우가 많습니다. 애자일 테스트에 널리 활용되는 몇 가지 접근 방식은 다음과 같습니다.
TDD(테스트 주도 개발)는 애자일 개발 프로세스의 첫 단계에 테스트를 배치합니다. 각 기능에 대한 테스트가 생성되고 실행됩니다. 기능의 코드가 아직 작성되지 않았기에 프로그램이 테스트에 실패하면 개발자는 테스트를 통과할 수 있도록 가급적 가장 간단한 코드를 작성합니다. 자동화된 테스트 스크립트는 테스트가 실패할 때만 코드를 작성하도록 개발자에게 안내하여 코드가 중복될 위험을 제거합니다.
ATDD(수용 테스트 주도 개발)는 표준 테스트 주도 개발과 유사합니다. 차이점은 ATDD의 경우 고객 사례를 만들면서 시작된다는 것입니다. 팀은 제품의 사용 방법을 확인한 후 개발에 도움이 되는 사용자 수용 테스트를 작성합니다. 이러한 접근 방식을 통해 개발 주기에서 사용자의 기대치를 최우선으로 고려하게 됩니다.
ATDD의 자연스러운 확장인 BDD(행동 주도 개발)도 사용자 사례를 만드는 것에서 시작됩니다. 그러나 이 사례는 비즈니스 결과와 직결되어야 하며 비즈니스 관점에서 이 기능을 개발해야 하는 이유를 명시해야 합니다. 그러면 원하는 비즈니스 결과를 얻을 수 있는 방향으로 개발이 이루어지도록 테스트가 작성됩니다.
TDD, ATDD 및 BDD 테스트 방법론에서는 자동화된 테스트 스크립트가 사용되지만, 탐색 테스트에서는 수동 접근 방식을 사용합니다. 개발 중인 제품을 탐색할 때 관련 테스트를 만드는 작업은 테스트 담당 인력에 의존합니다. 탐색 테스트는 위에 열거된 테스트 방법론만큼 체계적이거나 빠르지는 않지만, 테스트 담당자의 기술과 직관을 충분히 활용하고 테스트에 대한 다른 접근 방식을 지나칠 수 있는 위험 관련 문제를 찾는 데 효과적입니다.
세션 기반 테스트는 탐색 테스트를 한 단계 더 발전시킵니다. 테스트 담당자의 본능에 크게 의존하기보다는 테스트를 수행할 수 있는 구조를 추가합니다. 각 세션 기반 테스트를 시작할 때 테스트 담당자는 팀이 테스트로 무엇을 찾기 바라는지 정확하게 설명하는 헌장을 작성합니다. 이어서 구체적이면서 중단 없는 테스트가 이루어지며, 이후 테스트가 보고됩니다. 명확한 목표를 염두에 두고 탐색 테스트를 시작함으로써 테스트 담당자는 어떤 영역도 간과하지 않을 수 있습니다.
애자일 테스트는 다양한 접근 방식과 테스트 유형을 제공하므로 어떤 테스트가 어떤 상황에 가장 적합한지, 수동 또는 자동 테스트 중 무엇이 더 나은 접근 방식인지 판단하기 어려울 수 있습니다. 개발 팀에 지침을 제공하기 위해 많은 비즈니스에서는 애자일 테스트 사분면을 활용합니다.
애자일 테스트 사분면은 기본적인 테스트 분류법을 제공합니다. 팀은 두 개의 왼쪽 사분면을 보고 어떤 종류의 코드를 작성해야 할지 신속하게 결정할 수 있으며, 두 개의 오른쪽 사분면에서 자신이 작성한 코드에 대해 자세히 알아볼 수 있습니다. 사분면은 다음과 같습니다.
이 사분면에는 코드와 제품을 개선하기 위해 존재하는 테스트가 포함됩니다. 일반적으로 이러한 테스트는 코드 품질에 대한 피드백을 개발자에게 제공하기 위한 목적으로 자동화되며 앱 개발 수명주기 전반에 걸쳐 이루어집니다.
두 번째 사분면은 제품의 비즈니스 결과를 개선하는 데 도움이 되는 테스트에 전념합니다. 이러한 테스트는 수동 및 자동 스크립트를 결합하여 제품이 예상대로 작동하고 비즈니스와 고객 모두를 위한 가치를 창출하는지 확인하는 데 도움이 됩니다.
이전의 두 사분면의 테스트에 대한 피드백을 제공하는 3사분면은 사용자 수용도, 사용성 및 탐색 테스트로 구성됩니다. 이러한 수동 테스트의 목적은 제품 자체와 사용자 경험을 모두 테스트하고, 개발자에게 중요한 제품 인사이트를 제공하여 제품이 의도된 기능을 제대로 수행하도록 보장하는 것입니다.
4사분면에는 데이터 보안, 안정성 및 호환성과 같은 제품의 비기능적 요구 사항과 관련된 테스트가 포함됩니다. 이러한 기술 대상 성능 테스트는 테스트 프로세스를 자동화할 수 있는 도구에 의존합니다.
이 사분면은 소프트웨어 테스트에 대한 종합적인 시야를 제공하여 의사 결정에 도움이 됩니다. 그러나 테스트의 우선순위를 정하는 방법은 제공하지 않으므로, 팀이 직접 관련 결정을 내려야 합니다.
애자일 소프트웨어 개발은 조직의 형태와 규모에 구애받지 않고 소프트웨어를 만드는 방식을 변화시켰으며, 애자일 테스트는 이 혁신을 이루는 데 큰 공을 세웠습니다. 그러나 개발 수명주기의 모든 단계에서 지속적으로 테스트를 통합하면 테스트 프로세스가 순식간에 난잡해질 수 있습니다.
IT 관리 솔루션 분야의 업계 리더인 ServiceNow는 애자일 테스트를 최대한 활용하는 데 필요한 도구를 제공합니다. ServiceNow 테스트 관리 2.0 애플리케이션은 테스트 프로세스 관리를 구성하고 간소화하는 과정을 지원합니다. 관리자는 테스트 및 테스트 세트를 쉽게 구축 및 모니터링하고, 테스트 계획 및 주기를 작성하고, 자원을 할당하고, 테스트 및 테스트 결과를 평가할 수 있습니다. 테스트 담당자도 마찬가지로 테스트 및 테스트 세트 작성, 테스트 수행 및 결과 기록, 결함 보고 측면에서 향상된 지원을 누리게 됩니다.
테스트에 애자일 개발을 최적화하는 역량을 불어넣을 수 있습니다. ServiceNow 테스트 관리 2.0을 사용하여 보고 테스트를 전례 없는 수준으로 발전시켜 보세요.