Puntuale ogni sei mesi è uscito il nuovo aggiornamento di Technology Radar, un documento che spiega quali sono i cambiamenti più interessanti in ambito Software Development secondo ThoughtWorks e che ci aiutano a capire quali saranno le tecnologie di software testing da adottare nel 2020. Sono quindi quei temi sui quali vale la pena informarsi o addirittura considerarne l'utilizzo in un progetto. A redigere questo report c'è un gruppo di circa 20 senior technologist di ThoughtWorks, chiamato TAB.
Il radar consiste nel tracciare tutte le tecnologie e le tecniche che giocano un ruolo nello sviluppo del software. Questi elementi, che ThoughtWorks chiama blips (segnali lampeggianti), vengono categorizzati in quadranti e in cerchi. I quadranti rappresentano le diverse tipologie di segnale, mentre i cerchi indicano a quale grado di adozione il TAB pensa che siano.
I quadranti si suddividono in:
- Programming Languages and Frameworks
- Tools (componenti, database, strumenti di sviluppo software, ecc)
- Platforms
- Techniques (include elementi del processo di sviluppo del software, come l'experience design, modalità di strutturazione del software come i microservizi, ecc)
Anche gli anelli sono 4:
- Adopt: sono quei blip che secondo ThoughtWorks dovrebbero essere presi in seria considerazione dai developer. Se un blip si trova nel raggio di adopt, non c'è dubbio che non sia pronto per l'uso.
- Trial: sono quei blip pronti all'uso ma non sono così collaudati come quelli che finiscono in Adopt. La raccomandazione qui è di provare questi strumenti per decidere se integrarli o meno.
- Assess: qui ci sono quei blip da tenere d'occhio, ma non vanno ancora necessariamente provati, a meno che non siano particolarmente interessanti e utili per il proprio processo.
- Hold: sono i blip che, anche se sono stati accettati dall'industria, ThoughtWorks non ha avuto una buona esperienza nel provarli. Questo può accadere perché non sono ancora abbastanza maturi, ma è bene avere un occhio per questi elementi che potrebbero tornare ad attaccare l'industria con più decisione.
Il quadrante che abbiamo deciso di esplorare è quello delle tecnologie. Diamo un occhio ai blip da adottare:
- Container security scanning: è nel radar da novembre 2016 ma solo tre anni dopo è passato ad Adopt. I container per il deployment hanno visto negli ultimi tre anni un'adozione continua, e in modo particolare con l'arrivo di Docker questa tecnologia è diventata necessaria. (Clicca qui per saperne di più sul Docker Security Scan Process)
- Data integrity at the origin: è un nuovo arrivo nel radar, andato direttamente in Adopt. Generalmente i dati entrano in pipeline da diverse fonti, vengono puliti e poi spostati da un'altra parte per essere consumati. Questo processo ha in origine la difficoltà di verificare l'integrità dei dati, per questo ThoughtWorks raccomanda che le fonti che forniscono i dati descrivano e garantiscano le misure di data quality.
- Micro frontends: già da novembre 2016 ThoughtWorks aveva visto un beneficio significativo nell'introduzione delle architetture di microservizi. La popolarità dei micro frontends ha continuato a crescere da quando sono stati introdotti, e da aprile di quest'anno sono passati ad Adopt.
- Pipelines for infrastructure as code: entrati nel radar esattamente due anni fa, quest'anno sono stati finalmente inseriti in Adopt grazie alla loro abilità di far trovare errori prima che questi vengano applicati ad ambienti operativi, come quelli utilizzati per lo sviluppo ed il testing.
- Run cost as architecture fitness function: un anno esatto da Trial ad Adopt. I team possono osservare il costo dei servizi gestiti versus il valore prodotto. Quando ci sono deviazioni da quanto atteso o quanto considerato accettabile, il team discute se può valere la pena far evolvere l'architettura. L'osservazione e il calcolo del costo di gestione sono implementati come una funziona automatizzata.
- Testing using real device: questo tema è quello che ci interessa particolarmente. E' la prima volta che entra nel radar e ci entra direttamente in Adopt:
"When adopting continuous delivery (CD) successfully, teams strive to make the various test environments look as close to production as possible. This allows them to avoid bugs that would otherwise only show themselves in the production environment. This remains just as valid for embedded and Internet of Things software; if we don't run our tests in realistic environments we can expect to find some bugs for the first time in production. Testing using real devices helps avoid this issue by making sure the right devices are available in the CD pipeline." - ThoughtWorks
Testare su device reali o simulatori è un elemento distintivo tra Testing Automation e Crowdtesting (qui abbiamo parlato delle differenze e di quando è meglio utilizzare l'una o l'altra tipologia). Testare su device reali significa chiedere ai tester (persone reali) di testare un prodotto digitale con i loro tablet, smartphone e pc (real devices) perché proprio questi dispositivi saranno poi utilizzati dall'utente finale dell'asset (app, sito, accessorio IoT, Chatbot, ecc).
Quali sono i dispositivi più diffusi sul mercato? Scarica qui il report!
Se non si testa su device reali, su cosa si testa?
Ci sono due tool: gli emulatori e i simulatori. Gli emulatori sono software che imitano l'hardware e il software del device scelto. Per farlo traducono l'ISA (Instruction Set Architecture) del dispositivo in quello utilizzato dal computer che funge da emulatore. I simulatori sono dei software che aiutano il computer a portare avanti dei programmi costruiti per diversi sistemi operativi. Sono più che altro costruiti per iPhone e iPad, mentre i dispositivi Android sono più semplici da emulare.Questa tabella rappresenta le differenze tra il test virtuale e quello su dispositivi reali. Ci sono però alcune precisazioni da fare.
Cost: Buying real devices at scale is cost prohibitive
Verissimo, è proprio per questo che esiste il Crowdtesting. Grazie a questo strumento, è possibile avere un numero infinito di device a portata di mano a un costo ridotto. Questo perché chi offre il servizio di Crowdtesting, come AppQuality, ha a disposizione una community di decine di migliaia di tester con i loro dispositivi reali pronti a testare sia lato funzionale che esperienziale. Questo abbassa enormemente i costi e permette di testare anche sui device appena usciti sul mercato.
Suitable for Debugging: Debugging with real testing devices could be tricky, especially while capturing defects
Anche qui ci sono delle precisazioni da fare. In AppQuality abbiamo una soluzione a questo problema, ovvero la nostra piattaforma Crowd e la nostra University. All'interno della piattaforma, i tester reali compilano i form in cui riportano un bug tramite descrizioni, screenshot e video. I bug trovati possono essere inviati tramite foglio Excel ma anche integrati ai sistemi più comuni, come ad esempio Jira. In questo modo, riportare un bug agli sviluppatori diventa semplicissimo, veloce ed efficace.
Fonte Radar: ThoughtWorks
Fonte tabella Real Testing Device vs Virtual Testing Device: Browserstack.com
