Difference between revisions of "COMPLEX ENVIRONMENT"
Jump to navigation
Jump to search
| Line 21: | Line 21: | ||
<br /> <br /> <span style="font-size: 16px">Other useful patterns:</span><br /> | <br /> <br /> <span style="font-size: 16px">Other useful patterns:</span><br /> | ||
| − | * <span style="font-size: 16px">[[ IT SIMPLE]]: this pattern is always helpful</span> | + | * <span style="font-size: 16px">[[KEEP IT SIMPLE]]: this pattern is always helpful</span> |
* <span style="font-size: 16px">[[ SHARE INFORMATION]]: use this pattern for better communication between development, testing and automation </span> | * <span style="font-size: 16px">[[ SHARE INFORMATION]]: use this pattern for better communication between development, testing and automation </span> | ||
<br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Issues]] / Back to [[Test Automation Issues]]</div> | <br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Issues]] / Back to [[Test Automation Issues]]</div> | ||
Revision as of 15:41, 4 April 2018
.................................................................................................................[Main Page]] / Back to [Design Issues]] / Back to [Test Automation Issues]]
.................................................................................................................Main Page / Back to Design Issues / Back to Test Automation Issues
Issue summary
The environment where the Software Under Test (SUT) has to run is complex
Category
Design
Examples
The problem range is:
- Different systems (hardware or software) that interact in some way.
- Test data is hard to create due to the number of systems involved or a limited refresh cycle.
- You have to simulate some hardware
Questions
Where does the complexity lie? In preparing the initial conditions? Test execution? Checking the results? Dependencies?
How do you collect the necessary data?
Resolving Patterns
Most recommended:
- DO A PILOT: use this pattern to find out what the problems are and ways to tackle them
- TAKE SMALL STEPS: use this pattern to break up the problems in more chewable chunks
- THINK OUT-OF-THE-BOX: try to look at the problem from unusual viewpoints
Other useful patterns:
- KEEP IT SIMPLE: this pattern is always helpful
- SHARE INFORMATION: use this pattern for better communication between development, testing and automation
.................................................................................................................Main Page / Back to Design Issues / Back to Test Automation Issues