Difetti del registro per guasti di altri sistemi?

4

Costruiamo prodotti che spesso si integrano con sistemi di terze parti. A volte questi errori di sistema, che a loro volta causano errori del nostro sistema. Ad esempio, chiamiamo un servizio web quando un utente aggiorna i propri dati dopo averli salvati nel nostro database. Durante il test, il servizio all'altra estremità non funziona correttamente.

Posso vedere entrambi i lati; da un lato il software non funzionerà fino a quando il servizio non sarà stato riparato, quindi è necessario rintracciarlo in qualche modo. Dall'altro, non c'è nulla che faremo per risolvere il problema e avere un difetto critico nel nostro sistema sembra esserci uno spreco (e potrebbe riguardare gli altri che guardano il sistema di tracciamento chiedendosi perché abbiamo dei difetti che non siamo agendo su).

La mia domanda è, se dovessero essere rilevati come difetti nel nostro sistema di tracciamento, o se i nostri addetti al controllo qualità non registrassero i difetti se sapessero che questo è il motivo (in genere fanno come me lo chiedono se non sono sicuri)?

Modifica: alcune persone stanno facendo ipotesi. Il servizio web chiamato è sviluppato da un altro negozio, e siamo entrambi pagati dallo stesso cliente per integrare i nostri sistemi. La nostra interfaccia utente gestisce correttamente l'errore non mostra un errore. Dice all'utente che non possono cambiare il loro account in questo momento. Il difetto segnalato dal nostro team qa è ovviamente che l'utente dovrebbe essere in grado di cambiare il proprio account, ma non sa se il problema è qualcosa che dobbiamo risolvere o l'altra azienda. In base alle nostre esigenze, non possiamo salvare le modifiche degli utenti se la chiamata di servizio fallisce. È stato deciso che questi fallimenti dovrebbero essere abbastanza rari che questo progetto è ok. Lavoravamo anche con l'altra azienda per appianare alcuni dettagli che sono emersi durante i nostri test.

    
posta Andy 10.05.2013 - 22:54
fonte

5 risposte

2

La tua domanda offusca la linea tra la gestione del progetto e lo sviluppo del software.

Come definisci ciò che è e non è un "difetto"?

Stai registrando un difetto ogni volta che il servizio web fallisce?

Per me, lo definirei come un problema di progetto. Vuoi comunque documentare la causa / ricerca ecc. Che hai inserito. Non mi piace inquinare il mio elenco di errori / difetti.

Ogni volta che devi spiegare al cliente o all'utente "La lista dei difetti è cresciuta di 43 difetti questa settimana, ma 39 sono i problemi di terze parti" semplicemente rende la gestione del tuo difetto ancora più confusa.

    
risposta data 11.05.2013 - 05:51
fonte
2

Direi che per l'esempio dato (se è davvero un esempio del mondo reale) dovresti sicuramente archiviarlo come un difetto nel tuo software di tracciamento. Il modo in cui l'ho letto, il problema è che il tuo sistema non funziona bene con il fallimento di una terza parte. Anche se si tratta di un semplice meccanismo per registrare l'evento e informare qualcuno, il sistema dovrebbe essere in grado di far fronte a tale scenario.

Più in generale, continuo a dire che sì, è un difetto nel tuo sistema e dovrebbe essere tracciato come tale se la tua applicazione sta gestendo male una situazione di errore. Non deve essere archiviato come un problema critico se la terza parte scompare solo una volta in una luna blu, ma se si tratta di un evento normale, è possibile / dovrebbe gestirlo.

    
risposta data 11.05.2013 - 12:53
fonte
1

Il tuo sistema è IL TUO SISTEMA indipendentemente dal software / servizi di terze parti che stai utilizzando. I difetti dovrebbero essere monitorati e segnalati. Se il tuo software non funziona (indipendentemente dalla causa) è ancora un bug nel tuo software.

Quando Microsoft rilascia un nuovo sistema operativo e un vecchio programma che utilizza un documento non documentato, destinato esclusivamente ai fini di utilizzo interno di Microsoft, causa la rottura del vecchio programma. È un bug del sistema operativo Microsoft o del vecchio programma? Per il cliente, è un problema con il nuovo sistema operativo. Periodo. Lo stesso vale per il tuo software.

EDIT: come per lasciare un difetto critico che non hai intenzione di aggiustare seduto nel tuo sistema di tracciamento. Una volta che il bug è stato segnalato e tracciato, la direzione potrebbe decidere di non risolverlo, di risolverlo, di trovare un rimedio o di mantenerlo nell'elenco come elemento a bassa priorità. Se la direzione decide di non risolverlo, il difetto viene chiuso. Non sarà seduto lì come attivo. Se il difetto è critico, non ho idea del motivo per cui decideresti di non risolverlo, anche se la soluzione è semplicemente visualizzare un messaggio di errore all'utente informandolo che un servizio necessario è attualmente inattivo.

Inoltre, penso che sia un difetto nel TUO SISTEMA se non gestisci correttamente un errore "critico" che sai esistere nel software di terze parti.

    
risposta data 10.05.2013 - 23:42
fonte
1

should our QA people not be logging defects...

La risposta a sopra è NO solido. I tester devono registrare i difetti come è il loro lavoro; sono responsabili che i problemi di qualità siano adeguatamente riflessi nel tracker dei problemi. Dire loro di non registrare i difetti equivale a dire agli sviluppatori di non codificare o dire ai manager di non lavorare con le persone.

Una domanda più realistica che dovresti chiedere sarebbe meglio, il QA non dovrebbe aprire nuovi difetti se è un bug noto?

Se tu (o tester) apri un problema "generalizzato" come <Third Party System> is freaking unstable , le cose diventeranno molto più semplici. Invece di inquinare il database dei bug con più difetti difficili da aggregare, saranno in grado di aggiornare il noto difetto "ombrello" con i dettagli di vari incidenti correlati (e rideterminarne la priorità se necessario).

Se i problemi con i sistemi di terze parti sono così frequenti come descrivi, tale elenco di incidenti correlati finirà per costituire una prova sufficiente del fatto che alcuni sforzi sono necessari per investire per affrontare un problema di fondo. Quando gli sviluppatori e la QA sollevano una preoccupazione consolidata sull'affidabilità di un particolare sistema, supportata dall'evidenza di 20 ... 30 ... 100 incidenti ad essa correlati, è molto più facile per la direzione decidere che ciò merita ulteriori indagini e attenzione di.

    
risposta data 11.05.2013 - 11:15
fonte
-2

Devi tenere traccia di tutto ciò che degrada le prestazioni generali del tuo sistema. Altrimenti ti rimane "non ha funzionato e nessuno sa perché".

    
risposta data 10.05.2013 - 23:39
fonte

Leggi altre domande sui tag