
Subscribe to
Computerworld April 02, 2003 (Computerworld) -- In case you don't know it, without automation, software testing is hopeless. The latest development tools and component libraries allow developers to develop so much functionality so fast that it is literally impossible, actually inconceivable, that you can test the finished applications by hand. Most test budgets are measured in fractions of development, so it's not like you can spend more time and people testing than you do developing.
Of course it's easy for developers to automate unit testing; after all, they have control of the source. They can use debuggers, instrument their code, insert breakpoints, whatever. But if you have ever tried to automate black box automated testing, you quickly discover that test tools can't drive applications whose components aren't strictly vanilla. Custom controls, third party components, complex objects within containers and just about any user-defined or modified object classes give test tools fits. They can't get the object names, let alone the methods and properties needed to interact with them. (Getting good names is a whole other storysee Smarter Tools, Dumber Developers.)
![]() ![]() |
|
| Linda Hayes is the CTO of WorkSoft Inc., developer of next-generation test automation solutions. She is the founder of three software companies and holds degrees in accounting, tax and law. A frequent industry speaker and award-winning author on software quality, she pioneered automated testing tools. Care to comment? Go here! |
So what's the problem? In my opinion, it's either ignorance, paranoia or pure laziness.
Ignorance because a lot of companies think that if they compile in a test hook, then do the testing, then remove it for shipment that they have not really tested the production code. This is nonsense. True, the production code does not have the same hook as the tested version, but so long as the source is otherwise identical between the two compiles the only difference is the test hook.
The key is that these hooks don't do anything unless called. They are usually just a DLL that lets the tool inside the application's process space so it can see the objects. They only provide information, they don't alter or create it. So, compiling the code without the hook should have zero effect on the application functionality.
But if you just can't shake this superstition, then leave the hook in when you ship. This is where paranoia comes in. Haven't you just created a security problem? After all, now someone could use that hook to spy on your software. To that I say, so what?
Let's face it. The newer runtime-based languages (Java, .Net) are basically interpreted anyway. You can reverse the original source code out to the letter. So don't kid yourself that someone might be able to somehow peek into your software just because of a hook. Good grief, there are OS security holes right now that let strangers across the globe take complete control of your whole computer and everything it is attached to.
If you are still really freaked out about it, then identify those objects that are high risk and make their methods and properties private. Even the hooks can't get into those. But for goodness' sake don't do it to any that are needed for interaction with user interface objects; since they are exposed to the user there can't be much to hide in the first place, and in the second place you'll cripple automation.
Which leads me to the last problem: laziness. I go nonlinear when I hear developers complain about the "effort" it takes to address automated testability. Last time I checked it takes only a few minutes to either add or remove lines of code, and since compilation is usually automated anyway it may take zero time after the initial setup. If you can't be bothered to invest a few precious minutes to save your company weeks or months of work, or to enable automation that could make a difference in orders of magnitude in quality or time to market, maybe you should just retire since you don't really want to work in the first place.
But in the final analysis, the reason doesn't really matter. The real question is not whether you should provide a test hook for automation, it is why would there even be a controversy in the first place. Why would management even contemplate, let alone tolerate, applications requiring manual testing that increases costs while reducing quality? Why aren't developers required to deliver test hooks as a matter of course? If you think about it, it's completely crazy to even argue about it. The benefits are so undeniable and the risks are so debatable that there should not even be a question, let alone a war.
Of course I could be wrong, but in 20 years of test automation I have never had or even heard of a test hook backfiring. Has anyone else?
|
|
Print this Story |
|
Send Us Feedback |
|
E-mail this Story |
|
Digg this Story |
|
Slashdot this Story |
|
|
|
|
|
|
|
|
|
|
All Zones Application Performance Zone Business Continuity Zone Data Center Management Zone Enterprise-Class Security Zone The File Data Management Zone Grid Computing on Windows Zone Security Management Zone ITIL Best Practices Zone The SAS Zone Storage Virtualization Zone Business Intelligence and Analytics Zone |
|
|
| ||||||||
| ||||||||
| ||||||||
|

Intercept Spam & Viruses With MessageLabs MessageLabs is offering a complimentary 30 day trial of its managed Anti-virus and Anti-spam security solutions. MessageLabs guarantees complete protection against all know and unknown email threats. By providing 24 hour support, your business can increase productivity and decrease risk. Register for a complimentary trial and receive a free datasheet.Download this white paper now!
|

| Detect, identify, and locate RF interference in 802.11 WLANs. AnalyzeAir software provides IT network professionals with the vision they need into the hidden world of RF, providing them with the ability to see the spectrum in a visible and intelligible format. AnalyzeAir software lets you see, monitor, analyze, and manage all the RF sources and wireless devices that influence your Wi-Fi network's performance and security, even if those devices are unauthorized or transient. AnalyzeAir Trial Software v3.1 highlights the features found in AnalyzeAir Software using a set of saved spectrum files. Replay the data and experience the visibility that AnalyzeAir Wi-Fi Spectrum Analyzer provides. Note: The trial software is limited to a player version only. It does not communicate with an AnalyzeAir PC card so it does not collect actual spectrum data. Register for this trial now.
|
| About Us Advertise Contacts Editorial Calendar Help Desk Jobs at IDG Privacy Policy Reprints Site Map |
|
CIO The Industry Standard |