스크럼 테스트 방법론 튜토리얼

소프트웨어 테스팅의 스크럼

소프트웨어 테스팅의 스크럼 스크럼은 복잡한 소프트웨어 애플리케이션을 구축하기 위한 방법론입니다. 복잡한 작업을 쉽게 실행할 수 있는 솔루션을 제공하며, 개발팀이 품질, 성능, 사용성 등 소프트웨어 제품 개발의 모든 측면에 집중할 수 있도록 도와줍니다. 또한, 소프트웨어 개발 과정에서 투명성, 검토, 적응성을 제공하여 복잡성을 방지합니다.

스크럼 테스트

스크럼 테스트 스크럼 방법론에서 수행되는 테스트는 소프트웨어 애플리케이션의 요구 사항이 충족되었는지 확인하는 것입니다. 여기에는 보안, 사용성, 성능과 같은 비기능적 매개변수를 검사하는 것이 포함됩니다. 테스트 과정에서 테스터의 적극적인 역할은 없으며, 일반적으로 개발자가 단위 테스트를 통해 수행합니다. 프로젝트의 성격과 복잡성에 따라 전담 테스트 팀이 필요한 경우도 있습니다. 현대의 팀들은 종종 Jira, Linear 등의 도구를 사용하여 이러한 작업을 조율합니다. Azure DevOps 또는 Asana.

스크럼 방법론의 주요 특징

다음은 스크럼의 주요 특징입니다.

• 스크럼은 조정 가능한 범위를 가진 짧고 고정된 릴리스 주기 일정을 특징으로 합니다. Sprints빠르게 변화하는 개발 요구 사항에 대응하기 위해서입니다. 각 릴리스에는 여러 개의 버전이 포함될 수 있습니다. Sprint각 스크럼 프로젝트는 여러 개의 릴리스 주기를 가질 수 있습니다.
• 반복되는 시퀀스 회의, 이벤트 및 이정표.
• 새로운 요구사항을 테스트하고 구현하는 관행으로 알려져 있습니다. 이야기각 작업 후에 일부 작업이 출시 준비가 완료되었는지 확인하기 위해서입니다. Sprint.

스크럼은 다음 세 가지 핵심 요소에 기반합니다.

하나씩 살펴보겠습니다.

1. 스크럼에서의 역할

스크럼 테스트에는 제품 책임자, 스크럼 마스터, 개발팀이라는 세 가지 주요 역할이 있습니다. 이들을 자세히 살펴보겠습니다.

제품 소유자	스크럼 마스터	팀
그 사람은 제품의 특징을 정의합니다.	그 사람은 팀을 관리하고 팀의 생산성을 책임집니다.	팀 구성원은 보통 5~9명 정도입니다.
제품 책임자는 출시일과 그에 따른 기능을 결정합니다.	그 사람은 차단 목록을 관리하고 개발 과정의 장애물을 제거합니다.	여기에는 개발자, 디자이너, 그리고 경우에 따라 테스터가 포함됩니다.
그들은 제품의 시장 가치와 수익성에 따라 기능의 우선순위를 정합니다.	그 사람은 모든 역할과 기능을 조율합니다.	팀원들은 스스로 업무를 조직하고 일정을 계획합니다.
그 사람은 제품의 수익성에 대한 책임이 있습니다.	그 사람은 외부 간섭으로부터 팀을 보호합니다.	프로젝트의 범위 내에서 목표를 달성하기 위해 모든 조치를 취할 권리가 있습니다. Sprint 골.
그 사람은 작업 항목 결과를 승인하거나 거부할 수 있습니다.	데일리 스크럼 초대, Sprint Rev검토 및 계획 회의.	일상적인 의식에 적극적으로 참여합니다.

2. 스크럼 아티팩트

스크럼 프로세스는 다음을 포함합니다:

• 사용자 스토리: 이는 테스트 대상 시스템의 기능에 대한 간략한 설명입니다. 예를 들어 보험 회사의 경우 "온라인 시스템을 통해 보험료를 납부할 수 있습니다."와 같습니다.
• 제품 백로그: 스크럼 제품에 대해 수집된 사용자 스토리 모음입니다. 제품 책임자가 준비합니다. 제품 백로그를 관리합니다. 제품 백로그는 제품 책임자가 우선순위를 정하며, 제품 책임자의 승인을 받으면 누구나 백로그에 항목을 추가할 수 있습니다. 최신 팀들은 Jira, 선형 모델 등을 사용하여 제품 백로그를 관리합니다. Azure DevOps 또는 Asana.
• 릴리스 백로그: 릴리스는 여러 번의 반복 작업이 완료되는 기간입니다. 제품 책임자는 조정을 담당합니다. 스크럼 마스터와 함께 릴리스에서 완료해야 할 스토리를 결정합니다. 릴리스 백로그에 있는 스토리는 해당 릴리스에서 완료되는 것을 목표로 합니다.
• Sprints: 사용자 스토리를 완료하는 데 필요한 기간은 제품 책임자와 개발팀이 정하며, 일반적으로 2~4주 정도입니다.
• Sprint 백 로그 : 이는 특정 기간 내에 완료해야 할 사용자 스토리 모음입니다. Sprint. 동안 Sprint 백로그는 작업이 절대 할당되지 않고 팀원들이 스스로 작업을 선택하는 방식입니다. 팀이 소유하고 관리하며, 남은 작업량은 매일 업데이트됩니다. 백로그는 팀에서 수행해야 할 작업 목록입니다. Sprint.
• 차단 목록: 이는 스크럼 마스터가 관리하고 매일 업데이트되는, 해결되지 않은 문제와 미결정 사항 목록입니다.
• 번다운 차트: 번다운 차트는 전체 프로세스에서 진행 중인 작업과 완료된 작업의 전반적인 진행 상황을 나타냅니다. 완료되지 않은 스토리와 기능을 그래프 형식으로 보여줍니다.

3. 스크럼에서의 행사(프로세스)

• Sprint 계획 : A Sprint 팀이 릴리스 백로그에서 스토리를 가져오는 것으로 시작합니다. Sprint 백로그는 스크럼 마스터가 관리합니다. 테스터는 백로그에 있는 다양한 스토리를 테스트하는 데 필요한 노력량을 추정합니다. Sprint 백로그.
• 일일 스탠드업: 데일리 스크럼이라고도 불리는 이 회의는 스크럼 마스터가 주최하며 약 15분 동안 진행됩니다. 데일리 스탠드업 회의에서는 전날 완료된 작업, 다음 날 계획된 작업, 그리고 작업 도중 발생한 문제점에 대해 논의합니다. Sprint팀 진행 상황은 다음과 같습니다. trac여기 케드가 있어요.
• Sprint Rev전망 / 회고: 이 회의 역시 스크럼 마스터가 주최하며, 약 2~4시간 동안 진행되고, 팀이 지난 몇 달 동안 달성한 내용을 논의합니다. Sprint 그리고 어떤 교훈을 얻었는가?

스크럼의 역할, 산출물, 그리고 의식이 정립되면, 테스터가 이 프레임워크 내에서 정확히 어떤 역할을 하는지 명확히 하는 것이 중요합니다.

스크럼에서 테스터의 역할

스크럼에는 테스터의 적극적인 역할이 없습니다. 일반적으로 테스트는 개발자가 단위 테스트를 통해 수행하며, 제품 책임자(Product Owner) 또한 각 단계별 테스트 과정에 자주 참여합니다. Sprint. 프로젝트의 성격과 복잡성에 따라 전담 테스트 팀을 운영하는 스크럼 프로젝트도 있습니다..

다음 질문은 스크럼에서 테스터가 하는 일은 무엇인가 하는 것입니다. 다음 섹션에서 이에 대한 답을 제시합니다.

스크럼에서 활동 테스트

테스터는 스크럼의 여러 단계에서 다음과 같은 활동을 수행합니다.

Sprint 계획

• In Sprint 계획 단계에서 테스터는 제품 백로그에서 테스트할 사용자 스토리를 하나 선택해야 합니다.
• 테스터는 작업에 얼마나 많은 시간(노력 추정치)이 소요될지 결정해야 합니다. 끝내기 위해 선택된 각 사용자 스토리에 대한 테스트.
• 테스터로서 그는 무엇을 알아야 하는지 알아야 합니다. Sprint 목표는 다음과 같습니다.
• 테스터로서 우선순위 설정 과정에 기여하십시오.

Sprint

• 개발자의 단위 테스트를 지원합니다.
• 사용자 스토리가 완료되면 테스트하십시오. 테스트 실행이 수행됩니다. 테스터와 개발자가 긴밀히 협력하는 연구실에서 결함은 기록됩니다. 결함 관리 도구 trac매일 점검합니다. 결함은 스크럼 회의에서 논의하고 분석할 수 있습니다. 결함이 발견되는 즉시 재테스트합니다. 해결 테스트를 위해 배포되었습니다. 최신 스크럼 팀은 일반적으로 Jira, Linear, Azure DevOps 또는 Asana 이 워크플로의 경우.
• 테스터로서 그는 자신의 의견을 제시하기 위해 모든 일일 스탠드업 회의에 참석합니다.
• 테스터는 현재 팀에서 완료할 수 없는 백로그 항목을 가져올 수 있습니다. Sprint 그리고 그것을 다음 칸에 넣으세요 Sprint.
• 테스터는 개발을 담당합니다.ping 자동화 스크립트. 그는 자동화 테스트 일정을 다음과 같이 잡습니다. 지속적 통합(CI) 시스템촉박한 납기일로 인해 테스트 자동화의 중요성이 커지고 있습니다. 테스트 자동화는 시중에 나와 있는 다양한 오픈 소스 또는 유료 도구를 활용하여 구현할 수 있습니다. 이를 통해 테스트해야 할 모든 영역을 효과적으로 커버할 수 있습니다. 팀 내 긴밀한 소통을 통해 충분한 테스트 커버리지를 확보할 수 있습니다.
• RevCI 자동화 결과를 확인하고 이해관계자에게 보고서를 보냅니다.
• 승인된 사용자 스토리에 대해 비기능 테스트를 실행합니다.
• 고객 및 제품 책임자와 협력하여 인수 테스트에 대한 승인 기준을 정의합니다.
• 의 끝에서 Sprint테스터는 경우에 따라 사용자 승인 테스트(UAT)도 수행하며 현재 버전의 테스트 완료 여부를 확인합니다. Sprint.

Sprint 회고전

• 테스터로서 그는 현재 시스템에서 무엇이 잘못되었고 무엇이 제대로 되었는지 파악할 것입니다. Sprint.
• 테스터로서 그는 얻은 교훈과 모범 사례를 파악합니다.

이러한 테스트 활동이 실행되면 각각 Sprint팀은 진행 상황을 전달하기 위해 명확한 지표에 의존하며, 바로 이 점에서 테스트 보고가 필수적입니다.

테스트 보고

스크럼 테스트 지표 보고는 이해관계자에게 프로젝트 진행 상황에 대한 투명성과 가시성을 제공합니다. 보고된 지표를 통해 팀은 진행 상황을 분석하고 제품 개선을 위한 향후 전략을 계획할 수 있습니다. Jira, Linear 등의 도구가 이러한 기능을 제공합니다. Azure 데브옵스와 Asana 이러한 보고서들을 자동으로 생성합니다. 보고서에 자주 사용되는 지표는 두 가지입니다.

번다운 차트: 스크럼 마스터는 매일 남은 예상 작업량을 기록합니다. Sprint이것은 매일 업데이트되는 번다운 차트입니다.

번다운 차트는 프로젝트 진행 상황을 한눈에 파악할 수 있도록 도와줍니다. 이 차트에는 프로젝트에서 완료해야 할 총 작업량, 각 단계별로 완료된 작업량 등의 정보가 포함됩니다. Sprint, 등등.

속도 기록 그래프: 속도 기록 그래프는 팀이 각 구간에서 도달하는 속도를 예측합니다. Sprint이는 막대 그래프이며, 팀의 성과가 시간에 따라 어떻게 변화했는지를 보여줍니다.

추가적으로 유용한 지표로는 일정 소진율, 예산 소진율, 테마 완료율, 완료된 스토리, 남은 스토리 등이 있습니다.

자주 묻는 질문