Ho un'app PHP che è molto grande. Di solito ci sono 2-3 sviluppatori che ci lavorano a tempo pieno e stiamo arrivando al punto in cui stiamo apportando modifiche e creando bug (funzionalità per la tosse!). Il software non è complesso per dire, ma c'è molto da fare (35 ~ controller, sugli stessi modelli, ecc.).

Anche facendo attenzione è facile cambiare in questa vista (modificando un ID su un elemento) per distruggere una query ajax che si verifica in una condizione speciale (disconnesso stando in piedi su un piede).

I test unitari sono le prime cose che mi vengono in mente, ma li abbiamo provati su un'altra app, ed è così facile dimenticarli / o passare più tempo a scrivere test che a fare test. Abbiamo un ambiente di gestione temporanea in cui il codice viene controllato prima di inviare live.

Forse abbiamo bisogno di una persona Q / A a tempo parziale?

Qualcuno ha qualche suggerimento / pensiero.

Sì, hai bisogno di personale di Q / A. Alcuni dei molti motivi includono

• Un tester dedicato costa denaro, ma spesso meno denaro di uno sviluppatore, quindi il vantaggio di non utilizzare il tuo tempo è maggiore della spesa aggiuntiva.
• Un tester dedicato sa come testare le cose, in particolare quelle che non è ovvio come automatizzare. Condurre test automatizzati per interagire con un sistema attraverso un browser è una disciplina un po 'pelosa ma consolidata. Se trovi qualcuno che già sa come farlo, non devi dedicare ancora più tempo all'apprendimento di buoni strumenti e configurazioni.
• Un tester professionista sa come trovare effettivamente i difetti. Sono molto più propensi a pensare come penserà un utente dell'applicazione e quindi esercitare quegli stati nel sistema che verranno effettivamente in produzione, il che significa che quei bug che risultano altamente visibili tenderanno a essere trovati prima , risparmiando imbarazzo e costi per patch ultra-urgenti.
• In generale, un tester non pensa come uno sviluppatore . È difficile comunicare quanta differenza fa se non l'hai sperimentata. Consapevolmente o no, uno sviluppatore non vuole trovare difetti. Sanno come funziona il sistema e tendono ad evitare i tipici input o dati assurdi (per loro) che causano problemi nella vita reale. Se qualcosa funziona in modo inaspettato, sanno come aggirarlo e tendono a non vederlo affatto come un difetto. Non lo fanno maihanno difficoltà a capire cosa significano le risposte di sistema, perché le hanno scritte, anche se questa è una delle principali cause di problemi in quasi tutti i sistemi reali. In breve: i programmatori tendono ad essere cattivi nell'avere i problemi tipici che hanno gli utenti, perché sono specialisti altamente qualificati. Un tester ha un tempo molto più semplice nell'esecuzione dei test più rilevanti.

Detto questo, nulla batte la cooperazione produttiva tra uno sviluppatore e un tester per guidare la qualità del sistema attraverso il tetto. Uno sviluppatore nota spesso i sintomi che qualcosa non va prima del tester. Uno sviluppatore può spesso consigliare a un tester come riprodurre un problema in modo molto più efficiente e come scrivere un rapporto sul problema corretto, ovvero includere quei dettagli che sono effettivamente necessari per capire il problema. Ma tutto ciò richiede almeno un tester con cui puoi lavorare insieme.

Molto probabilmente hai bisogno di test di regressione più o migliori (non specificamente test unitari ). Che tipo di test che dovresti essere devi analizzare te stesso, ma dovrebbero rilevare i bug di cui stai parlando. Ti suggerisco di iniziare a fare un piano di test e dare priorità a quei test - e quando lo fai, inizialmente non pensare troppo all'automazione dei test.

Successivamente, chiediti se puoi automatizzare alcuni o la maggior parte dei test con ragionevole sforzo. Se la risposta è sì, allora dovresti programmarli. Se la risposta è "no" e pensi che la "persona a tempo parziale Q / A" sia più economica, allora dovrebbe essere ovvio ciò di cui hai bisogno. Nella maggior parte dei casi, è una buona idea avere entrambi: una persona di Q / A per test manuali e inventare nuovi test, e anche molti test di regressione automatizzati.

Assumi un QA professionale

Questo dovrebbe essere fatto se stai sviluppando un progetto commerciale. Avere un prodotto pronto senza una solida strategia di test ti costerebbe di più con le correzioni di bug. Inoltre, acquisire nuovi clienti o fidelizzarli dipenderà anche dalla validità della tua applicazione.

In generale, i test unitari dovrebbero essere applicati alla base di codice, tuttavia i test di integrazione e quelli manuali non devono essere scartati.

Il test unitario è davvero una buona idea, soprattutto se il tuo progetto è in crescita. Se scrivere unit test diventa un'abitudine, faciliterà molto il tuo lavoro. C'è un video su YouTube sulla scrittura di codice pulito, che è più facile da mantenere e testare.

Anche un ingegnere addetto al controllo qualità è un must. Un buon tester QA non solo troverà bug nella funzionalità, ma verificherà anche se l'app è user-friendly (che è quasi impossibile testare da soli). Ecco un bell'articolo che spiega come il team addetto al controllo qualità ti farà risparmiare tempo e denaro e ti aiuterà a fornire software migliore.

15 controller e modelli non sono molto grandi. Ci vuole un po 'di tempo per rendere la scrittura test un'abitudine, calciarsi a vicenda (in un modo amichevole prima) aiuta molto.

Esistono strumenti che possono controllare la copertura del test in una certa misura. Strumenti di copertura del codice per PHP