유저 스토리
유저 스토리란 사용자가 서비스에서 원하는 목적을 달성하기 위해 해야 하는 액션을 한 문장으로 정리한 것
- 쪼렙 서비스 기획자
- As a:: 성남에 사는 시민으로서
- I Want:: 부산에 열차를 타고 가기 위해
- so that:: SRT 티켓을 원한다
유저 스토리 작성은 Happy Path 뿐만 아니라, 정상적이지 않은 예외적인 상황에서도 추가될 수 있다.
 |
 |
- GIVEN:: 열차가 존재한다.
- GIVEN:: SRT 회원이 존재한다.
- WHEN:: 회원이 열차 예약 시 남은 좌석이 존재하지 않는 경우
- THEN:: 잔여석 없음 얼럿을 보여준다.
인수 테스트
인수 조건: 소프트웨어 제품이 사용자, 고객, 기타시스템에서 수락하기 위해 충족해야 하는 조건
각 유저스토리 마다 고유하며 최종 사용자의 관점에서 기능 동작을 정의한다.
인수 조건 ?
제품이 사용자의 요구사항을 만족하고 있는지를 판별하기 위한 기준이다. 사용자의 관점에서 제품의 기능을 정의
본격적으로 개발에 착수하기 이전에 요구분석 결과를 바탕으로 제품의 기능과 목적을 정의하는 과정에서 인수조건을 결정
고객을 행복하게 하는 제품 개발 인수조건 中 - team typed
인수조건은 테스트가 가능한 조건이어야 한다.
인수조건에 설계 조건이나 구체적인 솔루션을 언급하지 않는다.
구체적인 예시를 활용하여 각 구성원들의 각기 다른 해석 가능성을 없애도록 한다. (유저스토리 기법 👍)
팀원들이 사용하는 유비쿼터스 언어가 있다면 적극 활용한다.
인수기준은 팀원 모두에게 공유되어야 하며, 피드백을 받는 과정이 필요하다.
개발팀은 기능을 정확하게 인지하게 되고, 기획팀은 구현된 기능으로부터 기대할 수 있는 결과를 이해하고 예측할 수 있기 때문이다.
인수조건은 개발이 시작되기 전에 작성이 완료된 상태이어야 한다. 제품 개발에 요구사항을 제대로 반영하도록 만들기 위한 장치이기 때문인데, 나중에 작성하면 의미가 퇴색된다.
인수조건을 잘 만들었다면 제품 개발에 분명한 방향성을 부여하고, 제대로 구현하고 있는지를 효율적으로 검증할 수 있을 것이다.
인수테스트를 위해 요구사항을 명확하게!
예시를 통하여 요구사항을 명확히 하자, 만들어 둔 예시들은 구현에 대한 테스트로 이용하자.
개발자:
안녕하세요. 이번에 할인 기능 제가 작업하기로 해서 연락 드려요. 혹시 할인 정책 정리된 거 있을까요?
기획자:
네, 정리해둔 거 있어요! 할인 정책 전달드려요.
고객이 우수고객이며 총 주문금액이 10달러 이하인가?
|
개발자: (이의제기1)
음.... 제가 이해한 바로는 아래와 같은데요.
혹시 우수고객이 50달러 초과 주문하면 할인율 정책이 어떻게 될까요? 1%? 5%? 6%?
| 고객 종류 | 총 주문액 | 할인율 | 고객 종류 | 총 주문액 | 할인율 |
| 우수고객 | 10$ | 0% | 최우수고객 | 10$ | 1% |
| 10.01$ | 1% | 10.01$ | 1% | ||
| 50.01$ | 1%? 5%? 6%? | 50.01$ | 5% |
기획자:
아, 우수고객이 50달러 초과 주문해도 할인율은 1%에요!
개발자: (이의제기2)
알겠습니다. 그리고 한가지 더요!
주문금액보다 큰 금액의 쿠폰 사용 시 주문금액은 0보다 작을 수가 있어요.
이 경우 할인율 적용하면 문제가 될 것 같은데, 할인율을 없애는게 맞으려나요?
기획자:
네, 주문금액보다 큰 금액의 쿠폰을 사용할 경우 할인율은 0%로 해주세요.
개발자: (최종확인)
네네, 그럼 정책은 아래와 같은지 한번 더 확인 부탁드려요.
정책이 맞다면 아래대로 개발 들어갈게요.
| 고객 종류 | 총 주문액 | 할인율 | 고객 종류 | 총 주문액 | 할인율 |
| 우수고객 | -0.01$ | 0% | 최우수고객 | -0.01$ | 0% |
| 10$ | 0% | 10$ | 1% | ||
| 10.01$ | 1% | 10.01$ | 1% | ||
| 50.01$ | 1% | 50.01$ | 5% |
기획자:
완벽합니다 💯
TODO:: 73~
TODO:: 개발자 인수 테스트? p199
TODO:: 테스트 평가 p249
