dovrei aiutare il team QA a trovare bug? [duplicare]

When I go through the code for an already developed application, I can see that there are some bugs

Questi piccoli bug dovrebbero essere trovati durante il test di sviluppo e dopo che lo sviluppatore di test di sviluppo deve anche eseguire l'applicazione per assicurarsi che funzioni come previsto prima di passarla al QA, quindi già lì qualcosa non sta andando molto bene.

I inform the QA team about these and ask them to open defects so that I can fix those bugs

Se il codice che viene distribuito nell'ambiente QA è bacato e quindi stai chiedendo loro di restituirlo a te in modo che tu possa aggiustarlo, posso assolutamente capire perché sarebbero un po 'strani. Si tratta davvero di aspettative e in questo caso si aspettavano che il codice distribuito funzionasse, se non funzionasse allora perché è stato distribuito in primo luogo?

La comunicazione è la chiave - quindi se per qualche motivo c'è una separazione tra te e l'effettivo team di sviluppo, quindi questo problema, consiglierei di parlarne e di spiegare loro il processo mentale effettivo che hai superato te stesso.

Se non c'è separazione tra te e il team di sviluppo e tu eri responsabile di quel codice in qualche modo allora sì non è professionale perché è stato rilasciato senza essere completamente testato.

Tuttavia, presumo che non sia così perché hai trovato i bug a metà strada e stavi semplicemente facendo loro sapere che parlare con loro e spiegare la situazione sarebbe la cosa migliore in questo caso.

Ho lavorato per un certo numero di aziende di alto profilo. È stato sempre accettato volentieri se una persona apre un bug quando scopre un bug. Non importa chi sia quella persona e di chi possa essere responsabile.

Se qualcuno potrebbe essere offeso avendo un bug archiviato contro il loro codice, queste persone agiscono in modo assolutamente non professionale. Uno sviluppatore dovrebbe essere il più privo di ego possibile, e una segnalazione di bug dovrebbe essere il più irreprensibile possibile. Questo vale anche per le autopsie.

Non c'è colpa e nessuna colpa; solo difetti che devono essere scoperti e risolti. Sospetto che non si esercitino nemmeno su recensioni di codice; dovresti.

Posso solo dirti quello che faccio. Per prima cosa, se vedi un bug, allora è "colpa tua" e dovresti inserirlo nel tracker, scrivere un test che mostri il bug, correggerlo e inviare la correzione. Se il team di controllo qualità vede un ma è "colpa loro" e deve essere inserito nel tracker con i passaggi da riprodurre.

Ora non si tratta di colpa, ma di responsabilità a lungo termine. Quando fai una riunione per parlare dei progressi, chi sarà il "capo di quell'errore". La migliore risposta è di solito quella che la trova. Significa che la squadra che inserisce il bug è quella che deve andare "hai risolto X ancora".

Ancora più importante è il fatto che non tutti i bug verranno risolti. Nel mondo reale devi gestire i bug v.s. vincoli di tempo e altri costi. È "ok" avere un bug che non verrà risolto nella prossima versione, purché tutti sappiano dove si trova, e c'è una chiara aspettativa di quando verrà risolto.

Quindi, innanzitutto se vedi un bug inseriscilo nel tracker. Gestire di conseguenza. Un bug documentato è 1000 volte migliore di quello non documentato.

Ora per dire al team addetto al controllo qualità di fare cose. Personalmente ritengo che non siano affari miei quello che fa il team di controllo qualità. Finché trovano bug e li inseriscono nel tracker in un formato concordato, allora sono bravo. Avendo quella separazione sento di massimizzare la loro utilità (trovare "bug" che si presentano, non perché errori di codice, ma a causa di errori di comprensione). Se sto dando una direzione al lavoro, mi sento come se non fossi in grado di fare ciò che devono fare. Come sono andati persino a rifiutare di aiutarli a fare qualcosa nell'app in modo che potessimo vedere se le cose che dovevano fare per svolgere il loro compito erano abbastanza intuitive.

Infine, a seconda della struttura aziendale, non dovresti dire a QA di fare qualsiasi cosa. Ti riferiscono? Firmate il loro assegno paga. Più spesso quindi il QA è uguale a Dev nella scala aziendale. Dire a qualcuno di fare più lavoro non è sicuramente il tuo lavoro (a meno che non lo sia). Ciò non significa che non lavori a stretto contatto con il controllo della qualità, dovresti esserlo. Allo stesso tempo, non fa parte della "tua squadra" così via.

La cosa più importante da tutto questo è:

• Se trovi un bug, inseriscilo e gestiscilo. Non chiedere ad altri di
• Non dare indicazioni di lavoro agli altri team, non è il tuo posto di lavoro

Ricorda che questa è una compagnia molto diversa dall'altra. Questo corrisponde strettamente a "cosa faccio". Ma diverse società faranno le cose in modo diverso. Dovresti usare il loro SOP o lavorare con loro per sviluppare un documento SOP.

Sono anche rimasto lontano dalle tecniche di gestione, organizzazione o planing. Ci sono molte risposte alle domande se adotti una tecnica o un'altra.

Sì, dovresti. La qualità del software è responsabilità di tutti i membri del progetto. Ok, fammi ritornare immediatamente ... dovresti effettivamente aprire il bug tu stesso, se è quello che il tuo manager dice che dovresti fare (dopo aver controllato che non sia già segnalato).

Avere un muro tra i due gruppi è controproducente, secondo me, perché porta a responsabilità, problemi di responsabilità e scarsa comunicazione. Se qualcuno è difensivo o distaccato, il problema è loro, la leadership del team o la leadership dell'azienda. Riconoscere che come imprenditore è importante, suppongo, in modo da non calpestare i piedi e compromettere il tuo stato.

Tutti i bug dovrebbero essere rintracciati perché, tranne in alcuni rari casi, tutti i software di una certa dimensione portano un backlog di bug. Comprendere il backlog è importante quando si sceglie su cosa lavorare, se rilasciare o meno un'iterazione e pianificare per il futuro.

Guardando il titolo "dovrei aiutare il team QA a trovare i bug?"

La mia risposta è No, o almeno incidentalmente.
Dovresti concentrarti sull'aiutare gli utenti del prodotto e quindi sul futuro dell'azienda con prodotti privi di errori.

I bug che vedi esistono per una vasta gamma di motivi di base che possono essere che non sono stati notati o lamentati, ma possono anche esistere perché ci sono altri progetti più importanti, non abbastanza entrate dal prodotto, niente di buono modi per distribuire patch al prodotto, documentazione che in realtà include bug, ecc. ecc.

Indica il caso in cui l'elemento deve essere registrato come rappresentante dell'utente.

Ottenere l'accesso al sistema di tracciamento dei bug per inserire i bug può essere buono, tuttavia non aspettatevi di iniettare improvvisamente un po 'di lavoro nei flussi di lavoro esistenti senza commenti. Quello che devi veramente fare è avere più dirigenti senior a bordo con questo e fargli comunicare la gente su questi biglietti e dedicare loro tempo e sforzi.

Non tentare di trasferirli negli attuali ticket perché generalmente riceverai il feedback dallo sviluppatore che "che non ha nulla a che fare con questo ticket e non ho toccato quell'area", più "è stato così prima del mio biglietto ". Quindi questo approccio tende ad essere un antipasto.

Fondamentalmente è necessario che i tuoi input lavorino insieme a tutti gli altri per creare un buon prodotto.