사용자 스토리 및 수락 기준이란 무엇입니까 (예)

예:

WhatsApp 사용자로서 채팅 쓰기 상자에 카메라 아이콘을 사용하여 사진을 캡처하고 전송하여 모든 친구와 동시에 내 사진을 클릭하고 공유 할 수 있도록합니다.

합격 기준이란 무엇입니까?

수락 기준은 제품 소유자 / 이해 관계자가 수락하기 위해 기능 또는 기능이 충족하고 충족해야하는 수락 된 조건 또는 비즈니스 규칙의 집합입니다.

이것은 사용자 스토리 완성의 매우 중요한 부분이며 단일 기준을 놓치면 많은 비용이들 수 있으므로 제품 소유자 및 비즈니스 분석가가 매우 세 심하게 연구해야합니다. 이것은 간단한 번호 또는 글 머리 기호 목록입니다.

형식은 다음과 같습니다.

' 내가 어떤 행동을 할 때 전제 조건이 주어지면 결과를 기대합니다. ”.

최고의 무료 PC 클리너는 무엇입니까

예 (위의 사용자 스토리에 w.r.t) :

• 친구와 채팅 중이고 사진을 찍을 수 있어야한다고 생각해 봅시다.
• 사진을 클릭하면 이미지를 보내기 전에 캡션을 추가 할 수 있어야합니다.
• 휴대 전화 카메라를 시작하는 데 문제가 있으면 '카메라를 시작할 수 없습니다.'와 같은 오류 메시지가 표시됩니다. 그에 따라 표시되어야합니다.

따라서 사용자 스토리는 모든 기능 또는 기능에 대한 요구 사항을 정의하고 수락 기준은 사용자 스토리 또는 요구 사항에 대한 '완료 정의'를 정의합니다.

QA로서 '테스트 시작'에 단 한 번의 의심도 남기지 않고 사용자 스토리와 수용 기준을 깊이 이해하는 것이 매우 중요합니다. 앞으로 사용자 스토리와 수용 기준을 '깊이'파헤치는 것이 왜 매우 중요한지 이해하겠습니다.

사용자 스토리 심층 분석

먼저 기본적이고 근본적인 것 즉, '심층'연구의 중요성을 이해합시다. 사용자 스토리.

다음의 경우는 저의 실제 경험입니다.

사례 # 1 :

3 년 전에는 모바일 애플리케이션 프로젝트를 진행하고 있었고 제품은 배달 담당자를 위해 설계된 애플리케이션이었습니다.

배달원이 배달을 위해 당신의 집으로 오는 것을 보았을 것입니다. 그리고 그들은 배달 후 서명을 요구하는 휴대 전화를 가지고 있습니다. 이 서명은 DTDC, FedEx 등과 같은 택배 서비스 제공 업체의 포털에 반영됩니다.

모바일 앱이 방금 시작되었고 포털이 이미 존재하고 가동 중이라고 가정 해 보겠습니다.

문제: Sprint의 경우 제품 소유자는이 모바일 앱에 대한 사용자 스토리를 가지고 있습니다. '포털 관리자로서 배달시 배달 담당자가받은 서명을 볼 수 있어야합니다.' . 여기서 포털 (웹 앱)은 서명을 반영하도록 변경 및 업데이트됩니다.

QA는 모바일 앱에서 캡처 한 서명이 포털에서 예상대로 반영되는지 확인해야합니다.

이 사용자 스토리를 보면 간단 해 보이지만 여기에 숨겨진 요구 사항이 있습니다. '이력 전달의 경우 서명 반영 기능이 없었으므로 포털 직원이 이전 전달을 보면 어떻게해야합니까?' 과거 데이터를 삭제해야합니까? 그러한 데이터에 대해 충돌이나 오류를 허용해야합니까?

물론 전혀 그렇지 않습니다. 이것은 정중하게 처리되어야합니다.

해결책: 각각의 DB 테이블을 업데이트하여 서명 위치에 대한 새 열을 추가 할 때 이전 데이터는 NULL 또는 0 값을 가져야하며이를 확인해야하며 '서명 없음'이라는 메시지가 표시되어야합니다.

이것은 제품 소유자 또는 비즈니스 분석가의 미스라고 할 수 있지만 반드시 수행해야합니다. 하나의 기능을 성공적으로 구현하지만 이와 함께 무언가를 깨뜨리는 것은 고객에게 바람직하지 않습니다. 이는 동일한 사용자 스토리와 동일한 스프린트에서 수행되어야합니다.

사례 # 2

6 년 전 저는 CA, Finance Advisors와 같은 재무 담당자가 다양한 통화에 대해이를 사용하여 투자 계획, 저축 등을 예측할 수있는 글로벌 응용 프로그램 인 은퇴 계획 재무 응용 프로그램 (BA 없음)을 작업하고있었습니다. 그들의 고객에게 큰 기간.

문제: 제품 소유자는 다음과 같은 사용자 스토리를 제공합니다. “어드바이저로서 제공된 재무 세부 정보를 기반으로 고객의 보고서를보고 싶습니다.”

여기에는 두 가지 숨겨진 요구 사항이 있으며 다음과 같은 이유로 불완전한 이야기라고 부를 것입니다.

에) 보고서는 마지막으로 본 보고서의 과거 환율이 아닌 일일 환율을 고려해야합니다.

비) 고객의 재무 정보를 제공 한 후 통화가 변경된 경우 보고서는 변경된 통화로 표시되어야합니다.

해결책: 저는이 문제를 제품 소유자에게 직접 제기하고이 두 가지 모두 가능한 한 빨리 수행해야한다는 사실을 알게했습니다. 그는 나와 동의하고 다가오는 스프린트를 위해 우선적으로 2 개의 다른 스토리를 만들었습니다.

멀리: 우리 모두가 제품, 디자인, 구조 등에 대해 잘 알고 있었기 때문에 잡혔습니다. 이러한 지식은 제품을 완전히 이해하고 모듈의 상호 운용성을 이해하고 사용자 스토리를 철저히 연구해야만 얻을 수 있습니다. 2 라이너.

일을 쉽게 할 수 있도록 메모를 작성하고 BA 및 개발자의 생각에 대해 논의하십시오.

합격 기준에 대한 심층 검토

허용 기준과 다른 모든 조건 및 규칙을 철저히 이해하는 것은 사용자 스토리를 과소 평가하는 것보다 훨씬 더 중요합니다. 요구 사항이 불완전하거나 모호하면 다음 스프린트에서 처리 될 수 있지만 수락 기준을 놓치면 사용자 스토리 자체를 공개 할 수 없습니다.

나는 우리 모두가 어느 시점에서 넷 뱅킹을 사용했을 것이라고 생각하며 우리 대부분은 매일 그것을 사용하고 내 역사적 진술을 많이 다운로드합니다. 주의 깊게 살펴보면 다운로드 할 수있는 특정 옵션이 있습니다.

명세서를 다운로드 할 파일 유형을 선택하는 옵션이 있습니다. 크레딧 / 데빗 / 둘 다 다운로드 할 것인지 선택할 수있는 옵션이 있습니다.

이제 제품 소유자가 '고객으로서 특정 기간 동안 수행 된 모든 거래를 볼 수 있도록 계정 명세서를 다운로드하고 싶습니다'라는 사용자 스토리를 제공한다고 가정 해보십시오.

다음 허용 기준 :

• 내역서 다운로드 페이지에있는 것을 고려할 때 명세서를 다운로드 할 기간을 선택해야합니다.
• 현재 내역서 다운로드 페이지에있는 것을 고려할 때 명세서를 다운로드 할 계정을 선택해야합니다.
• 내가 과거 명세서 다운로드 페이지에 있다는 점을 감안할 때 향후 '종료'날짜에 대한 명세서를 다운로드 할 수 없습니다.
• 내가 과거 명세서 다운로드 페이지에 있다는 점을 고려할 때 과거 10 년 이후의 '시작'날짜를 선택할 수 없습니다.
• 명세서 다운로드를 고려하면 다운로드 한 파일을 볼 수있을 것입니다.
• 내가 역사 명세서 다운로드 페이지에 있다는 것을 고려할 때, 내 명세서를 doc, excel 및 pdf 형식으로 다운로드 할 수 있어야합니다.

이 수락을 통과하면 여기에 누락 된 3 가지 항목이 있습니다.

• 다운로드 할 파일 이름의 이름과 형식입니다.
• 파일에 표시되는 정보 (열 이름).
• 고객이 원하는 거래의 종류 (예 : 차변 만 또는 대변 만 또는 둘 다)를 선택하는 옵션 목록입니다.

이러한 경우는 가끔씩 발생하지만 각 허용 기준에 대해 잘 연구하고 사용자 스토리를 참조하여 시각화하려고합니다. 조건과 비즈니스 규칙에 대해 더 많이 공부할수록 기능에 대한 지식이 더 많아집니다.

초기 단계에서 발견 된 버그는 '테스트'단계에서 발생할 수있는 비용에 비해 비용이 들지 않습니다.

사용자 스토리 / 수락 기준에서 불일치를 찾는 중요성

개발 또는 테스트가 시작되기 전이라도 초기 단계에서 사용자 스토리와 수용 기준을 심층 분석하는 것이 항상 중요합니다.

다음이 포함되기 때문입니다.

# 1) 시간 낭비 :

개발이 진행 중이거나 테스트가 진행 중일 때 사용자 스토리 / 수락 기준에서 불일치 또는 실수가 발견되면 남은 스프린트 시간에 많은 재 작업을 수행해야 할 수 있습니다.

제품 소유자가 몇 가지를 놓친 경우에도 사용자 스토리를 다가오는 스프린트로 이동하지는 않습니다. 95 %의 확률은 팀에 필요한 구현을 수행하고 동일한 스프린트에서 릴리스하도록 요청하는 것입니다.

따라서 추가 시간을 보내거나 주말에 오거나 늦은 밤에 일해야하는 팀에게는 악몽이됩니다. 이것은 가능한 한 빠른 단계에서 사용자 스토리 / 수용 기준을 연구하고 논의함으로써 피할 수 있습니다.

# 2) 노력의 낭비 :

개발자와 QA는 구현 된 코드와 테스트 사례를 다시 검토해야합니다. 요구 사항에 따라 업데이트, 추가 및 제거는 쉬운 작업이 아닙니다. 이미 제 시간에 배달해야한다는 압력이 있기 때문에 너무 고통스러워집니다.

이러한 상황에서는 개발 또는 테스트 단계에서 실수 할 가능성이 있습니다. 이러한 상황이 발생하면 'DevQA 페어링'으로 이동하세요. 케이크 장식으로 추가 작업에 대한 보상을받지 못할 수도 있습니다.

결론

사용자 스토리와 수용 기준에 대한 깊은 이해는 그것을 연구하는 데 엄청난 시간을 할애해야만 얻을 수 있습니다.

제품에 대한 논리적 사고, 경험 및 지식에 관한 것이기 때문에 시장에서이를 수행 할 수있는 특정 도구 나 과정이 없습니다.

사전 계획 회의에 적극적으로 참여하고, BA와 대화하고, 혼자 공부하는 것은이를 달성하는 데 도움이 될뿐입니다. 더 많은 노력을 기울일수록 더 많이 배우고 성장합니다.

QA 든 개발자 든 모두가 사용자 스토리와 승인 기준에 대해 동일한 페이지에 있어야합니다. 그래야만 고객의 기대치를 성공적으로 달성 할 수 있습니다.

User Stories 작업에 대한 경험에 대해 공유 할 새로운 것이 있습니까? 아래에 당신의 생각을 표현 해주세요 !!

추천 도서

• MongoDB 사용자 생성 및 예제로 역할 할당
• 예제가있는 합격 테스트 보고서의 샘플 템플릿
• MongoDB의 사용자 인증
• 사용자 정의 변수를 사용한 JMeter 데이터 매개 변수화
• Unix 권한 : 예제가있는 Unix의 파일 권한
• 수락 테스트 란 무엇입니까 (완전한 가이드)
• UAT (User Acceptance Testing) 란 무엇인가 : 완전한 가이드
• 예제가 포함 된 Python DateTime 자습서