답변.

문제의 역사:

일반적인 문제는 사용자 흐름에 대한 불완전하거나 비구조적인 설명으로, 이는 개발/테스트에서 분석가로의 많은 작업 반환을 초래합니다. 이는 고려되지 않은 전환, 역할, 오류 처리 조건 때문입니다.

문제:

사용자 흐름과 시나리오는 종종 임의의 스타일로 설명되며, 항상 구조적으로 또는 포괄적으로 설명되지 않습니다. 이로 인해 비즈니스의 기대와 실제 구현 간의 불일치가 발생하고, '수정 요구' 반환은 기한을 연장합니다.

해결책:

시스템 분석가는 다음과 같은 접근 방식을 적용합니다:

• Use Case 템플릿을 통한 시나리오 형식화: "주요 흐름", "대체 흐름", "예외".
• 시각적 도표 사용: 플로우차트, 활동 다이어그램, 와이어프레임/모형을 통해 모든 단계의 시각적 조율.
• 팀과의 정기적인 데모 및 '실시간 시나리오 실행' 수행.
• 각 시나리오에 대해 acceptance criteria 기록, 경계 조건 및 비표준 상황 포함.
• 개발자 및 QA로부터의 피드백이 최종 시나리오 구조에 영향을 미침.

주요 특징:

• 구조를 제공하는 서식 템플릿(Use Case, Gherkin 시나리오) 사용.
• 복잡한 분기 및 상호작용에 대한 시각화는 필수.
• 모든 흐름은 문서화 전에 비즈니스, 아키텍처 및 개발과 조율됨.

트릭 질문들.

선 다이어그램 없이 텍스트 설명만으로 시나리오를 한정할 수 있나요?

아니요, 도표 없이 텍스트 설명은 불편하게 이해하고 검증하는 데 문제가 발생합니다. 종종 분기점과 대체 흐름이 사라집니다. 텍스트와 도표의 조합이 검증된 관행입니다.

happy path(주요 성공 시나리오)의 기록이 충분한가요?

아니요, 대부분의 오류는 대체 및 예외 경로에서 발생합니다. '무엇을, 만약…'에 대한 완전한 분석이 필요합니다. 이것 없이 지속 가능한 솔루션을 구현하는 것은 불가능합니다.

QA 및 개발자와 협력 없이 사용자 흐름을 작성할 수 있나요?

아니요, 기술적 및 테스트 측면이 없으면 중요한 세부 사항이 누락될 수 있으며, 이는 나중에 발생해 수정이 필요할 수 있습니다. 사용자 흐름 작업은 교차 기능적인 과제입니다.

일반적인 오류 및 안티 패턴

• 시나리오에서 제외되는 경우와 오류를 무시함 (성공적 흐름만 초점).
• 사용자 흐름 분석 없이 와이어프레임으로 넘어감.
• 사용자 흐름과 acceptance 기준 간의 충분한 연계 부족.

실제 사례

부정적 사례: 분석가는 전통적인 경로로만 구매를 위한 사용자 흐름을 설명했습니다 — 반환, 취소 및 타임아웃 없이. 테스트 중에 많은 질문과 수정을 요구하는 반환이 발생했습니다.

장점:

• 작업 시작을 위한 문서화를 신속하게 받았습니다.

단점:

• 반환으로 인해 기한이 지연됨.
• 시나리오를 다시 작성해야 함.

긍정적 사례: 유사한 프로젝트에서 분석가는 분기점과 예외를 작업하고, 각 작업의 플로우차트를 그렸으며, QA 및 개발로부터 정기적으로 피드백을 수집했습니다.

장점:

• 신속하게 시나리오를 확인하고 승인 받음.
• 분석으로의 반환이 최소화됨.

단점:

• 초기 작업에 더 많은 시간이 필요함.