The first part of this series examined the different perspectives developers and QA testers have on the QA process. For the next part in our series I want to talk about how QA teams look at features and the type of information they need from development teams. To do this I’ll start with an example that our instructor used when delivering a QA class. He asked the students to describe for him how to do a Web search. Naturally a number of answers came out and were listed on the board. Those answers and the follow-on conversation provide some interesting insights.
The answers that came back basically amounted to the following:
- Open your browser
- Type the search string into the search box.
- Click the search button
Then the instructor asked some follow on questions:
- Was a browser even used?
- How do I open the browser?
- Where is the search box?
- In the standard browser configuration are their multiple boxes in the browser interface that users might be confused by such as multiple search engines or a “find on page” box?
- Was the address bar used instead of the dedicated search box?
- Was a search page used instead of the browser’s search?
- Specifically, where on the screen is the search box they are to use?
- Is that the same in different browser applications (IE, Firefox, Chrome, etc.)?
- Are there other ways to initiate the search such as typing the search string and pressing enter? Examples might be pasting text, using drop down control or clicking links for common searches, using autocomplete, or using Alt-Enter to get results on a new page or tab.
- Is there a specific search engine or search toolbar that is assumed to be installed?
Now, anyone familiar with managing development projects should be waving their arms right now and saying that this should never happen. In the best of all worlds everything is defined in the specification before the developers’ fingers touch the keys for the first time. The application specification should detail the features that are in the application, how they are accessed, the user interaction, and how the features should behave. Unfortunately that is often not the case. Sometimes design or UI is being developed in parallel with back-end functions, or changes in functionality are requested. Things are not always completely defined, and often change, so there is frequently a need for this type of communication in the QA process.
Even this simple example shows that when something is not defined explicitly, assumptions are made. Developers often make different assumptions than QA testers or end-users will. Developers are often very close to the features they are coding – sometimes doing dozens of unit tests a day as code is being finalized. Compounding this, when people are familiar with features, they make assumptions without thinking about it. Disconnects happen when assumptions are made. Specifying things exactly alleviates QA strain and reduces QA churn.
In these instances, what the QA team needs from developers are explicit instructions, they need to know how a feature is supposed to work in very granular and explicit form. It’s QAs job to step back and look at both the application as whole, the feature or function as a whole, and approach it from an unfamiliar perspective. Just like end users, they have not seen the feature before. Before submitting to QA, developers can speed the QA process by stepping back and taking a look at what they’re submitting from that perspective.
This example also tells you something else about good QA. Good QA should try to think of ways to approach and use functions and features that developers don’t – they should try to break things. It’s painful for developers, as bugs are generated that are sometimes seen as out of scope from the specification. But the fact is, if a three person QA team finds a usability, functionality or usage issue, you can bet customers and end users will find it too.
To close out this post, developers should try to step back from the features and functions they are coding in the moment, and look at the application as a whole, how the feature they are about to submit fits in, and different ways it will be accessed and used. That takes a lot of effort with development deadlines, but will save QA cycles and yield better results and fewer long nights in the project. Developers should also be prepared for the fact that QA may generate usability bugs. Those bugs should be addressed if time permits because it will make your application better, and easier to use.
