You might find it familiar to be involved in, or responsible for, the planning and design of testing on a project where the business drivers around why/how the project is important, in the larger sense, are not entirely clear to the team.
To test this, try randomly springing one of these questions on your teammates (one-on-one in the hallway is best):
- “So, who does this project help (in the real world)?”
- “Why is this project important to the company?”
- “Do your assignments add value to the business? Why?”
It can be revealing.
As often an outsider to a new client’s business, I feel one of the most significant first steps is to rapidly integrate with the mindset of the client’s teams and to “get immersed in their world”.
A key conversation to have is regarding “What is success?” on a given project, for a particular system, in that organization, with those users, at this time.
Input to this query would be gathered from:
- Customer Representatives
- Technical “Peers” (architecture, business analysts, developers, testers, support)
- Management (project management, departmental management)
- Business Organization (strategic planning, corporate management)
In particular, it is always important to understand from the Business Organization:
- What motivates them (Goals)
- What they are afraid of (Risks)
- What will really make a positive difference for them (ROI)
- What they are NOT willing or able to do/pay for (Constraints)
And of course, projects are routinely constrained in terms of resources, budget, and schedule. And, when there isn’t enough of one of these, or something else, to let us do whatever we want when we want, we are dealing with ‘scarcity’. In the face of scarcity, choices, often tough choices, will need to be made.
Being prepared with answers to the above lets us facilitate these decisions while planning and prioritizing our testing activities accordingly.
What’s It All For Anyway?
Testing is always working for someone, either directly or indirectly. Stakeholders provide input that we use to plan and design testing activities. Stakeholders are represented by Testing in the course of us performing our verification and validation activities. Stakeholders consume the data that Testing collects and analyzes so they can make informed decisions.
Of the stakeholder groups, Testing has day-to-day interaction with Technical Peers, frequent contact with Management and Customer Representatives. But, the Business Organization is often at such a distance that it is heard from rarely, and perhaps only when there are big decisions to hand down; decisions in response to challenges with scarcity that may or may not be directly stemming from your project.
When these tough choices need to be made, Testing needs to have already been making visible the value being added and enabling informed decision-making.
Let’s Play a Game
The following role-play exercise has been adapted from my course “Test Management: Leading Your Team To Success“. Typically, this activity would be conducted in pairs, but you should feel free to mix it up as best suits your team.
Step 1: The first person assumes the role of a senior individual in the Business Organization and:
- Chooses an industry and/or business type
- Selects a type of system and a type of project
- Decides on two (2) dominant personality characteristics for themselves to role-play in terms of priorities, preferences, eccentricities, etc. (here are some ideas)
- Chooses one (1) common project challenge and/or constraint
- Chooses one (1) unusual project challenge and/or constraint
- Chooses two (2) project challenges and/or constraints that will be kept secret until Step 4.
Step 2: The second person assumes the role of the Test Planner for the above project, and interviews the first person, navigating the challenges of understanding the first person’s “world” and their personality, to determine/elicit:
- What is the project?
- What is “success” to them?
- What is “quality” to them?
- When would testing be considered to be “done”?
- What are the project challenges and/or constraints?
Step 3: Based on the information the second person gathers during Step 2, they will describe to the first person an applicable test approach for the project.
Step 4: The first person will then (constructively) critique the proposed test approach based on:
- The points or “facts” from Step 1 and Step 2
- The two (2) secret project challenges and/or constraints from Part 1 (reveal them now!)
Step 5: Both parties proceed to discuss and negotiate what adjustments and/or compromises can be made to close the gaps in agreement. (Be sure to note down impacts to the definitions of “success” and “quality” from Step 1)
Step 6: Considering all the proceeding steps, both parties summarize:
- The revised definition for “success” and “quality” for the project
- The Business Organization’s appetite for risk on the project
A test planning game or exercise like the above will help hone your elicitation and negotiation skills for when you next talk to the Business Organization, or any other stakeholder.
Conclusion
Quality can mean different things to different people, and that is largely because we hold different aspects of quality to be more or less important than another, given our context.
It would be a limited view indeed to simply consider the views of a single stakeholder group when defining “quality” for a project. It would likewise be limiting if the input and context of any significant stakeholder group was left out of that definition.
Remember to remember (to mind) your own Business Organization when investigating what testing can, specifically, do to add value and bring about project success.
For related reading, check out these articles:
