È ragionevole che il mio project manager non si aspetti che nessun bug arrivi a un sito live,

No.

o è ragionevole dire che non posso sempre controllare tutto o garantisco che non ci sarà mai un bug?

Sì, lo è. Altrimenti non spediresti mai nulla.

E come potrei bilanciare la quantità di test previsti con un grande carico di lavoro?

Ora stiamo arrivando da qualche parte: - ). Questa è un'ottima domanda da porre. Questo è ciò che dovresti chiedere al tuo project manager: è loro compito decidere se più funzionalità o una qualità superiore sono più importanti.

Si spera che il tuo manager capisca che c'è un compromesso coinvolto - è il vecchio "triangolo del progetto" (costo - ambito - tempo, scegline due), solo con "qualità" come dimensione aggiunta.

Se il tuo PM capisce che esiste un compromesso tra caratteristiche e qualità, discuterne con loro e decidere insieme dove si vuole essere o se l'intero approccio deve cambiare (ad esempio assumendo un tester). Se il tuo PM non lo capisce, allora hai molte spiegazioni da fare ...

Esperienza precedente: sviluppatore di software su PC e dispositivi da 30 anni.

No. Non è normale aspettarsi nessun bug

Lo estenderei per dire che non è ragionevole. Ci si possono aspettare bug. Ho molta paura quando scrivo qualcosa di complesso e non ha bug . Questo di solito mi dice che mi sto perdendo qualcosa di importante e mi chiedo se sta raggiungendo i metodi che dovrebbe.

Ci saranno dei bug. Periodo. Nessun software tranne il più semplice programma banale è privo di bug. Nessuna. Mai.

Chiederei al tuo PM di trovarti un'azienda che non ha mai avuto bisogno di patchare il suo software. Zero bug è un obiettivo. Nient'altro.

Consentitemi di aggiungere questo comunque. Niente di tutto questo significa che un bug in produzione è accettabile. Risolvilo.

Sì, vendo sistemi finanziari privi di bug personalizzati che funzionano perfettamente all'interno dei loro parametri ben definiti una volta che il cliente li ha. Ogni singola cosa in essi viene testata almeno due volte la maggior parte vengono testati molto più di due volte.

Mi costa molto farli in questo modo, ma quel costo viene trasferito al cliente e il tempo per renderli in questo modo viene preso in considerazione nei tempi.

Non riesco a capire queste altre risposte dicendo che non è possibile soprattutto per piccoli progetti. In effetti non solo è possibile, ma è il risultato desiderabile. Se un cliente veniva da me con un bug, scopriva che avrei licenziato qualcuno. I tempi di inattività di questi sistemi possono costare ai clienti centinaia al minuto.

Personalmente penso che sia irragionevole aspettarsi che nessun bug compaia in produzione quando non esiste un solido framework di test. Quando si esegue il test manuale, si è inclini a perdere errori qua e là.

Ti consiglio di far venire l'idea di utilizzare test automatici, ad esempio utilizzando Selenium o GhostInspector, per assicurarti che le tue funzioni continuino a funzionare, anche dopo che sono state apportate modifiche. Una volta impostati questi test e assicurati che vengano eseguiti prima che le modifiche arrivino alla produzione, dovrebbe essere possibile disporre di un ambiente di produzione privo di semplici bug.

I bug critici e spettacolari sono una cosa. Dovresti sempre provare a testarli il più possibile. E ci sarà sempre una minima possibilità che si verifichi qualche caso limite davvero strano. Il modo migliore per gestirlo è sistemarlo, creare un test e andare avanti.

Tuttavia, penso che sia praticamente impossibile fare ciò che richiedono. La cosa più importante per me è che non esiste una definizione di ciò che è considerato un "bug".

C'è uno stile di cui non piace l'aspetto? L'interfaccia utente non sta esattamente facendo quello che si aspettava?

È qui che devi esaminare veramente: è un bug o un risultato non intenzionale? Ad esempio, se ho reso il testo blu senza alcun obbligo di dire che doveva essere blu o non essere rosso o essere di qualsiasi colore, il project manager mi urla perché ha un aspetto migliore in verde (e non c'era alcun requisito per il verde ), Direi che questo non è un bug e che non ci si poteva aspettare che lo sapessi. Assicurati quando dicono che è un bug: è qualcosa che è un comportamento sostanzialmente inaspettato quando qualcosa era esplicitamente previsto.

Ora non sto dicendo che devi essere veramente pignolo con ciò che è e non è un bug. L'ultima cosa che vuoi è iniziare a scontrarti con il tuo project manager su una cosa del genere. Quello che vuoi fare è rimanere sulla stessa pagina: riconosci di essere d'accordo sul fatto che idealmente dovrebbero esserci zero bug, ma non puoi aspettarti che non accadrà mai. È impossibile conoscere le infinite combinazioni di azioni e aspettative per creare tutti i test per loro. E quasi certamente i bug si verificheranno in molti gradi diversi. L'importante è affrontarli in modo professionale e tempestivo riducendo al minimo l'impatto sugli utenti.

Inoltre, forse non correlato alla domanda principale, ma penso che potrebbe essere utile: quando ho a che fare con qualcuno (un manager, un cliente, un utente, qualunque cosa) che è arrabbiato con me: riconosco le loro preoccupazioni, mi concentro sul capire capire qual è il loro problema e rispondere con empatia e logica. Determina di cosa sono turbati, fai (o in alcuni casi non fai) ciò che deve essere fatto per risolverlo, quindi parlane. Mantieni la calma, pensa e rispondi. Parlare e comunicare sono spesso trascurati e necessari quando entrambe le parti devono fidarsi l'una dell'altra per fare le cose.

Per aggiungere a ciò che altri hanno detto qui, ci sono un paio di cose che vedo qui che sono potenziali insidie ​​per te, insidie ​​che probabilmente hanno aiutato un PM a chiederti di sviluppare software "senza bug" (qualunque cosa significa anche), ma insidie ​​che si distinguono da sole.

• Mancanza di un team di test separato. Anch'io sono uno sviluppatore web e " sono stato in team che eseguono i propri test e team che hanno un team QA dedicato per farlo per loro, e lascia che ti dica una cosa: quest'ultima impostazione è di gran lunga preferita. Come sviluppatore, semplicemente non sarai bravo a cogliere i tuoi errori, in particolare se stai scrivendo entro una scadenza, e in particolare se stai scrivendo un miglioramento molto specifico per una pagina o qualcosa tu. Anche in quelle squadre che facevano le cose "da soli", tendevamo a non testare le nostre cose; invece, abbiamo testato gli ambienti gli uni degli altri.

• Mancanza di documentazione di progettazione specifica. Non credo che il design "privo di bug" sia affatto compatibile con le tecniche Agile perché l'intero punto di Agile è che raccogli i requisiti, costruisci qualcosa che pensi possa soddisfare quei requisiti e in una o due settimane parli con i tuoi stakeholder di quanto bene funzioni il trucco. Un widget che non fa esattamente ciò che i tuoi stakeholder stavano immaginando è una specie di bug (ed è parte del motivo per cui non capisco cosa significhi "senza bug") e l'unico modo per aggirare questo problema nel mio libro è richiedono una documentazione di progettazione complessa e completa che sia praticamente uno schema per l'applicazione web stessa.

• Mancanza di un paradigma di sviluppo basato sui test. Certo, il TDD è una cosa che ho problemi a implementare, specialmente nel mondo dello sviluppo web. Tuttavia, è una buona idea fare il possibile per acquisire familiarità con il software di test disponibile, progettare test che non avranno successo finché non avrai terminato il miglioramento, quindi scrivere per avere successo. Se esegui continuamente questi test sulla tua app web e mantieni quelli vecchi in giro per assicurarti che tutto funzioni ancora, questo potenzialmente automatizza gran parte del lavoro che un team di test separato potrebbe fare e, cosa più importante, il fatto che il le stesse identiche cose vengono testate sempre nello stesso modo significa che c'è poco spazio per ignorare qualcosa.

Comunque, qualunque sia il caso, suona davvero per me come se il tuo PM stesse tagliando due gambe dal triangolo del progetto da sotto di te (in questo caso, richiede alcuni problemi molto specifici relativi al prodotto mentre non paga per le persone per il controllo qualità del tuo lavoro) ea loro modo ti sta preparando per fallimento. No, non va bene.

Sono un tester di software per una grande società di ingegneria e non posso sottolineare abbastanza quanto sia irragionevole il tuo capo.

Lo scopo fondamentale del test non è trovare problemi, ma ridurre il rischio di un prodotto. Questo può essere fatto cercando e trovando problemi, tuttavia per trovare ogni possibile problema, secondo l'International Software Testing Qualifications Board (ISTQB) è impossibile . Va tutto bene avere casi d'uso / accettazione che funzionano, tuttavia rimarrai sorpreso da come i clienti lo useranno. Non hanno una conoscenza di base del sistema, quindi useranno l'intuizione che li condurrà a problemi che TI PERDERÀ .

Il test è un processo continuo che mira a ridurre il rischio del sistema e si arresta solo quando viene raggiunto il livello di rischio concordato. Questo dovrebbe essere stabilito in un piano di test quando il progetto viene avviato e concordato con tutte le parti interessate al progetto.

Pertanto il tuo PM deve capire che nulla è privo di rischi e per assicurarsi che qualcosa sia privo di bug è impossibile, avvicinarsi il più possibile a un bug privo di bug richiederebbe test infiniti.

Deve concordare in che misura raggiungerà il test e definirlo nel piano di test del progetto.

Cerca un modello nel piano di test ISTQB.

Questo è un tipico esempio di compromesso tra costi e benefici. Puoi fornire un tempo di attività più elevato (ad esempio: meno bug) ma costerà di più.

Maggiore è lo sforzo che dedichi alla progettazione / test / automazione / ecc., meno bug avrai. È tuo compito istruire il product manager su questo compromesso ed è il suo ruolo a decidere quanto tempo / denaro / impegno vuole investire nella riduzione dei bug.

È tuo compito spiegare al responsabile del prodotto quanto tempo / sforzo in più richiederebbe per avere meno bug e poi può determinare se è nell'interesse dell'azienda farlo.

Penso che la prossima domanda logica che dovrebbe seguire sia: quanti bug o quanto tempo di inattività puoi tollerare in un anno? Questo è generalmente misurato in nove.

• 3 nove, ovvero una disponibilità del 99,9% significa che avrai 9 ore di inattività all'anno
• 4 nove, ovvero una disponibilità del 99,99% significa che avrai 50 minuti di inattività all'anno
• 5 nove, ovvero una disponibilità del 99,999% significa che avrai 5 minuti di inattività all'anno

Fonte

Un altro interessante articolo sul tempo di attività e se dovresti puntare a 5 9 secondi di tempo di attività: http://www.continuitycentral.com/feature0267.htm

Modifica: Un altro pensiero. Il desiderio di essere privi di bug non è abbastanza buono di per sé. Anche la NASA che mira ad avere il 100% di uptime e zero bug non è in grado di realizzarlo. Ci vuole tempo ed esperienza con l'ambiente, i clienti e i problemi attuali prima di poter comprendere i casi limite che incontrerai e come risolverli.