My Story of Test Automation

I use to think I am not technical and very far away from the thing called Test Automation (TA). Then I started to work at this one company, who were having huge quality problems. I asked how automation looks like and found out that they do not have any (yes, even no unit tests) and that they currently work on defining CI pipeline. This is how my operation and test automation journey started. It turned out that even I thought I am not technical enough and knew a bit about TA, others knew less or were not motivated to introduce it to the company.  Next few years I worked closely together with operation team, supported creation of CI pipeline, defined processes and introduced automation.

One of the first thing that I did – I asked developers from each project to explain how the build process works in his/her project. I found out that many developers did not know how it works. I found out that some developers did not know how to build release and were deploying snapshots. Why did I ask developers about something that usually should be done by operations? Because problems do not appear in operations or in development, they appear where everyone should work together. Another thing – we wanted to create general approach and process to enable employee switchover in case of necessity (vacation or illness).

Parallel to building CI pipeline I started to automate. Just as every other beginner I made many, many mistakes on the way. At the beginning, I was too focused on the tool and too less on the mindset about automation. During TestBash Brighton 2015 several other attendees stayed in my hotel, and I remember that one morning  we all came together at the breakfast table. It was very energised and inspiring morning. That breakfast was an eye-opening moment for me. Richard Bradshaw was sitting at the table as well and told me about his Lego automation workshop, I could see immediately how to implement some of his ideas into project I was currently working on. I was sitting there trembling and panicking – is it too late to change our approach? Some of the projects were already automating everything – a test for each acceptance criteria in a user story. Developers were not involved in creation and maintenance of test automation, but hoped that GUI automation will be their safety net and supported customers wish to automate ALL tests. We started to observe problems with testing and some people got very disappointed. I saw it but did not understand where it comes from and how to fix it. TestBash and ongoing conversations with others helped me to see the cause. I started to learn more about mindset and realised that by automating everything, I have build technical debt. We needed test automation strategy!

If you think that this story has happy ending, I have to disappoint you. One thing I have learned in 20 years of IT – it is not about tools, methods and processes. It is about people and people are stubborn. I saw my mistakes, I learned a lesson and of course it was hard for myself to accept that some of my mistakes were so huge and I misled others. But denial or to hide evidence has never been something what I do. I went back to the teams I was working with, explained what I have discovered and what I want to change and… they refused my suggestions! They thought it is OK how it is running. I tried to point out to problems we were having, but they found another reason and explanation. They just wanted to keep to automate everything…

Soon after that all happened, I felt urge to speak about it and make people aware of pitfalls. I started to give workshops for other in-house teams, our project managers and for customers. I had so much fun by doing that that I got the idea to do workshops and trainings full time. Fast forward – here I am, working as full time trainer and guess what I talk the most in my trainings? Yes, mindset! And very little about tools and concrete examples, because I still need to learn a lot and you could have better ideas than I do. This is my happy ending.

If you want to learn more about automation tests, I suggest you to visit evil testers website.

 

Explaining Software Testing

Michael Bolton is good in summarising fundaments of software testing in a tweet. In my eyes this piece of information deserves a little blog post.

The last sentence is something what I teach my ISTQB Foundation Level students – you cannot assure that there are no bugs, but you can collect information about bugs you have found. You can analyse them e.g. with aim to create set of actions how to secure your software developing process from reappearance of that type of bugs.

Most of developers want to know if a feature does work or not, but we as testers can only say that Version A did work on Machine B under Circumstances C.  Project managers and customers want to know if it will work on production. We as testers cannot assure it, because we did not (and we should not) test on production environment with production data. Based on tests on similar environments and under similar circumstances we can suppose that it can work.

Sounds very logical, but it can escalate very quickly, because DEVs, PMs and customers think that testers are there to save the word and to give certificates that the software they are working on, works perfectly as described.

What to do if you still get asked:

– “What do you do whole day long if you cannot tell me will it work or not?!” 

In heated situation like this it is too late to explain semantics, fundaments of testings or why software development process is complex. You should done it as soon as possible, when you started to work on a new feature, on new project, in new team or new company.  Remember – one of most important skill of a tester is communication skills. We need those not to be able to talk about the weather, but for explaining what is testing and how testing can help to DEVs, PMs, customers and all others. Daily.

Michael suggests 4 step plan how to learn fundaments of software testing:

  1. Learn how to test: How can a trainee improve his/her skill sets in testing?; To The New Tester
  2. Declare your commitments: A Tester’s Commitments
  3. Recognise that all testing is heuristic: Heuristics for Understanding Heuristics
  4. Learn to tell the testing story: How is the testing going?

Looks simple, but as you start to read the linked resources you will understand that studies can take years. Take deep breath. To be able to explain testing to others, you have to learn it first for yourself. Do not panic if it does not work on a first try. Make experiments, try new approaches, improve your skills. One day you will master it!