how do you decide which defects are acceptable
Il software Go-Live è sempre un grande evento per qualsiasi prodotto software. È importante assicurarsi assolutamente che tutto funzioni e che lo siamo rilascio di software di qualità agli utenti .
Un prodotto scadente o prematuro o instabile o difficile da usare può causare molte perdite finanziarie e potrebbe anche far perdere la fiducia dell'utente al marchio stesso.
Spesso sentiamo che i test dovrebbero essere eseguiti fino a quando non soddisfiamo i criteri di uscita. Sentiamo anche che i difetti devono essere fissati a un livello accettabile.
Sebbene queste siano linee guida dal suono eccezionale, sono vaghe.
Per essere più precisi:
- Quale percentuale di difetti è accettabile per il go-live del software?
- Come decidi i difetti aperti con cui il software può andare a vivere?
- Che cosa tipi di difetti sono più gravi degli altri?
Lettura consigliata => Quando interrompere il test?
Hai mai avuto queste domande? Quindi, questo articolo ti aiuterà a rispondere. Continuare a leggere…
Il software complesso non è esente da difetti ed è una storia di uova e galline sulla chiusura dei difetti rispetto al software funzionante.
Più correggi i difetti, più è probabile che sia stato iniettato un nuovo difetto durante la chiusura del difetto. Così,
- Come decidi l'entità dei difetti e il tipo di difetti con cui puoi andare a vivere?
- Come si definisce il software da distribuire per il go-live?
- Come fanno i coordinatori UAT a chiamare a go-live o no?
- In base a quali parametri dovrebbe essere giudicato il software?
- Come rispondiamo: il software è adatto all'uso e porterà valore agli stakeholder?
Entrare in produzione è una pietra miliare importante per il cliente e per il venditore, in quanto è solitamente collegata alle tappe di pagamento. Entrambi hanno la stessa responsabilità nel garantire che i grandi progetti di trasformazione abbiano successo.
La mia esperienza mostra che i clienti vogliono il loro rapporto qualità-prezzo e hanno un criterio di uscita per UAT per andare a vivere con.
I suddetti criteri di uscita definirebbero più o meno l'entità accettabile dei problemi in tutte le aree dell'applicazione, come ad esempio:
- Funzionale
- Prestazioni e carico
- Usabilità
- Sicurezza
- Integrazione con sistemi esterni
- Rapporti
- Migrazione dei dati
Credo che ognuno di questi tipi di difetti debba essere ulteriormente spiegato. Ed è esattamente quello che faremo ora:
esempio per l'interfaccia astratta in java
# 1. Difetti funzionali:
Se il software viene creato secondo le specifiche fornite dal cliente, deve soddisfare i requisiti. Eventuali deviazioni vengono registrate come difetti funzionali.
Difetti funzionali vengono quindi classificati in base a gravità e priorità .
Le seguenti sono considerazioni importanti:
- I difetti di elevata gravità e priorità sono generalmente quelli che potrebbero influire sull'utilizzo quotidiano del software. Questi tipi di difetti sono quelli che devono essere corretti prima di andare in produzione. Nessuna eccezione.
- A volte i difetti funzionali sono classificati come richieste di modifica in quanto non facevano parte dei requisiti originariamente forniti. Tali CR, che sono un must affinché le aziende funzionino dopo il go-live, sono anche indispensabili per essere implementate.
- La classificazione dei difetti e la prioritizzazione dei difetti funzionali vengono effettuate dai coordinatori UAT in collaborazione con gli utenti aziendali e gli analisti aziendali. Di solito, il cliente ha un criterio di uscita che indica la percentuale di difetti che può essere aperta per il go-live.
# 2. Difetti di prestazioni e carico:
Difetti di prestazione sono importanti da considerare per il go-live e ancora di più se il software deve essere utilizzato da utenti esterni.
Se il software è lento per un determinato numero di utenti, gli utenti eviterebbero di utilizzare il software in quanto il caricamento richiede molto tempo. Gli utenti tendono a spostarsi sul sito della concorrenza se il software è molto lento, perdendo così affari.
A volte, anche le parti dell'applicazione che non sono rivolte al client possono influire sulle prestazioni.
Per esempio: Se è presente un processo batch che viene eseguito alla fine di ogni giorno e se il tempo di risposta dell'applicazione soffre mentre si continua, anche le prestazioni del batch sono un fattore da considerare.
- Le prestazioni vengono solitamente misurate in termini di tempo di risposta delle schermate per il rendering e la disponibilità per gli utenti quando sul sistema è presente un certo numero di utenti simultanei.
- I test delle prestazioni vengono eseguiti utilizzando strumenti come LoadRunner , WebLoad , Neoload ecc.
- Le prestazioni del software a un determinato carico e a un carico previsto futuro sono generalmente documentate nel contratto e devono essere dimostrate prima del go-live.
- Le schermate o parti dell'applicazione che vengono utilizzate meno dagli utenti vengono rimandate alle valutazioni dopo il go-live.
- Le prestazioni dipendono anche dal tipo di hardware e dalle condizioni di rete su cui viene distribuito il software.
- I test delle prestazioni vengono eseguiti durante l'UAT nell'hardware specificato utilizzando strumenti per le prestazioni ei loro difetti vengono tracciati in modo simile a quello dei difetti funzionali. Viene inoltre data loro la priorità e viene raggiunto un consenso sul rispetto dei criteri di uscita per il go-live.
- Di solito, i test delle prestazioni e del carico in UAT vengono eseguiti dopo che l'UAT funzionale da parte degli utenti aziendali è stato completato e viene raggiunto un criterio di uscita accettabile per i difetti funzionali.
# 3. Difetti di usabilità:
Il software creato dovrebbe essere facilmente utilizzabile dagli utenti finali utilizzando diversi tasti di scelta rapida, scorciatoie, il numero minimo di schermate di navigazione, impaginazione, ecc. Il software deve essere intelligente e intuitivo.
Se ci sono troppi movimenti della pagina prima di passare alla schermata appropriata, gli utenti di solito mostrano meno interesse nell'uso del software.
- Le linee guida sull'usabilità vengono create prima della creazione del software. Il software deve aderire a queste linee guida.
- Durante la creazione del software potrebbero esserci anche limitazioni degli strumenti che devono essere superate in modo intelligente prima che il software possa essere utilizzato dagli utenti finali.
- Con un software altamente utilizzabile, un utente finale può inserire dati fino a 5 volte il software normale.
- L'aspetto del software deve essere nitido e anche le questioni legali devono essere risolte prima del go-live.
- Molte volte viene nominato un consulente per l'usabilità per garantire agli utenti un'esperienza di usabilità fluida.
- La documentazione che deve uscire con l'applicazione software deve anche aderire a rigorose linee guida sull'usabilità in quanto possono essere utilizzate legalmente.
- Anche i difetti di usabilità registrati dai tester UAT / tester esterni hanno la priorità come difetti funzionali e di prestazioni e devono soddisfare i criteri di uscita per il go-live.
# 4. Difetti di sicurezza:
Sicurezza del software è un problema scottante poiché l'applicazione software può essere violata e i dati sensibili dei clienti possono essere rubati in pochissimo tempo.
Pertanto, un software affidabile non dovrebbe consentire nemmeno a un hacker molto competente di accedere all'applicazione senza i privilegi adeguati.
- I test di sicurezza vengono eseguiti in UAT con input specifici nel software per garantire che non sia hackerabile.
- I test di sicurezza vengono eseguiti da hacker legali che tentano di hackerare il software per verificare se è vulnerabile.
- Tutti i difetti di sicurezza devono essere chiusi prima che il sistema diventi attivo.
- Sicurezza significa anche Login e ruoli e privilegi a vari utenti (esterni e interni) per utilizzare diverse sezioni delle applicazioni e anche per creare e approvare dati.
# 5. Integrazione con sistemi software esterni:
Di solito, un'applicazione software che deve essere distribuita presso il sito del cliente deve interfacciarsi con qualsiasi software esistente che potrebbe già esistere lì.
Per esempio: Con il sistema di stampa, hanno in uso o potrebbero essere sistemi esterni come un'applicazione di fatturazione o sistemi di schermatura dei dati. L'applicazione software da distribuire dovrebbe integrarsi perfettamente con questi sistemi esterni. Tutti gli input e gli output di questi sistemi dovrebbero funzionare in modo sincrono. La tecnologia oggi comprende app mobili e diverse piattaforme software che l'applicazione deve essere compatibile con .
Il controllo dell'interfacciamento del sistema esterno deve essere eseguito in modo estensivo durante le fasi del sistema e dell'UAT. Dovrebbe essere un must sui criteri di uscita che dovrebbero essere soddisfatti prima del go-live.
# 6. Rapporti:
I report dall'applicazione software sono un modo fondamentale per mostrare che i dati all'interno dell'applicazione stanno coincidendo.
Ad esempio: tutti i dati relativi alla fatturazione devono coincidere con i saldi in accredito e in addebito.
- Tutti i dati nel software devono essere riconciliati. Questa riconciliazione dei dati all'interno del software viene mostrata tramite report e devono funzionare come previsto.
- Ciò è particolarmente vero se la migrazione dei dati da un vecchio sistema a un nuovo sistema è l'intenzione primaria della versione corrente.
# 7. Migrazione dei dati:
Se un vecchio sistema viene sostituito da uno nuovo, i dati dal vecchio sistema vengono spostati in quello nuovo (dopo che è stata raggiunta una data limite utilizzando il nuovo sistema). I dati migrati dovrebbero essere supportati dal nuovo sistema come definito durante la raccolta dei requisiti.
Tutti i vecchi dati potrebbero non essere disponibili nel nuovo sistema; tuttavia, nel nuovo sistema potrebbe essere disponibile un'istantanea dei vecchi dati. Questi dati dovrebbero essere disponibili come concordato.
Nota : L'elenco precedente non è esaustivo. A seconda del tipo di applicazione, potrebbero esserci più cose che devi convalidare o non tutto ciò di cui sopra potrebbe essere applicabile. Pertanto, una conoscenza approfondita del software, dello scopo aziendale, delle aspettative dell'utente e delle dipendenze dall'architettura o dall'hardware è essenziale per sviluppare criteri di uscita completi.
Un esempio di criteri di uscita per il go-live:
Questo è solo un esempio. Può variare da progetto a progetto.
- Il 100% dei difetti con priorità 1 è chiuso (gravità critica e priorità 1)
- Il 90% dei difetti con priorità 2 è chiuso (Gravità alta e priorità 2) con una soluzione logica disponibile per il resto del 10% dei difetti. Inoltre, è disponibile un piano per la chiusura del resto del 10% dei difetti.
- L'elenco di controllo per l'implementazione e l'integrità della produzione è pronto.
- Il team di supporto alla produzione è stato formato e pronto per la chiusura dei ticket.
- Il 70% dei difetti con priorità 3 è chiuso ed è in atto un piano per la chiusura del resto del 30% dei difetti bassi.
Alcuni punti da notare:
- Tutte le definizioni di gravità e priorità vengono decise durante gli incontri di lavoro tra il cliente e il fornitore all'inizio del programma.
- Dopo che tutti i difetti dell'UAT sono stati registrati e tutti gli altri difetti sono stati chiusi, i coordinatori UAT e gli sponsor aziendali si incontrano per fare il punto sui difetti in sospeso e aperti. Se tutti i difetti necessari per il go-live Day-1 vengono chiusi, gli sponsor aziendali vedono la loro disponibilità per il go-live e mettono il software in produzione.
In conclusione
Ci auguriamo che questo articolo ti abbia fornito alcuni spunti su alcune delle considerazioni importanti da considerare nella creazione di criteri di uscita solidi come la roccia che proteggono il software da potenziali guasti nelle produzioni.
Circa l'autore: Questo è un articolo di Krishnan Venkatraman. Ha quasi 18 anni di esperienza nel test del software. Ha lavorato a molti progetti di test del software ampi e complessi.
Sentiti libero di pubblicare le tue domande / commenti qui sotto.
Lettura consigliata
- Migliori strumenti di test del software 2021 [Strumenti di automazione del test QA]
- Lavoro assistente QA test software
- Corso di test del software: quale istituto di test del software dovrei iscrivermi?
- Scegliere il test del software come carriera
- Lavoro di freelance di scrittore di contenuti tecnici di test del software
- Alcune interessanti domande di intervista sul test del software
- Feedback e recensioni sul corso di test del software
- Software Testing Help Affiliate Program!