소프트웨어 테스팅의 애자일 방법론

테스트에서 애자일 방법론이란 무엇입니까?

Agile Methodology는 다음을 촉진하는 관행을 의미합니다. 연속 반복 프로젝트의 소프트웨어 개발 라이프사이클 전반에 걸쳐 개발 및 테스트를 수행합니다. 소프트웨어 테스팅의 Agile 모델에서는 Waterfall 모델과 달리 개발 및 테스트 활동이 동시에 진행됩니다.

애자일 소프트웨어 개발이란 무엇입니까?

The 민첩한 소프트웨어 개발 방법론은 비즈니스 요구에 대한 비전을 소프트웨어 솔루션으로 전환하는 가장 간단하고 효과적인 프로세스 중 하나입니다. Agile은 지속적인 계획, 학습, 개선, 팀 협업, 혁신적인 개발 및 조기 제공을 사용하는 소프트웨어 개발 접근 방식을 설명하는 데 사용되는 용어입니다. 변화에 대한 유연한 대응을 장려합니다.

애자일 소프트웨어 개발은 XNUMX가지 핵심 가치를 강조합니다.

프로세스 및 도구에 대한 개인 및 팀 상호 작용
포괄적인 문서보다 작업 소프트웨어
계약 협상에 대한 고객 협력
계획에 따른 변경에 대한 대응

민첩한 모델과 폭포수 모델

Agile 모델과 Waterfall 모델은 소프트웨어 개발 프로세스에 대한 두 가지 다른 방법입니다. 접근 방식은 다르지만 요구 사항과 프로젝트 유형에 따라 두 방법 모두 유용할 때가 있습니다.

애자일 모델	폭포 모델
소프트웨어 테스팅 정의의 애자일 방법론: 애자일 방법론은 소프트웨어 설계에 대한 점진적이고 반복적인 접근 방식을 제안합니다.	폭포수 모델(Waterfall Model): 소프트웨어 개발은 시작점에서 끝점까지 순차적으로 진행됩니다.
The 애자일 프로세스 소프트웨어 테스팅은 디자이너가 작업하는 개별 모델로 나뉩니다.	디자인 과정은 개별 모델로 나누어지지 않습니다.
고객은 제품을 보고 결정을 내리고 프로젝트를 변경할 수 있는 기회를 조기에 자주 갖게 됩니다.	고객은 프로젝트가 끝난 후에만 제품을 볼 수 있습니다.
테스트 중인 애자일 모델은 폭포수 모델에 비해 구조화되지 않은 것으로 간주됩니다.	폭포수 모델은 계획 지향적이기 때문에 더 안전합니다.
소규모 프로젝트는 매우 빠르게 구현할 수 있습니다. 대규모 프로젝트의 경우 개발 기간을 예측하기가 어렵습니다.	모든 종류의 프로젝트를 추정하고 완료할 수 있습니다.
오류는 프로젝트 중간에 수정될 수 있습니다.	마지막에만 전체 제품이 테스트됩니다. 요구사항 오류가 발견되거나 변경이 필요한 경우 프로젝트를 처음부터 시작해야 합니다.
개발 프로세스는 반복적이며 프로젝트는 짧은(2~4주) 반복으로 실행됩니다. 계획은 매우 적습니다.	개발 프로세스는 단계적으로 진행되며 단계는 반복보다 훨씬 큽니다. 모든 단계는 다음 단계에 대한 자세한 설명으로 끝납니다.
문서는 다음보다 우선순위가 낮습니다. 소프트웨어 개발	문서화는 최우선 순위이며 직원 교육 및 다른 팀과 함께 소프트웨어 업그레이드에도 사용할 수 있습니다.
모든 반복에는 자체 테스트 단계가 있습니다. 새로운 기능이나 로직이 출시될 때마다 회귀 테스트를 구현할 수 있습니다.	별도의 부품이 제대로 작동하지 않기 때문에 개발 단계 이후에만 테스트 단계가 실행됩니다.
민첩한 테스트에서는 반복이 종료되면 제품의 출시 가능한 기능이 고객에게 전달됩니다. 새로운 기능은 배송 후 바로 사용할 수 있습니다. 고객과의 접촉이 원활할 때 유용합니다.	개발된 모든 기능은 오랜 구현 단계를 거쳐 한 번에 제공됩니다.
테스터와 개발자가 함께 일함	테스터는 개발자와 별도로 작업합니다.
모든 스프린트가 끝나면 사용자 승인이 수행됩니다.	사용자 승인은 수행 프로젝트가 끝나면.
개발자와의 긴밀한 커뮤니케이션이 필요하며 함께 요구 사항 및 계획을 분석합니다.	개발자는 요구 사항 및 계획 프로세스에 관여하지 않습니다. 일반적으로 테스트와 코딩 사이의 시간 지연

또한 확인:- 애자일 대 폭포수: 방법론의 차이점을 알아보세요

민첩한 프로세스

아래를 확인하세요 민첩한 방법론 성공적인 시스템을 신속하게 제공하는 프로세스입니다.

여러 가지가있다. 민첩한 방법 애자일 테스트에 존재하며 그 내용은 다음과 같습니다.

스크럼

SCRUM은 팀 기반 개발 환경 내에서 작업을 관리하는 방법에 특히 중점을 둔 민첩한 개발 방법입니다. 기본적으로 스크럼은 럭비 경기 중에 발생하는 활동에서 파생됩니다. 스크럼은 소규모 팀(예: 7~9명)에서 일하는 개발 팀과 옹호자들에게 권한을 부여하는 것이 중요하다고 믿습니다. Agile과 Scrum은 세 가지 역할로 구성되며, 각 역할에 대한 설명은 다음과 같습니다.

스크럼 마스터
- 스크럼 마스터 팀 구성, 스프린트 회의를 담당하고 진행을 방해하는 장애물을 제거합니다.
제품 소유자
- 제품 소유자는 제품 백로그를 생성하고, 백로그의 우선순위를 지정하며, 각 반복에서 기능 제공을 담당합니다.
스크럼 팀
- 팀은 자체 작업을 관리하고 스프린트 또는 사이클을 완료하기 위해 작업을 구성합니다.

제품 백 로그

이것은 각 릴리스에 대해 완료해야 할 요구 사항(사용자 스토리)의 수에 대한 세부 정보와 함께 요구 사항을 추적하는 저장소입니다. 제품 소유자가 유지 관리하고 우선순위를 지정해야 하며 스크럼 팀에 배포해야 합니다. 팀은 또한 새로운 요구 사항 추가, 수정 또는 삭제를 요청할 수 있습니다.

스크럼 관행

실습은 다음과 같이 자세히 설명되어 있습니다.

스크럼 방법론의 프로세스 흐름:

의 프로세스 흐름 스크럼 테스트 다음과 같습니다 :

스크럼의 각 반복은 다음과 같이 알려져 있습니다. Sprint
제품 백로그는 최종 제품을 얻기 위해 모든 세부 정보가 입력되는 목록입니다.
각 기간 동안 Sprint, 제품 백로그의 상위 사용자 스토리를 선택하여 Sprint 주문 잔고
팀은 정의된 스프린트 백로그에서 작업합니다.
팀의 일일 업무 확인
스프린트가 끝나면 팀은 제품 기능을 제공합니다.

익스트림 프로그래밍(XP)

익스트림 프로그래밍 기술은 고객의 요구 사항이 끊임없이 변화하거나 시스템 기능에 대해 확신이 없을 때 매우 유용합니다. 이는 짧은 개발 주기에서 제품을 자주 "릴리스"하는 것을 옹호하며, 이는 본질적으로 시스템의 생산성을 향상시키고 고객 요구 사항을 쉽게 구현할 수 있는 체크포인트도 도입합니다. XP는 고객을 목표로 삼는 소프트웨어를 개발합니다.

비즈니스 요구 사항을 스토리 측면에서 수집합니다. 그 모든 이야기는 주차장이라는 곳에 저장되어 있다.

이러한 유형의 방법론에서 릴리스는 14일 기간의 반복이라는 더 짧은 주기를 기반으로 합니다. 각 반복에는 코딩, 단위 테스트 및 시스템 테스트와 같은 단계가 포함되며 각 단계에서 일부 사소하거나 주요 기능이 애플리케이션에 구축됩니다.

eXtreme 프로그래밍의 단계:

Agile XP 방법에는 6단계가 있으며, 이에 대한 설명은 다음과 같습니다.

계획

이해관계자 및 후원자의 식별
인프라 요구 사항
보안 관련정보 및 수집
서비스 수준 계약 및 조건

분석

주차장의 이야기를 담다
주차장 이야기 우선순위화
추정을 위한 스토리 스크러빙
반복 SPAN(시간) 정의
개발팀과 QA팀 모두를 위한 리소스 계획

디자인

작업 분석
과제별 테스트 시나리오 준비
회귀 자동화 프레임워크

실행

코딩
단위 테스트
수동 테스트 시나리오 실행
결함 보고서 생성
수동을 자동화 회귀 테스트 사례로 변환
중간 반복 검토
반복 검토 종료

포장

소규모 릴리스
Regression Testing
데모 및 리뷰
필요에 따라 새로운 스토리 개발
반복 검토 의견 종료를 기반으로 한 프로세스 개선

폐쇄

파일럿 출시
트레이닝
생산 개시
SLA 보증 보증
RevSOA 전략 보기
생산 지원

매일 작업을 추적할 수 있는 두 가지 스토리보드가 있으며, 참고용으로 아래에 나열되어 있습니다.

스토리 카드보드
- 이는 일일 XP 활동을 추적하기 위해 스틱 노트 형태로 보드의 모든 스토리를 수집하는 전통적인 방법입니다. 이러한 수동 활동에는 더 많은 노력과 시간이 필요하므로 온라인 양식으로 전환하는 것이 좋습니다.
온라인 스토리보드
- 온라인 도구인 스토리보드를 사용하여 스토리를 저장할 수 있습니다. 여러 팀에서 사용할 수 있습니다. 다른 목적으로.

수정 방법론

Crystal Methodology는 세 가지 개념을 기반으로 합니다.

전세: 이 단계에 관련된 다양한 활동으로는 개발팀 구성, 예비 타당성 분석 수행, 초기 계획 개발 및 개발 방법론 미세 조정 등이 있습니다.
주기적 전달: 주요 개발 단계는 두 개 이상의 납품 주기로 구성되며, 그 동안
1. 팀이 릴리스 계획을 업데이트하고 개선합니다.
2. 하나 이상의 프로그램 테스트 통합 반복을 통해 요구 사항의 하위 집합을 구현합니다.
3. 통합된 제품이 실제 사용자에게 전달됩니다.
4. Rev프로젝트 계획 및 채택된 개발 방법론에 대한 이해
마무리 : 이 단계에서 수행되는 활동은 사용자 환경으로의 배포, 배포 후 검토 및 반영입니다.

동적 소프트웨어 개발 방법(DSDM)

DSDM은 신속한 애플리케이션 개발 (RAD) 소프트웨어 개발 접근 방식을 취하고 민첩한 프로젝트 전달 프레임워크를 제공합니다. DSDM의 중요한 측면은 사용자가 적극적으로 참여해야 하며 팀에 결정을 내릴 수 있는 권한이 부여된다는 것입니다. DSDM은 빈번한 제품 배송이 핵심입니다. DSDM에 사용되는 기술은 다음과 같습니다.

Time BoxING
모스크바 규칙
프로토 타이핑

DSDM 프로젝트는 7단계로 구성됩니다.

사전 프로젝트
타당성 조사
비즈니스 스터디
기능적 모델 반복
반복 설계 및 구축
실시
프로젝트 후

기능 중심 개발 (FDD)

이 방법은 "설계 및 구축" 기능에 초점을 맞춥니다. 소프트웨어 엔지니어링의 다른 Agile 방법과 달리 FDD는 기능별로 별도로 수행해야 하는 매우 구체적이고 짧은 작업 단계를 설명합니다. 여기에는 도메인 워크스루, 설계 검사, 빌드 홍보, 코드 검사 및 설계가 포함됩니다. FDD는 대상에서 다음 사항을 유지하면서 제품을 개발합니다.

도메인 객체 모델링
기능별 개발
구성요소/클래스 소유권
기능 팀
검사
구성 관리
일반 빌드
진행 상황 및 결과의 가시성

린 소프트웨어 개발

린 소프트웨어 개발 방법은 "적시 생산" 원칙에 기반합니다. 소프트웨어 개발 속도를 높이고 비용을 줄이는 것을 목표로 합니다. 린 개발은 7단계로 요약할 수 있습니다.

폐기물 제거
학습 확대
약속을 미루다(가능한 한 늦게 결정)
조기 배송
팀에 힘을 실어주기
건물 Integrity
전체를 최적화하라

Kanban

Kanban 원래는 일본어에서 유래한 것으로, 완성까지의 각 단계에서 제품에 필요한 모든 정보를 담은 카드를 의미합니다. 이 프레임워크나 방법은 특히 Agile 개념에서 소프트웨어 테스트 방법에 꽤 많이 채택됩니다.

스크럼 대 칸반

스크럼	Kanban
스크럼 기법에서는 테스트를 분할하여 한 스프린트 내에서 완료할 수 있도록 해야 합니다.	특정 품목 크기가 규정되지 않았습니다.
우선순위가 높은 제품 백로그를 규정합니다.	우선순위는 선택사항입니다.
스크럼 팀은 반복을 위해 특정 양의 작업을 수행합니다.	약속은 선택사항입니다.
번다운 차트가 규정되어 있습니다.	특정 품목 크기가 규정되지 않았습니다.
각 스프린트 사이에 스크럼 보드가 재설정됩니다.	Kanban 보드는 지속적입니다. 워크플로 상태의 항목 수를 제한합니다.
진행 중인 반복에 항목을 추가할 수 없습니다.	용량이 확보될 때마다 항목을 추가할 수 있습니다.
WIP는 간접적으로 제한됨	WIP가 직접 제한됨
시간 상자 반복이 규정됨	시간 상자 반복은 선택 사항입니다.

또한 확인:- 칸반 대. 스크럼: 차이점이 무엇인가요?

애자일 측정항목

Agile의 효과적인 사용을 위해 수집할 수 있는 지표는 다음과 같습니다.

드래그 팩터
- 스프린트 목표에 기여하지 않는 시간당 노력
- 공유 리소스 수를 줄이고 기여하지 않는 작업량을 줄임으로써 드래그 팩터를 개선할 수 있습니다.
- 새로운 추정치는 드래그 팩터의 백분율로 증가될 수 있습니다. - 새로운 추정치 = (기존 추정치+드래그 팩터)
속도
- 스프린트의 배송 가능한 기능으로 변환된 백로그(사용자 스토리)의 양
추가된 단위 테스트 수
일일 빌드를 완료하는 데 걸리는 시간 간격
반복 또는 이전 반복에서 발견된 버그
생산 결함 누출

당신은 좋아할 것입니다 :