Datasheet

10 ■ Optimize Quality for Business Outcomes
To answer that question let’s first look at some testing defini-
tions:
This is true for software, as well as for all other products built
to suit specific needs. Testing is done by everyone all the time,
so why bother?
If we start looking at the testing process more carefully, we find
that in most cases, testing is not just about finding defects, but
also about knowing whether a product meets business expecta-
tions.
Although this sounds pretty much the same, there is a funda-
mental difference. A defect is any flaw or imperfection in a
software product or process. This implies that a definition of
the perfect working product has been made and is clear to all
stakeholders. It’s not a defect just because the expectations of
an individual tester have not been met.
Unfortunately, intuitive testing based on undocumented expec-
tations is a common approach in the industry today. This test-
ing approach is limited because it only works with the
completed product and does not allow testing to be done early
enough in the SDLC or in parallel with development.
The answer to the last question is that we can’t improve the
testing process using this knowledge because in today’s mar-
ket, IT often dominates discussions around product expecta-
tions and defines the desired functionality around
technological aspects rather than business needs. Therefore,
the testing process is often misaligned with the needs of the
business or ideal business outcomes.
Testing is about finding defects, bugs, or flaws.
Testing is to determine if a product meets
business expectations.
MQM.book Page 10 Wednesday, May 7, 2008 11:29 AM