J'ai une application PHP qui est très grande. Il y a généralement 2-3 développeurs qui y travaillent à plein temps et nous arrivons au point où nous apportons des modifications et créons des bugs (fonctionnalités contre la toux!). Le logiciel n'est pas complexe, disons, il se passe beaucoup de choses (35 ~ contrôleurs, environ les mêmes modèles, etc.).

Même en faisant attention, il est facile pour un changement dans cette vue (peaufiner un identifiant sur un élément) de détruire une requête ajax se produisant dans certaines conditions spéciales (déconnecté en se tenant debout sur un pied).

Les tests unitaires sont les premières choses qui me viennent à l'esprit, mais nous les avons essayés sur une autre application, et il est si facile de les oublier / ou de passer plus de temps à écrire des tests qu'à faire des tests. Nous avons un environnement de transfert où le code est vérifié avant de pousser en direct.

Peut-être que nous avons besoin d'une personne Q / A à temps partiel?

N'importe qui a des suggestions / réflexions.

Oui, vous avez besoin de personnel Q / A. Certaines des nombreuses raisons incluent

• Un testeur dédié coûte de l'argent, mais souvent moins d'argent qu'un développeur, donc l'avantage de ne pas utiliser votre temps est supérieur aux dépenses supplémentaires.
• Un testeur dédié sait comment tester des choses, en particulier des choses qu'il n'est pas évident de savoir comment automatiser. La conduite de tests automatisés pour interagir avec un système via un navigateur est une discipline quelque peu velue mais bien établie. Si vous avez quelqu'un qui sait déjà comment le faire, vous n'avez pas besoin de passer encore plus de temps à apprendre de bons outils et de bons réglages.
• Un testeur professionnel sait réellement détecter les défauts. Ils sont beaucoup plus susceptibles de penser comme le pensera un utilisateur de l'application, et donc d'exercer les états du système qui apparaîtront réellement en production, ce qui signifie que les bogues qui se révèlent très visibles auront tendance à être trouvés plus tôt , vous évitant l'embarras et les coûts des patchs ultra-urgents.
• Généralisant cela, un testeur ne pense pas comme un développeur . Il est difficile de dire combien cela fait de différence si vous ne l'avez pas vécu. Consciemment ou non, un développeur ne veut pas trouver de défauts. Ils savent comment fonctionne le système et ont tendance à éviter les entrées ou les données absurdes typiques (pour eux) qui causent des problèmes dans la vie réelle. Si quelque chose fonctionne de manière inattendue, ils savent comment le contourner et ont tendance à ne pas voir cela comme un défaut. Ils n'ont jamaisont du mal à comprendre ce que signifient les réponses du système, car ils les ont écrites, même si cela est une cause majeure de problèmes dans presque tous les systèmes réels. En bref: les programmeurs ont tendance à ne pas avoir les problèmes typiques des utilisateurs, car ce sont des spécialistes hautement qualifiés. Un testeur a beaucoup plus de facilité à effectuer les tests les plus pertinents.

Cela dit, rien ne vaut une coopération productive entre un développeur et un testeur pour conduire la qualité du système à travers le toit. Un développeur remarque souvent des symptômes que quelque chose ne va pas avant le testeur. Un développeur peut souvent conseiller à un testeur comment reproduire un problème beaucoup plus efficacement et comment rédiger un rapport de problème approprié, c'est-à-dire inclure les détails réellement nécessaires pour comprendre le problème. Mais tout cela nécessite au moins un testeur avec lequel vous pouvez travailler.

Vous avez très probablement besoin de tests de régression plus ou meilleurs (pas spécifiquement des tests unitaires ). De quel type de tests devriez-vous faire pour vous analyser, mais ils devraient détecter les bugs dont vous parlez. Je vous suggère de commencer à faire un plan de test et de prioriser ces tests - et lorsque vous faites cela, au début, ne pensez pas trop à l'automatisation des tests.

Ensuite, demandez-vous si vous pouvez automatiser certains ou la plupart des tests avec un effort raisonnable. Si la réponse est oui, vous devez les programmer. Si la réponse est «non», et que vous pensez que la «personne à temps partiel pour les questions / réponses» est moins chère, alors ce devrait être ce dont vous avez besoin. Dans la plupart des cas, c'est une bonne idée d'avoir à la fois - une personne Q / A pour les tests manuels et inventer de nouveaux tests, et beaucoup de tests de régression automatisés, aussi.

Embaucher un QA professionnel

Cela devrait être fait si vous développez un projet commercial. Avoir un produit prêt sans une stratégie de test robuste vous coûterait plus cher avec des corrections de bugs. En outre, gagner de nouveaux clients ou les fidéliser dépendra également de la qualité de votre application testée.

De manière générale, les tests unitaires doivent être appliqués à votre base de code, mais les tests d'intégration et les tests manuels ne doivent pas être ignorés.

Le test unitaire est une très bonne idée, surtout si votre projet se développe. Si l'écriture de tests unitaires devient une habitude, cela facilitera beaucoup votre travail. Il y a une vidéo sur youtube sur l'écriture de code propre, qui est plus facile à maintenir et à tester.

L'ingénieur QA est également un must. Un bon testeur QA trouvera non seulement des bogues dans la fonctionnalité, mais testera également si l'application est conviviale (ce qui est presque impossible à tester par vous-même). Voici un bel article expliquant comment l'équipe QA vous fera gagner du temps et de l'argent et vous aidera à fournir de meilleurs logiciels.

15 contrôleurs et modèles n'est pas très grand. Il faut un certain temps pour que le test d'écriture devienne une habitude, se donner des coups de pied (d'abord de manière amicale) aide beaucoup.

Il existe des outils qui peuvent contrôler la couverture du test dans une certaine mesure. Outils de couverture de code pour PHP