Introduzione
Buongiorno, cybernauti. Recentemente ho affrontato un compito di test per una posizione di QA Lead in una compagnia fintech. Il primo compito, redigere un piano di test con una checklist completa e esempi di casi di test per verificare un bollitore elettrico, si risolve in modo piuttosto triviale:
È difficile inventare un piano di test migliore con una checklist completa.
Ma la seconda parte si è rivelata una domanda: “Esistono problemi comuni a tutti i tester che ostacolano il lavoro con maggiore efficienza?”.
La prima cosa che mi è venuta in mente: elencare tutti i problemi più o meno evidenti che ho incontrato durante il testing, escludere le piccole cose e riassumere il resto. Ma ho capito rapidamente che il metodo induttivo risponderebbe a una domanda che si riferisce non a “tutti”, ma, al massimo, solo alla “maggior parte” dei tester. Quindi ho deciso di affrontare la questione da un altro punto di vista, quello deduttivo, e questo è ciò che ho ottenuto.
Definizioni
La prima cosa che di solito faccio quando affronta un compito nuovo è cercare di capire di cosa si tratta, e per questo devo capire il significato delle parole con cui è formulato. Le parole chiave da chiarire sono le seguenti:
- il problema
- tester
- lavoro del tester
- efficienza del lavoro del tester
Rivolgiamoci a Wikipedia e al buon senso:
(dal greco antico πρόβλημα) in senso ampio — una questione teorica o pratica complessa, che richiede studio e risoluzione; in scienza — una situazione controversa, che si presenta sotto forma di posizioni opposte nella spiegazione di fenomeni, oggetti, processi, e che richiede una teoria adeguata per la sua risoluzione; nella vita, un problema è formulato in modo comprensibile per le persone come 'so cosa, non so come', cioè è noto ciò che si deve ottenere, ma non è noto come farlo. Deriva dal latino tardo problēma, dal greco πρόβλημα 'lanciato in avanti, posto davanti'; da προβάλλω 'lanciare in avanti, mettere di fronte a se; accusare'.
Non ha molto senso, in sostanza, “problema” = “qualunque cosa con cui bisogna fare i conti”.
— specialista (non faremo distinzione, poiché ci interessano tutti i tester), coinvolto nel testing di un componente o di un sistema, il cui risultato è:
— un insieme di attività relative al testing.
(lat. effectivus) — rapporto tra il risultato raggiunto e le risorse utilizzate (:2015).
— conseguenza di una serie (catena) di azioni (risultato finale) o eventi, espressi qualitativamente o quantitativamente. I risultati possibili includono vantaggio, disagio, beneficio, perdita, valore e vittoria.
Così come per il 'problema', il significato è scarso: qualcosa che si è ottenuto alla fine del lavoro.
— possibilità misurabile quantitativamente di svolgere un'attività da parte di una persona o di un gruppo; condizioni che permettono di ottenere un risultato desiderato attraverso determinate trasformazioni. Un tester è una persona, e secondo la teoria delle risorse vitali, ogni persona possiede quattro attivi economici:
risorse finanziarie (reddito) — risorsa rinnovabile;
energia (forza vitale) — risorsa parzialmente rinnovabile;
tempo — risorsa fissa e fondamentalmente non rinnovabile;
conoscenze (informazioni) — risorsa rinnovabile, parte del capitale umano che può aumentare o diminuire..
Voglio sottolineare che la definizione di efficacia nel nostro caso non è del tutto corretta, poiché più conoscenze utilizziamo, minore è l'efficacia. Pertanto, ridefinirei l'efficacia come 'rapporto tra il risultato ottenuto e le risorse spese'. Allora tutto è corretto: le conoscenze non si esauriscono durante il lavoro, ma riducono il costo dell'unica risorsa fondamentalmente non rinnovabile del tester: il suo tempo.
Soluzione
Dunque, cerchiamo i problemi globali dei tester che peggiorano l'efficacia del loro lavoro.
La risorsa più significativa che viene spesa nel lavoro del tester è il suo tempo (le altre possono in un modo o nell'altro essere collegate a essa), e affinché possiamo parlare di un calcolo corretto dell'efficacia, è necessario correlare il risultato al tempo.
Consideriamo un sistema la cui vitalità è garantita dal lavoro del tester. Tale sistema è un progetto che include un tester nel team. Il ciclo di vita del progetto può essere grossolanamente rappresentato dal seguente algoritmo:
- Lavoro con i requisiti
- Formulazione del capitolato tecnico
- Sviluppo
- Test
- Rilascio in produzione
- Supporto (torna al p.1)
In questo modo, l'intero progetto può essere ricorsivamente suddiviso in sottoprogetti (feature) con lo stesso ciclo di vita.
Dal punto di vista del progetto, l'efficacia della sua realizzazione è tanto maggiore quanto minore è il tempo speso su di esso.
Così arriviamo alla definizione della massima efficienza possibile per il tester dal punto di vista del progetto: si tratta di un stato del progetto in cui il tempo per il testing è pari a zero. E il problema comune per tutti i tester è l'impossibilità di raggiungere questo stato.
Come procedere?
Le conclusioni sono piuttosto ovvie e sono già ampiamente utilizzate:
- Lo sviluppo e il testing dovrebbero iniziare e concludersi praticamente simultaneamente (questo è solitamente compito del reparto ). La soluzione ideale è che tutte le funzionalità in fase di sviluppo siano già coperte da test automatici al momento della loro preparazione, organizzate in test di regressione (e, se possibile, di pre-commit) con l'aiuto di qualche .
- Maggiore è il numero di feature nel progetto (più è complesso), maggiore sarà il tempo da dedicare a verificare che la nuova funzionalità non abbia rotto quella precedente. Pertanto, più complesso è il progetto, maggiore è l'automazione richiesta per il .
- Ogni volta che trascuriamo un bug in produzione e un utente lo trova, dobbiamo spendere ulteriore tempo per passare attraverso il ciclo di vita del progetto partendo dal p.1 (Lavoro con i requisiti, in questo caso, degli utenti). Poiché le ragioni per il mancato rilevamento del bug sono in generale sconosciute, ci rimane solo una via di ottimizzazione: ogni bug trovato dagli utenti deve essere incluso nel testing di regressione, per essere certi che non si ripresenti.
Fonte: habr.com
