Per l’integrazione continua non bastano gli strumenti. Ecco cosa serve: ContinuousIntegrationCertification, di Martin Fowler e Jez Humble.
Archivi categoria: testing
InfrastructureAsCode
Una gestione dei server e dell’infrastruttura di rete che riduce al minimo l’intervento umano, definendo le configurazioni tramite script, con sistemi e processi auto-documentati e sottoposti continuamente a test automatizzati.
InfrastructureAsCode, di Martin Fowler.
Diagrammi di stato per applicativi web
Usare la logica delle macchine a stato per rappresentare e testare gli applicativi web: Testing Web Applications with State Objects, di Arie Van Deursen su Communications of the ACM, August 2015.
Heuristic Test Strategy Model
Per progettare casi di test, l’ottimo Heuristic Test Strategy Model di James Bach: https://t.co/3nNwxeQ2lR
Scuole di software testing
Il software viene testato troppo poco. Almeno, questo è ciò che ci viene da pensare quando funziona male.
Ma qual è il modo migliore di testarlo? Testare un software critico per la vita umana è un conto; il sito web di un’associazione tra amici comporta di solito meno rischi, anche quando ha dei problemi.
Per il testing si possono adottare diversi approcci organizzativi e tecnici, diverse strategie, diverse tattiche, diversi strumenti.
Per evidenziare affinità e differenze, anni fa alcuni esperti identificarono quattro “scuole” di software testing: l’analitica, l’industriale, la “Quality Assurance”, e infine la propria, “Context-Driven”. L’esistenza e la caratterizzazione delle quattro scuole si possono leggere nella presentazione del 2003 “Four Schools of Software Testing“, di Bret Pettichord.
La “Context-Driven School“, in particolare, affermava che la scelta del processo, delle strategie, delle tattiche e degli strumenti varia in modo sostanziale a seconda del contesto in cui ci si trova: quale tipo di prodotto, in quale mercato, per quale tipo di utenti/clienti, in quale situazione organizzativa.
Un recente e interessante dibattito tra due tra i maggiori esperti di software testing, Rex Black e Cem Kaner, ha discusso se la distinzione in “scuole” sia ancora utile, o non sia soprattutto un argomento usato da alcuni consulenti per promuovere le proprie attività denigrando quelle di altri. Probabilmente entrambe le cose sono vere, come emerge dal video del dibattito: http://kaner.com/?p=437 .
Test: end-to-end
Sul Google Testing Blog: “Just say no to more End-to-End tests“. Interessanti l’articolo e le critiche, tra cui “Making End-to-End tests work“, di Adrian Sutton.
Exploratory Testing 3.0
Una ridefinizione della pratica di testing esplorativo è stata proposta da James Bach e Michael Bolton , per superare la distinzione tra il “testing guidato da script” e, appunto, il “testing esplorativo”:
we now define all testing as exploratory. Our definition of testing is now this:
“Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modeling, observation and inference, output checking, etc.”
Secondo il loro punto di vista, il testing guidato da script può essere solo uno strumento tattico da usare in particolari situazioni, ma è come un ospite in casa d’altri, un elemento estraneo al vero e proprio testing.
Mocks, Stubs, Spies, Fakes
Mocks, Stubs, Spies, Fakes. Sono tutti Test Doubles, cioè porzioni di codice usate per agevolare lo unit testing, quello praticato dagli sviluppatori per verificare una porzione limitata di codice, un singolo mattoncino.
Sono termini propri del testing “white box”, che richiede a chi lo effettua di conoscere il codice che sta testando (a differenza del testing “black box”, che non richiede la conoscenza del codice, e che viene praticato normalmente da chi non ha sviluppato).
Un intervento di Robert Martin sotto forma di dialogo spiega in modo chiaro la differenza tra i diversi tipi di Test Doubles: The Little Mocker.
Test Driven Development: indispensabile?
Nelle ultime settimane si è sviluppata una discussione in merito al Test Driven Development (sviluppo guidato dai test, una pratica che prevede la scrittura dei test prima della scrittura del codice necessario a superarli).
Iniziata con un intervento di David Heinemeier Hansson, l’ideatore di Ruby on Rails, la discussione sta coinvolgendo alcuni tra i migliori esperti di software design, come Robert Martin, Kent Beck e Martin Fowler. Tra Heinemeier Hansson, Beck e Fowler sono in corso dialoghi interessanti: uno , due , tre (e successivi).
Software Testing su IEEE Computer
Il software testing è il tema centrale in IEEE Computer di febbraio 2014, con articoli sul testing di web services, sul penetration testing, sul testing combinatorio e su quello di applicazioni mobili.