Establishing Test Objectives
Definition:
Test objectives are the types of information we wish to learn about the software we are going to test.
A context where I used this skill:
The challenge is to understand what the stakeholders are aware of and how their understanding may be self-limiting. We as testers need to be aware of more than the simple, easy to define things we can provide to them. We need to understand their needs at least as well as theirs so we can explain what the implications of each “objective” is. The most commonly defined objective is to verify or validate requirements. For some projects this is adequate. Others may take us to work with and understand the needs of the stakeholders and help them appreciate those that are possible.
For me, I spend a fair amount of time talking with business and customer representatives about how they expect the software to behave and what it is they hope to gain from the changes. This gives me the opportunity to go more in depth into the question of “Why are we doing this?” than simply considering what the written documentation provides. This in turn gives them language and understanding to see there are many things that testing can provide beyond “verify the requirements. " When this is understood, I can work with project stakeholders to help them define what it is they want testing to do for this project.
Note: Test objective can relate and tie to: scope, risk (see risk skills), product, quality and management items (e.g. cost and schedule). A tester will likely have to balance these in determining test objectives. For example, we do not want to set objective to test low risk quality factors that we do not have schedule and budget to support.
How I’d recommend someone learn this skill:
Many models that try define “good testing” focus on validating requirements. Requirements can be vague and prone to misunderstanding. If a tester takes that as their default position, that they tested the requirements, that may be adequate for some companies and keep them out of trouble. Testing requirements, however, is a small part of what testing, even with new software, is really about. The most useful tool I have found in most situations, is to have an informal conversation (like over coffee or lunch) with a product owner or subject matter experts involved in the project and ask them what they are really interested in learning about the software. This may be asked as “What is it you hope this software will do after the changes that it won’t do now?” For other circumstances, for example, software in regulatory controlled environments, that question may be asked as “What is it that you are most concerned about with this software?” Usually, the answers have nothing to do with requirements.
Additional resources:
By: Jon Hagar