This was my first start of an article that went with an abstract (for TestNet NL)... Because I was so 'wet behind the ears' back then and a relative 'new' tester, the presentation became a fiasco (to put it mildly) with me more in tears than in a happy mood... It can happen, but I didn't give up! ~Remember that things don't always go perfect the first time around...
As I read it now, I'm still behind the matter and it's still very relevant. I think I was 'before the time'... enjoy ... I'm curious what you find of the stuff... (date of last revision: fourth of February 2008...text below is UNchanged!, presentation was held on 'Fall event of TestNet in September 2008). It wasn't completely finished either; I guess I was too 'frightened' after the presentation fiasco to push ahead...still it gives a good idea of what I had in mind back then...
~~~~
Testing
has been a hot item the last couple of years. More and more businesses are
starting to understand the importance of testing to mitigate their risks and
establish a certain amount of quality of their product(s).
Over
the years testing has evolved from ‘an activity done just before production’ to
‘a structured process of measuring characteristics of a process or system’.
This
structured process is - for its part- based on Risks (Risk Based Testing) or
Requirements (Requirement Based Testing). Also methods have been developed that
are involving ‘the business’ or ‘the management’ more because typically one
seems to think that the prioritization of risk or requirements are best set by
‘the business’ or ‘the management’.
Testers
or test managers repeatedly seem to fail to involve the ‘real’ client when
developing policies, strategies or plans. Not the one who pays the money but
the people who are meant to work with the product and/or processes should have
an important contribution in this stage. Especially in companies where
requirements are poor and there is no time or money to develop these (for
example Agile testing) or in companies where there are too little or too many
stakeholders to determine the prioritization of risks (layering, budgets etc.)
Hence
the introduction of Client Based Testing, or – in short- CBT. CBT should be
approached in two ways; from the testers view and from the clients view.
Firstly
the Testers view, or in particular, the test managers view. At setting up the
test planning mostly risks or requirements are used for determining the
activities to be performed for testing, when these cannot be produced by the
organization the manager will mostly look for specifications and/or use-cases
and will set up his tests on these bases. Forgetting a very important and very
accurate source, namely: the end-users or production-unit of the company. Even
though the British standard provides for this group of people by the means of
being a test bases, most test managers ‘forget’ to involve these group of
people. In practice I’ve found that this has a couple of reasons.
- The ‘old school’ tester (now manager) gives a natural preference to non-human input or non-communicative input, having been a programmer in the past
- The test manager (formally non-test) has a natural tendency not to involve the ‘common people’ and always communicate with people higher in the organizational hierarchy
- People ‘on the floor’ have a tendency not to have any time available (or otherwise said: have a natural dislike to management-people and or new software being developed (and tested) which implies the possibility of rendering them unnecessary) or do everything not to help (on which the reaction of the test manager is to ignore them in the first place)
Client
based testing obligates the tester to develop more communicating skills but it
also requires qualities like empathy, pliability and the ability to translate
jargons.
Secondly
the Clients view. Some years ago I received a questionnaire called TUSK which
Isabel Evans had developed, was still developing. The TUSK list is based on the
SUMI list for software but in this case the questions are translated to how the
client or organization experiences the tester of test team and what part of the
testing activities should be improved to the clients liking. I used this list – as a pilot to write an
article on TUSK usage - in different organizations and found that not the information
the answers provided helped the most in improving the test process, but the
time spent with the customer and listening tot the client was the most helpful.
The client really felt understood and was more willing to participate and
cooperate with the test team on improving their deliverables and processes.
