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.