-
Notifications
You must be signed in to change notification settings - Fork 28
프로젝트 계획
강현구 edited this page Mar 24, 2023
·
21 revisions
본 프로젝트는 "린 애자일 기법을 활용한 테스트 주도 개발"에서 소개하는 프로세스를 참고하여 진행합니다.
기획 - 기능 - 스토리 - 시나리오 - 테스트
- 기획: 전체 프로젝트에 대한 테스트, 목적에 대해 결정하는 단계
- 기능: 고수준의 요구사항을 수립하는 단계
- 스토리: 기능을 바탕으로 사용자 스토리를 도출하여 인수 기준을 결정하는 단계
- 시나리오: 사용자 스토리를 바탕으로 유스케이스를 작성하는 단계
- 테스트: 유스케이스를 검증하는 테스트를 정의하는 단계
- 비전: 왜 이 프로젝트가 끝나야 하는지 프로젝트의 최종 상태를 기술
- 미션: 비전에 도달하기 위해 필요한 경로
- 목표: 외부에서 볼 때 프로젝트의 성공을 측정할 수 있는 기준
- 원칙: 팀이 의사결정을 할 때 사용할 수 있는 가치있는 문장
- miro
- 수집된 기능 목록 - 구현할 기능 목록을 수집
- 결정된 기능 목록 - 수집된 기능 목록을 대상으로 이번 마일 스톤에서 진행할 항목을 정함
- 우선순위가 높고 중요한 순으로 선정
- 구현 가능한지 예측 필요
- 가능하다면 기능에 대한 계획과 일정을 세우기
기능을 스토리로 분할
As a user
I want to receive issue webhooks from Gitlab
So that I can list all current tasks
역할(누가)
- 기능을 다루는 주체
- 특정한 사람일 필요는 없음
역할의 스토리 예시
- 작성자가 학습 내용을 정리 하기 위해 학습로그를 작성한다.
- 사용자가 다른 크루들의 학습 형태를 참고 하기 위해 다른 크루의 학습로그를 조회한다.
스토리 인수 조건
- 스토리는 간단한 설명 정도로 짧으면 좋다.
- 상세한 사항은 스토리 구현 직전이나 구현 중에 기술할 수 있다.
- 기술 의존적인 용어 보다는 고객의 언어로 작성되어야 한다.
ex) 다른 크루의 학습로그 조회
- 학습로그를 작성한다. 작성된 학습 로그를 조회한다.
하나의 스토리에 대해 여러 케이스에 대한 유스케이스를 도출하기
- A 스토리
- 정상 케이스
- 예외 케이스1
- 예외 케이스2 ...
- 스토리 별로 유스케이스를 작성
- 유스케이스는 정상적인 케이스 + 예외 케이스에 대해서도 함께 작성
- 세부 규칙은 유스케이스별로 나누지 않기
- 각 유스케이스는 인수 테스트로 검증됨
유스케이스
- 사용자와 소프트웨어 간에 발생하는 일련의 행동과 반응의 기록
- 스토리를 위한 업무 흐름을 기반으로 작성
시나리오를 기반으로 인수 테스트를 만든다. 테스트와 함께 문서화도 진행한다.
테스트의 구조
- given, when, then 형식을 사용할 수 있음
- 테스트가 검증할 시나리오를 표현