스크럼 스프린트에서 테스트를 맞추는 방법과 스크럼에서 사용자 스토리를 작성하는 방법

저는 회사에서 새 프로젝트의 개발 팀장입니다. 이것은 회사가 스크럼을 사용할 첫 번째 프로젝트입니다. 폭포 / 반복 SDLC가 있습니다. BA는 요구 사항 문서를 작성하고 개발 및 테스트에 넘겨주고 개발을 시작하며 반복 테스트를 릴리스합니다. 테스터는 개발자가 개발을 계속하고 현재 릴리스의 버그 수정을 수행하는 릴리스를 테스트하는 데 오랜 시간이 걸립니다. 몇 가지 질문이 있습니다

1. 테스트를 위해 언제 릴리스합니까? 개발자가 스토리를 완료하자마자 또는 모든 스토리가 완료된 후 스프린트가 종료되기 전에 테스트에 필요한 시간을줍니다.
2. BA가 사용자 스토리를 작성하는 경우 세부 사항이되어야합니다. 전통적으로 모든 UI 레이아웃, 동작, 텍스트 등을 완성하여 스펙을 작성하는 데 시간이 오래 걸립니다. 내 질문은 구현 가능하고 테스트 가능한 스토리를 작성하는 방법입니다.
3. 테스트 팀은 비 기술적입니다. Scrum에 대한 UI 테스트를 자동화하는 것이 얼마나 중요한지. UI는 WPF를 기반으로합니다.

민첩한 방법 (TDD, 코드 검토, 리팩토링 등)을 사용하는 탄탄한 개발 경험이 있지만 스크럼에 익숙하지 않습니다.

편집 : 반복으로 100 요구 사항이있는 경우 100 요구 사항이 모두 완료 될 때까지 기다리지 않고 30, 35, 35 요구 사항을 완료했을 때 테스트를 릴리스 할 수 있음을 의미합니다.

테스트와 개발이 분리 된 경우 두 개의 별도 스크럼 팀이 있습니다. 한 손으로 다른 손으로 작업하는 것은 좋지 않습니다.

개발자 는 이 팀과 별도로 자체 테스트를 작성 해야합니다 . 이 다른 "테스트"팀을 고객으로 취급해야합니다.

스프린트에서 ... 테스트를 위해 언제 릴리스합니까?

스프린트가 완료되었을 때. 완전히 끝났습니다. 즉, 자체 단위 테스트를 수행 했으며 제대로 작동 하는지 확인하십시오 . 개발 팀이 완료되면 "테스트"또는 "배포"또는 조직에서 발생하는 모든 작업을 위해 다른 팀에 배포합니다.

내 질문은 구현 가능하고 테스트 가능한 스토리를 작성하는 방법입니다.

팀마다 다릅니다. BA는 개발 팀의 일부입니다. 적절한 세부 정보를 얻으려면 팀 (BA + 개발자)으로 작업해야합니다. BA에서 다른 팀으로 올바른 정보를 얻으려는 팀의 노력입니다.

Scrum에 대한 UI 테스트를 자동화하는 것이 얼마나 중요한지.

본질적인. 모든 UI 개발에 필요합니다. 개발자는 "테스트 팀"에 제공 되기 전에 모든 테스트를 스스로 수행해야합니다 . UI가 있으면 테스트해야합니다. UI가 없으면 자동화 된 UI 테스트가 필요하지 않습니다. 테스트가 필요하며 UI를 테스트해야합니다. 자동화 된 테스트는 현재 모범 사례입니다.

결론. 모든 세부 사항을 작성하는 별도의 "테스트"팀과 BA는 Scrum을위한 최적의 조직이 아닙니다. 스크럼은 조직뿐만 아니라 프로세스를 재고해야한다는 것을 의미합니다.

내가 줄 대부분의 대답은 소프트웨어 개발의 Agile 방법과 Iterative Waterfall 방법에 관한 것입니다. 스크럼은 인기있는 애자일 구현입니다.

1. 일반적인 스크럼에서는 별도의 테스트 단계가 없습니다. 정식 테스트는 전체 스프린트 전체에서 이루어져야하기 때문입니다. 개발자가 사용자 스토리를 마치면 QA 리소스는 이미 테스트 사례를 준비하고 그 시점에서 테스트를 시작해야합니다. 테스트 사례가 통과되면 사용자 사례를 수락하고 다음 사례로 넘어갑니다. 모든 사용자 스토리가 완료되고 수락되면 스프린트가 끝나고 다음 단계를 시작합니다. 이것은 물론 지속적인 통합에 의존하므로 QA는 즉시 개발 변경 사항을 이용할 수 있습니다. 추가 개발은 TDD 지침을 따라 회귀 테스트가 가능한 한 빠르고 고통없이 이루어 지도록해야합니다.

2. BA가 사용자 스토리를 작성하는 것이 좋지만보다 상세하고 구체적인 제어를 위해 사용자 스토리는 공식 요구 사항 문서와 함께 제공 될 수 있습니다. 사용자 스토리는 역할별로 단일 사용자 관점에서 작성해야합니다. 소프트웨어는 현재 사용자의 관점에서 요구를 표현하므로 소프트웨어가 현재 해당 요구의 모든 측면을 충족시키는 경우 사용자 스토리가 충족됩니다. 사용자 스토리는 하위 사용자 스토리와 할당 가능한 작업으로 구성 될 수 있습니다. 여러 사용자 스토리에 대한 작업이 겹칠 수 있습니다.

3. 자동화 된 UI 테스트는 좋은 일이지만, 개인적으로 모든 Business Logic의 TDD 방법과 100 % 단위 테스트 범위에 대한 노력이 더 중요하다고 생각합니다. 대부분의 소프트웨어 개발 팀은 Business Logic의 100 % 적용 범위를 달성 할 수 없으므로 자동 UI 테스트는 BL에 대한 더 많은 단위 테스트를 작성하는 데 사용할 수있는 귀중한 시간 낭비입니다. 제 생각에는 사치가 아닙니다.

1. 스크럼에서는 각 스프린트가 끝날 때 배송 가능한 소프트웨어 증분 을 생산해야합니다 . 결과적으로, Scrum은 주어진 사용자 스토리를 수행하는 데 필요한 모든 기술이 팀에 존재해야하는 전체 팀 또는 부서 간 팀 개념을 홍보합니다 .

   현재 진행중인 프로젝트에서 완전히 테스트 된 스토리는 완료에 대한 정의의 일부이므로 팀에 테스터를 포함 시켰습니다. 스프린트 첫 며칠 동안 개발자가 첫 번째 사용자 사례를 다루기 시작하는 동안 테스터는 테스트 시나리오를 준비하고 일부 테스트 데이터를 설정합니다. 사용자 스토리 중 하나에 대한 개발자가 완료 되 자마자 테스트합니다.

2. 이것은 Scrum IMO에서 가장 큰 어려움 중 하나입니다. 구현 가능하고 테스트 가능한 사용자 스토리를 얻는 데 필요한 적절한 사양을 찾아야합니다. 선행 분석, 문서 및 사양이 너무 많으면 스프린트 과정에서 필연적으로 잘못 될 수있는 엄격한 계획이 생깁니다. 반대로, 제품 소유자가 명확하게 정의하고 표현하지 않은 사용자 스토리는 스프린트 동안 개발자와 PO 사이의 포화 된 통신 대역폭과 개발 지연으로 이어질 것이며 PO는 스프린트의 중간 단계에서 사용자 스토리에 대한 결정을 내립니다. .

   우리의 경우에, 우리는 사용자 스토리에 대한 적절한 양의 세부 사항을 "/ ... 내가 원하는 ...으로 ..."와 2 / 일련의 수용의 형태로 설명으로 정의했습니다. 기준. 우리는 사전에 UI 모형을 거의 만들지 않으며, 스프린트 계획 중에 발생할 수 있지만 나중에 폐기되는 더 많은 스케치입니다.

3. 내 경험상 자동화 된 UI 테스트는 시간이 많이 걸리고 부서지기 쉽습니다. WPF 에는이 를 수행 할 수있는 방법 이 있지만, 그러한 테스트를 유지하기 전에 그러한 테스트의 유지 비용을 이점으로 신중히 고려할 것입니다.

더 짧고 짧은 반복으로 작업하면 이러한 핸드 오프가 점점 더 비싸집니다. 배치 크기를 반으로 줄이고, 편안하게 작업 할 수있는 방법을 바꾸고, 행복해질 때까지 반복하여 어리 석고 간단한 규칙을 따르면 이러한 비용을 줄일 수 있습니다.

5 층짜리 스프린트 예제를 보자. 팀이 5 층 모두에 대한 코드를 작성하는 데 익숙하다면 5 층을 모두 테스트하면 배치 크기는 5 층입니다. 반으로 잘라 다음 스프린트에서는 가장 시급한 3 가지 이야기를 먼저 수행하여 가능한 빨리 테스트 할 준비를하십시오. 테스터가 3 층을 테스트 할 때 나머지 2 층은 테스트 준비를 할 수 있습니다. 이것은 약간의 고통을 유발할 것입니다. 보다 편안하게 작업하기 위해 작업 방식을 변경하십시오.

예를 들어, 더 많은 사람들이 각 스토리를 함께 작업 할 것이므로 더 많은 페어링을 시도하여 더 꾸준히 작업하는 데 도움이되는지 확인하십시오. 또는 테스터는 스토리 2에서 스토리 5에서 작업을 시도하는 동안 일부 프로그래머의주의를 산만하게하는 문제를 발견 할 수 있으므로 다음 스프린트에서 프로그래머와 테스터가 "첫 번째 배치에서 스토리 중 하나를 테스트하는 방법에 대해 먼저 논의하도록 장려하십시오. "프로그래머가 테스터가 테스트를 쉽게 잡을 수있는 실수를 할 가능성이 줄어 듭니다.

프로그래머가 다음 단계의 스토리에서 작업하는 동안 테스터가 작은 스토리를 테스트하는 것과 관련된 큰 문제를 해결하려면 약간의 스프린트가 필요할 수 있습니다. 편안 해지면 배치 크기를 다시 반으로 자릅니다. 그리고 다시. 년 정도 내에서 팀은 프로그래머들이 그들과 함께 마친 생각으로 편안하게 이야기를 테스트 될 것입니다 및 아마 길을 따라 더 적은 실수를. 각 이야기는 더 빨리 이루어질 것입니다.

물론이 시점에서 이제 팀이 제품 소유자로부터 받거나 팀이 운영 조직으로 배송하는 배치와 동일한 작업을 수행 할 수 있습니다. 등등. 이 시점에서 "BA가 스토리에 대해 얼마나 상세하게 작성해야합니까?"를 해결할 수 있습니다. 문제.

그건 그렇고 : 테스터가 처리 시간을 단축하려면 자동화 방법을 배우고 프로그래머가 자동화를 돕는 방법을 학습하여 자동화를 채택해야합니다. 배치 크기를 줄이려고 할 때 이러한 문제를 해결해야하는시기를 알 수 있습니다. 책에서 필요하다고 말해서 자동화를 추가하지 마십시오.

도움이 되길 바랍니다.

아래와 같이 경험을 나누고 싶을 때 도움이 되길 바랍니다.

테스트를 위해 언제 릴리스합니까? 개발자가 스토리를 완료하자마자 또는 모든 스토리가 완료된 후 스프린트가 종료되기 전에 테스트에 필요한 시간을줍니다.

각각의 큰 사용자 스토리마다 많은 하위 작업으로 세분화되어야하며 개발자가 하위 작업을 완전히 수행하면 즉시 테스트를 위해 QC로 릴리스해야합니다. 하위 작업에 대한 테스트 후 테스트 완료 후 결함을 수정해야합니다.

BA가 사용자 스토리를 작성하는 경우 세부 사항이되어야합니다. 전통적으로 모든 UI 레이아웃, 동작, 텍스트 등을 완성하여 스펙을 작성하는 데 시간이 오래 걸립니다. 내 질문은 구현 가능하고 테스트 가능한 스토리를 작성하는 방법입니다.

Scrum에서 사용자 스토리는 스토리를 둘러싼 대화가 발생하고 완료되거나 정적 인 것으로 예상되지 않는 한 임의의 형식이어야합니다. 단순히 사용자 스토리라고하는 작은 스토리는 잘 이해되고 스프린트 내에서 구현할 수있는 스토리입니다. 스토리의 우선 순위는 ROI, 비즈니스 가치 또는 사용자가 동의 한 기타 사항을 기반으로 할 수 있습니다. 이것은 PO의 활동입니다.

테스트 팀은 비 기술적입니다. Scrum에 대한 UI 테스트를 자동화하는 것이 얼마나 중요한지. UI는 WPF를 기반으로합니다.

스크럼에서 자동화 테스트를 적용하는 것은 매우 어려운 작업입니다. 모든 기능이 불완전하게 구현되어 실제로 자동 테스트 툴에 의해 QC가 테스트 케이스를 구현할 수 있도록 안정적이지는 않기 때문입니다. 스프린트 : 회귀라는 스프린트에 대해 수행해야합니다.