Explore It! @ Book

Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing

A good book that covers the exploratory testing methods along with general insights on testing.

“Exploratory Testing” is about exploring the system you’re working on. It’s not only for simple functional testing, but also an discovery process for identifying whether the system satisfy the requirements. It has some aspects of creative process to find out the paths and directions, and quite involves high observation skills and experiences.

The fundamentals are basic testing techniques, like picking up boundary conditions and invalid formats, etc. However, it’s sometimes difficult to dig deep on everything in the system for every viewpoint. Exploring a system requires skills and insights, in order to avoid being lost in the infinite landscape.

Another interesting points discussed were about requirements meeting and conflict between testers and developers. Testers and developers can have conflicts because sometimes their short-time goals (getting the current work done) becomes different, though the long-term goals would be the same (making good products). As indicated in the book, discussing the features requirements among members in the early phase, would be an important step for avoiding the reworks.

Notes

  • Exploring involves 3 factors: Target (what to test), Resource (what you bring with) and Information (what you’re hoping to find).
  • “Observation” is one important factor in testing. Some weired noise in the hard-drive could indicate a serious issue. Console and logs have plenty of information, and checking them while testing helps identifying the possible issues.
  • Even the smallest system has number of variations to explore. Leave open possibilities that there is something you haven’t considered yet.
  • Think about how to validate the result. Sometimes it’s difficult, especially if you’re not the expert in the system domain. One approach is to identify the “Never and Always” rules that applies to your system (ex. In server-based systems, you should never make the system unavailable to other users by a user’s certain action).
  • For digging deeper into system, one option is to list up related nouns and verbs, and then combine them. It provides combinations of actions that doesn’t make sense, but thinking about it invokes your creativity to find interesting viewpoints.
  • Exploring the system well helps refining the system requirement too. One example is inconsistencies between behaviors, that is relatively easier to avoid in the early phase of the development.
  • Testers who reports bugs can be seen as “making stuff up” from developers by piling up unexpected behaviors through invalid scenarios. It’s because developers can see them as new requirements, rather than defects (they were not initially indicated! kind of response). If you don’t calibrate expectations with the team early on, you’re likely to end up arguing about real scope of the features later.
Advertisements

Posted on July 3, 2013, in Book, Web. Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: