[SW요구사항] 좋은 유저스토리 작성 따라하기 INVEST

좋은 유저 스토리를 작성하기 위해서는 좋은 유저 스토리의 특성이 무엇인지 알아야 한다. 유저 스토리를 작성에는 "Hard core Rules" 가 없기 때문이다.

좋은 유저 스토리란 아래 6가지 특성을 만족한다라고 한다.

• (I)ndependent - 독립적이다
• (N)egotiable – 협상 가능하다
• (V)aluable – 사용자 및 고객에게 가치가 있다
• (E)stimable – 추정 가능하다
• (S)mall - 작다
• (T)estable – 테스트 가능하다

 

참고, 

유저 스토리 - Facts!!

• 유저 스토리는 "Specific task(특정 작업)" 가 아니며 제품의 모든 독립적인 기능에 대한 간단한 설명이다.
• 유저 스토리는 개발자에게 기능이 어떻게 작동하는지 알려주지 않는다.
• 애자일 개발은 개발 중에 변경을 환영하므로 개발의 "Final word" 가 아니다.
• 유저 스토리는 독립적 일 필요가 없으며 한 스프린트에서 실행 가능한 경우 2 개 이상의 기능을 조합할 수 있다.
• 유저 스토리를 작성하기 위한 특정 "Format(형식)" 이나 "Rules(규칙)" 이 없다.
• 유저 스토리가 고객과 공유되지 않는 경우가 있다.

유저 스토리 - Check List

• 가능한 한 짧아야 한다.
• 단순하고 "Customer(고객)" 또는 "End user(최종 사용자)" 가 쉽게 이해할 수 한다.
• 유저 스토리는 "User(사용자)" 관점에서 작성되어야 한다.
• 유저 스토리의 "Value benefit(가치 이점)" 이 명확해야 한다.
• 유저 스토리가 큰 경우 기능을 분리시켜야 한다.
• 항상 "Acceptance criteria(인수 기준)" 를 따라야 한다.

 

소프트웨어 요구 공학, Requirement Engineering

---

 

 

Independent - 독립적이다

스토리는 독립적인 경우 작업하기 가장 쉽다. 즉, 개념이 겹치지 않도록 하고 어떤 순서로든 일정을 잡고 구현할 수 있기를 바란다. 항상 이것을 달성할 수는 없다. 때때로 우리는 "첫 번째 보고서에 대해 3 점, 나머지 각각에 대해 1 점"과 같은 말을 할 수 있다.

유저 스토리 간의 의존성을 제거하여 독립성을 유지한다.

독립적인 스토리는 프로젝트의 비즈니스 및 기술 측면 모두에 도움이 된다고 한다. 

• 사업적 관점 : 기술에 종속되지 않고 사업 목표에 초점을 맞출 수 있음.
• 기술적 관점 : MVP(최소 가치 제품)의 구현 실현 및 종속을 최소화하는 설계 가능
• 의존성 종류 : Overlap Dependency, Order Dependency, Containment Dependency

Overlap Dependency : 중복 의존성 제거

기존 스토리 => “User sends and receives messages” and “User sends and replies to messages.”  의존성 제거 스토리 => User sends [new] message => User receives message => User replies to message

Order Dependency : 주문(순서) 의존성의 문제

“this story must be implemented before that one.” 우선 순위 결정 및 계획 수립에 문제를 발생시킬 수 있기 때문에 구현전에 미리 체크해야 한다. 예 => 사용자가 이메일을 보내기 전에 계정이 필요할 수 있습니다.  => 따라서 먼저 계정 관리 스토리를 구현해야한다고 생각할 수 있습니다. ("관리자가 계정 생성" 과 같은 스토리) 해결 => 초기 계정을 제공할 수 있습니다. ("하드 코딩" or "초기 계정 제공")

Containment Dependency : 포함에 의한 의존성 문제

유저 스토리가 커지면 에픽으로 분류하고 하위에 유저 스토리가 여러개 생성될 수 있다. 이 경우 스토리가 많아지면서 한 스프린트 주기(Iteration) 안에서 개발이 어려울 수 있다. 바로, 하나에서 파생되는 계층구조가 복잡하고 많을 수록 우선순위 설정 및 일정 수립이 어렵다. 이 경우 스토리를 다른 기준에 의해 분리하여 의존성을 갖는 스토리끼리 합치는 작업을 함으로써 해결할 수 있다. 아래 개념으로 재 조합하기를 권장한다. - Affinity diagram - pivot

 

 

---

 

 

Negotiable - 협상가능하다

좋은 스토리는 협상 가능하다. 기능에 대한 명시적인 계약("contract")이 아니다. 오히려 세부 사항은 개발 중에 고객과 개발팀이 공동으로 작성한다. 좋은 스토리는 세부 사항이 아닌 본질을 포착한다. 시간이 지남에 따라 카드는 메모(주석), 테스트 아이디어 등을 얻을 수 있지만 스토리의 우선순위를 지정하거나 예약하는 데 이러한 정보가 필요하지 않다.

 

주요 포인트

- The importance of collaboration (협업의 중요성)
- Evolutionary design (혁신적인 설계)
- Response to change (피드백)

 

"Card" 는 스토리에 대한 짧은 설명일 뿐이다.
- 세부사항은 "Converation(대화)" 단계에서 작성한다.
- 고객과 개발팀은 대화를 통해 기능에 대해 협상할 수 있다.

"Card" 의 너무 자세한 스토리 내용은 고객과의 대화를 제한할 수 있다.
- 한 문장은 한 가지 내용으로만 작성해야 한다. ('and', 'or' 를 사용하지 않는다)
- 스토리의 길이를 적절하게 조정해야 한다. (짧게)

"Card" 는 완성된 요구사항이 아니다.
- 대화를 이끌어내기 위한 단서의 역할을 한다.
- 대화를 통해 아주 중요한 세부사항은 주석으로 추가한다. (Conversation 작성)

 

 

Collaboraion : 개발에서 협업은 필수적이다.

노벨상 수상자 인 Ronald Coase, 개인과 일하는 것은 회사에서 일하는 것보다 많은 비용이 들어간다. => 회사는 더 높은 신뢰를 가질수 있는 영역을 제공하여 더 적은 비용이 발생한다. 개발팀은 서로간의 신뢰를 바탕으로 더 나은 결과를 바란며, "Negotiable" 은 이러한 신뢰를 바탕으로 한다. => work together. (함께 일하고) => share ideas. (아이디어를 공유하며) => jointly own the result. (결과를 공동으로 소유한다.)

Evolutionary Design : 협상을 통해 더 고급형태로 발전시키 수 있다. (from basic to advanced form)

상위 수준의 유저 스토리는 시스템을 사용하는 행위자 관점에서 구현(개발)방식을 구체적으로 제한하지 않고 기능을 정의한다. => specify what, not how. (방법이 아닌 기능을 정의한다.)  예시 - 온라인 서점 주문 시스템 Card (상위 수준 유저 스토리) => 주문처리 시스템("Fulfillment")은 책과 영수증을 전송한다. Conversation (협상을 통해 상세 작성) => 주문처리 담당자는 보낼 내용을 확인하고 선반에서 제품을 꺼내 영수증을 쓰고, 포장하고, 패키지를 배달파트로 옮긴다. => 시스템(창고)는 운송 통로 또는 고객별로 분류된 포장할 품목을 생성한다. => 점원 A는 "배송 리스트"를 확인하고 창고에서 요청된 품목을 가져온다. => 점원 B는 라벨과 영수증을 인쇄하고 포장한다음 발송할 위치에 옮겨둔다. => 품목은 포장되어 지정된 (스마트)선반에 보관된다. => 선반은 품목을 라벨확인 기계로 보낸다.  => 라벨확인 기계는 배송업체가 픽업할 수 있도록 상자를 분류하는 분류파트로 보낸다.

Response to change : 상위 수준 요구사항의 이점

"Negotiable Story"(협상 가능한 스토리)는 모호한 상황에서 도움이 된다. 초기에 상위 수준으로 작성하여 대화를 통해 세부 사항을 작성할 수 있다. 상위 수준 스토리(요구사항)으로 시작하면 필요에 따라 세부사항으로 확장할 수 있고, 더 배우기 위해 여지를 남겨두면 모든 요구사항의 균형을 맞출수 있는 솔루션으로 더 쉽게 발전할 수 있다. By starting with stories at a high level, expanding details as necessary, and leaving room to adjust as we learn more, we can more easily evolve to a solution that balances all our needs.

설득력 있게 말하기, 6하원칙과 Context 그리고 습관

효과적인 의사소통 방법 (PMP)

 

---

 

 

Valuable – 사용자와 고객 혹은 구매자에게 가치 있다

스토리는 가치가 있어야 한다. 우리는 누구에게나 가치가 있어야 하는 것이 아니라 고객에게 가치가 있어야 한다. 개발자는(합법적인) 우려 사항이 있을 수 있지만 이러한 우려는 고객이 이를 중요하게 인식하게 만드는 방식으로 구성된다.
이것은 스토리를 분할할 때 특히 문제가 될 수 있다. 전체 스토리를 네트워크 계층, 지속성 계층, 논리 계층 및 프레젠테이션 계층과 같은 다중 계층의 케이크라고 한다. 스토리를 나누면 그 케이크의 일부만 제공한다. 우리는 고객에게 전체 케이크의 본질을 제공하고 싶으며 가장 좋은 방법은 레이어를 수직으로 자르는 것이다. 개발자는 종종 한 번에 하나의 레이어에서만 작업하려는 경향이 있다. 그러나 전체 데이터베이스 계층에서 프레젠테이션 계층이 없는 경우 고객에게 거의 가치가 없습니다.

 

"이 프로젝트의 가치는 무엇입니까?"

• 명확하게 대답할 수 있어야 합니다.
• 다양한 이해관계자가 어떻게 혜택을 받고 있는지 알 수 있어야 한다.
• 이해관계자 : 사용자, 구매자, 관리자, 개발 조직, 스폰서 등

 

개발자에게만 가치 있는 스토리를 피하라!

ex> 데이터 관리

• 개발자 관점 : 모든 데이터베이스 연결은 커넥션 풀을 통해 이루어져야 한다.
• 고객 관점 : 사용자 라이선스 5개로 50명까지 데이터베이스에 연결하여 사용할 수 있어야 한다.

ex> 로그 관리

• 개발자 관점 : 모든 에러 처리 및 로그 생성은 공통 클래스를 통해 이루어져야 한다.
• 고객관점 : 모든 에러는 사용자에게 보여야 하며, 일관된 형태의 로그로 기록되어야 한다.

 

고객이 직접 스토리를 작성하는 것이 가장 좋다.

• 고객 : 이해관계자 모두.
• 인터뷰 또는 VOC 를 통해 요구사항을 수집할 수 있다.

 

What is Value? : 고객에게 필요한 가치를 생각한다.

IRACIS means: - Increase Revenue. (수익 증대) => 새로운 기능을 추가하거나 기능을 개선하여 지금보다 더 많은 비용을 지불하도록 함. - Avoid Costs. (비용 절감) => 사람을 대체 또는 줄일수 있는 프로그램을 도입. (ex> 콜센터 지원 프로그램) - Improve Service. (서비스 개선) => 기능이나 품질을 개선하여 고객의 이탈을 방지한다. (ex> skype 통화 품질 개선) others: - Meet Regulations (규정 준수) => 정부 기관의 규제나 특정 도메인의 법규(상황)에 의해 반드시 필요한 기능 개발 및 고객에게 기능 제안 (ex> 비대면 솔루션) - Build Reputation (평판 구축) => 시장에서 우리의 가치를 높이기 위해 수행되는 작업 (ex> 무료 버전 제공) - Create Options (옵션 생성) => 더 많은 유연성을 제공하기 위해 제공. (ex> 고객사 요청 DBMS 로의 변경) - Generate Information (정보 생성) => 고객이 더 나은 결정을 할 수 있는 정보를 제공 (ex> A-B 테스트 기능) - Build Team (팀의 구성) => 팀의 구성이나 발전을 위해 필요한 기능 때문에 선택될 수도 있음.

Valuing External Impact : 외부에 미치는 영향을 확인한다.

소프트웨어는 현실세계에서 무엇을 달성하기위해 만들어졌다. 시스템 효과에 초점을 맞춘 전통적 방식 스토리 - 시스템이 완벽한 기술로 구현된것 처럼 시스템 동작을 설명한다. - 시스템 외부에서 내부로 이동하거나 내부에서 외부로 나가는 것을 명확히 한다. 작성된 스토리는 제품 소유자와 사용자(고객)가 명확히 이해할 수 있어야 좋은 선택을 할 수 있다. - 우리가 사용하고있는 솔루션(기술)에 대한 "스토리" - 시스템 제작자 또는 사용자가 원하는 것에 대한 "스토리"

Value for Whom? : 누구에게 가치를 제공할 것인가?

우리가 개발한 소프트웨어로부터 얻는 가치는 사람들마다 다양하다. 개발팀의 업무 중 일부는 다양한 이해 관계자의 요구 사항을 균형있게 조정하는 것입니다. - User => 실제로 소프트웨어를 사용하는 사용자의 요구사항. => 소프트웨어를 사용하는 간접 사용자의 요구사항. => 예로, 콜 센터에서 상담원은 직접 사용자이고 고객은 간접 사용자이다. - Purchasers => 구매자의 요구가 사용자의 요구와 완전히 일치하지 않는 경우가 많다. => 예로, 도입한 소프트웨어에 대한 모니터링 도구는 시스템 관리자만 필요하다. - Development Organizations => 표준 준수, 기본 언어 및 아키텍처 사용 등에 반영되는 요구 사항이 있을 수 있다. - Sponsors => 투자 수익을 원한다.

PON (Problem/Opportunity, Needs) - 제품 관리자

 

---

 

Estimable – 추정 가능하다

좋은 스토리는 추정할 수 있다. 정확한 추정은 필요하지 않지만 고객이 스토리 구현의 순위를 매기고 일정을 잡는 데 도움이 될 만큼 충분하다. 우리가 이해하지 못하는 스토리는 추정하기가 어렵기 때문에 추정 가능하다는 것은 부분적으로 협상의 기능이다. 또한 크기의 함수이기도 합니다. 더 큰 스토리는 추정하기가 더 어렵습니다. 마지막으로 이는 팀의 기능입니다. 예측하기 쉬운 것은 팀의 경험에 따라 다릅니다.
때때로 팀은 적절한 추정을 내기 위해 충분한 정보를 제공하는 "SPIKE" 와 원하는 기능을 실제로 구현할 나머지 스토리로 나누어야 할 수 있습니다.

 

개발자들은 각 스토리의 크기 혹은 작업 소요 시간을 추정할 수 있어야 한다.

- 추정은 Agile 시리즈 책 1권 분량의 어렵고 고통스러운 작업이다.
- 간단하게 아래 방법으로 추정해 볼 수 있다.
- counting stories : 작성된 스토리 수로 추정한다. (이전 평균(샘플) 값 필요)
- historical estimates : 기존 작업 이력을 기반으로 추정한다. (칸반 WIP)
- rough order of magnitude estimates : 대략적인 크기를 산정하여 추정한다.

 

 

추정이 쉽지 않은 경우 및 해결책

– 해당 분야(도메인)의 지식이 부족 
=> 고객 인터뷰를 통해 해결책을 모색한다.

–기술적인 지식이 부족 (짧은 Spike를 통해 극복)
=> 정보수집을 위한 민첩한 스파이크
=> 실제 작업을 수행하는 스토리
* Spike : 개발이나 설계전 프로토타입 형태로 간단하게 구현 또는 시뮬레이션하는 방법

– 스토리가 너무 크다.
=> 스토리를 작은 스토리로 나눈다.
=> Epic 으로 구분하여 향후 스토리로 세분화한다.

 

 

추정 관련하여 언급하기

Why Is It Hard to Estimate? : 추정이 어려운 이유가 무엇인가?

소프트웨어 개발에는 알려지지 않은 사항이 너무 많다. (so many unknowns) 아래 항목들은 하루 또는 일주일 동안 계획하고 회의에 참석하고 헌신적으로 시작한다고해서 어려움을 극복 할 수는 없다. - The Domain => 도메인을 모르는 경우 고객과 오해를하기가 더 쉽고 더 나은 솔루션에 대한 깊은 통찰력을 갖기가 더 어려울 수 있다. - Level of Innovation => 이전에 한 번도 해본 적이 없는 일을 해야하는 분야(domain)에서 운영(operating)해야 한다.  - The Details of a Story => 우리는 종종 완전히 이해되기 전에 이야기를 추정하고 싶어한다. => 아직 명확하지 않거나 예상하지 못한 복잡한 비즈니스 규칙과 제약의 영향을 예측해야 할 수 있어야 한다. - The Relationship to Other Stories => 일부 스토리는 구현 될 다른 스토리에 따라 더 쉬울 수도 있고 어려울 수도 있다. - The Team => 같은 프로젝트, 팀 사람이도 시간이 지남에 따라 변한다. => 새로운 팀에서는 더 어렵다. - Technology => 대규모 프로젝트에서 사용할 기술 중 일부를 알고 있을 수 있지만 모든 것을 미리 알수 없다. => 따라서 추정치는 학습 시간을 고려해야한다. - The Approach to the Solution => 우리는 문제를 어떻게 해결할 것인지 아직 알지 못할 수 있다. - The Relationship to Existing Code  => 기존 솔루션의 섹션("habitable section")에서 작업 할 것인지 여부를 알 수 없습니다. - The Rate of Change  => 우리는 단지 "스토리가 무엇인가?" 를 추정해야되며 또한, "마지막으로 무엇이 될까?" 까지 추정해야 할 수도 있다. - Dysfunctional Games => 일부 환경에서 추정은 정치적 권력을 위한 도구로 평가된다. (힘, 권력에 따라 결정) => 예상 대 약정, 일정 관리 및 기타 많은 악용 등 - Overhead => 외부 요인이 추정에 영향을 준다. => 멀티 태스킹을하거나 사이드 프로젝트를 맡게되면 일이 더 오래 걸린다.

Simple Estimates: Count the Stories

Don Wells 는 매우 간단한 접근 방식을 제안했다. "그냥 이야기를 세어보세요." thought experiment 1. 스토리의 실제 크기를 나타내는 숫자를 가져옴. 2. 무작위 샘플 채취함. 3. 샘플의 평균을 스토리 크기로 설정. 4. 총계에 대한 추정치는 스토리 수에 샘플 평균을 곱한 값. 주의. - 시간이 지남에 따라 능력치나 적응력이 향상된다. (회고를 통해 간격을 좁혀야 함.) - 실제 크기를 가지지 않는 스토리는 무시함 (의존도가 높은 경우)

Historical Estimates (ala Kanban)

work-in-progress (WIP) is the challenge 칸반의 WIP 개념에 대해 먼저 이해를 해야 한다. 개발 기록을 추적하면서 시간을 측정하고 패턴을 찾아낼 수 있어야 한다. - 평균 스토리 전달에 10일 - 스토리 95% 전달하는데 22일 이하 소요 => 다음 스토리 전달에 걸리는 시간을 추정할 수 있다. 이것은 "얼마나 큰가?" 에서 추정 질문을 "얼마나 빨리받을 수 있나요?" 로 바꿀 수 있다. WIP 가 높으면 개발팀의 퍼포먼스가 높은 것이며 WIP 가 낮아지면 개발항목의 중요도가 높은 것이다.

Rough Order of Magnitude

대략적인 추정치는 시간 단위(시간, 일, 주, 월, 년)를 추정한다. - 리스크, 가치 및 옵션을 탐색("Explore")한다. - 대략적인 규모를 추정한다. - 가장 중요한 스토리의 유용한 버전을 작게 만드는 것에 먼저 집중한다. - 해당 버전에서 이해 관계의 균형을 맞추기 위해 협상한다. (어떻게 그리고 얼마나 진행할지 결정) - 이 과정에서 배워나가야 한다.

 

스크럼에서의 소프트웨어 품질 관리

 

---

 

 

Small Scalable – 작아야 한다

좋은 스토리는 작은 경향이 있다. 스토리는 일반적으로 최대 몇 주 분량의 작업을 나타낸다. (일부 팀에서는 며칠의 작업으로 제한한다.)
이 규모보다 크면 스토리 범위에 무엇이 있는지 알기가 너무 어려워 보입니다. "한 달 이상 걸릴 것이다." 라는 말은 종종 "무엇이 수반되는지 이해할 수 없기 때문에" 묵시적으로 추가한다. 작은 이야기는 더 정확한 추정치를 얻는 경향이 있다.

 

주요 포인트

- High-Level Stories: Themes and Activities
- Middle Level: The Headline
- Low Level: The Details

 

세 가지 레벨을 확인하는 것이 도움이 된다.

• Theme – High level : 올바른 일을 다루고 있습니까?
• Headline – Mid level : 사용자가 관심 있는 기능을 얻고 있습니까?
• Details – Low level : 새로운 기능이 필요합니까, 아니면 이전 기능을 개선할 수 있습니까?

 

스토리의 적절한 크기는 개발팀의 역량이나, 사용하는 기술에 따라 결정된다.

– 스토리의 하나의 크기는 1일 ~ 2주 내외로 결정한다.
- 하지만 5일(1주)을 넘지 않는 것이 좋다.

 

Epic 또는 Theme 처럼 큰 스토리의 경우

– 복합적인 스토리 : 작은 스토리를 여러 개 포함

• 스토리 나누기.
• 스토리 합치기.

– 복잡한 스토리

• 크면서도, 나누기 쉽지 않다.
• 스토리 자체에 대한 불확실성에 기인한다.
• 문제를 조사하는 스토리와 기능을 개발하는 스토리로 나눈다.
• 고객이 조사하는 스토리에도 우선순위를 결정할 수 있다.

 

유의 사항

• 스토리를 분리하여 더 강한("intensifying") 스토리로 만든다.
• 큰 스토리는 까다롭다. ("tricky")
• 하나의 헤드라인은 다양하게 변형이 가능하다.
• 기술적 스토리는 작을지 모르지만 그것은 유저 스토리가 아니다.

 

High-Level Stories: Themes and Activities

여기서 언급한 내용은 너무 커서 스토리가 아니라 다르게 불린다. “themes” (Kent Beck), “activities” (Jeff Patton) “epics” (SaFE) “kite level” (Alistair Cockburn) 예> - Reserving cars (자동차 예약) - Renting cars (자동차 대여) - Returning cars (자동차 반납)

Middle Level: The Headline

시스템 외부에서 시작하여 이해 관계자가 관심을 갖는 작업을 수행하는 사용자 또는 시스템 작업을 설명할때 사용한다. 헤드 라인은 템플릿을 따를 필요는 없지만 기본적으로 Industrial Logic 이 제안하는 안을 사용한다. - Role(역할) => 스토리를 동작("triggering")시키는하는 사용자 또는 시스템 - Action(행동) => 무슨 일이 일어나는가 Context [optional] (컨텍스트) =>  언제, 어디서, 그리고(또는) 방법 예> 고객이 품목을 구매 한다. 예> 고객이 직불 카드로 항목을 구매 한다.

Low Level: The Details

우리가 작업해야될 항목을 관리한다. - Middle level => 고객이 품목을 구매 한다. - Low level => 실제 상점에서는 고객이 점원에게 품목을 요청할 수 있습니다. => 슈퍼마켓에서 고객은 상점을 걸어 다니고 원하는 품목을 카트에 넣은 다음 상점 앞의 계산대에서 점원과 계산할 수 있습니다. => Amazon.com에서 상품을 구매하면 신용 카드가 등록되어 있고 Amazon은 체크 아웃하는 동안 교차 판매 및 상향 판매를 시도합니다.  하나의 헤드라인("A single Headline)으로 다양한 변형이 가능하다. 이것이 스토리의 확장성이다. ("That is scalability in stories.")

확장 가능한 스토리의 이점

- 진행 사항의 가시화를 돕는다.  - 빠르게 유용한 도구를 제공한다. ("utility") - 더 가치있는 결과를 얻는데 도움되는 피드백을 제공한다. - 시장("market") 및 기술적 리스크를 줄이는데 도움을 준다.

누구나 따라하기 쉬운 요구사항 작성 Tip, 템플릿

 

 

---

 

 

Testable – 테스트 가능해야 한다

테스트 가능한 스토리는 입력이 주어지면 예상되는 시스템 동작 또는 출력에 동의할 수 있는 스토리이다.

좋은 스토리는 테스트할 수 있다.  "내가 원하는 것을 충분히 이해하여 테스트(케이스 or 명세)를 작성할 수 있다."
여러 팀이 스토리를 구현하기 전에 고객 테스트를 요구함으로써 팀의 생산성이 더 높다라는 보고도 있다.
"테스트 가능성" 은 항상 좋은 요구 사항의 특징이다. 실제로 테스트를 일찍 작성하면이 목표가 충족되었는지 알 수 있다.
팀은 비 기능적 요구 사항 (예 : 성능 및 사용성)을 테스트해야 하는 것으로 취급할 수 있다. 이러한 테스트를 운영하는 방법을 파악하면 팀이 진정한 요구 사항을 파악하는 데 도움이 된다.

 

테스트가 힘든 스토리

- 절대 발생하지 않는다는 것은 입증이 불가능하다
– 예> 어떤 화면도 사용자를 오래 기다리게 해서는 안 된다
=> 새 화면은 95%의 경우 2초 안에 나타나야 한다.

Testable Trigger Words

아래 언급된 단어가 포함될 경우 테스트 가능하지 않을 수 있다. Just (그냥, 단지)  => 아주 작은 단어이지만 실제로 문제를 해결하지 않고 우려의 중요성을 최소화하기 위해 종종 힘의 움직임으로 사용된다. => Just check each of these against all the others Appropriate, right, suitable (적절함) =>물론 당신은 적절한 일을 원한다. => 그러나 "적절한" 이 실제로 의미하는 바를 정의하지는 않는다. Best, worst (최고, 최악)  => "Best" 라고 말하지만 "Best" 를 정의하지 않는다. Most, least, shortest, longest (가장, 최소, 가장 짧은, 가장 긴) => 가장 원하는 것이 무엇인지, 아니면 가장 적게 원하는 것이 무엇인지 명확하다면 도움이되지만  => 이러한 단어는 계산 비용이 많이 드는 선택을 숨길 수도 있습니다. All combinations, all permutations (모든 조합, 모든 순열) => 이 단어는 잘 정의되었지만 계산적으로 실행 불가능한 것을 나타낼 수 있다. Any of, don't care (모두, 상관 안 함)  => 이러한 문구는 종종 비-결정적("non-deterministic") 예제에서 사용된다. => 합법적이지만 이러한 예를 사용하여 테스트 사례를 지정하는 것은 까다로울 수 있다. => Will you list all possible solutions? (가능한 모든 솔루션을 나열 하시겠습니까?) Fun, easy to use, people, like (재미 있음, 사용하기 쉬움, 사람, 좋아요) => 이들은 비 기능적 속성에서 일반적이거나 연구 프로젝트를 숨길 수 있다. I’ll know it when I see it (내가 볼 때 알게 될거야) => 한 번에이 문제를 제대로 해결할 기회가 없다.

several challenges with tests

해결해야 할 문제 => Magic (마법) => Intentional Fuzziness (의도적 인 흐릿함) 알아야 할 과제 => Computational Infeasibility (계산 불가능성) => Non-Determinism (비-결정론) 우연히 받아들이지 않을 위험 => Subjectivity (주관성) => Research Projects (연구 프로젝트)

탐험적 테스팅(exploratory testing), 애자일 소프트웨어 개발

소프트웨어 품질 활동 이해 (QC, QA, QI, QM)

 

출처 : xp123