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

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

소프트웨어 테스팅의 스크럼 복잡한 소프트웨어 애플리케이션을 구축하기 위한 방법론입니다. 복잡한 작업을 실행하기 위한 쉬운 솔루션을 제공합니다. 스크럼은 개발팀이 품질, 성능, 사용성 등과 같은 소프트웨어 제품 개발의 모든 측면에 집중할 수 있도록 돕습니다. 복잡성을 피하기 위해 소프트웨어 개발 중에 투명성, 검사 및 적응을 제공합니다.

스크럼 테스트

스크럼 테스트 소프트웨어 애플리케이션 요구 사항이 충족되었는지 확인하기 위해 스크럼 방법론에서 수행되는 테스트입니다. 보안, 사용성, 성능 등과 같은 비기능적 매개변수를 확인하는 것을 포함합니다. 이 프로세스에서 테스터의 적극적인 역할은 없으므로 일반적으로 개발자가 단위 테스트를 수행합니다. 때로는 프로젝트의 특성과 복잡성에 따라 전담 테스트 팀이 필요합니다.

스크럼 방법론의 주요 특징

다음은 Scrum의 주요 기능입니다.

스크럼에는 조정 가능한 범위를 갖춘 짧은 고정 릴리스 주기 일정이 있습니다. 달리기 빠르게 변화하는 개발 요구 사항을 해결하기 위해. 각 릴리스에는 여러 스프린트가 있을 수 있습니다. 각 스크럼 프로젝트에는 여러 릴리스 주기가 있을 수 있습니다.
반복되는 시퀀스 회의, 이벤트 및 이정표
새로운 요구사항을 테스트하고 구현하는 관행으로 알려져 있습니다. 이야기각 스프린트 후에 일부 작업이 릴리스되도록 합니다.

Scrum은 다음의 3가지 기둥을 기반으로 합니다.

하나씩 살펴보자

1. 스크럼에서의 역할

스크럼 테스팅에는 제품 소유자, 스크럼 마스터, 개발팀의 세 가지 주요 역할이 있습니다. 자세히 연구해보자

제품 소유자	스크럼 마스터	팀
그는 제품의 기능을 정의합니다.	그는 팀을 관리하고 팀의 생산성을 관리합니다.	팀은 보통 5~9명 정도
제품 소유자가 출시 날짜와 해당 기능을 결정합니다.	그는 차단 목록을 유지하고 개발 장벽을 제거합니다.	여기에는 개발자, 디자이너, 때로는 테스터 등이 포함됩니다.
그들은 제품의 시장 가치와 수익성에 따라 기능의 우선 순위를 정합니다.	그/그녀는 모든 역할과 기능을 조정합니다.	팀이 스스로 작업을 구성하고 일정을 계획합니다.
그/그녀는 제품의 수익성을 책임집니다.	그는 외부 간섭으로부터 팀을 보호합니다	스프린트 목표를 달성하기 위해 프로젝트 범위 내에서 모든 것을 수행할 권리가 있습니다.
작업 항목 결과를 수락하거나 거부할 수 있습니다.	일일 스크럼, 스프린트 검토 및 계획 회의에 초대합니다.	매일의 행사에 적극적으로 참여하십시오.

2. 스크럼 아티팩트

스크럼 프로세스에는 다음이 포함됩니다.

사용자 스토리: 이는 테스트 중인 시스템의 기능에 대한 간단한 설명입니다. 보험 제공자의 예는 "보험료는 온라인 시스템을 사용하여 지불할 수 있습니다."입니다.
제품 백로그: 스크럼 제품에 대해 캡처된 사용자 스토리 모음입니다. 제품 소유자가 준비합니다 제품 백로그를 유지 관리합니다. 제품 소유자가 우선순위를 정하며, 제품 소유자의 승인을 받아 누구나 추가할 수 있습니다.
릴리스 백로그: 릴리스는 반복 횟수가 완료되는 기간입니다. 제품 소유자가 조정합니다. 스크럼 마스터와 함께 릴리스 대상으로 삼아야 할 스토리를 결정합니다. 릴리스 백로그의 스토리는 릴리스에서 완료되는 것을 목표로 합니다.
Sprints: 사용자 스토리를 완성하는 데 걸리는 시간은 제품 소유자와 개발자 팀이 결정하며 일반적으로 2~4주 정도 소요됩니다.
Sprint 백 로그 : 스프린트에서 완료해야 할 사용자 스토리 세트입니다. 스프린트 백로그 동안 작업은 할당되지 않으며 팀은 스스로 작업에 등록합니다. 팀이 소유하고 관리하는 반면 남은 예상 작업은 매일 업데이트됩니다. 수행해야 하는 작업 목록입니다. Sprint
차단 목록: 스크럼 마스터가 소유하고 매일 업데이트되는 블록 및 미결정 의사결정 목록입니다.
번다운 차트: 번다운 차트는 프로세스 전반에 걸쳐 진행 중인 작업과 완료된 작업의 전반적인 진행 상황을 나타냅니다. 완성되지 않은 스토리와 특징을 그래프 형식으로 표현합니다.

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

Sprint 계획 : 스프린트는 팀이 릴리스 백로그에서 스프린트 백로그로 스토리를 가져오는 것으로 시작하며, 스크럼 마스터가 호스팅합니다. 테스터는 다양한 스토리를 테스트하기 위한 노력을 추정합니다. Sprint 백로그.
일일 스크럼: 스크럼 마스터가 주최하며, 약 15분 동안 진행됩니다. Daily Scrum 동안 멤버들은 전날 완료한 작업, 다음날 계획된 작업, 스프린트 동안 직면한 문제에 대해 논의합니다. Daily Standup 회의 동안 팀 진행 상황을 추적합니다.
Sprint Rev그렇죠/회고적: 이 회의는 스크럼 마스터가 주관하며, 약 2~4시간 동안 진행되며, 팀이 지난 스프린트에서 무엇을 달성했는지, 어떤 교훈을 얻었는지 논의합니다.

스크럼에서 테스터의 역할

스크럼에는 테스터의 적극적인 역할이 없습니다. 프로세스. 일반적으로 테스트는 개발자가 단위 테스트를 통해 수행합니다. 제품 소유자도 각 스프린트 동안 테스트 프로세스에 자주 참여합니다. 일부 Scrum 프로젝트에는 프로젝트의 특성 및 복잡성에 따라 전담 테스트 팀이 있습니다..

다음 질문은, 테스터가 스크럼에서 무엇을 하는가? 다음 메모가 답할 것입니다.

스크럼에서 활동 테스트

테스터는 Scrum의 다양한 단계에서 다음 활동을 수행합니다.

Sprint 계획

스프린트 계획에서 테스터는 테스트해야 할 제품 백로그에서 사용자 스토리를 선택해야 합니다.
테스터는 작업 시간(노력 추정)이 얼마나 소요되는지 결정해야 합니다. 끝내기 위해 선택한 각 사용자 스토리에 대해 테스트합니다.
테스터는 스프린트 목표가 무엇인지 알아야 합니다.
테스터로서 우선순위 지정 프로세스에 기여

Sprint

단위 테스트에서 개발자 지원
완료되면 사용자 스토리를 테스트합니다. 테스트 실행이 수행됩니다. 테스터와 개발자가 함께 작업하는 실험실에서요. 결함이 로그인되었습니다. 결함 관리 도구 매일 추적됩니다. 스크럼 미팅을 통해 결함을 제시하고 분석할 수 있습니다. 결함이 발견되는 즉시 다시 테스트됩니다. 해결 테스트를 위해 배포됨
테스터로서 그는 매일 모든 스탠드업 회의에 참석하여 발언합니다.
테스터는 현재 스프린트에서 완료할 수 없는 백로그 항목을 가져와 다음 스프린트에 넣을 수 있습니다.
테스터는 자동화 스크립트 개발을 담당합니다. 그는 자동화 테스트 일정을 다음과 같이 계획합니다. 지속적 통합(CI) 시스템. 자동화는 납품 일정이 짧기 때문에 중요성을 받습니다. 테스트 자동화는 시중에 판매되는 다양한 오픈 소스 또는 유료 도구를 활용하여 수행할 수 있습니다. 이는 테스트해야 하는 모든 항목이 포함되었는지 확인하는 데 효과적인 것으로 입증되었습니다. 팀과의 긴밀한 커뮤니케이션을 통해 충분한 테스트 범위를 달성할 수 있습니다.
RevCI 자동화 결과를 조회하고 이해관계자에게 보고서를 전송합니다.
승인된 사용자 스토리에 대한 비기능 테스트 실행
고객 및 제품 소유자와 협력하여 승인 테스트에 대한 승인 기준을 정의합니다.
스프린트가 끝나면 테스터는 어떤 경우에는 수락 테스트(UAT)도 수행하고 현재 스프린트에 대한 테스트 완료성을 확인합니다.

Sprint 회고전

테스터로서 그는 현재 스프린트에서 무엇이 잘못되었고 무엇이 잘 되었는지 알아낼 것입니다.
테스터로서 그는 배운 교훈과 모범 사례를 식별합니다.

테스트 보고

스크럼 테스트 지표 보고는 이해관계자에게 프로젝트에 대한 투명성과 가시성을 제공합니다. 보고된 측정항목을 통해 팀은 진행 상황을 분석하고 제품 개선을 위한 향후 전략을 계획할 수 있습니다. 보고에 자주 사용되는 두 가지 측정항목이 있습니다.

번다운 차트: 매일, 스크럼 마스터는 스프린트에 대한 예상 남은 작업을 기록합니다. 이것은 번다운 차트에 불과합니다. 매일 업데이트됩니다.

번다운 차트는 프로젝트 진행 상황을 빠르게 간략하게 보여줍니다. 이 차트에는 프로젝트에서 완료해야 하는 총 작업량, 각 스프린트 동안 완료된 작업량 등의 정보가 포함되어 있습니다.

속도 기록 그래프: 속도 이력 그래프는 각 스프린트에서 도달한 팀의 속도를 예측합니다. 막대 그래프이며 시간이 지남에 따라 팀의 출력이 어떻게 변했는지를 나타냅니다.

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

이것은 소프트웨어 엔지니어링의 스크럼에 관한 것입니다.

당신은 좋아할 것입니다 :