Il documento esplora i test automatizzati con Serenity BDD, affrontando tematiche come la QA, i diversi tipi di test (funzionali e non funzionali) e l'importanza dell'automazione. Viene discusso l'approccio Agile alla QA e la percezione dei QA da parte degli sviluppatori, enfatizzando la responsabilità condivisa per la qualità del software. Infine, presenta Serenity BDD come strumento per test efficaci e reportistica, evidenziando le best practice e gli antipattern nella test automation.

1. DIEGO MAURICIO LAGOS MORALES
Test Automatizzati con
Serenity BDD

2. Agenda
Un po’ di teoria sulla QA ed i test
 Problematiche, antipattern e possibili soluzioni
QA stato dell’arte e evoluzione
TDD, BDD, ATDD (hai un problema con le sigle?)
Serenity BDD (aka Thucydides)
Demo time

3. QA e test automation
un po’ di teoria

4. Test Funzionali vs
Non Funzionali

5. Test Funzionali
Si occupa di verificare che l’applicazione sia
conforme alle specifiche
Che rispetti le richieste del cliente
Mantiene costante il valore del software
Descrivono in poche parole cosa faccia il prodotto
Esempi di test funzionali possono essere:
 Unit Testing, Smoke Testing, Sanity Testing, Integration
Testing, White box testing, Black Box testing, User Acceptance
testing, Regression Testing

6. Test Non Funzionali
Sono test focalizzati al modo in cui lavora l’applicazione
più tosto che al come
Hanno bisogno di metriche come specifiche
Vengono eseguiti dopo i test funzionali, ma per questo
non sono secondari
Esempi di test non funzionali possono essere:
 Baseline testing, Compliance testing, Documentation testing,
Endurance testing, Load testing, Localization testing and
Internationalization testing, Performance testing, Recovery testing,
Resilience testing, Security testing, Scalability testing, Stress testing,
Usability testing, Volume testing

7. A cosa serve il
test
automation
L’automazione può essere
considerata come una rete di
sicurezza
 Non trova nuovi bug
 Non sostituisce il valore umano
 Non è la panacea di tutti i mali
 Ci assicura soltanto un grado di
confidenza sullo stato del prodotto

8. Best practice nei test automatizzati
Test manuali
ed esplorativi
Test manuali
ed esplorativi
• Lenti nell’esecuzione
• Lenti al cambiamento
• Costosi
• Fragili
• Ma più vicini al business
• Lenti nell’esecuzione
• Lenti al cambiamento
• Costosi
• Fragili
• Ma più vicini al business
• Veloci
• Economici
• Isolati
• Più vicini allo sviluppo
• Ma più lontani dal business
• Veloci
• Economici
• Isolati
• Più vicini allo sviluppo
• Ma più lontani dal business

9. Nella cima della piramide Nella base della piramide
Si è concentrati sulle
funzionalità che danno
valore al business
Evito regressioni nel
valore
Documentazione
vivente
Basso costo nella
scrittura/manutenzion
e dei test
Aumento rapidità
feedback
Robustezza dei test
Evito regressioni nella
funzionalità
Punti di forza dell’automazione

10. Antipattern

11. Antipattern (1/2)
Ice Cream

12. Lato Business Lato Tecnologico
Antipattern (2/2)
piramide duale
Test manuali
ed esplorativi
Test manuali
ed esplorativi

13. Antipattern della piramide duale
Tra i due antipattern è il più insidioso
Hai la sensazione di star facendo bene
Duplichi i test
Lavori a silos (moooolto sbagliato)
Incongruenze e limita visione del progetto
Falsi Positivi
Varie ed eventuali….

14. Panoramica sulle problematiche
degli antipattern
Limitati, fragili
Hanno un’esecuzione molto lenta
Tempo di regressione molto alto
Alto costo
 per fix problemi
 per mantenimento (per evitare obsolescenza)
Non si ha la visibilità su ciò che si è testato
Difficoltà di individuazione dei bug dentro lo stack
Tempi di attesa alti per avere tutto lo stack
funzionante e coerente

15. QA in Agile ed in Google

16. Come sono visti i QA dagli sviluppatori

17. Come vedono i QA gli sviluppatori

18. QA in agile
1. Fare i test nel mentre invece di farli alla fine
2. Prioritizzare la scrittura dei test, invece di farli alla
fine
3. Prevenire i bugs invece di trovarli
4. Capire cosa si sta testando invece di verificare la
funzionalità
5. Costruire un sistema migliore invece di rompere il
sistema
6. Il TEAM è responsabile della qualità invece di
essere solo il QA ad essere responsabile

19. QA in Google
Il team si incarica della qualità
I developer devono aiutare nel test
Creazione di un unico linguaggio condiviso (UL)
I tester hanno lo scopo di rendere più produttivi gli
sviluppatori
La qualità non è uguale a testare
La qualità è un atto di prevenzione più di quanto sia
un atto di rilevamento
La qualità è un problema dello sviluppo non del
testing

20. HOUSTON, ABBIAMO UN PROBLEMA
TDD, BDD, ATDD, *DD

21. TDD (test driven development)
Si orienta allo sviluppo (xUnit test)
Si focalizza nella creazione di test
prima ancora della funzionalità
I test guidano lo sviluppo
I suoi benefici ultimamente vengono messi in
discussione

22. BDD (behavior-driven development)
Evoluzione del TDD
Orientato all’integrazione e al business
Sfrutta le best practice del DDD
Permette la creazione di strumenti e processi
condivisi
Consente la creazione di documentazione viva della
nostra applicazione
Utilizza un linguaggio il più vicino a quello naturale

23. BDD
(esempio con JBehave)

24. As Is To Be
Utilizzo di Jbehave
Creato dall’inventore
del BDD (Dan North)
Molto completo e
robusto
Solo piattaforma JVM
Utilizzo di Cucumber
Multi piattaforma
(ruby, js, java, ecc..)
Progetto molto attivo
ed ampiamento
utilizzato
BDD tools

25. ATDD (Acceptance test-driven development)
Non è una vera tecnologia, ma un processo
Coinvolge tutto i team
Utilizza i criteri di accettazione ed esempi come
strumenti
Si concentra di più sulle esigenze del cliente
Molto spesso può essere confuso oppure integrato
direttamente con il BDD

26. Serenity BDD

27. Cos’è Componenti
Serenity BDD helps you
write better, more
effective automated
acceptance tests, and use
these acceptance tests to
produce world-class test
reports and living
documentation
Jbehave o Cucumber
(BDD)
Serenity BDD
 Integrazione con i vari
moduli
 Reportistica
Selenium
Java
Cos’è Serenity BDD

28. Serenity BDD
Serenity + SeleniumJBehave
Architettura di Serenity BDD
Story (BDD)
Implementazione
Story in java
Flow Steps
Serenity Page
Object
Web Page
Reportistica

29. Demo time di Serenity

30. Risorse (1/2)
1. http://googletesting.blogspot.it/
2. https://josepablosarco.wordpress.com/
3. http://www.xoriant.com/blog/software-testing-
and-qa/extended-role-qa-test-driven-
development-tdd.html
4. http://martinfowler.com/tags/testing.html
5. http://mkolisnyk.blogspot.it/2013/03/jbehave-vs-
cucumber-jvm-comparison.html

31. Risorse (2/2)
1. http://thucydides.info/docs/serenity-staging/
2. Esempi di Serenity e Thucydides:
1. https://github.com/serenity-bdd/serenity-demos
2. https://github.com/thucydides-webtests/thucydides-
smoketests