testing

Ho pubblicato una breve presentazione dello standard ISO 25010 “Systems and software engineering - System and software quality models”, uscito nel 2011.

ISO 25010 fornisce una classificazione di requisiti non funzionali (o “attributi di qualità”) che sostituisce quella del precedente standard ISO 9126. La nuova classificazione distingue tra requisiti sulla qualità intrinseca del prodotto (“product quality”) e requisiti sulle caratteristiche inerenti all'uso del prodotto (“quality in use”).

Solo quando il software viene effettivamente usato dagli utenti possiamo sapere se a loro va bene o no. Ovvio, no?

Tutte le attività di testing che facciamo prima del rilascio, comprese quelle di far usare il sistema a "utenti proxy" (cioè non agli utenti reali, ma a persone che vorrebbero rappresentare gli interessi degli utenti reali), non ci possono dare la certezza del fatto che il software sarà davvero apprezzato.

Possiamo fare ipotesi, speculazioni, ragionare in termini di probabilità. Ma la realtà verrà fuori solo dopo il rilascio.

Elisabeth Hendrickson ne parla in "What Software Has in Common with Schrödinger’s Cat".

Il Software Testing Forum si è tenuto a Milano il 20 e 21 giugno 2011, organizzato da ITA-STQB e BCI Italia.
Sul sito sono disponibili una serie di video degli interventi, da cui risulta una immagine parziale ma significativa dello stato del software testing in Italia.

Cem Kaner è uno tra i massimi esperti di testing ed è autore dei corsi online della Association for Software Testing. Ha recentemente pubblicato una ricca bibliografia sulle tecniche di testing.

"Inondare un progetto con gli unit test non è il modo giusto per testarlo bene", è la provocazione di Cedric Beust, ideatore del framework di testing TestNG.

I test unitari, cioè quelli che verificano il comportamento di un singolo mattoncino software preso isolatamente, non bastano. Anzi:

"Gli unit test sono un lusso. A volte, potete permettervi un lusso; altre volte, dovreste aspettare un momento migliore e concentrarvi su qualcosa di più essenziale - come la scrittura di un test funzionale."

I test non deterministici producono ad ogni esecuzione un risultato imprevedibile, in quanto determinato da fattori al di fuori del controllo di chi ha progettato il test, come ad esempio il momento dell'esecuzione o la concorrenza di risorse con sistemi diversi da quello testato.

Un effetto negativo della presenza di test non deterministici è che la loro presenza in una suite di test automatizzati rende ogni esecuzione della suite di difficile interpretazione.

Su come gestire i test non deterministici, un articolo di Martin Fowler.

I test di usabilità non possono essere completamente automatizzati, ma l'automazione può essere di aiuto. Una serie di esperienze recenti presso Google e eBay con l'uso di WebDriver (ora parte della suite open source Selenium), in un articolo di Julian Harty su Communications of the ACM, February 2011: "Finding Usability Bugs with Automated Tests".

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.

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."

"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