The Clock is ticking

Nelle mie letture serali ho trovato un articolo ( di Thanh Huynh nel sito https://www.asktester.com) molto bello sul tema: "Non C'è mai abbastanza tempo..." è oramai un frase, un pensiero, uno stress che abbiamo tutti in tutti gli ambiti sia lavorativi che personali... Un piccolo esempio di vita quotidiana:

andare al cinema...

lo spettaccolo inizia alle 20, occorrono circa 30/40 minuti per raggiungerlo con i mezzi e devo contare di arrivare un pelo in anticipo per gestire eventuali file alla biglietteria, per cui devo partire verso le 19 da casa e lo spettacolo finisce alle 22.30 ed i ristoranti stanno chiudendo quindi come facciamo per la cena?

se questo capita per una cosa così banale sarà anche peggio nella vita lavorativa dove si devono rispettare scadenze, kpi etc etc.

L'articolo comincia con una verità..."Va bene NON eseguire tutti i casi di test.", lo dice anche la ISTQB  nei 7 princpi del testing il test esaustivo è impossibile, bisogna imparare a prioritizzare:

 Molto spesso, quando si prepara un piano di test, abbiamo una serie di casi di test che dobbiamo eseguire per i test di regressione. Si teme che, se non si eseguono questi casi, ci sfugga "qualcosa"... e nel test del software, la mancanza di difetti si trasforma molto probabilmente in un incubo per il tester.

Sono d'accordo sul fatto che l'esecuzione di tutti i casi aiuta a rafforzare la fiducia nella qualità della build in fase di test. È anche vero che l'esecuzione di un maggior numero di test riduce la possibilità di difetti mancati. Tuttavia, se si esaminano nuovamente i casi di test, ci sono sempre casi di test più importanti da eseguire rispetto agli altri. Anche tra i casi di test importanti, ce ne sono di ancora più importanti degli altri.

Detto questo, in generale non è necessario gestire tutti i casi. È sufficiente assicurarsi che i casi più importanti siano coperti e che siano ben informati o concordati.

Per ottenere questo risultato, potreste provare tecniche come i test basati sul rischio, i test esplorativi, gli smoke test o le checklist.
...ed essere informati

E a proposito, quando pensate di ridurre i test, non abbiate paura di informare i team che non siete in grado di eseguire una regressione completa.

 un'altro bel concetto che compare è :

"La qualità del software è ben lontana dalla semplice esecuzione di una serie di test."

Potete eseguire tutti i casi di test e il vostro prodotto è ancora un rottame. Lo stesso vale quando non è necessario eseguire alcun caso di test e si ha comunque un software di qualità (ok, con un po' di fortuna :D). Ciò significa che sono molti gli aspetti che contribuiscono alla qualità di un prodotto, non solo i test, non solo il team di test.

In questo caso, come tester, è naturale informare i team che non è possibile eseguire una regressione completa e condividere il nuovo piano di test di conseguenza. Quando le cose sono informate e concordate, siete a posto.

inoltre hai già pensato all'automazione?

Se i vostri test di regressione sono ripetuti e vengono eseguiti manualmente, potreste volerli automatizzare per velocizzare i vostri test nel lungo periodo. Anche se l'automazione dei test costerà del tempo, che al momento non è molto, se si fa bene l'automazione sarà la vostra arma più potente quando si tratta di test di regressione.

Se state eseguendo un test di automazione funzionale, concentratevi sulle suite di test valide e ripetute. Non ha molto senso scrivere script automatizzati ed eseguirli solo una volta nella vita, altrimenti non aggiungono (molto) valore.

 ancora, sai gestire le tue attività?

a quante riunioni partecipi? è davvero necessaria la tua presenza? quante cose "impreviste" ti fai e che possono rallentarti? hai provato ad usare la tecnica del pomodoro?

Le crisi sono sempre un ottimo momento per fare retrospezione e miglioare, per cui se nonostante tutti i suggerimenti  di sopra forse è il caso di pensare a cambiare il processo di test

Dopo aver rivisto il piano di test e averne ridotto l'ambito, si ha ancora la sensazione che il carico di lavoro sia elevato. Questa è una buona occasione per rivedere il vostro processo di test.

È interessante notare che è l'ultima cosa che i tester/team di test esaminano quando non hanno abbastanza tempo per testare. Perché? Perché: 1) cambiare il processo è difficile e 2) non pensano che sia un problema di processo perché "è quello che facciamo da anni".

So che non sarà facile, ma esaminando il vostro processo di test capirete dove va a finire il vostro tempo o dove è il vostro collo di bottiglia

 

ecco il link all'articolo completo