Sono "difficili da trovare bug" la responsabilità dello sviluppatore o del tester?

0

Potrebbe sembrare una domanda aperta (o non costruttiva in base agli standard di stackoverflow) .... ma ti sto chiedendo se c'è qualcosa di rigido secondo gli standard dei processi software che affrontano questo argomento?

Se ci sono uno o più "bug difficili da trovare" che richiedono scenari complessi, test approfonditi, serie di dati molto grandi o speciali da mostrare ... è questa la responsabilità dello sviluppatore o del controllo qualità?

    
posta osama yaccoub 25.09.2016 - 10:05
fonte

4 risposte

7

Non esiste un singolo processo di sviluppo software standard con responsabilità definite chiare per tutto:

  • Da un lato questo è sfortunatamente, perché rende la vita più difficile. Devi organizzare tutto in ogni progetto e concordare ruoli e responsabilità. Se il software è costruito per un cliente, questo potrebbe essere parte del contratto. E non sarà sempre così chiaro chi è la colpa di cosa, né se c'è qualcuno da incolpare affatto.

  • Dall'altro lato, questa è una fortuna: ogni progetto è in qualche modo unico e tu hai la libertà di organizzare le cose nel modo più adatto alle sue esigenze e sperimentare approcci innovativi.

Quindi chi è la colpa?

  • Il cliente potrebbe accusare il project manager
  • Il project manager potrebbe incolpare il responsabile della qualità per non averlo trovato, o lo sviluppatore per aver lavorato spensieratamente
  • L'addetto all'assicurazione della qualità poteva incolpare il cliente perché nessuno gli aveva parlato dello scenario di test reale o non aveva fornito dati di test rappresentativi. Il cliente potrebbe biasimare in cambio il responsabile della qualità, perché non ha mai chiesto o non ha verificato la rappresentatività dei dati. Quindi, l'ingegnere di qualità alla fine incolperà lo sviluppatore del software per la sua cattiva qualità.
  • Lo sviluppatore del software poteva incolpare l'ingegnere della qualità perché non si verificava abbastanza bene. Poteva biasimare l'architetto o l'analista, per non aver menzionato alcune circostanze specifiche (se l'avesse saputo, avrebbe impedito che accadesse). L'analista aziendale potrebbe incolpare il cliente, e così via ...
  • Alla fine, tutti potrebbero dare la colpa a tutti gli altri, e spetterà al giudice risolvere il caso

Ma aspetta un attimo ... giudice? Astuccio ? Bene, ... Spero che prima di arrivare a una fine così insoddisfacente tutte le parti si renderanno conto che sono sulla stessa barca!

La qualità è una responsabilità condivisa. Quindi alla fine è inutile incolparsi l'un l'altro. Tutti devono contribuire a raggiungere un risultato accettabile.

L'unico che potrebbe essere incolpato alla fine è il project manager. Perché è sua responsabilità far lavorare le persone insieme. E lui / lei dovrebbe assicurare che l'assicurazione della qualità sia adeguatamente organizzata al di sopra e al di là dei confini organizzativi. Ha molti modi per farlo, partendo dall'impostazione del ciclo di vita del progetto (ad es. Agile vswaterfall), dall'organizzazione del coinvolgimento degli stakeholder e dalla scelta dell'approccio di validazione (ad esempio TDD o tradizionale V- validazione del modello ) e facilitazione del team durante tutto il progetto.

    
risposta data 25.09.2016 - 13:27
fonte
3

If there are one or more "Hard to find bugs" that need complex scenarios, extensive testing, very big or special data set to show up ... Is this the responsibility of the developer or the QA ?

È responsabilità dell'intero team del software.

  • Gli sviluppatori devono testare il proprio codice, al fine di fornire il codice di massima qualità possibile.
  • Se hai un team di controllo qualità separato, è compito loro trovare bug di cui gli sviluppatori non erano a conoscenza.

Per quanto riguarda la consegna di bug al cliente, non importa se sono facili da trovare o difficili da trovare. entrambi i gruppi sono responsabili.

    
risposta data 25.09.2016 - 13:50
fonte
0

Da quando lo sviluppatore è su di te per iniziare, per creare un codice pulito e disaccoppiato che faccia poche possibilità di errori "difficili".

Inoltre, tu sei colui che ha creato il programma e tu sei colui che sa come funziona e dovrebbe sapere come testare. E dovresti includere il test di ogni unità nel modo in cui solo lo sviluppatore può sapere come testare ogni piccolo pezzo.

Quindi, dico che lo sviluppatore è il massimo responsabile di tutto ciò che è in quel codice, e non dovresti mai fare affidamento su un tester per trovare i tuoi bug.

Detto questo, quando aggiungi i tester al mix, la loro responsabilità è quella di catturare tutto ciò che lo sviluppatore potrebbe aver perso, ma, come sviluppatore, sei ancora responsabile, il team di controllo qualità è lì solo per sicurezza, ma nessuno sviluppatore dovrebbe fare affidamento su di loro.

Quindi, in fondo, tu come sviluppatore è responsabile di ogni bug, e se sei un QA sei responsabile di cogliere ciò che lo sviluppatore ha mancato.
Se un sacco di bug sono passati all'ambiente di produzione, entrambe le parti dovrebbero sentire l'acido delle loro responsabilità.

    
risposta data 25.09.2016 - 13:39
fonte
0

Diverse organizzazioni vedono i ruoli di tester e sviluppatori in modo diverso. In generale, un tester verifica che il sistema sia conforme alle sue specifiche e soddisfi i suoi requisiti. Uno sviluppatore crea il sistema ed esegue la manutenzione.

In genere, un tester non deve passare una scoperta a uno sviluppatore senza una descrizione riproducibile di come il comportamento del sistema differisce dalle sue aspettative. Quindi può esserci una discussione sulla base di tale descrizione, sia che questo comportamento sia un difetto o, in realtà, in base alla progettazione, sia che la progettazione abbia un senso, se debba essere mantenuta o modificata. Tuttavia, un tester si occupa solo del comportamento del sistema. Non giudicano tra giusto / comportamento sbagliato e non affrontano le cause di tale comportamento.

Se c'è una decisione per correggere il comportamento osservato, uno sviluppatore dovrà rintracciare causa di questo comportamento, ad esempio osservando il programma con un debugger o analizzando i file di log. Mentre gli sviluppatori possono usare il codice sorgente, di solito non hanno una mentalità e una formazione QA.

Tutto ciò significa che mentre non è possibile trovare bug senza uno sviluppatore, lasciare che uno sviluppatore cerchi un bug senza una buona idea di cosa cercare è probabilmente un uso non ottimale delle risorse. Idealmente, un tester dovrebbe provare a farlo. Dopotutto, il codice stesso può essere perfetto se la causa del problema era durante l'analisi dei requisiti, o se la causa è nella comprensione del dominio del problema da parte dello sviluppatore. Uno sviluppatore potrebbe essere "cieco" a tali cause.

Quindi, mentre i tester portano competenze uniche e un punto di vista prezioso, potrebbero non essere in grado di riprodurre alcun comportamento segnalato. Uno sviluppatore probabilmente ha una migliore comprensione del sistema, può vedere possibili circostanze che potrebbero nascondere il problema a un tester o può contribuire a rendere il comportamento più facilmente riproducibile. Per esempio. È improbabile che i bug di concorrenza siano riproducibili con un approccio black-box, ma spesso possono essere provocati con un sleep(1) ben inserito nel codice. Se un tester ritiene di poter essere coinvolto in qualcosa, ma non ha le conoscenze o le capacità per perseguire con successo, dovrebbe ovviamente coinvolgere altri che lo fanno, compresi gli sviluppatori.

Per riassumere, la responsabilità di riprodurre un certo comportamento tende a dipendere dal controllo qualità. Naturalmente i tester e gli sviluppatori dovrebbero collaborare dove necessario. Una determinata organizzazione può avere politiche formali o informali su come ciò dovrebbe essere fatto, o anche usare una definizione diversa per i ruoli "tester" e "sviluppatore".

    
risposta data 25.09.2016 - 13:46
fonte

Leggi altre domande sui tag