- Why Ask "Why?"
- Asking Questions as a Method of Generating Test Ideas
- How Can Questions "Unravel" an Application?
- Asking Questions in the Right Way
- A Final Tip: Record Your Results
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
How Can Questions "Unravel" an Application?
So far, we’ve asked only a few questions about the web site. But the answers may already have given us some important facts about the sample application. By asking who can log in, maybe we’ve learned that inactive student accounts can access the site. By asking about the inventory process, perhaps we’ve discovered that the site hasn’t yet addressed how to remove or "deactivate" books.
I know this sounds basic. But, depending on the maturity of the application being tested, or how well the application has been designed, I’ve uncovered missing product functionality by just asking questions. In other cases, my questions have led to tests with which I’ve found defects in the functionality that has been built.
Not every question you raise has to be asked of someone. There are multiple ways to resolve questions:
- Ask people on the product team.
- Test to discover what you don’t know.
- Check the product documentation for answers.
- Ask developers questions and then test the application to see whether the product matches what the developer expects. You’ll probably find bugs in the gaps between expected and actual behavior.
Now let’s combine questions to find more test ideas on our bookselling web site example. We’ll combine "how" and "to what extent":
Q. How is the product list updated? To what extent is the list updated?
A. The database administrator updates the database with a list of books. The update process adds new books and deactivates books that haven’t been ordered in the past two semesters.
Test planning might change with this information:
- Can we run the update process without a DBA’s assistance, so we can control the product list ourselves in a test environment?
- Regardless of how we’ll accomplish changing the product list and product inventory, we’ll need to identify a test to add new books and a test to see whether the same book can be added twice.
- We add tests to deactivate books. We test to find out what happens when we attempt to add a book that was previously deactivated; does the book get reactivated, or added again? What happens if the book is added again and then deactivated? Will we encounter a uniqueness error when the book is deactivated a second time?
- We create tests to check that books not ordered within the past two semesters are deactivated. We check that books not ordered in the past semester are still active.
In short, we test both valid and invalid criteria, and we look for other criteria such as conditions or states that haven’t been defined. In a tester’s mind, the question "what if" lives behind much of what we do. This is why testing is a discovery process.
By asking questions about to what extent, we might learn more details about processes that take place within an application, such as real-time inventory updating; or processes that take place outside the application, such as the product list being updated before each semester by a DBA running a database script. The "to what extent" questions can help find the nuances of an application that developers and product designers may or may not think to include in product documentation. This is one reason that I don’t like to begin planning by reading the documentation. I prefer to generate ideas and then read the product documentation.
Using reporters’ questions is a reasonable method for new testers because it requires no previous testing background. It’s also a method that can be used by a tester who has extensive experience with an application, as you attempt to take a fresh look at a product you already know—or think you already know. Ask questions as you traverse through functionality, and see if you can find more test ideas.