Sì, hai bisogno dello staff 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 cose che non è ovvio come automatizzare. Guidare test automatici per interagire con un sistema attraverso un browser è una disciplina un po 'pelosa ma ben consolidata. Se ricevi qualcuno che sa già come farlo, non devi dedicare ancora più tempo all'apprendimento di buoni strumenti e set-up.
• Un tester professionista sa come trovare effettivamente i difetti. È molto più probabile che pensino come un utente dell'applicazione penserà, e quindi eserciteranno quegli stati nel sistema che verranno effettivamente messi in produzione, il che significa che quei bug che risultano essere altamente visibili tenderanno a essere trovati prima , risparmiando imbarazzo e costi per patch ultra urgenti.
• Generalizzando che, un tester non pensa come uno sviluppatore . È difficile esprimere la differenza che ciò comporta se non l'hai provato. Consapevolmente o no, uno sviluppatore non vuole per trovare difetti. Sanno come funziona il sistema e tendono ad evitare i tipici input o dati privi di senso (per loro) che causano problemi nella vita reale. Se qualcosa funziona in modo inaspettato, sanno come aggirarlo e tendono a non vederlo come un difetto. Loro mai hanno difficoltà a capire cosa significano le risposte del sistema, perché le hanno scritte, anche se questa è una delle principali cause di problemi in quasi tutti i sistemi reali. In poche parole: i programmatori tendono ad avere problemi con i problemi tipici degli utenti, perché sono specialisti altamente qualificati. Un tester ha un tempo molto più semplice per eseguire i test più rilevanti.

Detto questo, niente 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 è sbagliato prima che il tester lo farebbe. Uno sviluppatore può spesso consigliare a un tester come riprodurre un problema in modo molto più efficiente e come scrivere un rapporto di emissione corretto, cioè includere i dettagli che sono effettivamente necessari per capire il problema. Ma tutto ciò richiede almeno un tester con cui poter lavorare insieme.

Molto probabilmente hai bisogno di test di regressione più o meno (non in particolare test unit ). Che tipo di test dovresti analizzare, ma dovrebbero rilevare i bug di cui stai parlando. Ti suggerisco di iniziare a fare un piano di test e di dare priorità a quei test e, quando lo fai, inizialmente non pensi troppo all'automazione dei test.

In seguito, chiediti se è possibile automatizzare alcuni o gran parte dei test con un ragionevole sforzo. Se la risposta è sì, allora dovresti programmarli. Se la risposta è "no", e pensi che il "part time Q / A person" sia più economico, allora dovrebbe essere ovvio ciò di cui hai bisogno. Nella maggior parte dei casi, è una buona idea avere sia una persona Q / A per testare manualmente e inventare nuovi test, sia un sacco di test di regressione automatici.

Assumi un controllo qualità 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 correzioni di bug. Inoltre, l'acquisizione di nuovi clienti o il loro mantenimento dipenderà anche da quanto è buono il test della tua applicazione.

In generale, i test di unità dovrebbero essere applicati al tuo codice base, tuttavia non devono essere scartati test di integrazione e test manuali.

Il test delle unità è davvero una buona idea, soprattutto se il tuo progetto è in crescita. Se scrivere test di unità 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 l'ingegnere del QA è un must. Un buon tester di QA non troverà solo bug in funzionalità, ma testerà anche se l'app è user-friendly (che è quasi impossibile testare da soli). Qui è un bell'articolo che spiega come il team del QA ti farà risparmiare tempo e denaro e aiuterà a fornire un software migliore.

15 controller e modelli non sono molto grandi. Ci vuole un po 'di tempo per fare in modo che l'abitudine alla scrittura sia un'abitudine, aiutarsi a vicenda (in modo amichevole prima) aiuta molto.

Esistono strumenti che possono controllare in qualche modo la copertura del test. Strumenti di copertura del codice per PHP