Please enable JavaScript.
Coggle requires JavaScript to display documents.
Exploratory Testing - part 2 - Coggle Diagram
Exploratory Testing - part 2
As you explore, make a point of choosing different mechanisms for each of kind of actions like what are the different ways to interact ?
Once you’ve identified a preliminary set of entities, the next step is to map out how the different kinds of entities are related to one another.
Explore our software with different personas to discover new perspectives.. Adopting the mantle of a persona prompts you to interact with the software with a self-consistent set of assumptions, expectations,desires, and quirks.
Shaking Up Sequences and interactions
To discover potentially serious problems involving the use and abuse of your software, you need to vary the way you interact with it. Instead of following
instead of following a sensible sequence of actions, take steps out of order. Instead of navigating
Instead of navigating using the same mechanisms every time, vary the paths you take through your system.
Instead of using reasonable data, use unreasonable data.
to explore effectively you have to go where you haven’t
gone before
One way to break out of your habitual rut is to allow randomness
to guide you.
The “Nouns and Verbs” technique provides a way to introducerandomness into how you interact with your software.
You start by makinga list of nouns and a list of verbs from which to pull
The four core operations you can perform on data in a table are "CRUD" i.e. create, Read, Update, Delete.
Alan A. Jorgensen uses three simple questions to detect states:
Are there things I cannot do now that I could do before?
Do my actions have different results now than before?
Are there things I could do now that I could not do before?
Bugs typically have an entire life cycle, with states like New, Assigned, Fixed, Deferred, Verified, and Closed.
After you interrupt the state, consider these questions:
After you recover from the interruption, is the behavior restored to normal?
Did the software lose or corrupt any data?
Did the software respond to the interruption the way you expected? Or
is it now in an unexpected state?
Exploring the state, transitions and events with interptions to discover time related issues.
State tables prompt you to consider what happens when you cause events to occur outside the bounds of expected transitions
When in doubt, start simple. You don’t need to include every detail inorder to have a useful diagram.
Get others involved. You might not have a full picture of the ecosystem. but if you team up with others you’ll have more perspectives to draw from
Share what you have. Even if you cannot get others to help you create the diagram, just sharing it may prompt others to offer corrections or additional details. So don’t wait until you think you’re done to share it.
Trust boundary
Once you identify a trust boundary, your task as an explorer is to violate that trust.
Enter invalid data, corrupt files, or otherwise take actions that the system is not expecting.
This leads us to the next technique for using your
ecosystem diagram to explore the system: What If?
what if ?
• What if this connection goes down?
• What if the service at the other end of this connection is not responding?
• What if the network is so slow that the request times out before the response comes back?
• What if this file is missing?