The Secret to Automation Success
If you are among the thousands who are struggling with a test automation record/play/script tool, I can tell you the secret to succeeding – or at least giving yourself the best possible chance to succeed – in a single sentence:
What you have is a tool and what you need is an application.
What’s the difference? Let’s use an analogy. Imagine that my accountant is keeping the books in a spreadsheet and, naturally, it is taking too long and he is making too many mistakes. So, I decide that automation is the answer. Would I record the current manual process and try to replay it every month? Would I buy him a compiler and expect him to develop an accounting system on the side, while he continues to keep the books by hand? Would I hire programmers to develop an accounting system for him?
I’m sure you are thinking – you should be, anyway – that all of these options are comical. The obvious thing to do is to buy an accounting application.
Now just substitute “tester” for “accountant” and “testing” for “accounting”, and you get the picture of why test automation has failed. Companies think they are buying a test automation application when what they are buying is a tool that lets them choose one of the above three options. They have no idea what they are getting into.
Recording a manual task does not make it automated. It is simply a stream of events at a given time without structure, logic or documentation. We test software because it changes, and maintenance of these sessions is difficult to impossible. Capture/playback is a marketing technique, not an implementation one.
Expecting manual testers to design and develop their own application while they are also required to meet schedules for the application under test is also absurd. And the best testers usually aren’t programmers anyway, so you need additional resources and skills to even attempt it.
But while buying a test automation application is an obvious answer, testing is not as easy as accounting. Accounting rules are standardized, testing isn’t. There is a never-ending mix of technologies, architectures, languages, and functionality that makes it impossible for one test automation application to handle all possibilities.
Or does it?
What made SAP so successful was the idea that functionality can be represented as a data model instead of as code. Instead of each customer developing their own custom applications because their processes were unique to them, SAP allows them to buy a packaged application and then customize it…without writing any code except perhaps in fringe cases.
And therein lies the core difference between a tool and an application: code versus data.
With a test recording and scripting tool, code is accumulated. Whether it is recorded, generated or developed, it must be managed and maintained. The problem is that application functionality expands over time, but the time and resources dedicated to testing are either flat or declining. This means more and more test code must be created and – especially - maintained with the same or less time and resources.
The math just doesn’t work.
So what’s the answer? A test automation application that uses a data model instead of code.
Now, you should be saying to yourself “Well of course she thinks that’s the answer. She’s a vendor and has a product she wants to sell, so her opinion is suspect.” And you would be partly right.
You would be right in that I am a vendor and do have a product to sell. I founded a company that markets a product that does exactly what I am describing. But I have also taught training classes, tutorials and seminars on how to build one yourself, and have had many successful students who were able to use the tools they had at hand to make it work.
But you would be wrong that my opinion should be suspect as a result. In fact, you should be even more skeptical if I didn’t have such a product, because it would mean I was one of those people who teaches about things I’m not capable of doing. If I hadn’t developed it, how could I be so certain that it works? What value would my opinion have if I had not put it to the test?
The bottom line is not whether or not you buy my product, it’s whether you buy what I’m saying
If you do, then your options are to do it yourself, buy it from Worksoft, or buy it from someone else. And if you decide to do it yourself because you already have an investment in a tool or because your application is not a good fit, I’ll do all I can to help you. Your choice.
What you have is a tool and what you need is an application.
What’s the difference? Let’s use an analogy. Imagine that my accountant is keeping the books in a spreadsheet and, naturally, it is taking too long and he is making too many mistakes. So, I decide that automation is the answer. Would I record the current manual process and try to replay it every month? Would I buy him a compiler and expect him to develop an accounting system on the side, while he continues to keep the books by hand? Would I hire programmers to develop an accounting system for him?
I’m sure you are thinking – you should be, anyway – that all of these options are comical. The obvious thing to do is to buy an accounting application.
Now just substitute “tester” for “accountant” and “testing” for “accounting”, and you get the picture of why test automation has failed. Companies think they are buying a test automation application when what they are buying is a tool that lets them choose one of the above three options. They have no idea what they are getting into.
Recording a manual task does not make it automated. It is simply a stream of events at a given time without structure, logic or documentation. We test software because it changes, and maintenance of these sessions is difficult to impossible. Capture/playback is a marketing technique, not an implementation one.
Expecting manual testers to design and develop their own application while they are also required to meet schedules for the application under test is also absurd. And the best testers usually aren’t programmers anyway, so you need additional resources and skills to even attempt it.
But while buying a test automation application is an obvious answer, testing is not as easy as accounting. Accounting rules are standardized, testing isn’t. There is a never-ending mix of technologies, architectures, languages, and functionality that makes it impossible for one test automation application to handle all possibilities.
Or does it?
What made SAP so successful was the idea that functionality can be represented as a data model instead of as code. Instead of each customer developing their own custom applications because their processes were unique to them, SAP allows them to buy a packaged application and then customize it…without writing any code except perhaps in fringe cases.
And therein lies the core difference between a tool and an application: code versus data.
With a test recording and scripting tool, code is accumulated. Whether it is recorded, generated or developed, it must be managed and maintained. The problem is that application functionality expands over time, but the time and resources dedicated to testing are either flat or declining. This means more and more test code must be created and – especially - maintained with the same or less time and resources.
The math just doesn’t work.
So what’s the answer? A test automation application that uses a data model instead of code.
Now, you should be saying to yourself “Well of course she thinks that’s the answer. She’s a vendor and has a product she wants to sell, so her opinion is suspect.” And you would be partly right.
You would be right in that I am a vendor and do have a product to sell. I founded a company that markets a product that does exactly what I am describing. But I have also taught training classes, tutorials and seminars on how to build one yourself, and have had many successful students who were able to use the tools they had at hand to make it work.
But you would be wrong that my opinion should be suspect as a result. In fact, you should be even more skeptical if I didn’t have such a product, because it would mean I was one of those people who teaches about things I’m not capable of doing. If I hadn’t developed it, how could I be so certain that it works? What value would my opinion have if I had not put it to the test?
The bottom line is not whether or not you buy my product, it’s whether you buy what I’m saying
If you do, then your options are to do it yourself, buy it from Worksoft, or buy it from someone else. And if you decide to do it yourself because you already have an investment in a tool or because your application is not a good fit, I’ll do all I can to help you. Your choice.
posted by WorkSoft
at
1:31 PM
0 Comments
