7
Software Testing Inspiration
It is often said, with right, that you need to consider a lot more than the explicit requirements in order to be
able to test a product well.
13
The most important rationale for this is that in testing, we know more about the product than before
implementation, and testers look at different detail levels. Other reasons are that requirements always are
incomplete (they weren’t written by an almighty; implicit requirements are almost endless), some things must
be tried out before you understand it, and you don’t want to spend too much resources on requirements
writing.
We should also ask ourselves what problem testing is trying to solve. I think there are more situations like this:
We know that there will be problems with the product we are building. We need your help to
make sure that the released product can be used by customers without failing, and satisfactorily
help them with their tasks.
than like this:
We must verify that the actual product meets the statements in the requirements document.
The insight of multiple information sources is often accompanied by a few examples of “the other
information”, e.g. something about the customer needs, or the necessity of reading the code, or knowing the
technology the software operates in, or an understanding of quality characteristics in the specific context.
On page 10-11, there is a thorough list
14
, which can be seen as a “checklist when building your own checklist”.
Everything is not always relevant, but I recommend spending a minute on each category. Think about what is
important, and decide for yourself which information sources to dig deeper into. The information you get can
give you good test ideas at once, can point to what is important, and eventually guide your test design
regarding details. The holistic merge make us understand what is important, in many situations.
By using multiple information sources, including the actual product and customer needs, your tests will get a
better connection with reality, they will be grounded.
Using Many Models
The requirements are an important model of what the software should accomplish, but it is more complex
than what ended up in the requirements document. You should challenge the requirements, and through
other sources try to find the implicit ones
15
that matter.
If there exists specifications of any type (conceptual, technical, functional, design) they are valuable input. You
can also look at specifications for other functionality, and in that case test specifications might be the most
interesting ones.
The actual code is also a model, and you might benefit from reading it, or let someone who has read it tell you
about it. Take special considerations to old, new, shaky, unread, reviewed code.
A help models the functionality, hopefully from a user’s perspective.
13
One of the best examples is “A tester who treats project documentation (explicit specifications of the product) as the sole source of
requirements is crippling his test process.”, Lessons 32 and 33 in Cem Kaner, James Bach, Bret Pettichord, Lessons Learned in Software
Testing, John Wiley & Sons, Inc., New York 2002
Another is “Testers should base their tests on the information they can get — and they can get plenty of information from sources other
than specifications.” Cem Kaner, The Ongoing Revolution in Software Testing, Software Test & Performance conference, 2004,
http://www.kaner.com/pdfs/TheOngoingRevolution.pdf
14
Rikard Edgren, Martin Jansson and Henrik Emilsson, 37 Sources of Test Ideas, http://thetesteye.com/blog/2012/02/announcing-37-
sources-for-test-ideas/
15
A good start of implicit specifications on slides 8-9 in Cem Kaner & James Bach, course Black Box Software Testing, Specification-Based
Testing http://www.testingeducation.org/BBST/specbased/BBSTspecBased.pdf