Difference between revisions of "CAN'T FIND WHAT I WANT"
m (Topic titles in capital letters) |
|||
| Line 12: | Line 12: | ||
=<span style="font-size: 16px">'''Resolving Patterns'''</span>= | =<span style="font-size: 16px">'''Resolving Patterns'''</span>= | ||
<span style="font-size: 16px">Most recommended:</span><br /> <span style="font-size: 16px">It is important to set out the "rules" for standard ways of identifying and naming automation artefacts, ideally from the beginning. This is one of the things to investigate when you [[DO A PILOT]]. The [[TESTWARE ARCHITECTURE]] defines where different types of things are stored, so that you know where to go to find them. It is important to [[SET STANDARDS]] for things such as how the artefacts are documented, naming conventions and other things that everyone has to deal with. For example, any script should state its purpose, its pre-requisites, and what it produces. This enables you to know whether or not it is actually suitable for you.</span><br /> <span style="font-size: 16px">For Example 3 you should check that your tool or framework is capable of compiling a usage list.</span><br /> <br /> <br /> <span style="font-size: 16px">Other useful patterns:</span><br /> | <span style="font-size: 16px">Most recommended:</span><br /> <span style="font-size: 16px">It is important to set out the "rules" for standard ways of identifying and naming automation artefacts, ideally from the beginning. This is one of the things to investigate when you [[DO A PILOT]]. The [[TESTWARE ARCHITECTURE]] defines where different types of things are stored, so that you know where to go to find them. It is important to [[SET STANDARDS]] for things such as how the artefacts are documented, naming conventions and other things that everyone has to deal with. For example, any script should state its purpose, its pre-requisites, and what it produces. This enables you to know whether or not it is actually suitable for you.</span><br /> <span style="font-size: 16px">For Example 3 you should check that your tool or framework is capable of compiling a usage list.</span><br /> <br /> <br /> <span style="font-size: 16px">Other useful patterns:</span><br /> | ||
| − | * <span style="font-size: 16px">[[SHARE INFORMATION]]</span> | + | * <span style="font-size: 16px">[[SHARE INFORMATION]]: Ask for and give information to managers, developers, other testers and customers</span> |
<br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Issues]], Back to [[Test Automation Issues]]</span></div> | <br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Issues]], Back to [[Test Automation Issues]]</span></div> | ||
Latest revision as of 15:42, 27 June 2018
Issue Summary
There is a script or file or dataset but you don't remember what it's called or where to find it.
Category
Design
Examples
- There is a script that initialises a data file that you want to use for a test. You have used it before but don't remember its name. You have looked through a long list of names but didn't recognise it.
- There is a useful little utility that will do just what you want, but you have no idea where you put it.
- You want to change the interface to a script or a keyword that you know is being used somewhere, and you need a usage list to make sure you update all the occurrences
Questions
How often does this happen?
What happens when you can't find something - do you make another (duplicate) one? Does this happen also in instances like example 3?
Resolving Patterns
Most recommended:
It is important to set out the "rules" for standard ways of identifying and naming automation artefacts, ideally from the beginning. This is one of the things to investigate when you DO A PILOT. The TESTWARE ARCHITECTURE defines where different types of things are stored, so that you know where to go to find them. It is important to SET STANDARDS for things such as how the artefacts are documented, naming conventions and other things that everyone has to deal with. For example, any script should state its purpose, its pre-requisites, and what it produces. This enables you to know whether or not it is actually suitable for you.
For Example 3 you should check that your tool or framework is capable of compiling a usage list.
Other useful patterns:
- SHARE INFORMATION: Ask for and give information to managers, developers, other testers and customers
.................................................................................................................Main Page / Back to Design Issues, Back to Test Automation Issues