If you're thinking of introducing test automation to your process, you may have a plan for how it will affect your testers. But what about the development side of things? In this article, Linda Hayes takes a look at how automation changes the relationship between test and development organizations and offers a way to handle it.
It seems obvious that automation will affect the test organization. Less obvious—but no less real—is that it will also affect the development organization. In fact, when you choose to automate the testing for an application, your relationship with development changes completely.
Think about it. Manual testers only have to be able to interact with the application using the screen, keyboard, and mouse or other device. Automated test tools, on the other hand, have to interact with the software at a deeper level, thus exposing the inner workings of the code and perhaps uncovering problems that prevent or complicate automation. If you're not careful, developers might think you have suddenly transformed into an interfering busybody who is sticking your nose into their business.
This shift in your relationship with development can be handled in a bad way or a good way.
The bad way is that you find yourself struggling with gibberish object names, dynamic attributes, closed objects, custom classes, and other coding horrors that make automation a tale of suffering and failure. You curse the software and the developer it rode in on, because it is downright hostile to your test tool and creates all manner of extra-hard consuming time and resources already in short supply. You moan to management and get sympathy but no action. Curing all of your automation ills will take time that isn't in the schedule. You despair.
Needless to say, the good way is much better. You meet with development as early as possible, before implementation starts if feasible, and:
Sell them on what automation means to them. You will be able to deliver more test coverage faster, resulting in reduced turnaround time and fewer defects that will translate into fewer fire drills and fixes for them. Look for areas where you and development can share both the effort and the rewards, such as the automation of a build or smoke test, or perhaps even unit and integration testing. My experience shows that the greater the involvement of development in the automation effort, the more successful it becomes. Developers can get hooked on using automated tests and would much rather find defects before you do.
Show them how your test tool works, if you have one. If you don't have one, review your options with them to see if you can pick one everyone could use. Discuss your implementation plans, including the framework architecture and key components, such as the object map or repository. Explore possibilities for generating, extracting, or otherwise automatically acquiring the object repository. Discuss change management and maintenance strategies to keep your tests current with the code.
If you can engage them, developers can be creative and responsive to providing the elements of a successful test automation library. In a recent project, the developers with whom I was working offered to develop the entire framework so long as they could take advantage of the tests that were developed.Educate them on what you need from the software—meaningful, persistent, and unique object names; access to object attributes, methods, and properties; standard classes at best or standard implementations of custom classes at worst; a stable and repeatable test data environment. Explain the implications for automation when these are missing. Discuss whether these issues exist in the application and what the effort and schedule will be to remedy them.
Overcome resistance to investing development resources in enabling automation by pointing out that the rigor and conventions required for automation also make the code more maintainable and transferable over the long term.
Be prepared to pull the plug on automation if you identify significant issues but no solutions are forthcoming. There is no reward for hard work if it doesn't get you anywhere. As they say, discretion is the better part of valor. If the application is a loser, face it and deal with it. Let management know that automation is not feasible and either look for another application to automate or wait until the changes you need can be made.
On the bright side, my experience shows that the more developers understand about automation, the more testable the applications they build and the more willing they are to cooperate. Even doing it the good way doesn't mean the outcome is guaranteed, but it will save you a lot of time and grief because you will find out sooner rather than later whether your relationship with development will survive automation.
What has your experience been? Share your comments below.
