E s s e n t i a l f o r s o f t w a r e t e s t e r sTE TERSUBSCRIBE
It’s FREE for testers
August 2014 v2.0 number 28£ 4 ¤ 5/
Including articles by:
Sakis Ladopoulos Intrasoft International
Sakis Ladopoulos Intrasoft International
Sakis Ladopoulos Intrasoft International
Sakis Ladopoulos Intrasoft International
Testing in the lead
This issue of Professional Tester is sponsored by
Including articles by:Henrik Rexed NeotysGregory Solovey and Anca Iorgulescu Alcatel-LucentNick Mayes PAC UKNormand Glaude ProtecodeEdwin van Vliet SupridaSakis Ladopoulos Intrasoft International
21PT - August 2014 - professionaltester.com
Testing in the lead
A few years ago, there was some debate about whether large enter-prises, governments, etc. should buy and become dependent upon systems and services that included free software components. The debate was too late, because they already had
and were. Concerns about quality and security, while valid, could not stand in the light of experience which shows that, while both have defects, so far, free software has proven to be at least as good as proprietary software at (i) not having them; (ii) having them found; and (iii) getting them fixed fast. Point (ii) is also logically obvious: general availability of the source code enables third parties to use a whole array of powerful test techniques not available without it.
So, the use of complete third-party free software components is generally beneficial, but it does create a prob-lem. This problem is something that should send a shiver down your spine when you realise its implications: code reuse, as every tester knows a rich source of defects, even more so when the reused code is someone else’s.
Does the product you are testing include code copied and pasted from free software source, plumbed in, and maybe hacked about a bit? What if it is defective? What if some of those defects are security vulnerabilities? You may think that an update from the original provider will fix it, but that’s only if you keep up with the updates. Either way, that code is sticky. You need to know, urgently, what it is, from where it came, and if possible, from what version. I’ll discuss how that can be done below, but first let us look at the implications of its presence.
What to do about suspect third-party codeFirst, find the origin of the third-party code and try to track its latest version. If it is the same as your code, minus the plumbing and hacking (and you understand the plumbing and hacking and are certain your developers did it),
Open but hiddenby Normand Glaude
Normand Glaude on a testing responsibility and technique you may have missed
From where did the code you are testing come?
22 PT - August 2014 - professionaltester.com
Testing in the lead
chances are you are current and will not learn much from the history of the code. Document your finding for repeatability.
If the code is different, whether or not you understand why, research the history of known defects in the product from which the code came. The release history may well inform easy tests for the most critical defects. But remember that testing can show only presence, never absence, of defects: those tests passing does not mean that the code is OK.
So, you must apply also whatever structural test techniques are, and to the greatest extent, available to you: use static and dynamic analysis
not to assess quality of the code, but to create test cases, with expected outcomes of which you are confident, and implement and execute those test cases, using unit test frameworks, debugging tools or instrumentation code as necessary.
Finally, revise your functional test plan in the light of the new information. Identify the tests most likely to exercise the suspect code. Trace them back to the requirements they were designed to assure. Now, using what you know about known defects in the product from which the code came, apply the fundamental technique error guessing to design additional tests to assure those requirements.
Is your product legal?The use of other people’s code comes with conditions, as defined in the licence of the product from which it came: many different licenses exist, and by their nature they often prove to be incompat-ible with business objectives. The first thing to establish is what licences apply and what conditions they require. For example, the MIT licence is one of the most permissive: to paraphrase, it says “you can do anything you like with this code except hold anyone else respon-sible for it”, but most forms of it also include the following statement:
“The above copyright notice and this permis-sion notice shall be included in all copies or substantial portions of the Software.”
Figure 1: Protecode reporting
Testing in the lead
If your product contains even a small fragment of code from another product released under such a licence, but does not include the copyright notice, you are in breach.
Most free software licences include more conditions. For example, the very widespread GPL licence uses the popular method “copyleft” which requires anything derived from anything it covers to inherit the same licence. In other words, if your product contains any GPL code, your product is also GPL and you must release its source code! If you don’t want to do that, you need to replace the GPL code. Now – before anyone finds out.
You may even discover that your prod-uct contains proprietary code – source or executable – which is not validly licenced at all.
Some code is also affected by other legal restrictions, eg export licences. For example, if your product borrows encryp-tion routines (one of the most frequently reused functions) it may be illegal to distribute it in certain countries.
Identifying reused codeSo, how to find the reused code in your codebase? Some instances, especially more substantial ones, may be revealed by design documentation and change management information, or by talking to programmers.
But, it is likely that some instances will not have been recorded nor remembered. My company’s product Protecode (see figure 1) detects these by scanning the product, both source and complied code. In a simi-lar way to how an antivirus program looks
for known code, Protecode compares the target code with its vast database contain-ing details of hundreds of millions of files. Importantly, the comparison is based on structure, not text equivalence, so it can find even code which has undergone a great deal of change.
As well as telling you from what product and version range your code came and whether it has been modified, Protecode uses the U.S. Government’s National Vulnerability Database (see http://nvd.nist.gov retrieved 12th August 2014 1400hrs UTC) to alert you to known vulnerabilities in those product versions, and reports exactly what licences and other restric-tions are in effect. Using it, testers can detect defects and risks associated with code reuse immediately they arise at any time, including very early in the lifecycle
Normand Glaude is chief operating officer at Protecode (http://protecode.com)
VISIT www.eurostarconferences.com OR
CONTACT [email protected] FOR MORE INFO
JOIN US AT EUROPE'S LARGEST
SOFTWARE TESTINGCONFERENCE & EXHIBITION60+ Sessions Including 6 Keynotes • 5 Full-Day Tutorials6 Half-Day Tutorials • 40 Track Sessions • 3 Workshops
BOOK BEFORE SEPTEMBER 26TH TOAVAIL OF THE EARLY BIRD DISCOUNT
