cosmetic functional bugs what has be treated
Ci sono sempre enormi responsabilità imposte al tester per scoprire qualsiasi tipo di bug che il software ha. Indipendentemente dalla funzionalità e dall'interfaccia utente, i tester possono sollevare bug ovunque vi sia una non conformità.
Questo articolo aiuta a comprendere l'importanza dei bug funzionali e cosmetici. Inoltre, i fattori da considerare nell'assegnazione delle priorità sono anche spiegati qui in modo comprensibile con alcuni esempi dal vivo per le illustrazioni .
miglior software gratuito di clonazione del disco rigido 2017
Cosa imparerai:
Importanza di bug funzionali e cosmetici
I bug sono inevitabili nello sviluppo del software. Quindi è sempre molto importante eseguire test approfonditi del software prima che possa essere utilizzato dal vivo. Test del software possono diventare più essenziali in quanto aiutano a identificare i file bug persi dagli sviluppatori .
Questi bug non identificati possono diventare molto costosi in tempo reale. Quindi è necessario eseguire un piano di test adeguato e il test per migliorare la qualità del software.
Fig. 1:
La figura sopra deve caricare un file immagine che il software non è riuscito a visualizzare. Questo è un problema serio che può seriamente causare impatti aziendali.
Bug cosmetici e la loro importanza significativa
I requisiti cosmetici non sono altro che l'interfaccia utente o solo l'aspetto front-end del software. La maggior parte delle volte accade che continui a cambiare tra diverse versioni.
Ciò accade soprattutto nei progetti in cui viene seguita la metodologia agile. I rilasci avvengono qui sotto forma di sprint. Quindi di solito vengono chiamati Sprint release o semplicemente SR-xx, dove 'xx' si riferisce al numero di release.
Ogni versione può avere un determinato insieme di requisiti. In genere, i client si preparano a richiedere molto spesso modifiche all'interfaccia utente o solo all'interfaccia utente.
Di seguito sono riportati alcuni esempi di requisiti cosmetici:
- I menu devono essere disponibili con i caratteri Calibri e.
- La casella di testo A deve essere di 1,2 pollici
- Tutti i rapporti generati devono avere il titolo con dimensione H1 con colore '002522'.
Quanto sopra sono alcuni esempi di requisiti cosmetici che possono emergere. Questi sono i requisiti a cui ci si rivolge principalmente improvvisando l'usabilità del software . Un altro motivo alla base dei requisiti cosmetici è l'ottimizzazione del software e del suo design per lo scopo aziendale.
Fig 2
Nella figura sopra, ci sono problemi sia funzionali che estetici. Un problema funzionale come la casella di controllo non viene visualizzato per un'opzione 'Usa DeathByCaptcha'.
Il problema estetico può essere visto qui come nessun carattere uniforme che è stato utilizzato.
Fattore di priorità per bug cosmetici o esigenze dei clienti
Le esigenze estetiche sono contrassegnate un po 'essenziali dai clienti. Ciò è dovuto alla preoccupazione verso la necessità di rendere l'interazione del software molto semplice e allo stesso tempo efficiente in modo che il raggiungimento degli obiettivi avvenga facilmente. In caso di problemi con l'interfaccia utente, i client raggiungono i fornitori con un bug a bassa priorità.
Come generalmente accade, gli aspetti funzionali del software sono preoccupati dagli sviluppatori rispetto agli aspetti estetici in quanto sono per lo più aree a basso impatto.
I tester del software vogliono che tutti i requisiti menzionati dai client siano disponibili nel software in mancanza, cosa che naturalmente sollevano un bug. Ed è qui che tutto decolla. La priorità impostata dal tester si verifica come risultato del suggerimento del cliente. Il punto di vista degli sviluppatori è leggermente diverso da quello che guardano i tester. Guardano sempre se il bug può causare un'interruzione della funzionalità.
Arrivano alcune discussioni ricorrenti e il risultato può avere le raccomandazioni del team di test a un certo punto. Se non nella versione corrente può succedere in quella successiva.
Esempio reale n. 1)
Il cliente ha richiesto che il logo della società appaia sulla home page all'interno del frame del titolo insieme a una funzione di caricamento rapido. Il venditore ha consegnato il software in cui il logo dell'azienda richiede tempo per il caricamento e i clienti con la sensazione che il logo non si sta caricando procedono a sollevare un problema live del cliente.
Quindi questo ha causato più danni ai venditori. La causa principale del problema potrebbe essere la dimensione dell'immagine o la natura dell'immagine o qualsiasi altra cosa. Sebbene questo non abbia interruzioni funzionali, è stato presentato come un problema live.
Bug funzionali: fattori critici e prioritari
In generale, i bug sono considerati prioritari in base alla priorità impostata dai clienti e ai potenziali impatti che possono lasciare all'azienda. È opinione generale degli sviluppatori che si debba lavorare sui bug critici. Questo è più ovvio in quanto i bug funzionali sono qualcosa che sopprime il loro lavoro.
E in base alla priorità, i clienti desiderano dare la priorità ad alcuni bug funzionali e cosmetici nella stessa versione. Il fattore di criticità dipende dall'impatto o dal potenziale impatto che il bug può lasciare. Il fattore di priorità si basa esclusivamente sul cliente e sulle sue esigenze.
In termini di criticità, i bug funzionali sono molto necessari per essere risolti senza ritardi. Per gli insetti cosmetici, possono andare con le decisioni prese dai clienti
Fig 3
Nella figura sopra, ci sono problemi funzionali come problemi di progettazione e sovrapposizione di testo e problemi estetici come il problema dei caratteri.
Esempio reale n. 2)
Il client nell'esempio n. 1 aveva più versioni dello stesso fornitore. I clienti sono soddisfatti dei risultati forniti dai fornitori. Ora improvvisamente ci sono pochi scenari aziendali che i clienti hanno identificato come non funzionanti insieme a pochi altri elenchi di problemi di visualizzazione. Poiché i problemi che hanno un impatto funzionale sono considerati critici per i clienti, hanno chiesto ai fornitori di risolverli il prima possibile.
E poiché i problemi di visualizzazione avevano segni di lasciare il minor grado di impatto, i clienti hanno dato loro la priorità in più versioni. I clienti erano pronti per andare in diretta con correzioni per alcuni problemi di visualizzazione e la maggior parte dei problemi funzionali. Questo perché tutte le funzioni possono avere un impatto sul business e i pochi problemi di visualizzazione hanno il potenziale per creare impatti.
Impatti sul business
Tutti i bug possono portare a una non conformità del software a quella dei requisiti del cliente. Quando si tratta degli impatti nel business, sono sicuramente i bug funzionali che meritano di causare gravi impatti al business. Poiché i bug cosmetici si conformano al problema con il design e l'aspetto dell'interfaccia utente, possono creare problemi con l'usabilità e l'aspetto tra gli utenti.
In altre parole, questi sono meglio definiti come miglioramenti cosmetici rispetto agli insetti. Sebbene questi non possano avere un impatto grave sull'azienda in modo maggiore, possono portare alcune difficoltà tra gli utenti durante l'utilizzo del software.
Esempio reale n. 3)
I fornitori hanno fornito una nuova versione dell'applicazione software in una versione mobile. Ci sono poche funzionalità nelle app mobili che richiedono all'utente di fare clic su alcuni collegamenti più spesso. Ciò ha creato un senso di usabilità degradata tra gli utenti. I fornitori devono riconsiderare il design e il flusso dell'applicazione. Dopo aver modificato il flusso, l'applicazione ha iniziato a essere utilizzata da più utenti.
L'usabilità assume il ruolo principale in molte di queste applicazioni. Sebbene non ci siano stati cambiamenti funzionali, ci sono stati pochi cambiamenti nei cosmetici che hanno reso le applicazioni più forti
Studio comparativo tra bug cosmetici e bug funzionali
Ci possono essere una serie di variazioni tra le classificazioni di bug come quelle funzionali e estetiche in molteplici aspetti nel ciclo di vita del test del software. Pochi tra loro sono formulati e tabulati come differenza tra le due tipologie:
| Area di confronto | Bug funzionali | Bug cosmetici |
|---|---|---|
| Possibili cause | Le cause possono essere molteplici: 1. Problemi di codifica 2. Problemi di sincronizzazione 3. Problemi di applicazioni dipendenti | Ciò può causare il problema: 1. Problemi di progettazione 2. Problema di file non supportato |
| Grado di ricreazione | La ricreazione dei bug funzionali può essere eseguita dai tester o dai clienti stessi | I bug cosmetici richiedono uno sforzo minimo nella ricreazione poiché vengono identificati principalmente a livello di interfaccia utente |
| Criticità | Sono per lo più critici in quanto la rottura funzionale può avere un impatto sull'attività in forma grave | Possono diventare critici in pochissime occasioni. |
| Priorità | La priorità è quella definita dai client | La priorità è quella definita dai client |
| Impatto potenziale | La rottura funzionale può causare seri problemi nell'attività dei clienti | Sebbene non possano creare un impatto diretto, possono anche assumere potenziali impatti. |
| Considerazione dei miglioramenti | Questi bug non possono mai essere consigliati o considerati come miglioramenti | Questi bug possono essere o considerati come miglioramenti |
| Costi quando non fissi | Costo elevato quando il problema viene rilevato sul software live | Non molto costo |
Illustrazioni di bug cosmetici
supporta le domande e le risposte dell'intervista ai tecnici
Il bug estetico può causare un impatto in alcuni punti in cui sono presenti loghi aziendali o immagini delle partnership sul software ma non viene caricato correttamente. Sebbene siano insetti non funzionali, possono diventare gravi. Comprendiamo le seguenti illustrazioni per comprendere l'importanza degli insetti cosmetici e il loro ruolo significativo.
Argomento di studio
Il software A è in fase di sviluppo da parte del fornitore B. La modalità di consegna al client è sotto forma di rilascio di codice una volta al mese dopo che è stata rilasciata una versione di base. Dal prodotto consegnato, i clienti elencheranno tutti i problemi, i bug, i miglioramenti in base alla loro criticità e priorità.
La priorità va come P1, P2, P3 e P4.
La criticità va come Grave, Maggiore, Alto e Basso.
Ora i client si aspettano che tutti i bug Gravi, Maggiori e P1 vengano corretti nella settimana 30. Allo stesso modo i bug High, P2 nella settimana 35. Le correzioni dei bug P3 bassi sono attesi nella settimana 40. Infine, i bug P4 sono attesi nella settimana 40. Tra tutte le versioni delle correzioni, il client blocca un periodo di tempo di buffer di 3 giorni.
Ora la seguente osservazione diventa molto critica:
- Poiché è stato pianificato come modalità pipeline, qualsiasi ritardo avrà un impatto maggiore sui piani successivi.
- Le priorità sono formate dai clienti e quindi prevedono di rilasciare nel periodo che desiderano
- Il ritardo nei bug a bassa priorità ha il potenziale per aumentare la loro priorità da bassa priorità a maggiore.
- Piccoli ritardi possono causare gravi impatti sul business, lasciando i bug bassi e minori a diventare maggiori.
Incontro tra tester e sviluppatori
'Non contare le uova prima che si schiudano' - Questa linea è applicabile sia agli sviluppatori che ai tester. Quando il software è stato sviluppato e pronto per essere testato, i tester tendono a pensare alle linee precedenti. Dopo il test, ora è il turno degli sviluppatori di scrivere le battute ai tester. I seguenti sono i pensieri che fluiscono tra di loro:
- I tester dicono agli sviluppatori che ci sono così tanti bug che possiamo rilevare nel tuo software. Quindi il tuo lavoro non è finito.
- Dopo che la fase di test è stata completata e dopo molti bug, gli sviluppatori dicono che non pensi di aver sollevato più bug, troveremo il motivo appropriato per rifiutare la maggior parte dei bug che hai sollevato che non sono autentici.
Quindi è sempre una sorta di approccio argomentativo che va tra i tester e gli sviluppatori. Per assicurarsi che i risultati finali del progetto siano sincronizzati è essenziale che una persona intermedia (project manager) possa risolvere le controversie in modo che i risultati finali siano ottimizzati e assoluti senza perdite di difetti.
Conclusione
Gli articoli di cui sopra devono aver spiegato tutti i aspetti inevitabili e importanti dei bug cosmetici e come può essere confrontato con i bug funzionali . L'articolo sopra spiega anche come trattare i bug cosmetici rispetto ai bug funzionali.
Sebbene le criticità dei bug funzionali siano superiori a quelle dei bug cosmetici, questi ultimi si riservano il proprio posto nell'ottenere priorità dai clienti. Per bilanciare il software con le risoluzioni di tutti i bug, generalmente si consiglia di trattare i bug comprendendone la criticità, la priorità e la raccomandazione del cliente.
Circa l'autore: Questo è un articolo scritto da Nagarajan. Lavora come test lead con oltre 6 anni di esperienza di test in varie aree funzionali come Banking, Airlines, Telecom sia in termini di manuale che di automazione.
Qual è la tua opinione sui bug cosmetici e funzionali? Vorrei vedere i tuoi pensieri di seguito.
Lettura consigliata
- Bias cognitivi nei test del software: perché i tester perdono i bug?
- Perché il software presenta bug?
- Come si risolvono tutti i bug senza l'etichetta 'Bug non valido'?
- Test funzionale vs test delle prestazioni: dovrebbe essere fatto contemporaneamente?
- 10 motivi per cui i tuoi bug vengono rifiutati e cosa puoi fare come tester!
- Che cos'è il test di longevità? Come catturare i bug prima che il cliente lo trovi
- L'arte della segnalazione dei bug: come commercializzare e correggere i bug?
- I 30 migliori strumenti di test funzionale nel 2021