Category Archives: Uncategorized

5 tips to keep automation maintainable

  1. Never automate tests without setUp and tearDown. Each test should be independent of the other. I.e. one test should not depend on the other to execute.
  2. Make sure even the tiniest of your tests are run on a CI server. E.g. Bamboo, Jenkins, Solano Labs.
  3. Learn how different models work and apply them. E.g. Page Object Model.
  4. Learn higher level frameworks and apply them. E.g. Robot Framework. It allows you to pick multiple frameworks. E.g. Appium and Selenium at the same time to test web and mobile within the same code.
  5. Do not attempt or promise to automate everything. Read Test Automation Myths.

Automation tips for Agile Test Automation Engineers

Lets say we are in a perfectly technical world, where the user of the technology is the technology itself. Everything can be automated then. Let the fun begin!
In an Agile environment it is easy to think that every ticket in a sprint needs to be automated. Thats what people new to automation attempt to do. However, it is imperative that you justify (and carefully estimate) automation task on every ticket. Below are the scenarios you might want to consider.
  1. Watch out for test redundancy. Will my test become redundant and get run only once? Will changes in the application make my tests inapplicable in the short run?
  2. What is the ROI for my automation work? It may take 2 weeks to automate a particular task but 1 hour to execute it manually. You can either park the automation for a suitable sprint with less work load and sign off the change after the short manual test. Or you can work on it for 2 weeks then move onto other tasks.  It is worth asking the business what is more suitable. E.g. the business can help you get more people to balance the load during your sprint. Do not settle for a test not to be automated or park it for later if the business provides help or agrees to automate in the current sprint. Remember that the rest of the team will move onto new tasks while you are still solving an old problem.
  3. That brings the next topic. The best time to automate a ticket is when the underlying application is being implemented. In that way, you can request for changes required to unblock you. Hence, within the sprint itself time your automation so that the relevant people can help you through.
  4. In case estimations show that you can complete 7 tickets for automation in a sprint, (if business permits) pick the ones with the lowest complexity first. If you start with the easy ones first you’ll get up to speed with the more complex ones later. Also more often than not initially you need to solve technical challenges that are common to most of the tickets in the sprint. It is better unblock those issues at a relatively simple task than the complex ones.
  5. Don’t forget People and other dependencies. Some tasks may involve people. In some cases, they may be external teams or vendors. Initiate those contacts first and park the tasks until they get back to you. You can always move onto another task while you are waiting on their response.
  6. Pick tickets based on your and your peer’s strengths. In case you get more hands in your project to automate tasks, remember that you are familiar with the application already, the new team member may not. Distribute the tasks to the new member that are more generic and easy to get up to speed. Take the lead!
  7. When we estimate test automation task we often think about the complexity and time only. Remember, automation is coding. Code may depend on code from other teams. Similarly the task itself may require people, new hardware implementation, new cloud service subscription, payment approval, etc. Most importantly the dependency on the change in application itself. E.g. if the change that you are going to automate will not finish until the end of the sprint, in most cases you can only prepare to automate the application, you can not get it to DONE state. Exception would be when you can automate before the change is implemented.
Getting automation done in an Agile environment is tricky. Things move fast and there is less documentation. The tips above are from years of experience in Agile Test Automation. They worked for me. However, I’d to hear more from you!
[Blog I wrote long time back. Posting on company website to give it life again]

Threats of Automation replacing Testers

It is technologically amusing to think automation will make our lives easy. When those jobs become victim of automation, it is not amusing anymore. Then you are talking about your jobs being replaced by bots. It is business at the end of the day. Automation can save money and thats what most businesses care about. Well it can, not that it always does.

For those who don’t know what is test automation, I’ll explain a bit more. In a typical technology team you’d have someone test your application before releasing it to mass of users. On a typical development cycle (sprint), you would deliver by developing, then testing and deploying your software. Software test automation automates the automation side of things. Well, where possible!

We face initial rejections sometimes that automation can not do what humans can do, hence automation is not needed. I think both are right.

  1. Automation can not replace a tester’s intuition. It can not replace human instinct. It can not feel human expectations in different situations. Not even AI can do that. Many more, many more things automation can not do.
  2. A tester can not do what automation can do. A tester can not run the same set of tests on 3 browsers 20 times in a row within 10 minutes. A tester can not accurately check the same specific expectation every time without developing fatigue. Many more, many more things we humans can not do!

I was listening to James Bach face-to-face once in a Sydney seminar. He answered and provided a solution to this dilemma in a simple few words.

Think of automation as a tool, like the Iron Man suit. It can do incredible things but only when the right person is wearing it! I strongly believe in it and it has proven to be successful for many businesses I have worked for.

Kaiser,

Consultant & Director, Robo Consulting Pty Ltd