Sheet 1
Project Information
  Preference
    Feelings
    Values
    Aesthetics
    Biases
  Reference
    Artifacts
      Builders' references
        Problem description
        Architecture diagrams
        Flowcharts
        Project charter
        Specifications
        Data dictionary
        Source code
        Project demos
        Timelines
        Glossaries
      Testing references
        General
          Risk List
          Testing Heuristics
        Project-specific
          Product and project risk list
          Coverage outline
          Test reports
          Bug reports
      Comparable products
        Previous version of the product
        Competitive products
        Known good example output
        Known bad example output
        (remember, a single feature, function, or data point can be comparable; that is, provide a basis for comparison on some point)
    Tools
      APIs
      Test frameworks
      Output checking tools
        Includes presumed good data and procedures for comparison
      Data generation
      Visualization
        Charting processes
        Showing patterns or trends in data
          e.g. sparklines,
        Illustration and sketching
        Features in existing tools
          e.g. Excel
            e.g. conditional formatting
            e.g. sparklines
      Mathematical/statistical analysis
    Documents
      Company Website
        General
        Product-specific
      Laws and regulations
      External regulations
      Standards
      User guide
      API documentation
      Subject literature from the product's domain
    Repositories
      Internal
        Support database
        Bug-tracking database
        Project management tools
      External
        Google
        Wikipedia
        Libraries
        Bookstores
        Standards bodies
  Conference
    Who
      Primary client
        Product Owner
        Development manager
        Test manager
        Test lead
      Key stakeholders
        Requesters
        Managers
        Developers
        Maintenance people
        Project managers
        Designer
        Technical support
      Stakeholders
        Users (focus groups)
        Subject matter experts
        In-house counsel
        Users
          Suppliers
      Others
        Outside experts
        The receptionist
        Previous testers
        Friends
    What or How
      Direct conversation
        Working interaction
        One-on-one meeting
        Group meetings
        Interviews
        Conferences
        Social interaction
      Mediated
        Instant messaging
        Project wiki
        Telephone
        Email
        Mail
  Inference
    Imagination
    Project management expectations
    Intended usage
    Consistency principles
      Patterns of familiar problems
      Explainability
      World
      History
      Image
      Claims
      Comparable products
      User desires
      Product
      Purpose
      Standards and statutes
      The product should be consistent with these
      The product should be inconsistent with these
  Experience
    Experiments on the product
      Direct user interaction with the product
      Preparation for automated checking
      Interpretation of automated checking results
      Interaction with the product's APIs
      In similar and different environments
      Output from these experiments
      Tools used for development
    Feelings experienced during testing
      Impatience
      Confusion
      Frustration
      Annoyance
      Suprise
      Amusement
      Fear
      Curiosity
    Stories, memories and tacit knowledge from...
      Previous iterations
      This project
        Business goals
      Previous projects
      This company
        Business goals
        Business process and culture
      Formal education
      Work-specific training
      Other companies
      Using other products
      Life outside the development world
  Sources of Project Information
    This mind map was prepared by Michael Bolton. It includes suggestions from the "Every Tester Has a PRICE" session at EuroSTAR 2014.
    This is not intended to be a comprehensive listing, but the outcome of one brainstorming session with extra ideas added later.
    PRICE comes from the initial letters of the top-level categories: Preference, Reference, Inference, Conference, and Experience. The mnemonic is intended to provide a trigger to think of new sources of information when testers are stuck.
    Information sources are closely related to oracles--means by which we recognize problems when they happen during testing. Problems in the product and the project can be identified by observing undesirable consistencies and inconsistencies between related things.
    These categories tend to overlap; that's okay. The purpose of this exercise is not to come up with an idealized map, but to learn and discover things as we sort and re-sort ideas into categories. In mind mapping, just as in testing, the mind is more important than the map.
Project information comes in many forms. In Rapid Testing, we identify Experience, Inference, Conference, and Reference as basic families of information sources. For EuroSTAR 2014, I playfully added "Preference" so that I could say that "every tester has a PRICE", focused the latter four letters, at least. Nonetheless, "Preference" is something that drives Experience and Conference. It's at the heart of testing work to find out what people prefer; what's good enough or not; what they like and don't like; what they want and don't want. After all, testing is all about exploring the product and the systems around it to help the business decide whether the product they've got is the product they want. Preferences are central to our individual and shared feelings and mental models of the product.
All of these references are heuristic in nature; that is, they are fallible ways to solve certain kinds of problems. They can be useful sources of project information, for sure. Yet they are often imperfect in many ways: incomplete, ambiguous, self-contradictory, vague, incoherent, out of date... You get the picture. Artifacts can be valuable, but they can also be unhelpful and misleading---and as with bugs, you can't also know right away that you're being misled.
The good news is that, while this is a problem for testing, it's precisely the kind of problem that testing can greatly help to resolve. Disagreement between explicit requirements is a hint that confusion exists somewhere else. Mysterious silences or omissions in descriptions of the product might indicate designers aren't thinking about that part of the design. If the testers don't have a straight story, it's possible that others (like developers) don't either.
There may be value in having the testers create or revise specific artifacts for the whole team, if those artifacts are missing or messy. Testing and documenting a product or an API can be a powerful way to structure learning about it and to discover problems at the same time. But in Rapid Testing, we urge people not to create a formal, heavyweight document unless the value of doing so justifies the cost.
My personal library often grows when I do testing in a new domain.
In Rapid Testing, your primary client is the person to whom you report directly; the person who has authority over the quality and structures of your work; the person you would probably say was your boss. There are lots of variations in the world.