- 29.1 Three Grains of Rice
- 29.2 Understanding Has to Grow
- 29.3 First Day Automated Testing
- 29.4 Attempting to Get Automation Started
- 29.5 Struggling with (against) Management
- 29.6 Exploratory Test Automation: Database Record Locking
- 29.7 Lessons Learned from Test Automation in an Embedded Hardware-Software Computer Environment
- 29.8 The Contagious Clock
- 29.9 Flexibility of the Automation System
- 29.10 A Tale of Too Many Tools (and Not Enough Cross-Department Support)
- 29.11 A Success with a Surprising End
- 29.12 Cooperation Can Overcome Resource Limitations
- 29.13 An Automation Process for Large-Scale Success
- 29.14 Test Automation Isn't Always What It Seems
This chapter is from the book
This chapter is from the book
This chapter is from the book
29.10 A Tale of Too Many Tools (and Not Enough Cross-Department Support)
Adrian Smith, United Kingdom
QA lead
I have been involved in five automation projects over 5 years, with varying degrees of success.
29.10.1 Project 1: Simulation Using a DSTL
The first project was written in Python and batch scripts, running functional and performance tests on 85 to 145 PCs, simulating more than 20,000 machines. It was not originally an automation project, but I made it so. What started as a simple control program ended up growing into a fully flexible domain-specific test language (DSTL), as it would now be called, that enabled the tester to write test steps in a simple though unstructured keyword/parameter language. Expand the tests, alter them, chain them, and add new elements to the language as needed. The potential 9-month project was still being used 6 years later, It has ended up having a much better ROI than expected as its scope has increased over time. Thousands of man hours were saved and vastly more test runs were performed than a could have been run manually and with fewer execution errors.
About halfway through the automation project, my manager wanted me to do some manual testing for a different project because it was way behind. I knew this would be the end of the automation, so I managed to convince him that it would be better for me to stay with this (ad hoc) project—and this contributed to its success.
29.10.2 Project 2: Testing a GUI Using TestComplete
The second automation project was to automate system-level applications. A tool was bought to experiment with: TestComplete 3. I had high hopes for another success using a DSTL for the testers, but this would take a long lead time to build. We then came across problems of automating GUI interfaces written in an automation-unfriendly way. I naively asked development to assist by modifying their code to help with the automation but was flatly refused. I had no support from management for this, so I had to go it alone. I probably should have stopped there and then.
But I didn’t. I persevered with the DSTL framework, though with little abstraction because I wanted to have something working sooner for management. At the time the first beta was just about ready, a new director of testing was appointed. The good news was that he thought automation was a good thing. The bad news was that he decided we needed to get “the right tool” with a single solution of manual test creation, results gathering, and reporting. I had to suspend my work with TestComplete and was given a 2-month task to evaluate a number of GUI automation tools. The final three were Rational Robot, Quality Centre QTP, and guess what: TestComplete. After the evaluation, I thought TestComplete was the most flexible and wanted to continue with it. The company thought differently, so this framework was never completed.
29.10.3 Project 3: Rational Robot
A 3-month proof-of-concept was then initiated for Rational Robot. If I had got further in the previous project, I could have at least reused the tests written. It was decided to do something similar with this tool, framework, abstraction, and tests being a thin layer on top. After 8 months, another automator and I had abstracted the tests and had a GUI object action library that could be generated automatically. Many hundreds of lines of code were automatically generated to do simple GUI actions as click a button or check a textbox. All that was changing was which control in which window to use. We had a good feeling about this framework because it was simple, and we were just starting to settle on a project to automate when, at this point, management decided to do a proof-of-concept for QuickTest Professional (QTP).
29.10.4 Project 4: Final Python Project and QTP Proof-of-Concept
Management were now getting involved and wanted to see some ROI that could be quantified to justify the purchase of this tool. We set to work on a single-use framework in Python, eventually automating 15 end-to-end smoke tests using GUI libraries. I had made a Python frontend so that testers could create and maintain tests without needing a lot of technical knowledge. The number of bugs that it found was too low to justify extending this automation to other areas. However, we were beginning to get occasional cooperation from developers. There were a couple of interfaces that could be called directly from Python to C written specifically for us to enable the tests to function.
We had one problem that we lost many days trying to figure out: The tool would crash but didn’t report any error. It turned out to be a bug in the tool itself.
For the proof-of-concept project for QTP, we had trouble trying to work with QTP in the way we wanted to, and a lot of time was wasted coming to grips with it. Eventually, we found a workaround to allow us to put many methods in one QTP file. At the end of this proof-of-concept, I would still have opted for one of the other tools.
Management chose QTP, and we had a real project to do with deadlines and end dates, so many of our ideals were curtailed, sidelined, or dropped. We again ran into problems with GUI objects and no help from developers.
29.10.5 Project 5: QTP2
With a new release of QTP, we tried to integrate our framework and Python code so that test results would be received centrally while still allowing us to launch tests including rebooting machines. This was using VMware virtualization and CruiseControl. We added extensively to application libraries, which were QTP libraries that did lots of specific tasks in a GUI, passing in a number of parameters. We also wanted to bring the test creation tool up to date so that the testers could use the automation easily. The thought behind this was that the easier it was to write a test, the quicker it would be to add tests, while the application libraries could be maintained by the automators.
However, management didn’t want “extraneous time” spent on this perceived nonproductive activity!
The way we automators wanted it was that testers would not have to learn much programming, but because there would be no tool to help with creating tests, then testers would have to learn programming and know much more about the internal workings of the automation system. This is not a bad thing, but with a lot of pressure on the test department, it seemed (and was proven to be true) that testers rarely had time to dedicate to automation programming before being taken off again by another project. In a lot of cases, they never made it to do any automation because of deadline changes. At this time, automation still was not at the forefront of management thinking, but it was definitely starting to get their notice.
Progress was being made, libraries were expanding, and the tests were nearing completion, having overcome many of the problems of GUI fragility.
Now a problem that we automators had “forgotten about” came back. For the first time in a couple of years, the GUI interfaces began to be amended or overhauled on a much more frequent but ad hoc basis (to us automators). We were not informed of changes as they happened, so our tests started failing, and it took a long time to find out why. After 2½ months of battling this upset (hundreds of changes to GUIs rendered even the smoke tests useless), I called a halt.
29.10.6 The End of the Story
Of the five automation projects I was involved in, only the first one achieved success. It was non-GUI and an isolated project. The others failed because of what seemed to be management decisions and lack of cross-department cooperation, but perhaps better communication would have helped.
Management had a bit of a shock and a rethink about automation after all the previous high-profile problems. Automation is now a deliverable for developers—one of the key problems before was that there was no incentive for developers or development managers to support or even cooperate with automators, as they had their own targets. Direct GUI automation has been abandoned, and automation is now at API level.
The final irony is that developers now have to maintain the APIs and automation code; if only they had agreed to maintain object libraries or had added a few lines to object maps earlier, there would have been less work for them now.