Oracolo del test - 3 abitudini che dovremmo perdere

Ciao,

oggi vi propongo la traduzione di un articolo molto interessante:

L'industria del software ha attraversato molte innovazioni ed evoluzioni. Ci sono stati più modelli, cicli e strutture, come cascata, V-Model, agile e le sue diverse varianti, e altro ancora.

Ci sono stati tentativi di standardizzare i test, ma sono stati contestati dalla comunità di test. I tester ritengono che sia una buona cosa che non ci siano standard e che praticano molte forme di test, inclusi test in produzione, gestione test basata su sessioni, test esplorativi e sviluppo basato su test e comportamento.

Ma anche con pratiche diverse, i test si evolvono e diventa chiaro che alcuni concetti a cui siamo abituati a fare non sono più applicabili oggi. È pericoloso continuare a fare qualcosa solo perché è il modo in cui lo abbiamo sempre fatto, quindi è importante fare periodicamente un bilancio delle nostre pratiche di test e scegliere quelle che non hanno più senso o che sono addirittura dannose.

Ecco tre pratiche di test comuni che è nel nostro migliore interesse smettere di fare.

1. Valutazione delle prestazioni basata sul conteggio degli errori
Se i tester vengono giudicati dagli errori registrati e risolti, l'attenzione non è più rivolta a una migliore qualità del prodotto. Le persone sono ora più preoccupate di quanti bug sono stati trovati, e lo spostamento degli obiettivi entra in scena.

I tester iniziano a archiviare bug facili da trovare o a creare più segnalazioni di bug per ogni piattaforma, e gli sviluppatori iniziano a rifiutare bug tanto difficili da replicare o meno da bug. Il tester che stava spendendo molto tempo a progettare un buon test per un bug critico ora sta cercando il frutto a basso impatto. Lo sviluppatore che stava progettando una soluzione a lungo termine per creare un prodotto più robusto ora sta applicando correzioni a breve termine per i bug a bassa gravità.

Il conteggio dei bug da solo non racconta mai la storia completa. Sostituisci la parola "bug" con "idea" e il concetto è più chiaro: una persona ha cinque idee e un'altra ha due idee. Significa che quello con cinque idee è il miglior tester o programmatore? Senza capire quali sono gli errori o la complessità di trovarli o risolverli, non possiamo giungere a conclusioni soddisfacenti.

Quindi, come valutiamo le prestazioni dei tester ora?

Innanzitutto, è una buona idea parlare con il tester e creare un piano per le competenze che aiuteranno sia loro che l'azienda. Se il tester non ha mai testato un'app mobile e il tuo team potrebbe aver bisogno di un tester di applicazioni mobili nei prossimi mesi, questa può essere una buona opportunità per tutti.

Se vuoi misurare quantitativamente le abilità dei tester, puoi comunque misurarli. Devi solo essere il più specifico possibile elencando le attività che il tester dovrebbe essere in grado di eseguire e assegnare ad esso una tempistica concordata di comune accordo. Ad esempio, il tester dovrebbe essere in grado di trovare bug nell'interfaccia utente, nel database e nei livelli del server, utilizzare strumenti come X, Y e Z e compiere le seguenti azioni.

Questi tipi di obiettivi si concentrano sull'apprendimento e sulle abilità del tester invece di concentrarsi su un attributo specifico. Potrebbe essere più dispendioso in termini di tempo che concentrarsi solo sulla conta dei bug, ma è più prezioso e migliora sia l'individuo che l'azienda.

2. Le percentuali di superamento e superamento della suite di test
Qualsiasi tester che abbia trovato alcuni bug sa che la maggior parte dei bug si trova quando si discosta dalla sceneggiatura. Tuttavia, i team dedicano molto tempo allo scripting dei casi di test ben prima di interagire con il prodotto. Un singolo test può essere un passaggio su una condizione e fallire su più altre condizioni non documentate. Puoi persino avere una percentuale di passaggio del 95% e avere ancora un centinaio di bug da correggere.

Scrivere tutti gli scenari di test e avere un caso di test per ogni bug non è una grande idea. La parte più divertente è quando le decisioni si basano solo sulla percentuale di pass / fail. Le squadre fanno affidamento su queste percentuali, ma è una falsa speranza.

Faremmo meglio se ci sbarazzassimo della percentuale di passaggio / fallimento e ci concentrassimo sulla fiducia data dai team. Possiamo utilizzare dashboard a bassa tecnologia e avere valutazioni soggettive in termini di copertura (bloccata, sanità, profondità) e sicurezza (bassa, media, buona) e debriefing in base alle combinazioni. Dovremmo andare dal chiedere quanti test passano e quanti test falliscono e iniziare a chiedere: "C'è un problema qui?"

Ho iniziato a condividere la mia dashboard con un elenco di funzionalità e i problemi esistenti in ciascuna funzione. Questo ci consente di sapere cosa ci impedisce di rilasciare una funzionalità e se abbiamo coperto i casi di utilizzo critici.

3. Sottoscrizione da parte del team di test
È risaputo che la qualità è responsabilità di tutti. I tester possono attestare la propria quota di qualità da soli, ma non possono garantire la qualità dell'intero prodotto. Tuttavia, il team del progetto si aspetta che il team di test fornisca un segnale dopo il ciclo di test.

Esistono diversi modi per garantire la qualità del prodotto, ma è necessario un approccio a tutto il team:

Tutti sono d'accordo per una definizione comune di qualità accettabile e hanno punti di controllo misurabili per garantirli
Ogni squadra è responsabile per la loro parte della qualità e prende misure per garantire che il deliverable soddisfi gli standard di qualità
Le barriere tra i ruoli sono spezzate e specialisti lavorano insieme come una squadra e si assistono a vicenda
Tutti i punti di forza unici sono usati per creare una cultura vincente di squadra e tutti possiedono la qualità
Quando un rappresentante di ogni team è coinvolto nel processo decisionale e può visualizzare i risultati del test, possiamo essere più collaborativi e smettere di giocare ai giochi di colpa. Le idee di test vengono esaminate dallo sviluppatore e dagli analisti aziendali, mentre i test unitari vengono svolti dai team di sviluppo e i test di accettazione degli utenti vengono eseguiti dagli analisti aziendali. Ciò garantisce che tutti siano a conoscenza della qualità del prodotto e che la decisione di rilascio sia condivisa. Sia i team di sviluppo che di testing danno input al proprietario del prodotto e agli analisti aziendali e la decisione finale spetta al proprietario del prodotto. Il team di test non possiede il signoff.

Ho appena scalfito la superficie di migliorare il processo di test evidenziando i tre concetti che ritengo debbano essere aboliti. Che cosa si applica al tuo contesto e quali pratiche o concetti hai già abbandonato dalle tue routine?

fonte originale: https://www.stickyminds.com/article/3-testing-practices-we-should-all-stop