DATA CREEP
Jump to navigation
Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
.................................................................................................................Main Page / Back to Process Issues / Back to Test Automation Issues
.................................................................................................................Main Page / Back to Process Issues / Back to Test Automation Issues
Issue Summary
There are countless data files with different names but identical or almost identical content
Category
Process
Examples
- Nobody knows what is being used and where, so nobody wants to be responsible for deleting eventually needed data
- To edit or remove the the data files is too much work: one has to look up all the places where they are used and change the referrals. If the files are similar rather than identical, a unified file has to be created.
Questions
Is the data documented?
Are there standards regarding naming and documentation?
Who creates the data? How? Who uses it?
Resolving Patterns
Most recommended:
- GOOD PROGRAMMING PRACTICES: Use the same good programming practices as in software development
- MAINTAINABLE TESTWARE: Design your testware so that it does not have to be updated for every little change in the Software Under Test (SUT)
- MAINTAIN THE TESTWARE: Maintain test automation scripts and test data regularly and from the very beginning
- MANAGEMENT SUPPORT: You will need this pattern to be able to change the current bad behaviour
- REFACTOR THE TESTWARE: Refactor your testware regularly
You should already be applying these patterns. If not, do it!
Other useful Patterns:
- GOOD DEVELOPMENT PROCESS: apply this pattern if you don't have a process for developing test automation. Apply it also if your process lives only on paper (nobody cares)
- LEARN FROM MISTAKES: apply this pattern to turn mistakes into useful experiences
- KILL THE ZOMBIES: Apply this pattern for a start
- DEFAULT DATA: use this pattern if your tests use a lot of common data that is not relevant to the specific test case
- DOCUMENT THE TESTWARE: you should be already applying this pattern. Retrofixing documentation is quite an effort. Do it in the future for all new projects and everytime you have to update something old
- KEEP IT SIMPLE: Always apply this pattern!
.................................................................................................................Main Page / Back to Process Issues / Back to Test Automation Issues