DATA CREEP
Jump to navigation
Jump to search
.................................................................................................................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