Testing SOA

Il Software Engineering Institute (SEI) ha pubblicato un report sul testing in architetture Service Oriented (SOA).

Il report comprende 65 raccomandazioni per affrontare i problemi specifici delle architetture SOA.

Chi fa testing

da Joel on Software:

"Who should be a tester? That’s tricky! Software testing is one of those careers that isn’t that well known, so a lot of people who would be great at testing and would probably enjoy it a lot never consider applying for jobs as testers.

Signs of a good tester:

• Scientific
• Loves a good puzzle, even the kind that takes days to solve
• Likes to think about things methodically
• Generally likes working with software and computers

[...] Since testing can be taught on the job, but general intelligence can’t, you really need very smart people as testers, even if they don’t have relevant experience. Many of the best testers I’ve worked with didn’t even realize they wanted to be testers until someone offered them the job."

Automation Paradox

"when a Metro subway train rammed into another train in Washington, D.C. last June, designers had to confront the unpleasant reality that automation may have been the cause.
The accident, which killed nine people and injured 80, may have been rooted in a computer malfunction and the operator’s inability to manually apply the brakes quickly enough.
The Metro train accident lies at the heart of what human factors experts refer to as the “automation paradox.” As automated systems become increasingly reliable and efficient, the more likely it is that human operators will mentally “switch off” and rely upon the automated system. And as the automated system becomes more complex, the odds of an accident or mishap may
diminish, but the severity of a failure is often amplified."

"Making Automation Work", di Samuel Greengard, in Communications of the ACM, dicembre 2009

Come rompere il software

How to break software. A Practical Guide to Testing, di James A. Whittaker, Addison-Wesley 2002.
Poca teoria, tanta pratica, suggerimenti concreti, anche un CD con tool per simulare problemi (poca memoria, connessioni interrotte, hardware mal funzionante...) nell'ambiente che ospita le applicazioni da testare. Testo utile e ben scritto.

Princìpi di software testing (Meyer)

Da un articolo di Bertrand Meyer, uno dei nomi più importanti nel campo del software design:

• Principle 1: Definition. To test a program is to try to make it fail.

• Principle 2: Tests versus specs. Tests are no substitute for specifications.

• Principle 3: Regression testing. Any failed execution must yield a test case, to remain a permanent part of the project’s test suite.

• Principle 4: Applying oracles. Determining success or failure of tests must be an automatic process.

• Principle 5: Manual and automatic test cases. An effective testing process must include both manually and automatically produced test cases.

• Principle 6: Empirical assessment of testing strategies. Evaluate any testing strategy, however attractive in principle, through objective assessment using explicit criteria in a reproducible testing process.

• Principle 7: Assessment criteria. A testing strategy’s most important property is the number of faults it uncovers as a function of time.

Su alcuni di questi princìpi (in particolare sull'ultimo) ho dei dubbi. Ma vale la pena di leggere l'articolo (su IEEE Computer, agosto 2008), per chi ha la possibilità di accedere alla rivista (che consiglio).

Software perfetto

"Perfect Software and other illusions about testing". È un libro di Gerald Weinberg, uscito da poco.

Tra tutte le attività collegate al software, il testing è l'attività più fraintesa. Anche dai professionisti dello sviluppo.

Il libriccino è sottile, scritto bene, si legge in fretta, non entra in dettagli tecnici. Un'ottima introduzione alla realtà del testing, per chiunque lavori in un progetto, per i manager, per i committenti. Anche per chi di software sa poco o nulla.

Un consiglio sentimentale

Da Ward Cunningham, sulla mailing list software testing. Cunningham è, tra le altre cose, ideatore del Wiki, di FIT - Framework for Integrated Testing, e di Extreme Programming. Ecco il consiglio:

'I have found that the world is the way it is for reasons very different from those often given as explanation. If you want to change the world, you need to understand all the forces that apply, and especially forces that are in flux. Then you stand a chance.

I don't, however, recommend that you debug your spouse. An old and wise friend of mine, who is still married to his high school sweetheart, says, "you have to decide, do you want to be right? or do you want to be loved?" '

The Chimera of Software Quality

by Les Hatton, in IEEE Computer, August 2007.

"Nobody knows how to produce a fault-free program. Nobody even knows how to prove it even supposing one we were magically provided. I teach my students that in their whole careers, they are unlikely ever to produce a fault-free program and if they did, they would never know it, they could never prove it and they could not systematically repeat it. It provides a usefully humble starting point.

[...] I've analysed enough failed systems in my time to know that there are two classic symptoms of a system on its way to the fairies. First, no independent audit is allowed and second, talking heads tell you everything is fine when the ultimate users tell you the opposite.

[...] The Linux kernel is now arguably the most reliable complex software application
humanity race has yet produced, with a mean time between failures reported in tens and in some cases, hundreds of years. Poetically, the development environment of Linux, which leverages the contributions of thousands of Web volunteers who give their spare time for the public good, breaks just about every rule which software process experts hold dear."