Better Software - January 2009 - (Page 102) Automation by Linda Hayes the Data is the haRDest PaRt. Automation is all about repeatability, and if your data is unstable or unpredictable, then your tests can’t be repeated. Consider using your automation tool to load data so you always know the state of your test environment. RecoRD anD PlaY is a MaRketing aPPRoach, not an iMPleMentation stRategY. Designed to make it look easy long enough for your check to clear, recorded scripts are nothing more than bad, fragile code. The mere mention of this term by a vendor should be grounds for expulsion from serious consideration, as it has been proven responsible for untold failed automation efforts. Don’t be fooled. Don’t wRite PRogRaMs to test PRogRaMs. Don’t try to replicate application logic in your tests or you will end up with more code than the application itself has. Write your automated test to expect the expected and use logic only to recover from the unexpected. voluMe is not a viRtue. Just because automation can run more tests than you can perform manually doesn’t mean more is better. Every test takes time to design, develop, execute, and analyze. Worry about coverage, not quantity. Make Maintenance a PRioRitY. We test software because it changes. If it takes too long to update your tests, you can’t keep up and you will have to revert to manual testing to meet schedules. If a vendor tells you it is easier to re-create the test than to maintain it, run for your life. Be sure that maintainability is a key quality of any test library design. Don’t Relegate autoMation to RegRession. Anyone who says you can’t automate until the application is complete and stable doesn’t know how to design a proper test. Modern techniques allow tests to be automated before the code is even available, allowing automation to play a part in even the most agile of environments. Don’t excluDe the exPeRts. If an automation tool is so technical it can’t be used by the people who know your application best, keep looking. Programming prowess is not a substitute for domain expertise. Testing is only as good as the tester. coloR insiDe the lines. Establish and enforce naming conventions, design standards, and change control procedures. Without them, you will lose track of your test assets, resulting in duplication and omission. If you can’t find a test, you can’t use it, and if you can’t make sense of it, you can’t maintain it. DocuMent YouR Design. The most elegant of all architectures has no value if you can’t understand it. Many a genius has labored over an advanced approach only to leave confusion behind when he leaves. Insist on diagrams and documentation that describe the overall structure and the purpose of components. involve DeveloPMent. Unless the developers cooperate by delivering testable code in the form of persistent object names, exposed methods and properties, and enough heads-up on changes for you to react, all of your efforts will be in vain. Make programmers your partners, educating them about what it takes to automate and supporting them with automated build tests and other time savers. 102 BETTER SOFTWARE JANUARY/FEBRUARY 2009 www.StickyMinds.com http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.