The Australian Government coat of Arms

Communities of practice

Communities of practice

Some subject areas to think about in automation

Hi all,

Automation is a big subject. So here are some ideas to kickstart thinking and discussions.

Topic – Technical
Automation testing – UI
Automation testing – Service Level
Unit and Integration Testing
Massive Data Generation
Automation Tools
Automation Frameworks
Maintainability of Automation Tests
Security systems and Automation
Topic – Test Case Writing and Testing Practices for Automation
Test Case Design Principles for Automation
Integrating Automation Testing with Manual Testing
Topic – Cultural and Organisational aspects of Automation
Adopting an Automation Culture and overcoming change resistance
Automation Bureaucracy, Processes, and Team Structures
Winning Management Support
Implementing Automation in an Agile team
Topic – Reporting, Metrics, and Automation
Metrics for Automation
Data Science, Reports, and Automation
Topic – Scheduling Automation and Health Checks
Best practice for Automated Health Checks and Scheduled Regression
Topic – General
General Automation Chat
What to Automate? What not to Automate?
Topic – DevOps
Automation and DevOps
Topic – Robotic Process Automation and Machine Learning
Robotic Process Automation
Machine Learning

–Cam

Yes, automation is definitely a big subject ! I’d say software development in general is about automation - we are writing software to automate things so we don’t have to do them manually. But I guess in this context we are taking “automation” to mean automating the things involved in the various aspects of the process of software development (or even just in using software we don’t build ourselves).

With regard to the more specific topic of test automation, there are two closely related things I am very interested in :-

  1. Automation of the creation of tests (as opposed to automation of the running of tests). Automation of running of tests gives us some savings over manually running tests, but there can still be a lot of work in creating those automated tests, eg writing or recording scripts etc. If we can automate the creation of the tests then we can step up to another level of productivity - and literally have thousands and millions of tests, rather than a small number that we can create by hand. Relevant techniques include things like model based testing, property based testing, test data generation.

  2. “Self-testing” systems, where we use the actual functionality of the system to help test itself. A simple example of this could be some kind of “round tripping”, eg if there is an import function in a system, and also an export, then if we first import something, then export it, we might be able to do some kind of comparison of the original data to the exported data and hope that they have some kind of correspondence. We have found (and made) this kind of opportunity in a number of our systems that have enabled us to more easily check whether the system is doing the right thing.

Another more broader automation topic that I am interested in is the role that DSLs (Domain Specific Languages) can play in software development. We have had some success in this area where we have provided a DSL that our business clients use to specify their systems, from which the working system is automatically generated. This allows the business people to concentrate on defining the business logic, and the developers to concentrate on building the translator/interpreter/compiler for the DSL.

I’d be very interested to hear what other people have done in any of these areas. I’ll also make some specific posts on these topics giving some more detail on our experiences and what we have done.

Awesome Glenn, I look forward to your posts, particularly on item 1. I now have to go and do some research on a couple things like DSLs too.

I’d like to add to the list of subject areas to talk about is Accessibility testing. I’ve spoken to @cameron.hill and a few others about this.

Although accessibility issues can’t all be picked up through automated testing we can shift the burden from developers having to test easy things. I.e. are headings structured correctly, do images have ALT attributes, are there any links labelled click here.

We can test “low hanging fruit” accessibility issues with a high degree of certainty as its a binary outcome.

Plus there is the benefit that automation can potentially allow more resources to be (re)directed at accessibility because other repetitive but time consuming tests can be automated, thus freeing up resources for intelligent accessibility testing.

1 Like