Affrontare problemi di qualità

Sembra che la complessità del sistema legacy sia tale che nessuno degli sviluppatori capisce veramente tutte le dipendenze e l'accoppiamento. Nell'essere stati assegnati all'utente, stanno modificando il codice che sta causando bug in altre aree e funzionalità a causa di questa non familiarità.

Questo è un problema che a breve termine può essere risolto solo mettendo da parte ulteriori ore per il test di accettazione degli utenti per ogni story utente. Senza un tester dedicato questo rallenterà in modo significativo i tempi di sviluppo.

A lungo termine, tuttavia, il refactoring e l'abbassamento dell'accoppiamento insieme all'inclusione graduale dei test unitari aiuteranno il software a diventare più stabile.

Hai già affermato più volte che assumere un tester dedicato non è possibile, ma è importante. Cerca di convincere il management che è una buona idea. I tester costano meno soldi degli sviluppatori, quindi se uno sviluppatore sta eseguendo il test di accettazione degli utenti, puoi sostenere che il gestore sta pagando troppi soldi per testare il lavoro all'ora. Se ci pensi, assumere un tester salvare i soldi del boss.

Uno dei motivi per cui gli sviluppatori non possono testare efficacemente (il modo in cui un QA dedicato fa, non il test unitario che tutti gli sviluppatori dovrebbero fare) è perché sanno cosa hanno fatto nel codice. Pertanto non spingono i bordi del sistema. Non faranno le cose che un utente potrebbe fare perché sanno che non funzionerebbe. Quindi non trovano gli insetti, i test unitari non prendono. Inoltre, non ho mai visto gli sviluppatori di applicazioni fare test di integrazione o test di regressione in modo efficace. Tutto quello a cui tengono è il loro piccolo pezzo, non come si combina con tutto il resto. Hai bisogno di questo tipo di test e chiaramente non lo capisci.

Hai davvero bisogno di qa professionale per prendere questa roba prima di andare in produzione. Salva i soldi e il tempo della compagnia e imbarazza dove gli utenti trovano i bug.

Dato che non hai qa professionale, è necessario che almeno uno sviluppatore diverso esegua il test rispetto a chi ha scritto il codice. Qualcuno il cui obiettivo è rompere il codice dell'altra persona. Se puoi prendere in prestito alcuni utenti per fare test degli utenti, è ancora meglio.

Potresti anche provare ad assegnare uno sviluppatore alla volta per il QA per uno Sprint (puoi cambiare ogni sprint se necessario) quella persona svilupperà gli altri tipi di test oltre i test unitari e scriverà i casi di test per l'utente tester da eseguire. Potresti trovare qualcuno che è veramente bravo e che gode di questo e all'improvviso hai l'inizio della tua squadra di QA.

Non esiste un modo scientifico con cui è possibile garantire la qualità senza allocare risorse nel piano, preparare casi di test completi ed eseguire tali casi.

Affrontare il fatto che il sistema ha problemi e avviare un progetto per risolverlo. Definisci casi di test che coprano l'ambito delle responsabilità del tuo progetto in modo accurato. Potrebbe essere il caso che non sei responsabile per il sistema legacy. Rendi il management consapevole di questo. Costruisci piccole squadre che potrebbero lavorare su interi flussi. Il singolo sviluppatore potrebbe non avere familiarità con l'intero flusso, quindi le tue piccole squadre dovrebbero essere costruite con questo in mente.

Beh, non è strettamente necessario un team di test dedicato, puoi anche fare in modo che i tuoi sviluppatori sviluppino i test. Non è il massimo e, ovviamente, quando stanno testando non si stanno sviluppando. E passare avanti e indietro comporta un sovraccarico con esso. Ma puoi raddoppiare. Tutto ciò che serve è tempo.

I test di regressione automatizzati giornalieri sono buoni. Il fatto che lasci passare un sacco di bug significa che i tuoi test non valgono molto. Devono essere ulteriormente sviluppati. E 2 settimane per sviluppare script di test per un sistema complesso non sono molti. C'è un motivo per cui le persone vengono assunte a tempo pieno per questo. Quanto tempo ci è voluto per svilupparsi? Ci vorrà così tanto tempo per testarlo completamente. Altrimenti, prevedi di spendere l'80% del tuo tempo per il debug (che è 4 volte più lungo dello sviluppo).

Ma prima aggiusta i bug in arrivo. Registrali e sviluppa i test case nel test di regressione. Quando hanno tempo, gli sviluppatori dovrebbero lavorare sullo sviluppo dei casi di test. Non aver paura di procurarti hardware extra per simulare l'input.

Stai avendo (o iniziato ad avere) test unitari, il che è veramente buono per iniziare.

Come stai dicendo che questo è un progetto complesso, è necessario un team di controllo qualità separato. Uno sviluppatore che testa il proprio codice non guarda l'applicazione con il punto di vista degli utenti e sarà in grado di progettare ed eseguire i casi di test che danno un maggiore livello di sicurezza.

Fino a quando il team di controllo qualità non è stato stabilito, chiedi agli sviluppatori di seguire i passaggi per aumentare la copertura del test per la tua applicazione e aumentare la sicurezza dell'applicazione.

1- Continuate ad aggiungere test unitari per tutti i nuovi codici e correzioni di errori.

2- Per test funzionale:

a) Annota i casi di test e falli rivedere con gli utenti. Non è necessario scrivere documenti dettagliati, ma i punti elenco sono sufficienti (ad esempio, aprire la scheda attività di un dipendente, approvare la scheda attività. Modificare la pianificazione per attraversare la mezzanotte, regolare e approvare la scheda attività, ecc.)

b) eseguirli e se trovi bug, non fermarti e correggere i bug. Ma documenta i bug e correggili alla fine e rilascia. Provali in ambienti non dev.

c) Ho anche visto problemi in arrivo per alcuni utenti / o alcuni scenari specifici. Questo è un chiaro indicatore di alcuni dei dati non sono corretti e altri dati vanno bene o il design dell'applicazione ha problemi.

quindi Se continui a vedere che molti bug si stanno insinuando, il problema deve essere a livello di progettazione o di dati. Assicurati che i dati siano puliti e db abbia vincoli sufficienti. Per problemi di progettazione, dovrai rifattorizzare l'applicazione lentamente.

Buona fortuna.