Using your naivety while testing
Exploratory testing is an ideal opportunity for feedback about the usability of a feature. When you start testing, you may be the first person to see this feature who wasn’t part of its design. To begin with, that lack of experience is a strength. Your task, as a tester, is to notice and explore possibilities, avoiding the prejudgment and expectations that come from greater experience in this area.
Later, it is important to understand the design and implementation of the code. The technique of white-box testing, described in Chapter 6, White-Box Functional Testing, requires you to check all code paths and try each special case using knowledge of the system. However, at the outset, this lack of knowledge is important to discover surprising or unexpected results, especially for user-facing interfaces and functionality. Anything that surprises you may also surprise your customers, so look out for anything that wasn’t obvious.
Keep track of anything you had trouble finding, any text you had to read twice, and anything that caught you by surprise while using the feature. That is all vital feedback for user experience design. Don’t assume it’s your fault if you didn’t understand something on first use – it may be the designer’s fault for not making it clearer. Some topics are inherently complex and require background knowledge before users will understand; however, any users of your product will probably have background knowledge of its existing functionality or other products within this domain. A well-designed interface should be able to build on that knowledge intuitively. If that’s not the case, then that’s a defect too. See Chapter 8, User Experience Testing, to learn more about usability testing.
The world of user experience has no firm answers, and just because something wasn’t obvious to you doesn’t mean that it will be for anyone else. Unlike other parts of testing, where there should be a clear answer as to whether the product meets the specification, user experience is much more subjective. It is worth raising any points you find challenging to gather others’ opinions. If enough people agree that something is confusing, it is a good argument to change it. You have to highlight those issues to start that discussion and decide on improvements.
Armed with this naïve approach, open to possibilities, and examining each one, you should aim to touch all the major functions of your new feature. From there, you can complete a miniature version of new feature testing, using all the different types of testing available. They are described in more detail in all the subsequent chapters of this book, but this is your chance to perform a cut-down version of different types of testing quickly and early in the project, as we’ll learn in the next section.
