Introduzione
Buongiorno, membri di Habr. Recentemente ho affrontato un compito di prova per una posizione di QA Lead in una azienda fintech. La prima attività, redigere un piano di test completo con una lista di controllo e esempi di casi di test per verificare un bollitore elettrico, è stata piuttosto triviale:
È difficile inventare un piano di test migliore con una lista di controllo completa.
Ma la seconda parte ha sollevato la domanda: “Ci sono problemi comuni a tutti i tester che ostacolano la loro efficienza?”.
La prima cosa che mi è venuta in mente è stata elencare tutti i problemi, anche marginali, che ho incontrato nel testing, escludere le sciocchezze e generalizzare il resto. Ma ho rapidamente capito che il metodo induttivo risponderebbe a una domanda riguardante non “tutti”, ma al massimo “la maggioranza” dei tester. Quindi ho deciso di affrontare la questione da un'altra angolazione, quella deduttiva, e questo è ciò che è emerso.
Definizioni
La prima cosa che di solito faccio quando affronto un nuovo compito è cercare di capire di cosa si tratta, e per questo è necessario comprendere il significato delle parole con cui è formulato. Le parole chiave da chiarire sono le seguenti:
- problema
- tester
- lavoro del tester
- efficacia 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; nella scienza è una situazione contraddittoria che si presenta come posizioni opposte nella spiegazione di fenomeni, oggetti o processi e richiede una teoria adeguata per la sua risoluzione; nella vita, un problema è formulato in modi comprensibili per le persone come 'so cosa, non so come', cioè è noto ciò che deve essere ottenuto, ma non è chiaro come farlo. Deriva dal tardo latino problēma, dal greco πρόβλημα "lanciato in avanti, posto davanti"; da προβάλλω "lanciare in avanti, mettere davanti a sé; accusare".
Non c'è molto significato, in sostanza, “problema” = “qualsiasi cosa con cui bisogna confrontarsi”.
— esperto (non faremo distinzione sui tipi, poiché ci interessano tutti i tester) che partecipa al collaudo di un componente o di un sistema, il cui risultato è:
— un insieme di attività relative al collaudo.
(lat. effectivus) — rapporto tra il risultato raggiunto e le risorse utilizzate (:2015).
— conseguenza di una serie di azioni (risultato) o eventi, espressi qualitativamente o quantitativamente. I risultati possibili includono vantaggio, svantaggio, beneficio, perdita, valore e vittoria.
Come con il "problema", il significato è poco chiaro: qualcosa che si ottiene alla fine del lavoro.
— possibilità misurabile in termini quantitativi di svolgere un'attività da parte di una persona o di più persone; condizioni che permettono, attraverso specifiche trasformazioni, di ottenere il risultato desiderato. Il tester è una persona e, secondo la teoria delle risorse vitali, ogni persona possiede quattro attivi economici:
fondi monetari (entrate) — risorsa rinnovabile;
energia (forza vitale) — risorsa parzialmente rinnovabile;
Il tempo è una risorsa fissa e fondamentalmente non rinnovabile;
La conoscenza (informazione) è una risorsa rinnovabile, parte del capitale umano che può crescere e decadere..
Vorrei sottolineare che la definizione di efficacia nel nostro caso non è del tutto corretta, poiché più conoscenze utilizziamo, maggiore è la diminuzione dell'efficacia. Pertanto, riformulerei l'efficacia come “il rapporto tra il risultato raggiunto e le risorse impiegate”. Allora tutto è corretto: le conoscenze nel lavoro non si esauriscono, ma riducono il consumo dell'unica risorsa fondamentalmente non rinnovabile del tester: il suo tempo.
Soluzione
Quindi, cerchiamo problemi globali dei tester che influenzano negativamente l'efficacia del loro lavoro.
La risorsa più significativa spesa per il lavoro del tester è il suo tempo (le altre possono in un modo o nell'altro essere collegate ad esso); per poter parlare di un calcolo corretto dell'efficacia, è necessario portare anche il risultato nel tempo.
Consideriamo un sistema la cui sostenibilità è garantita dal lavoro del tester. Questo sistema è un progetto che include un tester nel proprio team. Il ciclo di vita del progetto può essere approssimativamente rappresentato dal seguente algoritmo:
- Gestione dei requisiti
- Formulazione del documento tecnico
- Sviluppo
- Test
- Rilascio in produzione
- Supporto (goto p.1)
In questo modo, l'intero progetto può essere ricorsivamente suddiviso in sotto-progetti (feature), con lo stesso ciclo di vita.
Dal punto di vista del progetto, l'efficacia della sua realizzazione aumenta man mano che si riduce il tempo dedicato.
Pertanto, arriviamo alla definizione della massima possibile efficienza del tester dal punto di vista del progetto: si tratta dello stato del progetto in cui il tempo dedicato ai test è pari a zero. Un problema comune per tutti i tester è l'impossibilità di raggiungere questo tempo.
Come affrontare questa situazione?
Le conclusioni sono piuttosto evidenti e già ampiamente utilizzate:
- Sviluppo e test devono iniziare e terminare quasi simultaneamente (questo è solitamente gestito dal reparto ). L'opzione ideale quando tutta la funzionalità sviluppata è già coperta da test automatici al momento della sua completazione, organizzati in test di regressione (e, se possibile, anche pre-commit) tramite un qualche tipo di .
- Più funzioni ci sono nel progetto (più è complesso), più tempo dovremo dedicare a verificare che la nuova funzionalità non abbia danneggiato quella esistente. Da qui, più complesso è il progetto, maggiore sarà l'automazione necessaria .
- Ogni volta che trascuriamo un bug in produzione, e un utente lo trova, dobbiamo spendere tempo extra attraversando il ciclo di vita del progetto a partire dal punto 1 (Gestione dei requisiti, in questo caso, degli utenti). Poiché le ragioni per cui viene trascurato un bug sono in generale sconosciute, l'unico modo per ottimizzare è che ogni bug trovato dagli utenti deve essere incluso nel test di regressione, per essere certi che non riappaia.
Fonte: habr.com
