verifica che un difetto sia un difetto di produzione o meno

5

Come persona del controllo qualità, credo sempre che un difetto dovrebbe avere tutti i passaggi necessari a chiunque lo risolva per poterlo riprodurre.

tuttavia, è assurdo pensare che ogni QA di difetti aperti debba essere controllato se esiste già nella produzione? Ragione, perché chiedo è che abbiamo un responsabile di sviluppo che costantemente piagnucola, beh se il QA avrebbe fatto questa indagine se questo problema esistesse in produzione o meno avrebbe risparmiato tempo agli sviluppatori. Questo lo capisco, ma continuo a pensare che non abbia senso controllare se anche tutti i bug riscontrati dal QA nel ciclo di test sono in produzione.

    
posta logiclife 28.05.2015 - 23:59
fonte

4 risposte

5

Dal punto di vista del responsabile dello sviluppo, è assolutamente importante se il difetto è nuovo o se si tratta di un difetto esistente perché ha un impatto diretto e immediato su come il bug deve essere gestito. Dal punto di vista del responsabile dello sviluppo, la domanda più importante è se un nuovo bug debba essere risolto nel ciclo di rilascio corrente o se sia possibile attendere e avere la priorità in un ciclo successivo. Questo, a sua volta, dipende spesso dal fatto che il bug sia nuovo o meno.

Se hai trovato un nuovo bug, questo implica che una delle nuove funzionalità / correzioni di bug nel ciclo di rilascio attuale ha introdotto il problema. In tal caso, qualcuno deve rimediare al problema come parte della versione corrente (ripristinando la modifica che ha introdotto il bug o correggendo il bug stesso) oppure l'azienda deve decidere se aggiungere la nuova funzione X vale la pena distribuire anche se introduce un nuovo bug Y. Quasi sempre, il bug deve essere risolto nell'attuale ciclo di build o la modifica offensiva deve essere ripristinata. D'altra parte, se hai trovato un vecchio bug che esisteva prima dell'attuale ciclo di modifiche, il ciclo di generazione corrente può generalmente continuare e il nuovo bug può essere priorizzato per una versione futura. Naturalmente, ci sono casi in cui un bug appena identificato deve essere gestito nel ciclo di rilascio corrente perché il bug è proprio così critico, quei casi tendono ad essere rari.

Ora, se dovrebbe essere la responsabilità di QA controllare se il bug influisce sulla versione corrente o se ciò dovrebbe essere fatto da chi sta dando la priorità ai bug (supponendo che la priorità avvenga immediatamente) è una domanda aperta. La mia preferenza sarebbe chiedere a QA di farlo poiché stanno già scrivendo il bug. Dal momento che la persona QA sa già come riprodurre il bug, è meglio posizionarsi per verificare se esiste in produzione o meno. Il dipartimento QA tende anche ad avere più ore a disposizione per questo tipo di indagine rispetto a chi fa la definizione delle priorità poiché il lavoro può essere diffuso tra molti analisti.

    
risposta data 29.05.2015 - 08:14
fonte
2

Due domande separate qui, se il sistema produttivo dovesse essere controllato e chi dovrebbe farlo? Supponiamo che stiamo parlando di due dipartimenti separati nella stessa azienda ...

  • Quale dipartimento ha il tempo di farlo? Nella maggior parte dei progetti che ho sperimentato, che si tratti di cascata o mischia, i test diventano il collo di bottiglia a mano a mano che il rilascio si avvicina. Potrebbe essere sensato consegnare il controllo sull'ambiente produttivo allo staff di sviluppo solo per questo motivo.
  • D'altra parte, molti tester guadagnano meno degli sviluppatori, quindi ha senso dal punto di vista economico lasciare che facciano i legwork se sono disponibili in numero sufficiente.
  • Chi ha l'accesso necessario all'ambiente produttivo? Dove lavoro, lo sviluppo spesso non ce l'ha, solo operazioni (ovviamente) e QA (perché stanno raddoppiando come supporto di secondo livello).

Dì al tuo responsabile di sviluppo che sei felice di eseguire i controlli sul palco, produttivo o qualsiasi sistema, purché il budget e il programma del progetto rispecchino questa responsabilità.

    
risposta data 30.05.2015 - 20:34
fonte
1

Una volta trovato un difetto, ritengo che la cosa più importante da fare sia registrarlo con le informazioni chiave: un titolo o un riepilogo, i dettagli sul difetto o sul problema, su cosa succede effettivamente e cosa si aspetta che accada , i passaggi necessari per riprodurlo e l'ambiente in cui è stato trovato (ad esempio il sistema operativo, il browser Web, la versione del software in prova, ecc.). A seconda del processo, la persona che invia il rapporto sui difetti può anche assegnare priorità e / o gravità.

Dal punto di vista della QA, di solito stai guardando un software che è ancora in fase di sviluppo o, nel migliore dei casi, un candidato al rilascio. Sebbene il team di sviluppo debba eseguire l'unità, l'integrazione e alcuni test di sistema prima di arrivarci, i loro test non sono perfetti e si troveranno i problemi che il team di sviluppo deve esaminare prima di andare a rilasciare. Alla fine, spetta a qualcuno dell'organizzazione stabilire la priorità dei problemi identificati e decidere se qualcosa verrà risolto in questo ciclo di rilascio o in un ciclo di rilascio successivo.

Durante tutto il ciclo di sviluppo, sia il team di sviluppo che il team addetto al QA dovrebbero cambiare i loro test. Potrebbe esserci una test di regressione che viene sempre eseguita, ma sospetterei che il test sia più completo e focalizzato su funzionalità o parti del software che sono cambiate. I difetti potrebbero essere esposti per qualsiasi numero di motivi. Un cambiamento potrebbe aver introdotto un difetto. Un cambiamento avrebbe potuto rendere il difetto più ovvio, più facile da innescare o più comune. I nuovi casi di test potrebbero aver trovato un difetto che è stato latente nel software per un lungo periodo di tempo. Indipendentemente dal motivo per cui il difetto è stato rilevato dal test non è così importante in questo momento - la prima priorità dovrebbe essere quella di correggere il difetto.

In alcuni ambienti, come il software self-host del cliente o dove c'è l'obbligo di supportare o mantenere più versioni, potrebbe essere necessario testare più versioni del software per determinare quando il difetto è stato introdotto per consentire ai clienti di essere notificato, specialmente se si tratta di un difetto significativo. In ambienti come questi, mi aspetto che il team addetto al controllo della qualità assuma un peso maggiore nell'individuare le versioni interessate tra quelle attualmente supportate e per capire perché il problema è sfuggito a più livelli e cicli di test. / p>

Tuttavia, in ambienti in cui è supportata solo una versione del software, non sono sicuro che sia veramente importante quale versione ha iniziato il difetto. Se il difetto stava interessando gli utenti e disponevano di un meccanismo per segnalare problemi, allora lo segnalerà come un problema. Tuttavia, dal punto di vista della qualità, è importante comprendere i problemi noti con il software. Dal punto di vista della gestione del progetto, la quantità di problemi aperti può essere utilizzata per determinare se il software è pronto per essere rilasciato o per pianificare il lavoro per un ciclo di sviluppo futuro. Anche se non è programmato per essere risolto prima della fine del ciclo di sviluppo corrente, potrebbe riflettersi nella documentazione rivolta all'utente, insieme con soluzioni alternative, fino a quando non può essere risolto.

Alla fine, dopo che il difetto è stato corretto, puoi scegliere di eseguire qualche tipo di analisi delle cause principali determinare quando il difetto è stato iniettato (nell'attuale ciclo di sviluppo), perché il difetto non è stato scoperto nei precedenti cicli di sviluppo e controllo qualità (se non è stato introdotto di recente) e quali tipi di test devono essere creati, eseguiti e gestiti per evitare che questo difetto ritorni in futuro.

Per inciso, vorrei sottolineare che ci sono più idee su cosa debba essere responsabile per l'organizzazione di un QA del software. In alcune organizzazioni, il QA del software è essenzialmente un team di test che rappresenta l'ultima linea di difesa per le versioni del software per garantire che soddisfi i requisiti e non abbia problemi significativi. In altre organizzazioni, il QA del software non è solo responsabile della qualità del prodotto, ma anche della qualità del processo e può essere coinvolto in ogni fase del processo di sviluppo per garantire che tutti i prodotti di lavoro (dai requisiti ai supporti di distribuzione) siano completi e corretti per standard. Ci sono anche altre aspettative. Questa risposta si concentra maggiormente sul controllo qualità del software responsabile della qualità del prodotto.

    
risposta data 29.05.2015 - 00:46
fonte
0

Come sviluppatore ottengo molto questo problema

Alcune nuove funzionalità vengono inviate al test e viene segnalato un bug che descrive un comportamento che, sebbene 'sembra sbagliato', è presente nell'ambiente live.

Questo è un problema perché abbiamo avuto il tempo assegnato per sviluppare la nuova funzionalità. Non correggere un "bug" casuale

Spesso ci deve essere una discussione estesa sull'eventualità che il comportamento sia un bug, quale correzione prioritaria dovrebbe prendere ecc.

Il problema deriva dalla creazione di ulteriori casi di test e non dall'esecuzione di questi nei confronti di live prima di aggiungerli alla suite di test.

Gli sviluppatori che utilizzano misum o qualche altro processo agli altri hanno il tempo in cui sono gestiti in modo abbastanza preciso.

Se i tester generano bug ad hoc piuttosto che contro i requisiti specifici che gli sviluppatori stanno lavorando, causano ritardi e frustrazione.

    
risposta data 30.05.2015 - 21:40
fonte

Leggi altre domande sui tag