에자일 모델 및 방법론 : 개발자 및 테스터를위한 지침

애자일 테스팅의 개념을 이해하려면 우선,

애자일 방법론이란 무엇입니까?

AGILE 방법론은 프로젝트의 소프트웨어 개발 수명주기 전반에 걸친 지속적인개발 및 테스트 반복 을 촉진하는 방법입니다 . 개발 및 테스트 활동 모두 Waterfall 모델과 달리 동시에 합니다.

나는 Agile에 대한 아이디어를 얻었 으면 좋겠다. 이제 애자일 테스트로 넘어갈 수 있습니다.

애자일 소프트웨어 개발은 ​​네 가지 핵심 가치에 중점을 둡니다.

1. 프로세스 및 도구에 대한 개인 및 팀 상호 작용
2. 포괄적 인 문서를 통한 작업 소프트웨어
3. 계약 협상을 통한 고객 협력
4. 계획에 따른 변화에 대한 대응

애자 일 대 폭포 방법

Agile과 Waterfall 모델은 소프트웨어 개발 프로세스를위한 두 가지 다른 방법입니다. 두 가지 방법이 서로 다르지만 프로젝트의 요구 사항과 유형에 따라 두 가지 방법이 유용합니다.

애자일 모델	폭포 모델
Agile 방식은 소프트웨어 설계에 대한 점진적이고 반복적 인 접근 방식을 제안합니다.	소프트웨어 개발은 ​​시작 지점에서 끝 지점까지 순차적으로 이루어집니다.
애자일 과정은 디자이너가 작업 개별 모델로 나뉩니다	디자인 프로세스가 개별 모델로 분리되지 않습니다.
고객은 제품을보고 결정을 내리고 프로젝트를 변경할 수있는 기회를 가끔 갖고 있습니다.	고객은 프로젝트가 끝날 때만 제품을 볼 수 있습니다.
애자일 모델은 폭포 모델과 비교하여 구조화되지 않은 모델로 간주됩니다.	폭포 모델은 계획 지향적이기 때문에 더욱 안전합니다.
소규모 프로젝트는 매우 신속하게 구현 될 수 있습니다. 대규모 프로젝트의 경우 개발 시간을 예측하기가 어렵습니다.	모든 종류의 프로젝트를 평가하고 완료 할 수 있습니다.
오류는 프로젝트 중간에서 수정할 수 있습니다.	결국에는 전체 제품을 테스트합니다. 요구 사항 오류가 발견되거나 변경해야하는 경우, 프로젝트는 처음부터 시작해야합니다
개발 프로세스는 반복적이며, 프로젝트는 2-4 주 정도의 짧은 시간 내에 실행됩니다. 계획은 매우 적습니다.	개발 프로세스는 단계적으로 진행되며 단계는 반복보다 훨씬 큽니다. 모든 단계는 다음 단계에 대한 자세한 설명으로 끝납니다.
문서는 소프트웨어 개발보다 우선 순위가 낮습니다.	문서화는 최우선 과제이며 교육 직원에게도 사용하고 다른 팀과 함께 소프트웨어를 업그레이드 할 수도 있습니다.
모든 반복에는 자체 테스트 단계가 있습니다. 새로운 기능이나 로직이 출시 될 때마다 회귀 테스트를 구현할 수 있습니다.	개발 단계가 끝난 후에 만 ​​테스트 단계가 실행됩니다. 왜냐하면 별도의 부분이 완전히 기능하지 않기 때문입니다.
애자일 테스트에서 반복 작업이 끝나면 제품의 발송 가능한 기능이 고객에게 전달됩니다. 새로운 기능은 선적 직후에도 사용할 수 있습니다. 고객과의 접촉이 좋은 경우에 유용합니다.	개발 된 모든 기능은 장기 구현 단계 후에 즉시 제공됩니다.
테스터와 개발자가 함께 작업합니다.	테스터는 개발자와 별도로 작동합니다.
모든 스프린트가 끝날 때 사용자 동의가 수행됩니다.	사용자 동의는 프로젝트가 끝날 때 수행 됩니다.
개발자와 긴밀한 의사 소통이 필요하며 요구 사항 및 계획을 함께 분석해야합니다.	개발자는 요구 사항 및 계획 프로세스에 관여하지 않습니다. 일반적으로 테스트와 코딩 간의 시간 지연

애자일 테스트 방법론

애자일 테스트 에는 다양한 방법 이 있으며, 아래에 나열되어 있습니다.

스크럼

SCRUM은 팀 기반 개발 환경에서 작업을 관리하는 방법에 중점을 둔 애자일 개발 방법입니다. 기본적으로 스크럼은 럭비 경기 중에 발생하는 활동에서 파생됩니다. 스크럼은 소규모 팀 (7-9 명)에서 일하는 개발 팀과 옹호자에게 권한을 부여한다고 믿습니다. 그것은 세 가지 역할로 이루어져 있으며 그 책임은 다음과 같이 설명됩니다.

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

제품 백 로그

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

스크럼 실습

관행에 대한 자세한 내용은 다음과 같습니다.

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

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

• 스크럼의 각 반복은 스프린트로 알려져 있습니다.
• 제품 백 로그는 모든 세부 사항을 입력하여 최종 제품을 얻는 목록입니다.
• 각 스프린트 기간 동안 제품 백 로그의 최상위 항목이 선택되고 스프린트 백 로그로 바뀝니다.
• 팀은 정의 된 스프린트 백 로그에서 작동합니다.
• 팀은 일일 업무를 확인합니다.
• 스프린트가 끝나면 팀은 제품 기능을 제공합니다.

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

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

비즈니스 요구 사항은 이야기 측면에서 수집됩니다. 그 이야기들은 모두 주차장이라는 곳에 보관됩니다.

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

극단적 인 프로그래밍 단계 :

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

계획

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

분석

• 주차장에있는 이야기 수집
• 주차장의 우선 순위를 매기십시오.
• 추정을위한 이야기 ​​스크러빙
• 반복 SPAN (시간) 정의
• 개발 팀과 품질 보증 팀 모두를위한 자원 계획

디자인

• 작업 분해
• 각 작업에 대한 테스트 시나리오 준비
• 회귀 자동화 프레임 워크

실행

• 코딩
• 단위 테스트
• 수동 테스트 시나리오 실행
• 결함 보고서 생성
• 수동 회귀 분석 테스트 케이스로의 변환
• 중간 반복 검토
• 반복 검토 종료

Wrapping

• 작은 릴리즈
• 회귀 테스트
• 데모 및 리뷰
• 필요에 따라 새로운 이야기를 개발하십시오.
• 반복 검토 주석을 기반으로 프로세스 개선

Closure

• 파일럿 시작
• 훈련
• 생산 개시
• SLA 보증 보증
• SOA 전략 검토
• 제작 지원

매일 작업을 추적하는 데 사용할 수있는 스토리 보드 2 개가 있으며, 아래에 나열되어 있습니다.

• 스토리 카드 보드
  • 이것은 일상적인 XP 활동을 추적하기 위해 스틱 노트 형태로 보드에있는 모든 이야기를 수집하는 전통적인 방법입니다. 이 수동 작업에는 많은 노력과 시간이 필요하므로 온라인 양식으로 전환하는 것이 좋습니다.

• 온라인 스토리 보드
  • 온라인 도구 스토리 보드는 스토리를 저장하는 데 사용할 수 있습니다. 여러 팀이 서로 다른 용도로 사용할 수 있습니다 .

결정론

크리스탈 방법론은 세 가지 개념을 기반으로합니다.

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

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

DSDM은 소프트웨어 개발에 대한 RAD (Rapid Application Development) 방식이며 애자일 프로젝트 제공 프레임 워크를 제공합니다. DSDM의 중요한 측면은 사용자가 적극적으로 참여해야하며 팀이 결정을 내릴 수있는 힘을 부여 받는다는 것입니다. 제품의 잦은 배달은 DSDM의 적극적인 관심사가됩니다. DSDM에 사용되는 기술은

1. Time Boxing
2. MoSCoW 규칙
3. 프로토 타이핑

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

1. 사전 프로젝트
2. 타당성 조사
3. 비즈니스 연구
4. 함수 모델 반복
5. 반복 설계 및 구축
6. 이행
7. 프로젝트 후

기능 중심 개발 (FDD)

이 방법은 "설계 및 구축"기능에 중점을 둡니다. 다른 애자일 방법과 달리 FDD는 기능별로 개별적으로 수행해야하는 매우 구체적이고 짧은 단계의 작업을 설명합니다. 여기에는 도메인 둘러보기, 디자인 검사, 빌드 승격, 코드 검사 및 디자인이 포함됩니다. FDD는 목표물을 따라 움직이는 제품을 개발합니다.

1. 도메인 객체 모델링
2. 기능별 개발
3. 구성 요소 / 클래스 소유권
4. 기능 팀
5. 검사
6. 구성 관리
7. 정규 빌드
8. 진행 상황 및 결과의 가시성

린 (Lean) 소프트웨어 개발

린 (Lean) 소프트웨어 개발 방법은 "Just in time production"원칙을 기반으로합니다. 소프트웨어 개발 속도를 높이고 비용을 줄이는 것을 목표로합니다. 경량 개발은 7 단계로 요약 할 수 있습니다.

1. 폐기물 제거
2. Amplifying learning
3. commitment 연기 (가능한 한 늦게 결정)
4. 조기 납품
5. 팀 역량 강화
6. Building 무결성
7. 전체 최적화

칸반

Kanban은 원래 일본어 단어 즉, 완성까지의 각 단계에서 제품에서 수행해야하는 모든 정보가 들어있는 카드를 의미합니다. 이 프레임 워크 또는 방법은 특히 애자일 테스트에서 소프트웨어 테스트 방법에 상당히 채택됩니다.

스크럼 대 칸반

스크럼	칸반
스크럼 기술에서 테스트는 하나의 스프린트 내에서 완료 될 수 있도록 분해되어야한다.	특정 항목 크기가 지정되지 않았습니다.
우선 순위가 부여 된 제품 백 로그를 지정합니다.	우선 순위는 선택 사항입니다.
스크럼 팀은 반복을 위해 특정 작업량을 커밋합니다.	약속은 선택 사항입니다.
번 다운 차트가 처방 됨	특정 항목 크기가 지정되지 않았습니다.
각 스프린트 사이에서 스크럼 보드가 재설정됩니다.	간판 보드는 영구합니다. 워크 플로 상태의 항목 수를 제한합니다.
진행중인 반복에 항목을 추가 할 수 없습니다.	용량을 사용할 수있을 때마다 항목을 추가 할 수 있습니다.
간접적으로 제한된 WIP	WIP가 직접 제한
지정된 타임 박스 반복	선택적으로 Timeboxed 반복

애자일 측정 항목 :

Agile을 효과적으로 사용하기 위해 수집 할 수있는 메트릭은 다음과 같습니다.

• 항력 인자
  • 스프린트 목표에 기여하지 않는 몇 시간의 노력
  • 공유 리소스의 수를 줄이고 비 공헌 작업의 양을 줄임으로써 드래그 요인을 개선 할 수 있습니다.
  • 드래그 팩터의 백분율로 새로운 추정치를 늘릴 수 있습니다. - 새 추정치 = (기존 예상치 + 드래그 팩터)
• 속도
  • 스 프린트의 발송 기능으로 변환 된 백 로그 금액
• 단위 테스트 수를 추가하지 않았습니다.
• 매일 빌드를 완료하는 데 걸리는 시간
• 반복 또는 이전 반복에서 발견 된 버그
• 생산 결함 누출