Introduzione
Buon pomeriggio, residenti di Khabrovsk. Proprio ora stavo risolvendo un compito di test per un posto vacante di QA Lead per un'azienda fintech. Il primo compito, ovvero creare un piano di test con una checklist completa ed esempi di casi di test per testare un bollitore elettrico, può essere risolto banalmente:
È difficile pensare a un piano di test migliore con una lista di controllo completa.
Ma la seconda parte si è rivelata una domanda: “Esistono problemi comuni a tutti i tester che impediscono loro di lavorare in modo più efficiente?”
La prima cosa che mi è venuta in mente è stata quella di elencare tutti i problemi più o meno evidenti che ho riscontrato durante i test, eliminare le piccole cose e riassumere il resto. Ma ho subito capito che il metodo induttivo avrebbe risposto a una domanda che non si applicava a “tutti”, ma, nella migliore delle ipotesi, solo alla “maggior parte” dei tester. Ho quindi deciso di affrontarlo dal lato opposto, deduttivo, e così è stato.
definire
La prima cosa che faccio solitamente quando risolvo un nuovo problema è cercare di capire di cosa si tratta, e per farlo ho bisogno di capire il significato delle parole che lo pongono. Le parole chiave da comprendere sono le seguenti:
- problema
- tester
- lavoro di tester
- efficienza del tester
Passiamo a Wikipedia e al buon senso:
(greco antico πρόβλημα) in senso lato: una complessa questione teorica o pratica che richiede studio e risoluzione; nella scienza - una situazione contraddittoria che appare sotto forma di posizioni opposte nella spiegazione di qualsiasi fenomeno, oggetto, processo e richiede una teoria adeguata per risolverla; nella vita, il problema è formulato in una forma comprensibile alle persone: "So cosa, non so come", cioè si sa cosa bisogna ottenere, ma non si sa come farlo . Viene da tardi. lat. problema, dal greco. πρόβλημα “gettato in avanti, posto davanti”; da προβάλλω “gettare avanti, mettere davanti a te; colpa".
Non ha molto senso, infatti, “problema” = “tutto ciò che deve essere affrontato”.
- uno specialista (non divideremo per tipologie, poiché a noi interessano tutti i tester) che partecipa al test di un componente o sistema, il cui risultato è:
— una serie di attività legate ai test.
(lat. effectivus) - il rapporto tra il risultato raggiunto e le risorse utilizzate (: 2015).
- una conseguenza di una catena (serie) di azioni (risultato) o eventi, espressi qualitativamente o quantitativamente. I possibili risultati includono vantaggio, svantaggio, guadagno, perdita, valore e vittoria.
Come nel caso del “problema”, c’è poco significato: qualcosa che è emerso come risultato del lavoro.
- la possibilità quantitativamente misurabile di svolgere qualsiasi attività di una o più persone; condizioni che consentono di utilizzare determinate trasformazioni per ottenere il risultato desiderato. Il tester è una persona e, secondo la teoria delle risorse vitali, ogni persona è proprietaria di quattro beni economici:
il contante (reddito) è una risorsa rinnovabile;
l'energia (forza vitale) è una risorsa parzialmente rinnovabile;
il tempo è una risorsa fissa e fondamentalmente non rinnovabile;
la conoscenza (l'informazione) è una risorsa rinnovabile, fa parte del capitale umano che può crescere ed essere distrutto.
Vorrei sottolineare che la definizione di efficienza nel nostro caso non è del tutto corretta, poiché maggiore è la conoscenza che utilizziamo, minore è l'efficienza. Pertanto ridefinirei l’efficienza come “il rapporto tra i risultati raggiunti e le risorse spese”. Allora tutto è corretto: la conoscenza non viene sprecata durante il lavoro, ma riduce i costi dell'unica risorsa fondamentalmente non rinnovabile del tester: il suo tempo.
Soluzione
Quindi, stiamo cercando problemi globali dei tester che compromettono l'efficacia del loro lavoro.
La risorsa più significativa spesa per il lavoro di un tester è il suo tempo (il resto può essere ridotto ad esso in un modo o nell'altro) e per poter parlare del corretto calcolo dell'efficienza, anche il risultato deve essere ridotto al tempo .
Per fare ciò, considera un sistema di cui il tester garantisce la fattibilità attraverso il suo lavoro. Un tale sistema è un progetto il cui team include un tester. Il ciclo di vita del progetto può essere approssimativamente rappresentato dal seguente algoritmo:
- Lavorare con i requisiti
- Formazione delle specifiche tecniche
- Разработка
- Test
- Rilascio in produzione
- Assistenza (vai al punto 1)
In questo caso l’intero progetto può essere suddiviso ricorsivamente in sottoprogetti (features), con lo stesso ciclo di vita.
Dal punto di vista del progetto, minore è il tempo dedicato ad esso, più efficace sarà la sua attuazione.
Arriviamo così alla definizione della massima efficienza possibile del tester dal punto di vista del progetto: questo è lo stato del progetto quando il tempo per il test è pari a zero. Un problema comune a tutti i tester è l'incapacità di raggiungere questo tempo.
Come gestirlo?
Le conclusioni sono abbastanza ovvie e sono state utilizzate da molti per molto tempo:
- Lo sviluppo e il test dovrebbero iniziare e terminare quasi simultaneamente (di solito questo viene fatto dal dipartimento ). L'opzione ideale è quando tutte le funzionalità in fase di sviluppo sono già coperte da test automatici nel momento in cui sono pronte, organizzate in test di regressione (e, se possibile, pre-commit) utilizzando una sorta di test .
- Più funzionalità ha un progetto (più è complesso), più tempo dovrà essere impiegato per verificare che la nuova funzionalità non rompa quella vecchia. Pertanto, più il progetto è complesso, maggiore è l’automazione necessaria .
- Ogni volta che perdiamo un bug in produzione e un utente lo trova, dobbiamo dedicare ulteriore tempo al ciclo di vita del progetto a partire dal punto 1 (lavorare con i requisiti, in questo caso gli utenti). Poiché le ragioni per cui un bug viene trascurato sono generalmente sconosciute, ci rimane un solo percorso di ottimizzazione: ogni bug trovato dagli utenti deve essere incluso nei test di regressione per essere sicuri che non venga più visualizzato.
Fonte: habr.com