Ep 68: Automatic for the people

This week I talk to Angie Jones about automation!

We talk about:

Getting into Automation and the different mindsets

  • Automation seems like a black box at times, especially moving from testing a GUI (Graphical User Interface) to testing the underlying code, it feels like a mental shift. Even to back-end developers, automation can seem like a black box.
  • What “test automation” is depends on the context you’re in. Are you scripting scenarios? Are you building GUI test automation? Web service test automation? Mobile test automation?
  • Is there an automation mindset? It’s a bit of both, a hybrid of a tester’s mindset with a developer’s skillset. In building test automation, I still need to keep my tester’s hat on – figuring out how to best find information and provide that to the team. I need a developer’s skillset to understand how all the pieces work together and what tools available to me to build automation.
  • Automation can’t explore, it mainly re-tests known functionality like a sanity check.
  • Google Chrome dev tools are a great place to start for understanding what is going on under the GUI, such as being able to inspect the HTML and the elements that make up the page. This can help you build GUI test automation but also help your exploratory testing.

How to know where to start with automation

  • Managers tend to decide that they want to automate all of the regression testing – how to know where automation fits? There is a cost to automation in same way there is for development code. Try to think more strategically, what should you automate? What is risky to you or your customers? Those are good things to build automation scripts around. Also, things that take your testers a long time to do, such as data setup can be automated.
  • In encouraging people to shift left and get more involved with the writing of code or automation tests, we’re pushing everyone to be able to write code and this isn’t necessarily everyone’s interest or strong point. There are so many things that go into automation engineering that testers can contribute to. Monitoring the test runs and whether they are passing is something can testers can help with, testers already have skills in looking at logs and working out what is going on. Getting involved looking at automation test results is taking that a step further.
  • You can start getting better at reading code and helping review developers code – starting to continuously test earlier in the process.
  • If testers were more involved in the triage and investigation of bugs with automated tests (as opposed to the product they are checking), they could help guide developers on which automation tests may need to be improved. For example, if there is a test that regularly fails over and over, it might need changing or even throwing away if it is costing a lot of time in maintenance.
  • Testers can also gain information by investigating the failures that are occurring with automation. If testers look at these failures, it might be useful information to know where to focus exploring more if there is an automation test that regularly fails in a particular area of a product.
  • You shouldn’t just rely on the licensed tools that you’re provided with at work, figure out what you need and look to get that. There are plenty of open source tools out there and there’s a great community who are vocal about their usage of tools and who are willing to help if you’re stuck. You can also help contribute fixes to open source tools and help improve the tools for others. The testers.io slack team is a great place to start asking.

Should automation code be peer reviewed?

  • Should automation code be peer reviewed by developers or testers? Absolutely, automation code is still code and it still needs to be done well. It makes a world of difference in terms of the code quality, automation code needs to be top quality. People don’t seem to treat their automation code as well as their production code, but they really should be treating the automation code more seriously so that you don’t have flakey or false-positive tests.
  • Code reviews are also useful for mentoring, so you can provide feedback on how code can be improved or made cleaner or even re-used for other work.
  • By encouraging developers to review and care about automation code, it encourages empathy, which allows them to understand what you might be struggling with and how they can change the product to become easier to automate around.

Useful links

  1. Angie’s twitter
  2. Angie’s blog
  3. testers.io slack team
  4. Google Chrome dev tools

Leave a Reply

Your email address will not be published. Required fields are marked *