Cosa si può fare per ridurre il numero di problemi in diretta con le applicazioni?

We require that our updates to applications be tested by at least one other programmer prior to going live.

Questo è un inizio, ma stai scrivendo qui perché hai dimostrato che questo è insufficiente.

Applications should be tested by end users

Abbiamo scherzato sul fatto che avremmo consentito agli utenti finali di testare il nostro codice. Il punto di test è trovare i bug prima degli utenti finali. In questo modo, gli utenti finali hanno una buona esperienza e raccomandano o acquistano altro software.

not [tested by] programmers

Cosa c'è che non va nei test dei programmatori? Penso che sia una parte importante dell'essere un buon programmatore. Alcune scuole di pensiero raccomandano che i programmatori scrivano test prima ancora di scrivere il codice! Penso che il problema a cui stai andando sia solo che i programmatori fanno test.

staging environment in place that is a clone of the live environment

Questo è molto buono. Ma se è veramente un clone, l'apprendimento che si ottiene dall'installazione dallo sviluppo alla messa in scena non viene trasferito dalla messa in scena alla produzione. In un modo o nell'altro, non ottieni il massimo beneficio da questo sistema. Esegui i tuoi test nell'ambiente di staging?

We don't do end user testing really at all.

Il test degli utenti finali di solito riguarda l'accettazione di nuove funzionalità, la facilità d'uso e il soddisfacimento delle esigenze degli utenti. Non per trovare bug. Utenti finali che trovano bug = clienti persi.

We don't have a QA team or anything of that nature. We don't have test cases for our projects that are fully laid out.

Eek! Questa è la causa principale dei tuoi problemi. Un team di QA sarebbe fantastico, ma anche un tester pieno ea tempo pieno capace sarebbe un miglioramento. Potresti avere un appaltatore a breve termine, ma avere qualcuno a bordo a lungo termine che riesca a tessere i test nel tuo intero ciclo di sviluppo sarebbe molto meglio.

Lavoro in una piccola azienda e abbiamo un test di regressione scritto che esaminiamo per ogni versione. Non è divertente, ma cattura i bug. A turno facciamo e basta.

Forse intendi qualcosa di diverso quando parli degli utenti che trovano bug. Se è così, devi trovare un modo diverso di esprimerlo, perché è una proposta perdente se ne ho mai sentito uno. In particolare, sembra che perda clienti. Promuovi invece per:

• Un tester professionale
• Un test di regressione scritto
• Sviluppo basato su test
• Stabilire una cultura della qualità.

Ognuna di queste è una soluzione standard del settore che rispetta il vero problema che sta affliggendo i tuoi profitti. Se mantieni le metriche, dovresti essere in grado di stimare una cifra in dollari per il numero di utenti che escono a causa di bug e la pubblicità negativa generata dai bug. C'è anche un costo opportunità, in cui i clienti che non trovano bug sono più felici e più propensi a raccomandare il tuo prodotto. Se l'80% del costo totale dei bug per la società è sufficiente per assumere un tester, questo è tutto il tuo business case. Davvero uno schianto. Buona fortuna!

Ci sono molti problemi qui.

I personally am completely against this as I think that applications should be tested by end users and not programmers as end users are much better testers than programmers.

Questo è esattamente l'atteggiamento sbagliato. I programmatori sono la prima linea di difesa contro la perdita di spazzatura. I tuoi utenti finali sono gli ultimi a cui desideri eseguire i test. Per prima cosa, è troppo tardi. Questi bug avrebbero dovuto essere rilevati e riparati molto prima che il prodotto uscisse dalla porta. Per un altro, la tua azienda sta rischiando di far diventare quegli utenti finali ex-utenti quando alla fine si ammalano di avere un prodotto buggy che vanno altrove.

We don't do end user testing really at all. We don't have a QA team or anything of that nature. We don't have test cases for our projects that are fully laid out.

Potresti non aver bisogno di un team di controllo qualità, ma ciò non significa che puoi rinunciare alla qualità. Tutti voi dovete agire come se foste membri del team di QA. Devi fare test end-to-end. Il test delle unità non è sufficiente. Devi prendere l'atteggiamento che gli insetti non dovrebbero insinuarsi. Sbattili sul nascere.

Ok, I am just a peon programmer at the bottom of the rung, but I am probably more tired of these issues than the managers complaining about them. So, I don't have the ability to tell them you are doing it all wrong.....I have tried gentle pushes in the correct direction.

A quanto pare qui c'è un problema con la gestione, ma stai spingendo esattamente nella direzione sbagliata. Ho il sospetto che la tua gestione abbia una mentalità da "fare finta" è solo un servizio di qualità. Questo deve cambiare. La concorrenza ti ruberà i tuoi clienti con un prodotto migliore e meno costoso, se non lo fa.

Il collaudo manuale da parte degli sviluppatori oltre "sì, l'app inizia" ecc., è una completa perdita di tempo. Vale la pena fare un test automatico, in quanto sta esaminando le cause dei guasti per vedere se è ragionevolmente possibile impedire che si ripetano nello stesso codice o in un altro codice.

Va bene far testare gli utenti finali se non hai nessun altro. Idealmente è strutturato in modo tale che gli utenti finali possano scegliere di testare o utilizzare una versione più stabile e assicurarsi di avere un buon modo per ottenere informazioni in caso di errore.

Gli utenti finali potrebbero essere le uniche persone che potrebbero pensare, ad esempio, a testare cosa succede quando ci si trova in una locale in cui la conversione di "I" in lettere minuscole non dà "i" (turco, e questo mi ha colpito) o eseguendo l'applicazione da un'unità DVD o senza alcuna rete connessa. Il trucco è coinvolgerli, in realtà rispondere a ciò che riferiscono e farli sentire come se stessero contribuendo invece di essere perseguitati.

Inoltre, in determinati ambienti è possibile selezionare un utente finale "amico" per testare determinate funzionalità / correzioni. Soprattutto se puoi vederli usare il programma, puoi imparare molto in quel modo.

Gli sviluppatori dovrebbero fare veri test di unità e di integrazione che possono essere automatizzati. Idealmente dopo ogni check in / commit (o almeno ogni notte) tutti questi test dovrebbero essere eseguiti e passati prima che il codice venga rilasciato. Esistono numerosi strumenti di integrazione continua che possono essere utilizzati per te (ad es. link ).

Quando definisci le attività per il tuo progetto, assicurati che le tue stime di tempo includano il tempo di sviluppo per la realizzazione di questi test. NOTA: di solito dedichi più tempo alla scrittura dei test rispetto a quando scrivi il codice effettivo dell'applicazione.

Ogni volta che viene segnalato un bug, inizia aggiungendo un test che lo riproduca. Quindi aggiusta il test. Ciò impedirà il ritorno dello stesso bug.

Per quanto riguarda la modifica della visione della gestione, puoi provare quanto segue: * Traccia ogni ora che viene spesa risolvendo bug * Evidenzia i bug che sono tornati ripetutamente * Mostra loro quanto tempo viene sprecato per correggere gli errori piuttosto che migliorare e aggiungere nuove funzionalità * Se hai dei tempi di inattività, avvia questi processi da solo, quindi almeno sai che il tuo codice è buono Se puoi mostrare loro in numeri il costo per la società, potrebbe cambiare la loro prospettiva.

I personally am completely against this as I think that applications should be tested by end users and not programmers as end users are much better testers than programmers.

Questo è non una buona pratica . La funzionalità dell'applicazione dovrebbe essere testata dal programmatore prima di gestirlo nella fase di test. Il controllo qualità deve essere responsabile della verifica della funzionalità e dei moduli correlati nella propria applicazione. Dopo aver passato il QA, i tuoi utenti client (non gli utenti finali) dovrebbero avere un UAT (test di accettazione dell'utente). Una volta passato UAT, lo si distribuisce in produzione.

Tuttavia, se i tuoi programmatori eseguono test attraverso la scrittura di unit test, allora questa è un'ottima pratica da seguire.