Is Software Test Automation for You?

Is software test automation for you? Isn’t that the million dollar question? Both from the standpoint of is this type of work right for you as a tester, and are you really skilled enough to do it. Especially due to the current trend to implement more and more “automation of testing” on projects. This is both a need and a repercussion of the implementation of agile methods on projects over the last 10 years. The need is to facilitate quicker turnaround of code changes and feedback on the health of the code overall. The repercussion is that the need has caused software teams to seek out new ways to become more efficient with the little time they have allocated before a release. This has led to an increased demand to use computers to aid in the overall process of software development, thus some form of “automation” of a task or tasks that a human has done in the past. And automation has become especially sought out to aid in the process of testing.

Taking a step back for a moment. Test automation, or more appropriately the “automation of test execution”, has been around for a long time in the software industry (almost from the beginning). It started off with homegrown tools built to record and playback a test. Eventually commercial/vendor based tools came around, but they were very costly to implement and use. The skill sets needed to use them (either one) were pretty basic; you didn’t have to be a highly skilled programmer.

With the introduction of Object Oriented Programming and Event-Driven systems, specifically Mac and Windows, things changed radically. Record/Playback tools proved to be inefficient because they created fragile tests that had higher maintenance time/costs associated to them. Concomitantly, commercial tool vendors upgraded their tools to allow for a programmatic approach to compensate, but this required users to have the equivalent skills to use them. A lot of these tools used “scripting” languages that were either similar to/or stripped down versions of C or Visual Basic. These tools had a code editor incorporated for more skilled people to use. Again, they didn’t require deep knowledge/skills in programming to use them. In addition, as already mentioned, these tools were expensive to obtain and maintain over the life of a project.

With the advent of open-source tools, the cost of entry came down, which is a good thing as it allowed more people and companies to enter into the realm of software test automation. But some of these tools are only pieces of the overall puzzle that are needed to create a whole solution like a commercial tool. An example for this is Selenium Webdriver; it is only a resource library that has the API’s and functionality to support interaction with a browser based application. You still need to have a programming language (Java, C# or Python) along with a test harness (JUnit, TestNG, NUnit, etc.) wrapped around it to get the level of functionality necessary to create an executable automated test case/script. Therefore, the required skills to implement and use them has increased drastically. This has had a major impact upon anyone previously working with test automation, or now wanting to get into this area of work. It has pushed test staff in general to become more technical in their skills and capabilities.

 

Are You a Technical or Non-Technical Tester?

What does it mean to be a “Technical” versus a “Non-Technical” tester? Pretty much what it sounds like; it basically comes down to mindset and emphasis, or focus, of what you are doing in testing. Personally, I am a Technical Tester and I tend to look at things from a process and technology viewpoint. I think more about the mechanics of the software; how it is put together and how it is used to solve the business problem it was built for. This is coupled with my knowledge of programming and experience with software development in general.

For “Non-Technical” testers the viewpoint is from a slightly different angle. These are testers who focus more on the business problem the software is built to solve. They understand the business rules and data that support them. They understand the process of the business and how a user will interact with the software. The understanding and focus is of a different type of mechanics regarding the software under test. They are not as concerned about the technology behind it, but more that the technology allows them to get their work done correctly and efficiently. Also, they may have some technical training along with some knowledge of programming and software development because they had classes in Computer Information Systems.

In relation to Software Test Automation work, there is a bias to the Technical tester, and it has been this way for a long time. However, nowadays, with the increased interest and demand for automation, there is an equal increased interest and demand for testers (Technical and Non-Technical) to be more adept and skilled to do the work. This is mainly due to the increased usage of open-source tools, and their higher requirements in skills to use them.

This has caused more testers to become a hybrid of developer and tester, and vice versa for developers getting into automation of their tests. These “Hybrids” have to be able to understand and do both testing and programming work, as it relates to automation of testing tasks. These “Hybrids” have to be able to meld the best of both worlds.

 

Upping Your Game

Therefore, testers have to “up their game” in both skills and capabilities. I’ve always been outspoken about automation staff needing to have a solid level of knowledge and skills in programming. This was because “good” automation means building modular, robust and maintainable code in order to create reusable automated tests. Automation is its own form of software development, it is creating “Testware” along with other necessary assets. As such, there are certain skills needed and practices to be followed in order to ensure the automation testware and that the assets are sound and maintainable. However, this doesn’t mean you need to be a top flight programmer either. Just a good and well-rounded one with some solid experience.

Admittedly, I too have to up my game and learn/re-learn the latest tools, programming languages and methods in order to continue to do this line of work. And I’ve been at this for over 25 years, and have had to retool myself a couple of times before as well.

My next steps will mean learning more about programming languages like Java, C# or Python. Going deeper into their constructs and functionality. Learning more about Object Oriented Programming (OOP) beyond what I know about the basic constructs of code (Classes, Methods, Properties, Functions, etc.) to Inheritance, Polymorphism, Abstraction, and Encapsulation methods. Taking this information and applying it to the code I create for test automation; this includes the frameworks, function libraries and test scripts built from them.

Also, instead of knowing a particular tool (or two) to fulfill my automation implementation needs, I will need to learn how to pull together different or disparate tools to successfully implement the automation itself. This can mean learning things such as Cucumber or SpecFlow along with Selenium, and associated methodologies like BDD (behavior-driven development) and TDD (test-driven development).

This means I need to become more technical. We all need to become more technical in order to do test automation work.

 

Conclusion

Hopefully I haven’t scared you off from getting into Test Automation. If you have the drive and mindset for it – then I say go for it. But understand what lays ahead of you in order to do it successfully and have a long career working in the discipline. Even an automation old dog like me needs to learn some new tricks.  😉

 

I would be happy to hear your thoughts in the comment section below!