Ordine / Gestione di migliaia di difetti appena prima del rilascio
Questa domanda mi è stata posta in un colloquio con un'azienda davvero buona, di seguito fornirò la domanda sotto forma di nostra interazione (M: io e io: intervistatore) Anche se non ci sono risposte definitive ma ho bisogno di sapere cosa idea / risposta che l'intervistatore voleva davvero :
I: Lo scenario sei tu e altri 2 costituiti dal team di test. Tu, il capo, sei l'unico che può fare l'automazione, gli altri possono fare solo test manuali. Hai quasi 10.000 bug che sono stati sollevati e hai 4-5 settimane o meno prima che questo prodotto venga consegnato. Cosa farai per assicurarti che il prodotto venga consegnato in tempo?
M: Filtra la priorità dei bug in modo saggio e riprova. Nel frattempo tieni un registro su quali funzionalità stanno affrontando più regressioni e quindi inizia ad automatizzarle. Bug simili o correlati verranno forniti ad altri per ulteriori test.
I: Supponiamo che nessuno dei bug sia stato contrassegnato con alcuna priorità. Cosa farai?
M: Filtrerò con le date. In qualsiasi tipo di SDLC, anche quello agile, i componenti principali vengono sviluppati per primi, se ci sono bug principali, devono essere prima risolti.
I: (con disapprovazione) E se una funzionalità molto importante viene aggiunta in uno sprint successivo? Inoltre come utilizzerai i tuoi compagni di squadra e la tua capacità di automatizzare.
M: Insieme alla data, come tester dovrò conoscere le funzionalità principali e importanti del prodotto fino alla data, quindi tenendolo a mente troverò le aree centrali di ogni sprint su cui lavorare (riguardo al team mated ha risposto la stessa cosa come prima).
I: Supponiamo che i bug non siano stati contrassegnati con la sequenza temporale di ogni sprint. Cosa farai?
M: Cercherò nell'elenco dei bug con parole chiave che rappresentano le funzionalità importanti senza le quali il prodotto non può essere rilasciato. Prenderò gli insetti da lì.
I: (Di nuovo in segno di disapprovazione) Con una parola chiave otterrai così tanti risultati, li esaminerai uno per uno?
M: (perdendo lentamente la speranza) Esaminerò il titolo e deciderò.
I: Generalmente i titoli non sono così esplicativi, come gestirai?
M: Inizierò a testare il prodotto da solo e cercherò bug simili che devo affrontare, piuttosto che cercare di esaminare i bug perché devo prendere una decisione per la consegna del prodotto.
I: Quindi ignorerai quei tanti bug? Le parti interessate potrebbero non essere d'accordo. (Dopo questo l'ho perso completamente e ho continuato a blaterare e non ricordo cos'altro è stato chiesto, anche ovunque è stata richiesta la gestione / lavoro degli altri 2 tester manuali)
Questa è stata un'intervista per Sr SDET.
Risposte
Oltre a quello che hanno detto le altre risposte, direi che l'intervistatore sta cercando come tu, come nuovo arrivato in una squadra, affronteresti una situazione senza vittorie. Francamente, sospetto che, come minimo, l'azienda si sia trovata in questo tipo di situazione in passato. Nel peggiore dei casi (ammetto liberamente di essere cinico) qualcosa di simile si troverà di fronte a chiunque abbia la posizione.
Come intervistatore, vorrei qualcosa del genere dalla persona che stavo intervistando:
Innanzitutto, vorrei sapere come sono organizzati questi bug, in particolare priorità, gravità e rischio. Presumo di trovarmi in questa situazione e non di essere stato coinvolto dall'inizio, perché questo tipo di situazione suggerisce che le cose sono andate male da qualche parte.
Se i bug non sono organizzati in un modo che implica priorità, gravità e rischio, vorrei parlare con gli altri tester, la gestione del progetto e lo sviluppo per determinare quali problemi sono a conoscenza che rappresentano il rischio maggiore per la distribuzione prevista Data.
Se esiste un'organizzazione del genere, cercherò di parlare con tester, gestione del progetto e sviluppo per confermare i bug a più alto rischio. Idealmente, sarei alla ricerca di un modo per creare un elenco di bug che devono essere corretti prima che il prodotto possa essere rilasciato. Con 10.000 bug, la creazione di tale elenco richiederà un po 'di tempo, e questo presuppone che non ci siano bug che i tester non sono stati in grado di trovare perché i bug segnalati li nascondono o li bloccano.
Una volta che ho un'idea di quanto sia grave la situazione, posso decidere se - a mio parere - è possibile rilasciare l'applicazione come pianificato. Se la maggior parte dei bug sono a rischio relativamente basso e i bug ad alto rischio sembrano essere ragionevolmente facilmente risolti, concentrerei il mio team sui bug ad alto rischio e lavorerei con il project manager e qualsiasi altro team conduce per ottenere il rischio più elevato (gravità alta, molto probabile che si verifichi sul campo e / o blocchi aree dell'applicazione) bug corretti e testati.
Se non riesco a vedere un modo per rilasciare il prodotto in tempo, inizierei a parlare con il project manager e il mio capo per vedere se c'è un modo per fare una versione beta limitata di funzionalità solide o per ritardare il rilascio. Dato che sono nuovo nella posizione, non so se ci sono requisiti contrattuali o altri fattori al di fuori del mio controllo che potrebbero costringere la data di rilascio a essere inamovibile.
Mi assicurerei anche che dopo il rilascio mi trovassi con i leader di tutti i team coinvolti per capire come si è verificata una situazione del genere e quali azioni potremmo intraprendere per evitare che accada di nuovo, nonché come possiamo lavorare insieme per abbattere il bug arretrato.
Nota che niente di tutto questo ha a che fare con il ruolo SDET. È chiaro dalla domanda che l'intervistatore si aspetta che un SDET funga anche da test lead: non penso che questa sia una cosa particolarmente positiva e, francamente, vorrei sapere se è qualcosa che l'azienda si aspetta dal suo SDET.
Vale la pena ricordare che, anche se le interviste sono situazioni di forte stress, cercare di pensare di traverso e guardare alle implicazioni delle domande che ti vengono poste piuttosto che immergerti. È difficile da fare perché sei stressato e cerchi di dare il meglio, ma se puoi prenderti un po 'di tempo per chiederti mentalmente che cosa sta cercando l'intervistatore con la domanda, di solito puoi dare una risposta migliore.
La prima cosa che mi viene in mente è: questi test hanno mai funzionato prima? Se è così allora, niente panico. Qualcosa è cambiato nel codebase o nel framework di test che probabilmente sta causando il fallimento di gruppi di essi. Rintracciarlo e vedere se riesci a eliminare diverse migliaia di errori in una volta sola. Dovrai comunque rileggere quelli che passano di nuovo manualmente e ricontrollarli, ma forse ci vorranno solo pochi giorni.
Se non fossero mai stati controllati prima, farei comunque qualcosa di simile: cerca eventuali elementi in comune che potrebbero consentire di correggere grandi gruppi contemporaneamente.
Altrimenti c'è così tanto rumore che potrebbe farti perdere qualcosa di critico che non funziona.
Dopodiché accetta il fatto che potresti non essere in grado di arrivare a tutto e concentrarti sul percorso del codice del creatore di denaro. Le cose che devono funzionare o gli affari si piegano. Quindi, dopo averne cancellati altri, a giorni alterni o tre, guarda se ci sono altri fallimenti raggruppati come menzionato prima e prova a cancellare qualche altro gruppo.
Nota: rispondere a questa domanda dal punto di vista di un SDET, qualcuno che può riparare da solo la base di codice offensiva.
Se l'intervistatore menzionava bug e non il fallimento del test (se il suo fallimento del test fare riferimento alla risposta di @Lewis
Prima di tutto avere 10000 bug attivi in un prodotto è davvero una grande bandiera rossa.
E non dovresti mai rilasciare un prodotto del genere. Ma se la decisione della direzione deve ancora essere rilasciata,
La risposta che l'intervistatore si aspettava sarebbe stata " gravità "
Il team dovrebbe concentrarsi prima sulla risoluzione dei bug di gravità elevata se non ci sono priorità e rimanere bassi una volta in attesa se non è un requisito urgente e non influisce sulla logica aziendale effettiva.
E concentrati inizialmente sull'automazione del test del fumo, quindi inizia ad automatizzare tutte le suite di regressione
Raggruppa i bug e vedi dove si verifica il clustering dei bug e verifica rigorosamente quel modulo una volta che la correzione è stata effettuata.
Prima del rilascio testare manualmente tutti gli scenari di test del fumo (logica aziendale critica)
Inoltre, avere 10000 bug può provocare il mascheramento dei difetti in cui questi bug mascherano alcuni bug critici all'interno del prodotto.
Quindi, una volta effettuata la correzione, dovrebbero essere effettuati test più rigorosi attorno ai moduli per cercare bug più critici
quindi se fossi nel colloquio, risponderei come:
- 10000 bug in qualsiasi progetto sarebbero un'enorme bandiera rossa, mostra che non esisteva un processo di correzione e stima dei bug adeguati. Mi preoccuperei sicuramente del clustering dei difetti e del mascheramento dei difetti, il che significa che ci sono possibilità che la maggior parte dei bug sia concentrata su un singolo modulo, e questo molti bug potrebbero mascherare altri bug critici che verranno identificati solo dopo aver corretto e ritestato il modulo in modo rigoroso . E consiglierà di spingere ulteriormente la data di rilascio per questo motivo.
Nel frattempo, mentre il team di sviluppo è impegnato a correggere i bug, inizieremo ad automatizzare i casi d'uso del test del fumo e i casi d'uso dei bug. Una volta arrivata la correzione, assegneremo le attività di ripetizione del test ai tester manuali e noi stessi eseguiremo rigorosi test ad hoc sul modulo per trovare eventuali bug critici mascherati.
- Se non c'è priorità, sarebbe inutile rivisitare prima i bug critici o di alta gravità, e anche indagare sulla durata dei bug e capire perché i bug non sono stati risolti per così tanto tempo per aiutare a migliorare il processo generale in futuro.
Per quanto riguarda i bug di bassa gravità, dobbiamo prendere una decisione del team sulla sequenza temporale e sulla decisione di rilascio se rilasciare la prima versione con questi bug, documentando comunque gli stessi e soluzioni alternative dove richiesto. Fornire anche la prossima data di rilascio per la possibile correzione, se possibile.
Quindi, essendo un QA senior, dovresti esprimere la tua forte opinione di rimanere "NO" quando vedi bandiere rosse. Non essere troppo flessibile
Le altre risposte qui sono buone se il punto della domanda è dare una risposta concreta.
Tuttavia, molti intervistatori fanno domande vaghe senza una risposta specifica perché vogliono sapere come pensi o capire se stai facendo supposizioni sulla domanda. Vogliono che tu faccia loro domande di chiarimento per ottenere informazioni specifiche. Questo aiuta a guidare la tua risposta.
Lo scenario sei tu e altri 2 costituiti dal team di test. Tu, il capo, sei l'unico che può fare l'automazione, gli altri possono fare solo test manuali. Hai quasi 10.000 bug che sono stati sollevati e hai 4-5 settimane o meno prima che questo prodotto venga consegnato. Cosa farai per assicurarti che il prodotto venga consegnato in tempo?
Alcune domande da porre:
- Quanto sono esperti i tester manuali di qualità?
- I tester manuali hanno esperienza in questo progetto? O sono anche loro nuovi nel progetto?
- Tutti i 10.000 devono essere riparati prima della data di consegna?
- Esiste un software di tracciamento dei bug utilizzato dai team? E anche se fosse?
- Come vengono tracciati i bug noti? Hanno una priorità, gravità elencata? Sono raggruppati / etichettati per funzione?
- Esistono test automatizzati attualmente in uso per il software? In caso affermativo, quanti unit test, test di integrazione, test dell'interfaccia utente? Oppure devo creare da zero tutti i test / framework automatizzati nel periodo di 4-5 settimane?
- Di quanti test sono responsabili gli sviluppatori? Stanno creando test di unità / integrazione?
- I 10.000 bug dell'interfaccia utente sono bug? O un mix di bug che possono essere testati utilizzando unit test, test di integrazione, test dell'interfaccia utente?
- Quali dispositivi devono essere utilizzati per i test?
- Qual è il livello di qualità che dobbiamo raggiungere per soddisfare utenti e stakeholder? In che modo gli stakeholder percepiscono la qualità?
- In che modo le parti interessate determinano un lancio di successo del progetto?
- Qual è la definizione di team di done?
- Il team avrà tempo dopo il rilascio del progetto per correggere i bug? O stiamo passando al prossimo progetto? Quanto tempo avremo se avremo tempo?
- Il team utilizza Agile SDLC o Waterfall SDLC?
C'è un numero infinito di domande che puoi porre per ottenere chiarimenti necessari per fornire una risposta ben ponderata.
E, dalla conversazione dettagliata sopra, l'intervistatore ha continuato a chiedere dettagli su come includere i tester manuali nel tuo piano. Questo ti dà un grande indizio di ciò che l'intervistatore sta cercando: non vogliono che tu ti assuma tutto l'onere di testare questo progetto da solo; vogliono sapere in qualità di ingegnere SDET / QA di livello senior come si fa da mentore / guida un team di tester di livello junior.
Tieni presente che le interviste non dovrebbero essere un interrogatorio in cui rispondi solo alle loro domande. Le interviste dovrebbero essere una conversazione in cui puoi chiedere qualsiasi cosa che aiuti a chiarire le loro domande.