SFDPOT

ExploratoryTesting에서 Product elements에 해당하는 모델

• Structure: Everything that comprises the physical product

• Function: Everything that the product does

• Data: Everything that the product processes

• Platform: Everything on which the product depends (and that is outside your project)

• Operation: How the product will be used

• Time: Any relationship between the product and time

https://groups.google.com/forum/?hl=ko&fromgroups#!msg/xper/YozTnmhgQoc/wey_ksv6EhIJ

by 김창준

• SFDPO는 San Francisco Depot이라고 하는데, 다음 자료들을 참고하세요.

  • http://en.wikipedia.org/wiki/San_Francisco_depot

  • http://www.satisfice.com/articles/sfdpo.shtml

  • http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=ART&ObjectId=12127&tth=DYN&tt=siteemail&iDyn=2

  • http://itknowledgeexchange.techtarget.com/software-quality/tips-for-figuring-out-test-coverage/

  • http://blog.testlabs.com/2009/03/informed-software-test-design-using-san.html

  몇 가지 예를 들면, 파일 처리를 모델링한다고 할 때,
  • Structure : 파일 처리 관련한 물리적 구조(파일관련한 콜 처리의 layer, 하드웨어 등)를 어떻게 모델링 할 것인가?
  • Function : 파일 처리 관련한 기능들(path 나열, CRUD 등)을 어떻게 모델링 할 것인가?
  • Data : 파일 처리에서 오가는 자료들(저장 데이타, 파일 이름, 속성 등)을 어떻게 모델링 할 것인가?
  • Platform : 파일 처리가 의존하는 플랫폼(OS, CPU, HDD, 네트워크, 버스 등)을 어떻게 모델링 할 것인가?
  • Operations : 파일 처리를 사용하는 사람 입장(일반적 시나리오, 극단적 시나리오 등)에서 어떻게 모델링 할 것인가?
  • Time : 파일 처리 관련한 시간(타임 아웃이나 동시성, 간발의 차이 등) 모델링을 어떻게 할 것인가?
  등을 예로 들 수 있겠죠.

http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=ART&ObjectId=12127&tth=DYN&tt=siteemail&iDyn=2

"If you were playing the Seahawks today, what would be your game plan?"

Wanting to provide a great quote, but thinking quickly, I might answer in terms of the following five elements:

• Structure: The team's composition
• Function: The team's capabilities
• Data: What the team might "process" (i.e., what we do with the ball)
• Platform: What the team depends upon
• Operations: How I'll use my team's skills

So if, an hour before a spontaneous project meeting, a project stakeholder asks you to be prepared to answer questions about your plan to find bugs, you might take the same approach:

• Structure: What is the software project comprised of? (Code, files, specs, wireframes, user docs, media, etc.)
• Function: What is it that the software can do? What are its features and subfeatures?
• Data: What kinds of data can the software process and how might it process it?
• Platform: What does the software depend upon? (Plug-ins, operating systems and related service packs, language and locales, etc.)
• Operations: What are the different ways the software's features can be used? What are the patterns and sequences of input, who is likely to use it?

Let me bring this scenario back to the coach in my football example.

I may answer the sports reporter's question like this:

"I've got a deep bench (Structure), so I'm confident that our past performance on special teams against the Seahawks has been great (Function) when we pass the ball instead of run it (Data). Given my star players aren't that healthy right now (Platform), I'd start them in the third quarter, especially if that wind picks up out there (Operations)."

I know it's a bit abstract, but this sound bite might give you an idea of how a coach might inventory their ideas about five major team dynamics on-the-fly. As coach, I might be wrong about this plan since the sound bite may be more of a gut check, but it's meaningful enough for now to solve the problem of the sound bite. Besides, I can always adapt the plan once the game starts and I get more information.