A few weeks ago I lectured about the importance of testing the test automation framework. At the beginning of the lecture, I asked the audience the following questions:
- “Who here writes automation?” – There was almost an entire show of raised hands.
- “Who here defines themselves as a developer?”- Only a few raised hands.
- “Who here writes tests for their test automation framework?” – The audience was silent. Out of 60 people, not even a single raising hand appeared.
This fact did not come as much surprise to me, since testing our automation is not so trivial (at least not currently). I hope that by the end of this post you will agree with me the testing your test automation framework is not something you should give up on.
3 main reasons for writing tests for our test automation framework
Reason #1 – We are developers!
It is very important that we remember that every one of us who writes code is, first of all, a developer. Even if your code does not go off to production and even if your code is not that great at the moment. We need to look at ourselves as developers and look at our automated tests as an automation product. As soon as we realize that our automation is a development product and that we’re developers, the way we’ll treat our code will change completely.
However, with this kind of change also comes a greater responsibility. We will have to learn how to code better, be familiar with design patterns, work with source control, code review each other, manage our automation project in Jira and most importantly, our product, just like an R&D product, will need to be tested.
Basically, our work quality (as well as the time we invest in our work) will have to scale up.
So, yes, considering ourselves as developers will not only be a good reason for us to write tests, but it will also skyrocket our automation quality (and as an outcome, it will also improve our tests and product quality) to a whole new level.
Reason #2 – The cobbler’s children must have shoes!
We must remember that the main purpose of our frameworks is to test, and in most cases, those who create the test automation frameworks are testers themselves. Therefore, we as testers must set a proper example for development teams on how to test a product and how the product’s tests need to look like. In other words, who are we to dictate a developer how to test his product (even if it’s a single test), if we don’t even test ourselves?!
Only after we understand how a developer tests his product (we are the developers in this case, remember? 😉 ), will we be able to build a trust with the development teams and emphasize how we believe the project needs to be developed in order for it to be “testable”.
Reason #3 – If it’s not high-quality automation, it won’t be a high-quality product!
No matter which angle we have a look at it – automated tests can have their occasional faults, thus automatically their credibility is jeopardized and the same goes for the product’s quality that was tested this way. In such a case, testing our automation is the perfect solution!
A test automation framework is basically code, and code usually has bugs (even if very talented people wrote it). Therefore, testing of our automation frameworks will lead to fewer bugs, which as a consequence will enhance everyone’s confidence when testing their product with test automation frameworks.
It’s also very important to remember that in our case, the need for testing is even higher since we do not have QA.
Developers can somewhat afford not to be 100% confident with their development, since in most cases their product undergoes another round of testings before releasing to production.
Conclusion
I tried to showcase in this post what I believe to be the main reasons for testing our test automation frameworks.
I invite you all to share in the comments below your automated tests challenges, and try to figure out which kind of tests you need to do in order to eliminate any possible failures.