In the past, in order to be a viable contributor in the world of Quality Assurance, all you had to know was enough about computers to run an application and how to collect test results. Today, as test automation becomes a more critical aspect of the QA landscape, testing practitioners need to know how to program. That's the simple, cold truth. Manual testing is falling by the wayside.
Most companies still doing manual testing understand the need to move to automation. But, moving a QA Department from manual to automated testing is not as easy as just sending the manual testers out for re-education. In fact, many companies that send their manual tester out for “training” fail. Why? Mostly for two reasons. First, some employees simply have neither the interest or aptitude to learn the programming skills necessary to do automated testing. Second, many companies completely underestimate the depth of understanding and work required for even the most able employees to acquire the knowledge and skills required to contribute effectively in terms of test automation.
So, what’s to be done?
The answer is to change the attitude and behavior by which employees and companies approach moving to test automation. Companies that really want to make it so that those moving from manual to automated testing are successful will do well to accept the following 4 assertions:
1. Accept that even the easy stuff is hard
2. Accept that learning to do abstract thinking counts
3. Accept that you need to be willing to do whatever it takes
4. Accept you need to program every day
Allow me to elaborate.
As much as some of the conventional wisdom will tell you otherwise, test automation programming is hard and learning to do it is even harder. Yes, there are some people out there that have a knack for coding. But even these people will end up spending hours, if not days, trying to solve a seemingly simple problem to which the answer might be something as trivial as identifying a misplaced comma in a line of code. There’s a lot of detail that goes with the art and science of coding.
Thus, any person or company transitioning from manual testing to automation needs to understand that when it comes to programming, even the easy stuff is hard. There is no pill to be swallowed that will magically inject the considerable knowledge and cognitive skill required to do even the most basic programming required for test automation. Individuals and companies must be willing to invest the time and do the work required to become competent, even at an elementary level. It’s more than a matter of a week or two of training. Getting a true understanding of the basics can be a process that can go on for months. Remember, we’re talking about changing how people think. This takes time. If the person or company is not willing to make the commitment of time and effort just to learn the basics, failure is more likely than not.
No matter what form a company’s test automation practice takes, those wanting to work in automation testing need to not only learn the basics of programming but also hone a highly developed understanding of abstraction.
Being able to convert testing scenarios into code means developing the ability to define entities and behaviors in a conceptual manner, a.k.a, the ability to abstract. Being able to identify general patterns from a variety of test instances provides the foundation for scalable test automation. One test pattern, properly understood, can be applied to many testing scenarios. Not only does abstraction reduce the cost of test automation by promoting reuse, the actual programming is a lot more fun. It’s the analogical difference between writing a recipe for making chocolate chip cookies and designing a baking process that can produce a number of different types of cookies.
Developing an acute sense of abstraction requires a special way of looking at the world. And, it takes time. Yet there is benefit. When you can look at your world in an abstract manner, transforming test scenarios into code will become second nature.
There are two things I’ve noticed about people that are very successful in acquiring new skills. First, they will do whatever it takes to get better. Second, they tend to surround themselves with people that are already very good at what they do. It’s like playing tennis. You always want to play against people who are better than you. You need to improve to keep up.
As competitive as the world of modern programming may be - and it can be very competitive - the profession has developed a benevolent attitude toward helping those who want to learn. Today any aspiring person can learn to code by spending an infinite amount of time watching videos on YouTube and studying code on GitHub. It wasn’t always this easy. Before the Internet came along, when you wanted to learn to code and you couldn’t afford the time or money to do formal study (a.k.a, go to college), you had to read a lot of books and/or know someone who knew programming who was willing to help you learn. Today we’re giving it away, literally.
Doing whatever it takes to be viable does not stop once the initial education experience is over. Technology is changing too quickly. There is always more to learn. One technique that many companies use to develop the skills of its technical staff, as well as improve code quality, is to engage in pair programming. Pair programming is when two programmers work on the same body of code together on a single computer. It’s as if two minds are coding as one.
Companies in the know understand the benefit of implementing some degree of pair programming, either formally or informally. In terms of professional development, I can attest to the fact that I’ve always benefited from a pair programming session, regardless of whether it’s with someone junior, or senior to me. I always walk away smarter.
Pair programming offers significant benefit In terms of test automation. First, the tests will probably be better in that two minds often better than one. (Ten minds, not so much, see Fred Brooks’s book, The Mythical Man Month.) Second, both parties will learn something new and improve. For the aspiring test automation engineer, pair programming can be a highly effective educational experience provided he or she is willing to accept the intellectual vulnerability that comes with the endeavor. It can be anxiety provoking. Yet, exposing one’s weaknesses to another person is a small price to pay for the enormous benefit to be gained.
Programming is like playing the piano. You need to do it everyday to reinforce and build upon what you’ve learned previously. Make every learning session count.
Those who have taken the time to acquire the necessary knowledge and skills to become effective at test automation must be given the opportunity to use what they have learned everyday. It makes no sense to invest time and money to help an employee to get competent at programming only to have him or her go back to doing incidental manual testing while waiting for an opportunity to come along to work on an automation project. Nor does it make sense to have employees engage in automation activity sporadically.
If a company wants to have automation as the foundation of it testing activity, it must allow those creating the automation to stay active consistently and continually. Otherwise, as the saying goes, “if you don’t use it, you lose it.”
Programming is fast becoming the lingua franca of modern QA. There will still be need for manual testing for complex test scenarios beyond those usual for typical business applications. But for the most part, manual testing will become the exception rather than the rule. To work in QA in the modern enterprise means knowing how to code.
Learning the programming skills required to work effectively in test automation requires time and commitment, both from employees and the companies for which they work. Those that are successful will understand the inherent difficulty of the work. They understand that even the easy stuff is hard. They will understand the importance of abstract thinking in modern test automation. They will make a commitment to create an environment in which learning is continuous and unfettered. They make sure that acquired skills are not left to wither away due to inactivity. In short, both the employee and company will be willing to do whatever it takes to implement automated testing in a manner that is effective for the long term. To do otherwise is to pursue test automation at your own peril.