Go ahead, search the interwebs. There are more posts and clause on “ The Ten Commandments of Test Automation ” than you can shake a examination causa at. Go ahead…I ’ ll delay.

Welcome back!

To set the level, I have not say any of those articles. Well, more accurately, I ’ ve not read any of them recently; most of them I ’ ve not read at all. I probably read one or two of them in the “ before times, ” but I don ’ t retrieve any of the specific commandments. Any of the ones I didn ’ t already know and found appropriate, I probably ingest into my learnings and approaches long ago. I make this point not to diminish the other posts, but to highlight them in the highly likely case that some of the following “ commandments ” have been stated before; I have not copied them and if I iterate them, I ’ m hoping to amplify them. I also want to innovate some ideas that you ’ ve not yet reckon.

As such, I will not be presenting THE Ten Commandments of Test Automation. Instead, I ’ ll be presenting Ten MORE Commandments of Test Automation. And away we go…

I - Thou shalt not only automate & quot; from trial cases & quot;

There is a common misconception that mechanization for testing necessarily derives from test cases. The automators take an existing, or freshly written, test case and turn it into an automated test script. This is telephone the mechanization drive-thru.

While there can be value in this approach, early approaches can furnish similar or better value. Byexpanding the definition of mechanisationbeyond test-case-tool-test-script to “ the judicious coating of technology to help humans do their business, ” we can exploit the power of computers to do the task for which they are best suited, leaving the humans—the testers—to do the rest tasks. Fortunately, much of what humans are full at, computers are bad at, and vice versa.

II - Thou shalt treat automation development as software development

Automation ontogenesisissoftware development. Even if we are using a drag-and-drop or record-and-playback interface to make that automation, somewhere, in the slew, under the hood or behind the drapery, there is code sequenced by our activeness. We must start treating our mechanization initiatives as software maturation initiative, lest we end up in a quag of unsustainability and early project expiry.

Treating it as software development means we must account for most, if not all, of the same activities and processes that application developer ask. These include:

• Design – we have to decide what to implement and how to implement it so that it ’ s maintainable and supportable.

• Implementation – we must write the code.

• Storage – the code and related artifacts need to be stored somewhere.

• Testing – Test the exam? Absolutely! We must experience sufficient sureness that the automation do the way we want it to. If we don ’ t trust the automation, it ’ s useless.

• Bugs – All software has bugs; mechanisation, be package, is no different. Testing will help but will not get all bug. Allow time in the agenda for bug pickle.

  SUSA automates exploratory testing with persona-driven behavior, catching bugs that scripted automation misses.

• Logs – Logs are the lifeline of automation. Without them, we can neither understand what the mechanisation is doing nor fix automation when it ’ s broken. Additionally, we wouldn ’ t be capable to state when there ’ s an subject with the automation as opposed to when there is an subject with the software be prove.

III - Thou shalt follow appropriate coding standards and accent

In following with treating automation like software, we must incorporate appropriate effectuation ideas in our implementation. Each tool or language has its own idioms and its own gotchas, but generally accepted approaches to design and implementation are usually appropriate.This article on encapsulation and generalisationprovides a sample implementation that can be fodder for other Implementations that are specific to our context.

IV - Thou shalt consider alimony and upkeep

Software is neither perfect nor consummate; this is no different for automation. There will be glitch. As the application we are testing is changing, we correspondingly need to change our mechanization. We can ’ t prevent these, but we can evolve our software in shipway that reduce the effort it takes to endorse and maintain mechanization software; we also must allocate time for these activities.This clause and this blog positionshed some light on constituent that are helpful when addressing anticipated maintenance.

V - Thou shalt not make scripts dependent upon each former

Creating a test book that is dependent upon another ’ s results is generally a strong anti-pattern. If scripts depend upon each early, they can not be run individually, which makes debug automation and app problems more time-consuming. Additionally, scripts that count on other scripts can notrun in parallelwith the hand on which they reckon.

There is a corner case where experience all early script depend onthe same, single script; this single book broadly performs some frame-up of the test environment, test data, etc. This case is increasingly rare when using the available automation and continuous deployment frameworks, but it still may be appropriate in cases where the available frameworks are not usable or appropriate for a specific automation enterprise.

VI - Thou shalt emit appropriate logging and reports

As described in this blog post, appropriate logs, issue, and error messages are critical to understanding, trusting, and maintaining mechanization. These logs are our elaborated view into mechanisation execution: what ran, how it ran, what failed, how it failed, how it succeeded, etc. That is, as long as we judiciously emit appropriate logarithm that deliver this information to us in a digestible manner.

VII - Thou shalt influence testability and automatability

Testability, the extent to which an covering or feature can be test, andautomatability, the extent to which testing-related activities can be performed by some automated mechanism, are not things that testers/QAs/QEs can implement, but surely, they are things that we can charm. It ’ s incumbent on us to exercise that influence. Developers don ’ t always know what we require to perform essay and to appropriately create automation. We must let them know. The blog billethere and heregive some brainwave into some aspects of testability and automatability.

VIII - Thou shalt not succumb to the sunk cost fallacy

Sometimes, we do fault. Sometimes, they are big mistakes. We do our better with the information we have at the time, but it doesn ’ t always act out. When something in our plan travel awry, our instinct is to try to fix it, and to keep assay to fix it. Sometimes, however, we should just start over differently we run the risk of “ drop good money after bad. ”

This is called thesunk price fallacy. Simply put, this fallacy is the thinking that we ’ ve sunk so much money into an activity that we must spend more money to rehabilitate it and get value for that money already spent orsunkinto the endeavor.

Perhaps we are emotionally invested in our software “ babe ”; we spent so much clip and money on it we can ’ t bear to throw it away and depart over. Perhaps we are afraid; our leading probably won ’ t be thrilled if we want to throw away the work that ’ s be do and “ recur the like work. ” We must work to view situations like these through our business Lens instead of strictly emotionally.

IX - Thou shalt beware of Rube Goldberg machines

Rube Goldbergmachines are complex machines that execute comparatively simple tasks, such as theSelf-Operating Napkin. In our automation cosmos, building these kinds of machines can be a lot of fun and they can do very cool things, such as chaining unrelated tools together in order to complete a testing task. Their downsides include being hard to realize and maintain; we must take care not to make something that is more effort to maintain than it would be to do the automated task ourselves.This blog spotgive more details about automation Rube Goldberg machines;this postgives some intellection about the province of “ being automated. ”

X - Thou shalt not make test data count on transient data

Recently, I came across a test script that, one day, just begin failing. After some investigation, we determined the failure had happened because the month changed from July to August. The script had been written in a way that the oracle was assure for date in July, which was just fine when the handwriting was running in July; application being tested was returning appointment in the current month, July. When the date vary to August, the covering start return dates in August, induce the book to neglect.

In this case, alternatively of hardcoding dates in July, it would have been better to dynamically create the dates based on the current month.

About the Author

As a Principal Automation Architect atMagenic, Paul Grizzaffi furnish technology solutions to testing and QA organizations, including automation assessments, implementations. He is also involved in activities that profit the broader testing community. Paul is an complete keynote verbaliser and author who has demonstrate at local and national conference and meeting. He is an advisor to Software Test Professionals and STPCon, as easily as a member of the Industry Advisory Board of the Advanced Research Center for Software Testing and Quality Assurance (STQA) at UT Dallas, where he is a frequent guest reader.