Is your testing tool behaving like a problem child? Injecting your application with some discipline may be what's needed. Sometimes, spending a few weeks of development time on creating a solution can save you months of testing time. In this article, Linda Hayes explains how one company did just that!
One of the thorniest problems in test automation is dealing with objects that the test tool can't see or interact with. Often these are third-party controls, but not always. Sometimes they are just complex controls within containers or other layers that obscure access to the methods and properties. But whatever the reason, in my experience they make up 20 percent of the application but take 80 percent of the effort, and in some cases, they have stymied automation altogether.
One of the most effective ways of dealing with this issue is to inject the application with some code or hook that gives the test tool access to the application internals. This might take the form of a DLL that is compiled in, an API that is exposed, or special methods that are added. But while this approach is usually the most powerful and efficient solution, it is usually the least likely to succeed for the simple reason that developers don't want to modify the application for test purposes.
The reasons run the gamut from an inchoate fear that the extra code might cause unpredictable problems, to the belief that if the test hook is removed when the application is delivered that the "real" code wasn't really tested. If it stays in, there is a major security risk that others might use it to interfere with the application. Or, in some cases, the developers simply don't see it as their problem, or they aren't motivated to invest the time and effort.
It seems there are no easy answers—or at least it did seem that way, until an enterprising software development company called CSG Systems came up with an ingenious solution. CSG Systems has been providing customer care and billing applications for twenty years to 265 companies in forty countries. Their software portfolio is massive, complex and critical—a perfect candidate for test automation.
Like most companies dealing with huge applications and widely varied customer needs, CSG has adopted an architecture that permits flexibility through configurability. This design relies on multiple components that are shared, resulting in objects that are contained with other objects—a classic automation challenge.
"We had objects that the test tool could not see," said Senior Manager Shane Perrien. "This prevented us from accessing the object methods and properties we needed." A related issue was the dynamic nature of the application: different conditions created different window object contents, and since the window handle was created new at runtime, it was difficult to set context. This caused excess maintenance overhead for test cases.
After exhausting all other options, Shane presented the problem to the development organization. Software Architect Miao Chen developed an application DLL that exposed the methods and properties of each window and object, and a second DLL stored in the system directory that accesses the first for the automated engine. Miao then created a tool for QA to identify a unique path for each object. Once these were in place, Edmond Sierens, the Software Engineer responsible for the test automation function library, retrofit his functions to call the system DLL and expose the window handle, which is then sent back with the unique object ID.