ATLC(Agile Testing Life Cycle)에 대해 잘 알고 있습니까? 소프트웨어 개발 팀이 응용 프로그램을 적절하고 효과적으로 테스트하기 위해 사용하는 프로세스입니다.
이 게시물에서는 ATLC의 이점, 프로세스와 관련된 단계, 실제 테스트 전략 계획, 요구 사항 수집 및 버그 추적을 기반으로 테스트 실행, 사용자 승인 테스트(UAT) 및 지속적인 테스트를 포함하여 ATLC에 대해 알아야 할 모든 것을 안내합니다. 테스트의 통합 및 자동화.
이 가이드를 읽고 나면 소프트웨어 개발 수명 주기의 일부로 애자일 테스트를 사용하는 방법을 더 잘 이해할 수 있습니다!
제품을 제공하는 더 나은 방법을 찾고 있는 민첩한 개발자, 테스터 또는 제품 관리자인 경우 이 기사에서 필요한 조치와 함께 관련된 단계를 설명합니다.
목차
애자일 테스트 수명 주기 개요
애자일 개발 세계에서 테스트가 매우 중요하다는 것은 비밀이 아닙니다. 그러나 그럼에도 불구하고 애자일 딜리버리 내에서 종종 과소평가되는 활동입니다. 그 이유는 물론 생산 납품까지의 시간과 관련된 비용 때문입니다.
그러나 자세한 테스트 없이는 팀에서 개발하는 모든 제품의 품질이나 신뢰성을 보장할 수 없습니다. 그렇기 때문에 작업 항목 식별에서 각 단계 내에서 사용해야 하는 테스트 유형 이해에 이르기까지 애자일 테스트 수명 주기를 이해하는 것이 중요합니다.
민첩한 테스트 주기에서는 개발자와 테스터가 매 스프린트에 참여해야 합니다. 이를 잘 수행하면 모든 단계에서 테스트 자동화가 가능하여 버그를 조기에 더 자주 감지하여 나중에 문제 해결 시간을 줄일 수 있습니다.
애자일 테스팅은 또한 요구 사항의 조기 검증에 도움이 되며 부작용으로 양질의 제품을 제공함으로써 고객 만족도를 향상시킵니다.
애자일 테스팅이란 무엇이며 그 이점
Agile Testing은 자동화를 활용하여 반복 테스트 프로세스를 생성하는 혁신적인 소프트웨어 테스트 방법론입니다. 이 자동화 중심 접근 방식은 팀이 코드의 불일치나 문제를 신속하게 분석한 다음 이 피드백을 기반으로 수정 사항을 테스트하는 데 도움이 됩니다.
따라서 이 프로세스의 주요 이점은 다음과 같습니다.
- 테스트가 필요한 영향을 미치도록 보장
- 보다 효율적인 개발 시간으로 이어지며,
- 개발된 시스템은 전반적으로 버그 해결 속도가 더 빠릅니다.
- 및 고객 만족도가 향상됩니다.
스프린트는 짧은 기간(일반적으로 2~4주)으로 정의되므로 품질과 속도가 중요한 요소입니다. 팀이 스프린트 테스트에 포함된 품질에 더 많이 의존할수록 팀은 더 높은 자신감과 더 빠른 개발 진행을 생성할 수 있습니다.
자동화에 중점을 두는 것은 모든 애자일 팀의 주요 목표여야 합니다. 이를 통해 팀은 비용이 많이 드는 실패의 위험을 낮추고 이미 생산 중인 콘텐츠를 수정하는 대신 새로운 콘텐츠 생성에 더 많은 시간을 할애할 수 있습니다.
또 다른 부수적 이점은 프로젝트 비용과 일정을 더 잘 예측할 수 있다는 것입니다. 제품이 훨씬 더 성숙하고 예측 가능하기 때문에 팀이 그러한 복잡한 문제를 사전에 계산하지 않고 스프린트 내에서 제기된 예기치 않은 문제를 처리해야 하는 상황이 적습니다.
애자일 테스트 수명 주기 단계
애자일 테스트 수명 주기는 4단계로 구성됩니다.
단위 테스트
개발 관점에서 코드가 준비되면 개발자가 수행하는 테스트입니다. 시스템의 다른 부분을 포함하지 않고 개발 환경에서 격리되어 실행됩니다.
단위 테스트는 코드를 테스트하기 위해 수행되며 수동 및 자동으로 수행할 수 있습니다.
수동으로 실행하는 경우 개발자는 코드에 대해 테스트 사례를 실행합니다. 이것은 금방 알아차릴 수 있지만, 특히 장기적인 관점에서 개발에 전념하는 스프린트에서 더 많은 시간이 걸립니다.
이에 대한 대안은 자동화된 단위 테스트 코드를 생성하는 것입니다. 이 코드는 기본적으로 기능 코드를 실행하여 확인합니다. 즉, 개발자는 새로운 기능을 개발하는 것뿐만 아니라 해당 기능을 테스트할 단위 테스트 코드를 개발하는 데도 시간을 투자해야 합니다.
그리고 이것은 단기적인 관점에서 보면 더 큰 노력처럼 보일 수 있지만 이러한 단위 테스트는 스프린트 테스트의 후반 단계에서도 쉽게 재사용할 수 있기 때문에 프로젝트 전체의 시간을 절약해 줍니다. 일반 회귀 테스트 사례에 포함될 수도 있으므로 훨씬 더 많은 시간을 절약할 수 있습니다.
마지막으로, 자동화된 단위 테스트에 의한 코드 범위가 높을수록 클라이언트에게 더 나은 코드 안정성 메트릭을 보여줄 수 있습니다.
기능 테스트
기능 테스트는 애플리케이션의 기능이 얼마나 잘 작동하는지 확인하도록 설계되었습니다. 이러한 유형의 테스트는 기술적 측면(주로 단위 테스트의 일부)이 아닌 코드의 올바른 기능을 보장하고 사용자의 요구와 기대를 충족하는지 여부를 평가하는 데 사용됩니다.
즉, 기능 테스트는 개발된 것이 비즈니스 사용자가 제공한 요구 사항을 충족하는지 확인하는 데 사용됩니다.
사전에 중요한 테스트 사례를 수집하고 관련 이해 관계자(제품 소유자 또는 최종 사용자)로부터 스프린트 내부 콘텐츠에 필요한 모든 테스트 사례 목록을 만드는 것이 좋습니다.
기능 테스트 자동화는 시스템의 다양한 부분을 함께 포함하여 검증해야 하는 복잡한 프로세스이므로 테스트 개발 측면에서 더 많은 노력이 필요합니다. 이 경우 가장 좋은 전략은 메인 개발팀이 새로운 기능을 개발하는 라인에 따라 기능 테스트 개발만을 전담하는 팀을 구성하는 것입니다.
물론 프로젝트의 경우 이는 별도의 팀을 유지하는 데 드는 비용 증가를 의미하지만 장기적으로 프로젝트 비용을 절약할 수 있는 큰 잠재력도 있습니다. 이러한 프로젝트 비용 승인 증가로 이어질 비즈니스 사용자 앞에서 확실한 주장을 하기 위해 이점과 절감액을 설명하고 구체적으로 계산하는 것은 프로젝트 관리자에게만 달려 있습니다.
반면에 수동으로 수행하는 경우 이 활동은 매우 작은 팀(경우에 따라 한 사람)으로도 수행할 수 있습니다. 그러나 매 스프린트마다 지속적인 수동 및 반복 활동이 필요합니다. 시간이 지남에 따라 시스템의 기능 세트가 확장됨에 따라 스프린트마다 견고한 기능 테스트 스프린트를 따라잡기가 더 어려울 수 있습니다.
회귀 테스트
회귀 테스트의 목적은 지금까지 작동했던 모든 것이 다음 릴리스 이후에도 작동하는지 확인하는 것입니다. 서로 다른 모듈 간에 호환성 문제가 없는지 확인하기 위해 회귀 테스트를 수행해야 합니다.
회귀 테스트를 위한 테스트 사례는 각 릴리스 전에 정기적으로 유지 관리하고 다시 방문하는 경우 가장 좋습니다. 구체적인 프로젝트 세부 사항을 기반으로 단순하게 유지하되 전체 시스템을 통해 실행되는 대부분의 핵심 기능과 중요한 종단 간 흐름을 포함하는 것이 가장 좋습니다.
일반적으로 각 시스템에는 다양한 영역을 다루는 프로세스가 있으며 이러한 프로세스는 회귀 테스트 사례에 가장 적합한 후보입니다.
기존에 자동화된 단위 테스트 및 기능 테스트가 있는 경우 자동화를 회귀 테스트로 만드는 것은 매우 쉬운 작업입니다. 시스템의 가장 중요한 부분(예: 생산에서 가장 많이 사용되는 프로세스)에 대해 이미 가지고 있는 것을 재사용하십시오.
사용자 승인 테스트(UAT)
마지막으로 UAT는 응용 프로그램이 프로덕션 배포에 필요한 요구 사항을 충족하는지 확인합니다. 이 접근 방식은 소프트웨어를 짧고 강렬한 주기로 자주 테스트할 때 가장 잘 작동합니다.
UAT 테스트는 애자일 팀 외부의 사람들, 이상적으로는 가능한 한 향후 생산에 가까운 전용 환경의 비즈니스 사용자에 의해 실행되어야 합니다. 또는 여기에서 제품 소유자가 최종 사용자를 대신할 수 있습니다.
어쨌든 이 테스트는 개발 팀과 연결되지 않고 최종 사용자의 관점에서 깨끗하고 기능적인 테스트여야 합니다. 이러한 테스트의 결과는 생산 릴리스에 대한 가장 중요한 진행/진행 불가 결정을 내리기 위해 여기에 있습니다.
효과적인 테스트 전략 계획
계획은 전체 전략을 하나로 묶기 때문에 애자일 테스트의 중요한 부분입니다. 또한 스프린트 맥락에서 명확한 타임라인 기대치를 설정해야 합니다.
애자일 테스트 계획을 효과적으로 관리함으로써 팀은 스프린트 내에서 리소스를 효율적으로 사용하는 명확한 방향을 만들 수 있습니다. 분명히 테스터와 개발자 간의 더 많은 협력이 기대됩니다.
또한 각 개발 스프린트 내에서 단위 테스트, 기능 테스트 또는 사용자 승인 테스트가 발생하는 시기를 파악하기 위한 포괄적인 계획을 수립해야 합니다. 따라서 성공적인 애자일 출시를 위해 언제 참여가 필요한지 모두가 정확히 알고 있습니다.
계획을 세우는 방법은 추가 논의와 합의에 따라 결정될 수 있습니다. 그러나 가장 중요한 것은 그것을 과정으로 만들고 고수하는 것입니다. 신뢰할 수 있고 예측 가능한 주기성을 만듭니다.
프로세스에서 벗어나지 마십시오. 그렇지 않으면 혼돈과 예측할 수 없는 생산 릴리스라는 정반대의 현실이 될 것입니다.
요구 사항 수집을 기반으로 테스트 실행
테스트는 각 단계의 요구 사항에 대해 실행되어야 합니다. 그런 다음 버그나 문제가 발견되고 개발 팀에 할당되면 티켓이 열리고 코드에 대해 수정하거나 변경해야 할 사항을 파악할 수 있습니다. 모든 버그가 수정되면 모든 테스트가 통과될 때까지 애자일 테스트 실행을 계속할 수 있습니다.
결과 검토 및 버그 추적
결과에 대한 효과적인 검토와 견고한 버그 추적 프로세스가 필수적입니다. 이 프로세스에는 프로젝트 관리자 및 테스터에서 개발자에 이르기까지 모든 관련 이해 관계자가 포함되어야 하며 궁극적으로 팀을 지원하고 피드백 수집을 위한 고객도 참여해야 합니다.
이것은 이미 예정된 릴리스 날짜가 위험에 처하기 전에 문제를 신속하게 식별하고 해결할 수 있도록 충분히 포괄적인 활동이어야 합니다.
도구 선택은 다시 팀의 몫입니다. 그러나 일단 선택되면 모든 테스트 활동에는 문제를 모니터링하고, 종속성에 따라 우선 순위를 지정하고, 해결 시 개발자의 상태 업데이트를 보고하거나, 추가 조사를 위해 전송하고, 해결되면 티켓을 종료하는 신뢰할 수 있는 버그 추적 프로세스가 포함되어야 합니다.
검토는 애자일 테스터가 시스템의 동작을 이해하고 프로세스의 나중이 아닌 각 단계에서 버그를 식별하는 데 도움이 됩니다. 정기적인 검토를 통해 애자일 팀은 개선이 필요한 추세와 영역을 식별하여 테스트 프레임워크를 지속적으로 업데이트하고 더 나은 품질의 제품을 더 빠르게 구축할 수 있습니다.
프로덕션 스모크 테스트로 제품 릴리스 마무리
릴리스의 성공을 극대화하기 위해 생산에 대한 스모크 테스트 실행(출시 직후)은 더 많은 확신을 얻을 수 있는 한 가지 방법입니다.
이 테스트는 생산 시스템 내부의 일련의 읽기 전용 활동으로 구성되며, 새로운 무작위 데이터를 생성하지는 않지만 최종 사용자의 관점에서 시스템의 기본 기능을 계속 확인합니다.
프로세스에 올바른 이해관계자를 참여시키면 목표 달성에 대한 자신감을 높이는 동시에 조정 및 책임을 보장하는 데 도움이 됩니다. 궁극적으로 이러한 테스트는 성공적인 릴리스를 보장합니다.
효율성 향상을 위한 테스트의 지속적인 통합 및 자동화
민첩한 프로세스를 다음 단계로 끌어올리기 위해 회사에서 테스트의 지속적인 통합 및 자동화를 점점 더 많이 채택하고 있습니다.
위에서 설명한 대로 팀이 자동화를 여러 단계로 구현할 수 있는 경우 이러한 단계를 결합하여 전용 테스트 파이프라인에 연결할 수 있습니다. 이 파이프라인은 기본적으로 다른 팀의 개입 없이 대부분의 테스트 활동을 독립적으로 수행하는 완전히 자동화된 배치 프로세스입니다. 회원.
시간이 지남에 따라 이러한 포괄적인 테스트 파이프라인은 모든 테스트 단계에 필요한 총 시간을 단축합니다. 결국 각 스프린트가 끝난 후 정말 빠른 증분 프로덕션 릴리스로 이어질 수 있습니다. 이것은 이상적인 시나리오이지만 실제로는 관련된 모든 테스트 단계로 달성하기 어렵습니다. 자동화는 거기에 도달하는 유일한 방법입니다.
애자일 테스트와 폭포수 테스트의 차이점
애자일 테스트 전략은 주기성, 병렬성 또는 각 활동에 대한 전용 시간과 같은 여러 가지 면에서 기존의 폭포수 테스트 전략과 다릅니다.
그러나 가장 눈에 띄는 차이점은 각 접근 방식의 초점입니다.
- 민첩한 테스트는 문제를 식별하고 제품을 신속하게 개선하기 위해 개발 및 피드백 루프의 지속적이고 신속한 반복에 중점을 둡니다. 고객 협업, 지속적 통합 및 적응형 계획에 중점을 둔 반복 프로세스입니다.
- 반면에 기존의 폭포수 테스트는 각 단계가 개별적으로 순차적으로 해결되는 선형 프로세스를 강조하여 전체 솔루션의 피드백을 프로젝트의 마지막 단계에만 남겨두고 최종 생산 릴리스 날짜에 매우 가깝습니다.
분명히 주요 이해 관계자가 문제를 빨리 식별할수록 프로젝트의 상황이 좋아집니다. 이와 관련하여 애자일 방법론은 분명히 성공 가능성이 더 높습니다.
결론
애자일 테스트 수명 주기가 폭포수보다 짧아 보일 수 있지만 실제로는 그렇지 않습니다. 전체 프로세스는 지속적이며 제품 출시일까지 계속됩니다. 각 스프린트에 사용할 수 있는 예산과 시간에 따라 특정 스프린트 중에 수행할 테스트의 우선 순위를 지정해야 합니다.
잘 계획된 테스트 전략은 다른 기능보다 더 많은 주의가 필요한 기능이나 모듈을 선택하는 데 도움이 됩니다. 자동화를 통해 동일한 스프린트에 여러 테스트 단계를 포함할 수 있으므로 스프린트 간에 시스템의 전반적인 안정성이 향상됩니다.
이제 스크럼 테스트의 몇 가지 모범 사례를 살펴볼 수 있습니다.