Exploratory Testing (or just "Testing")

Tips

Don't fixate on working applications. Explore a wireframe. Explore a mockup. Explore databases, systems diagrams, APIs, acceptance criteria, ideas, processes, feature files, assumptions, the UI, specifications. Go and explore anything you can gather useful information from!
Exploratory testing is an experiment mindset. Channel your curiosity and amplify your investigative approach. Seek out truth and discover answers to questions about risks and assumptions.
Give your exploratory session purpose. Become a charter-generating machine. Too refined and you’ll restrict an opportunity to uncover a useful array of information. Go too wide, lose focus, and you’ll miss important discoveries. With practice, you’ll be setting goals that feel “just right”.
Charter Definition: Explore <target> with <resources> to discover <information>
Example: Explore the shopping basket with the basket API to discover security vulnerabilities
Let requirements become an oracle to trigger test ideas and conversation, not the key influencer of where to place exploratory efforts.
Automate tasks to support your exploratory efforts: write scripts that input data
Define a set of heuristics before exploration and refer to them to trigger ideas (see examples in Data Type Attacks section)
Use comparable products to form an opinion. This can also help spark ideas for testing, development, and feature enhancements.
Look at the browser’s console and view application logs

Anything can guide the tester in what to test, how to test, or how to recognize a problem, such as:
- The project context, market forces that drive the product (competitors, desired customary benefits, users), hardware and software platforms, and development history of prior version and related products.
- Risks, failure history, support record of this and related products and how this product currently behaves and fails.

Study competitive products (how they work, what they do, what expectations they create)
Research the history of this / related products (design / failures / support)
Inspect the product under test (and its data) (Create function lists, data relationship charts, file structures, user tasks, product benefits)
Question: Identify missing info, imagine potential sources and potentially revealing questions (use reference materials to supplement answers)
Review written sources: specifications, other authoritative documents
Try out potentially useful tools
Hardware / software platform: Design and run experiments to establish procedures and techniques (ex: printing)
Create and apply models:
- A model is a simplified representation of a relationship, process or system. The simplification makes some aspects of the thing modeled clearer, more visible, and easier to work with.
- A model is often an expression of something we don’t understand in terms of something we think we do understand
- All tests are based on models:
  - Many models are implicit
  - When the behavior of a program “feels wrong”, it is clashing with your internal model of the program and how it should behave.

Timeouts
Time Difference between Machines
Crossing Time Zones
Leap Days
Always Invalid Days (Feb 30, Sept 31)
Feb 29 in Non-Leap Years
Different Formats (June 5, 2001; 06/05/2001; 06/05/01; 06-05-01; 6/5/2001 12:34)
Daylight Savings Changeover
Reset Clock Backward or Forward

Violates Domain-Specific Rules (an ip address of 999.999.999.999, an email address with no “@”, an age of -1) See Email Field Sheet for more info on testing email fields
Violates Uniqueness Constraint

See also Data Type Attacks
HTML/JavaScript Injection (allowing the user to enter arbitrary HTML tags and JavaScript commands can lead to security vulnerabilities)
Check Max Length Defined on Text Inputs
> 5000 Chars in TextAreas