Difetti revisione e gestione

Mi sembra una ripartizione della comunicazione a un paio di livelli. Dal momento che non hai anche specificato quale sia la tua posizione nel progetto, suppongo che tu sia un dev regolare che lavora sotto un architetto.

Analisi del flusso di lavoro

In primo luogo sembra che non ci sia un modo ben definito per gestire i bug mentre vengono inseriti nel sistema di tracciamento. Qualcuno deve classificarli in base all'importanza e quindi assegnarli per essere fissati entro i limiti di budget e di tempo.

Anche i sistemi di tracciamento dei bug di base hanno la capacità di classificare, classificare e documentare vari aspetti del problema. Se ritieni che queste funzioni possano essere utilizzate al meglio, fai una discussione con il tuo architetto o manager.

Analisi della fiducia

Ancora più importante, sembra che ci sia un po 'di difensività e sfiducia nei confronti di chiunque sia il tuo tester.

Comprendi che il loro ruolo è quello di agire come utente, quindi potrebbe essere meglio se non sono troppo impantanati con i dettagli della specifica dei requisiti. Se sollevano bug per te, non dare immediatamente per scontato che non abbiano compreso abbastanza bene i requisiti; prova ad approfondire cosa stanno cercando di fare esattamente e perché sono atterrati in quel caso d'uso.

Anche se è qualcosa che continua a venire, potrebbe esserci qualcosa che non è stato definito correttamente nei requisiti.

Sommario

Tutto sommato, comprendi solo che tu e i tester siete nella stessa squadra e che entrambi cercherete di creare un prodotto migliore per l'utente. Dopo tutto, i clienti non hanno intenzione di ottenere i documenti dei requisiti; o la cosa funziona o no.

Ho molta familiarità con questo problema!

Inoltre, controverso, credo che sia causato da AGILE DEVELOPMENT!

Pensaci. Agile cerca di guidare gli sviluppatori più velocemente facendoli concentrare sul completamento di ciò che viene richiesto e passare all'attività successiva. Questo è grandioso, ma mette una grande pressione sulla persona che scrive le specifiche. Se perdono qualcosa, non si farà.

Di solito la persona che scrive le specifiche o le attività è un project manager che a: non è tecnico e b: non ha ricevuto nulla di più di 'Voglio una pagina Webernet! hai 3 mesi! '

Si aggira il problema di "nessuna specifica" assoldando i tester e dicendo "Alza qualsiasi cosa che non ti piace come un bug"

Anche questo va bene, perché Agile dovrebbe essere iterativo. Questi bug possono tornare in coda come requisiti e basta girare la rotella di sviluppo finché tutti sono felici.

MA! quello non succede. Quello che succede è che il compito non è accettato come fatto a causa di bug, il progetto è ritardato indefinitamente e gli sviluppatori sono accusati di essere lento o di scrivere codice buggato.

La mia soluzione personale per questo (come sviluppatore) è di chiedere prima di scrivere i casi di test.

Se sai quali sono i test, puoi testare il tuo codice prima di rilasciarlo per testare e dovrebbe passare il 100% delle volte. Happy Testers, happy Devs

Se la lista dei test sembra breve, il PM può vederlo lì e dire "Oh, sicuramente dovrebbe anche farlo?" Buon PM