In un periodo in cui stiamo preparando diverse attività per voi (ci siamo quasi ), ci sembrava giusto fare chiarezza su uno degli argomenti più dibattuti qui su Otium: la valutazione delle vostre segnalazioni.
Le tante osservazioni che riceviamo su questo tema ci hanno suggerito di confrontarci nuovamente con i Test Manager e spiegarvi come funziona il processo di valutazione dei bug segnalati in campagna.
I TEST MANAGER
I Test Manager sono le persone che ricevono tutte le vostre segnalazioni e che decidono se l’anomalia che avete riscontrato può essere o meno considerata come bug. Se viene valutata come bug, la segnalazione è accettata; al contrario, se non viene ritenuta un bug, invece, è rifiutata.
Una volta accettata la segnalazione, il Test Manager assegna una gravità alla stessa. La gravità è il “danno” che il bug provoca all’applicazione, un danno che è valutato come basso, grave, alto o bloccante.
I TEMI
Riassumendo, i punti sui quali abbiamo volute concentrare la nostra riflessione sono:
- segnalazione di bug che vengono valutate con gravità troppo basse;
- segnalazioni rifiutate per “comportamenti attesi”
- segnalazioni rifiutate per “test non riproducibili in laboratorio” - segnalazioni rifiutate in una campagna ma accettate in una campagna “gemella” o accettate in entrambe ma con gravità diverse
Con questo articolo, che avrete sempre a vostra disposizione, proveremo a spiegarvi:
1) Come funziona il processo di valutazione delle vostre segnalazioni;
2) Quando e perché ricevete le risposte che abbiamo citato poco sopra;
L'OBIETTIVO DEI TEST MANAGER
Partiamo dalle basi: il nostro obiettivo è migliorare la qualità dei prodotti digitali dei nostri clienti. Come? Con le nostre campagne, con le quali potete segnalare tutti i diversi malfunzionamenti dei software che compongono gli stessi prodotti, evitando così che essi vengano riscontrati nel mercato reale.
Quindi, più malfunzionamenti trovate, maggiore è la nostra soddisfazione: l’obiettivo dei Test Manager è il vostro ed ogni singolo bug che riuscite a segnalarci è importante per fornire ai nostri clienti il miglior servizio possibile.
Le cause di un rifiuto di una vostra segnalazione non sono dovute né a motivi di budget, né a valutazioni totalmente soggettive dei Test Manager.
Un bug è considerato tale solo ed esclusivamente dai parametri tecnici definiti da ISTQB® (International Software Testing Qualifications Board), organizzazione non-profit e leader mondiale nella certificazione delle competenze sul software testing.
PRIMA DELLE CAMPAGNE
Prima di scendere nel dettaglio dei parametri ISTQB®, sottolineiamo che i prodotti e i servizi digitali che testate, prima dell’inizio di ogni campagna, vengono sottoposte ad un “sanity check”: una serie di verifiche che servono ad indicare se il prodotto è sufficientemente maturo per essere verificato.
Se l’esito è negativo, si comunica al cliente che ha commissionato la campagna che l’app non è pronta e l’attività si “congela” fino al superamento delle verifiche (è la ragione per cui, in alcuni casi, siamo costretti a posticipare le campagne anche pochi minuti prima del loro start).
LA VALUTAZIONE DEI BUG: I PARAMETRI ISQTB
Ogni segnalazione, come detto prima, viene verificata e valorizzata rispetto a tre parametri stabiliti da ISTQB®:
1) “Severity”: è quello che indichiamo come livello di gravità, cioè quanto un bug impatta la funzionalità di un app o servizio digitale. I livelli di gravità riconosciuti sono:
- Critical (la nostra “Bloccante”) --> le anomalie che appartengono a questa categoria riguardano il blocco totale del servizio che si sta testando, a cui non si riesce ad accedere, o il blocco totale di una funzione del servizio stesso. Esempi: down del server, perdita di dati ecc.
- Major (la nostra “Alta”) --> le anomalie che appartengono a questa categoria limitano notevolmente le funzioni principali del servizio che si sta testando, rendendolo quasi del tutto inutilizzabile
- Moderate (la nostra “Media”) --> le anomalie che appartengono a questa categoria non mettono a repentaglio le funzioni del servizio che si sta testando, ma la loro presenza fa abbassare la comprensibilità o fruibilità delle funzioni stesse.
- Low (la nostra “Bassa”) --> le anomalie che appartengono a questa categoria non impattano le funzionalità dell’app che si sta testando o potrebbero generare una sensazione negativa da parte dell’utente (rientrano le cosiddette anomalie “Experience”)
2) Attributo di qualità: indica su quale componente qualitativa del software impatta il bug individuato. Gli attributi di qualità sono basati sui parametri ISO/IEC 25000 (detti anche SQuaRE (System and Software Quality Requirements and Evaluation):
- Funzionalità --> la capacità del servizio che si sta testando di fornire funzioni che soddisfino le esigenze esplicite ed implicite quando il software viene utilizzato sotto specifiche condizioni;
- Accuratezza --> la capacità del servizio che si sta testando di fornire i risultati concordati o I precisi effetti richiesti;
- Usabilità --> la capacità del servizio che si sta testando di essere capito, appreso, usato dall’utente, quando utilizzato sotto condizioni specificate;
- Interoperabilità --> la capacità del servizio che si sta testando di interagire e operare con uno o più sistemi specifici;
- Affidabilità --> la capacità del servizio che si sta testando di mantenere uno specificato livello di prestazioni quando usato in date condizioni per un dato periodo;
3) Area funzionale: indica su quale elemento funzionale del servizio che si sta testando incide il bug individuato. I valori delle aree funzionali dipendono fortemente dal software sotto analisi e vengono definite in fase di progettazione della campagna.
LA VALUTAZIONE DEI BUG: GLI ALTRI PARAMETRI
La definizione di un bug e l’assegnazione di una gravità sono compito del Test Manager che, come detto, si basa sui parametri precedentemente citati. Inoltre, prima di ogni attività insieme al cliente che ha commissionato la campagna, viene effettuata un’analisi dettagliata del prodotto che sarà oggetto della vostra campagna e, allo stesso tempo, viene anche determinata la priorità secondo la quale un malfunzionamento deve essere risolto.
In sintesi, la conoscenza approfondita del prodotto e l’assegnazione delle priorità determinano, insieme ai parametri ISTQB®, la valutazione delle segnalazioni da parte del Test Manager.
LA DIFFERENZA CON LE VOSTRE VALUTAZIONI
Arriviamo quindi al punto più controverso, cioè la differenza fra le vostre valutazioni e quelle del Test Manager. Perché un bug che sembrerebbe impattare in modo critico o grave l'app che state testando viene valutata con gravità minore o, addirittura, non è accettata?
Premettendo che uno dei nostri principali obiettivi è di riconoscere al meglio il tempo che impiegate e la dedizione che dedicate nella ricerca di bug in ogni campagna, il Test Manager è la persone più adatta per determinare la validità e la gravità di un malfunzionamento che avete trovato.
Ad esempio, consideriamo il caso in cui uno di voi trovi un malfunzionamento importante, che sembra impattare gravemente il funzionamento dell’app che state testando. Quello che sembra per voi un bug di gravità maggiore in realtà non lo è. Il problema, infatti, avviene solo in determinate condizioni (versioni firmware più datate, smartphone di un determinato brand), che non riguardano la maggioranza dei consumatori finali che utilizzeranno la stessa app una volta lanciata sul mercato. Per questo motivo, non viene considerato prioritario procedere con l’immediata risoluzione, anche perché risulterebbe troppo costoso e coinvolgerebbe risorse che potrebbero essere utilizzate per risolvere altri malfunzionamenti ritenuti più importanti.
La vostra segnalazione potrebbe comunque esservi riconosciuta ma alla stessa non verrà assegnata una gravità alta poiché l’anomalia interesserebbe una minima parte di utenti.
Lo stesso scenario può avvenire al contrario, quando un bug che sembrerebbe solo Experience – ad esempio un errore nel nome di un prodotto - può invece impattare in maniera significativa l’utilizzo dell’app. In questo caso alla segnalazione può essere assegnata una gravità maggiore di quella apparente.
I COMPORTAMENTI ATTESI
Una delle risposte che ricevete più frequentemente è che “la segnalazione aperta non risulta essere un’anomalia in quanto il comportamento mostrato è quello atteso”.
Quando un comportamento di un app o di un prodotto digitale può essere considerato “atteso”?
Dal 6 febbraio 2020 non riceverete più questa motivazione perché entrerà in vigore il nuovo processo di valutazione per cui vi rimandiamo alla sezione dedicata che trovate in basso.
TEST NON RIPRODUCIBILE IN LABORATORIO
Facciamo invece un passo indietro e andiamo a vedere insieme le ragioni che concorrono a giustificare il rifiuto di una segnalazione con l’espressione “test non riproducibile in laboratorio”.
Ci teniamo particolarmente a dissipare le nubi su questo aspetto, molto criticato perchè contro le stesse logiche del crowdtesting.
Il motivo del rifiuto è effettivamente poco chiaro e non facilita a far passare un concetto chiave, che vi spiegheremo tra poco. Per questo motivo, da ora in poi, non verrà più utilizzato come spiegazione per motivare il rifiuto di una segnalazione.
Tutte le vostre segnalazioni che sono risultate “non riproducibili”, hanno seguito il normale processo di verifica ma mancavano di alcuni dettagli che non hanno permesso, almeno inizialmente, un’adeguata valutazione da parte dei Test Manager.
D’ora in poi, in casi come questi, vi inviteremo quindi ad aggiungere ulteriori informazioni e/o allegati che ci permettano di verificare l’anomalia che avete segnalato.
Cambiando la nostra comunicazione vogliamo incentivarvi a migliorare la qualità delle vostre segnalazioni e ad aumentare le vostre possibilità di ricevere una valutazione positiva.
VALUTAZIONI DIVERSE IN CAMPAGNE "GEMELLE"
Infine, ci sono le valutazioni discordanti tra campagne cosiddette “gemelle”: ad esempio, uno stesso bug segnalato ed accettato in una campagna Android che viene accettato anche nella campagna iOS, ma con una gravità diversa.
Anche in questo caso, valgono i parametri ISQTB citati prima e la differenza tra i sistemi operativi può essere determinante nella decisione dei Test Manager. Ma dobbiamo comunque ammettere che, in alcuni casi, c’è stata una mancanza di comunicazione tra le parti coinvolte (normalmente, i Test Manager di due campagne “gemelle” sono diversi) che ha portato ad una valutazione errata in una delle campagne in cui avete aperto la stessa segnalazione.
Dalle prossime campagne “gemelle” ci sarà quindi un confronto tra i due o più Test Manager responsabili delle valutazioni che eventualmente potranno modificare la gravità delle vostre segnalazioni, rendendole più coerenti tra loro.
GLI ERRORI
Con questo articolo speriamo di avervi spiegato al meglio il processo di valutazione di ogni vostra singola segnalazione e di aver risposto a tutte le vostre domande. Se non è stato sufficiente a chiarire i vostri dubbi, siamo disponibili a rispondere a qualsiasi altra domanda relativa a quest’argomento.
Nel frattempo, sottolineiamo che questo processo, nonostante sia basato su parametri definiti che limitano decisamente la valutazione soggettiva, è comunque soggetto ad errori umani che cercheremo di ridurre al minimo ma che, ovviamente, non possiamo evitare.
Certi della vostra comprensione, vogliamo evitare che le richieste di rivalutazione siano un continuo muro contro muro tra il Test Manager e voi crowders. Vi ripetiamo: il vostro obiettivo è uguale, trovare più bug possibili.
IL NUOVO METODO DI VALUTAZIONE DAL 6/02/2020
Da adesso in poi (6/02/2020) in caso di rifiuto della segnalazione per motivi tecnici da parte del cliente e da parte dei Test Manager (anche e soprattutto nel caso di "comportamento atteso" che non verrà più utilizzata come motivazione di rifiuto) la stessa verrà rivista da un altro team che farà un'altra valutazione focalizzata più sull'User Experience (slegata quindi da quella cliente) basata sui criteri spiegati dopo.
Una segnalazione, infatti, verrà accettata se ricade in una o più di queste casistiche:
1 - Migliora l’utilizzo generale e la Customer Satisfaction della maggior parte degli utenti; questa valutazione sarà fatta prima con il cliente e poi con il nostro team.
2 - Aggiunge una funzionalità che è posseduta dai maggiori competitor, e quindi corrisponde ad una aspettativa che l’utente ha maturato nei confronti del servizio/prodotto; in questo caso verrà accettata solo se comprovata da video e descrizione dettagliata sull'eventuale vantaggio che porterebbe il vostro suggerimento
3 - Implementa una funzionalità che aggiunge un oggettivo valore competitivo al servizio/prodotto; anche in questo caso la valutazione sarà fatta prima con il cliente e poi con il nostro team
4 - Viene suggerito un nuovo modo per svolgere un determinato task facilitando il raggiungimento della finalità dello stesso
Questa nuova valutazione sarà fatta prima di quella ufficiale che vi viene notificata su Negotium, non ci sarà quindi bisogno di aprire un ticket per richiederla.
Nel caso in cui il vostro bug non è nè di tipo tecnico, nè ricade nelle quattro casistiche citate prima, verrà rifiutata con una delle seguenti motivazioni di rifiuto:
- Unrelated: non è una segnalazione di User Experience poiché non rientra negli ambiti richiesti in campagna citati nel Manifesto di campagna e quindi non rispetta i criteri di valutazione
- Unpractical: È un’opinione o un consiglio personale, non è verificabile l’impatto positivo sull’Experience generale
- Overstressed: si evidenzia un problema creando e agendo in uno scenario limite che differisce fortemente da un’abituale utilizzo
I ticket vecchi ancora in pending verranno rivisti in questi giorni seguendo i criteri che vi abbiamo elencato prima.
PER APPROFONDIRE
Qui di seguito alcuni link a siti internet dove potete approfondire l’argomento (in lingua inglese)
imXDBle
Non sarebbe male, a questo punto, avere un elenco dei device di “serie a”
Inoltre sorge spontanea la domanda: se uno stesso bug viene valutato diversamente a seconda del device, sarebbe corretto accettare segnalazioni “duplicate”, una a bassa valutazione per il device obsoleto e una a valutazione piena per il device moderno top di gamma
sarisssimaParlando dei comportamenti attesi molte segnalazioni sono state rifiutate con questa segnalazione. Non esiste. Poniamo il caso di bug di experience, se tutte le app della stessa categoria streaming hanno l'anno di uscita del film e l'app che stiamo testando no, è un difetto grave e mina l'esperienza dell'utente, che ricerca invece questo aspetto. Noi diamo anche consigli su quello che manca e quello che è necessario per l'app per essere migliore. Perché dichiararlo come un comportamento atteso s... moreParlando dei comportamenti attesi molte segnalazioni sono state rifiutate con questa segnalazione. Non esiste. Poniamo il caso di bug di experience, se tutte le app della stessa categoria streaming hanno l'anno di uscita del film e l'app che stiamo testando no, è un difetto grave e mina l'esperienza dell'utente, che ricerca invece questo aspetto. Noi diamo anche consigli su quello che manca e quello che è necessario per l'app per essere migliore. Perché dichiararlo come un comportamento atteso se invece è una mancanza degli sviluppatori che non hanno inserito qualcosa che invece gli utenti vogliono e cercano?? Cioè non stiamo parlando di un colore diverso della homepage o del layout che è sicuramente più che soggettivo, ma di alcune mancanze che ci sono e non ci sono in altre app, che voi invece considerate comportamenti attesi. Dai ragazzi volete dirmi che volontariamente degli sviluppatori hanno deciso di non indicare l'anno in un app di streaming o di non permettere di elencare i film in ordine cronologico o alfabetico? Dove le persone ricercano film continuamente in base all'anno di uscita, se il film è recente o no? Cosa devo guardare in internet su Google quello che mi serve? Siamo realisti. Voi volete i bug, noi Ve li forniamo ma chi ci dice che tanti dei comportamenti attesi che voi indicate poi non diventino dei consigli da dare al cliente essendo comunque delle mancanze? La fiducia ormai è prossima allo zero..
imXDBleUn piccolo appunto sulla sezione “comportamento atteso”:
È chiaro che L’ app si comporti in un certo modo perché programmata per farlo, ciò che spesso il crowder contesta è che la programmazione sia errata, non il comportamento dell’app
Mi spiego: ho segnalato in fire tv che il tasto hamburger del telecomando non è attivo in Tim vision, comportamento atteso; ovviamente l’app si comporta come per tutte le altre piattaforme, la mancanza sta nel non aver preso atto che uno dei 6 tasti del telecoman... moreUn piccolo appunto sulla sezione “comportamento atteso”:
È chiaro che L’ app si comporti in un certo modo perché programmata per farlo, ciò che spesso il crowder contesta è che la programmazione sia errata, non il comportamento dell’app
Mi spiego: ho segnalato in fire tv che il tasto hamburger del telecomando non è attivo in Tim vision, comportamento atteso; ovviamente l’app si comporta come per tutte le altre piattaforme, la mancanza sta nel non aver preso atto che uno dei 6 tasti del telecomando sia “hamburger” e nel non aver integrato questo aspetto nella versione fire tv dell’app
Oppure
Registrazione di TIMVISION, L’ email viene registrata al primo passaggio senza aver ultimato la registrazione è senza alcuna conferma dell’ utente, ne tramite app ne tramite link via email; comportamento atteso
Anche qui non si contesta il fatto che L’ app si comporti per come sia stata programmata, si contesta che l’app sia stata programmata male, perché è assurdo che io possa “bloccare” qualsiasi email semplicemente scrivendola in fase di registrazione
CrowdvilleCiao @imXDBle nel caso in cui ci fossero device più importanti di altri ai fini della campagna, verrà chiaramente esplicitato nel Manifesto
@sarisssima @imXDBle le mancanze, gli errori di programmazione, di implementazione ecc. di cui parlate voi risultano come comportamento atteso perché il cliente che commissiona la campagna ne è già a conoscenza. Questo non significa che gli sviluppatori vogliono che l'app rimanga così, significa che il bug che avete trovato voi è già stato segnalato e/o ve... moreCiao @imXDBle nel caso in cui ci fossero device più importanti di altri ai fini della campagna, verrà chiaramente esplicitato nel Manifesto
@sarisssima @imXDBle le mancanze, gli errori di programmazione, di implementazione ecc. di cui parlate voi risultano come comportamento atteso perché il cliente che commissiona la campagna ne è già a conoscenza. Questo non significa che gli sviluppatori vogliono che l'app rimanga così, significa che il bug che avete trovato voi è già stato segnalato e/o verificato (e che, in alcuni casi, sono già al lavoro per risolverlo).
I TM non possono inserirle nelle segnalazioni note per i motivi descritti sopra: ci vorrebbero centinaia di pagine e neanche riuscirebbero ad elencarli tutti.
imXDBle
Allora forse in questi casi è meglio trovare una nuova dicitura, per evitare valanghe di ticket...
Certo però è che così la caccia ai big diventa uno sparare alla cieca
ideosCrowdville il reparto ticket continua a rifiutare le segnalazioni accettate in una campagna GEMELLA e non nelle restanti, soprattutto nei casi di anomalie che non dipendono dal particolare device o sistema operativo utilizzato.
vi volevamo comunicare che è in atto una discussione interna sulla rivalutazione delle segnalazioni, in particolare su quelli rifiutati con le seguenti motivazioni:
- comportamento atteso
- segnalazione non riproducibile in laboratorio
- comportamento in linea con i requisiti
Per questo motivo, i ticket che riguardano questi casi e che vi ritrovate "in pending" sono stati lasciati in standby per essere sufficientemente verificati. La nostra intenzione è rimuovere queste motiva... moreCiao a tutti,
vi volevamo comunicare che è in atto una discussione interna sulla rivalutazione delle segnalazioni, in particolare su quelli rifiutati con le seguenti motivazioni:
- comportamento atteso
- segnalazione non riproducibile in laboratorio
- comportamento in linea con i requisiti
Per questo motivo, i ticket che riguardano questi casi e che vi ritrovate "in pending" sono stati lasciati in standby per essere sufficientemente verificati. La nostra intenzione è rimuovere queste motivazioni e rendere le valutazioni sempre più chiare.
La prossima settimana vi aggiorneremo sulla questione!
Grazie!
renny
Mah. Mi sembrava che le segnalazioni Experience ci fossero già e che venissero valutate come tali e non come comportamento atteso. Perché si parla adesso di cambiare modalità di valutazione, considerando l'experience, quando doveva essere già valutata?
), ci sembrava giusto fare chiarezza su uno degli argomenti più dibattuti qui su Otium: la valutazione delle vostre segnalazioni.
Comments (9)