Les tests logiciels sont-ils réellement effectués sur des projets professionnels?

J'ai été impliqué dans de nombreux projets dans plusieurs entreprises car je suis développeur depuis longtemps et je suis entrepreneur.

J'estime que moins de 20% des projets sont méthodiquement testés. Par tests méthodiques, je veux dire tous les tests au-delà des tests ad hoc sans plan.

J'estime également que moins de 10% des projets sont minutieusement testés méthodiquement lorsqu'ils ont des testeurs dédiés au sein de l'équipe, un document de plan de test, où les développeurs écrivent des tests automatisés, puis ils suivent également la couverture des tests et mesurent les résultats.

Deux questions

1. Quelle est votre estimation en pourcentage de ce problème?
2. Quelle est votre expérience professionnelle en matière de tests de logiciels?

Remarque additionnelle

Étant donné que la question des tests méthodiques peut obtenir des réponses assez biaisées (les gens aiment se vanter d'être supérieurs aux autres), j'encourage les autres développeurs (ceux qui ne sont pas exposés aux tests méthodiques) à fournir également leur réponse, car sinon cela ressemblera à des tests. se fait partout ... sauf dans votre entreprise.

Le modèle que j'ai vu avec les tests au cours de ma carrière montre une forte correspondance avec le risque d'échec dans un projet. Les grands projets sont plus susceptibles d'être testés que les petits, les applications critiques sont plus susceptibles d'être testées que les sites Web marketing, les systèmes internes sont moins susceptibles d'être testés que ceux destinés au public.

Cela dit, il y a encore des projets qui ont été excessivement testés et ceux qui n'ont pas été suffisamment testés, mais ce sont la minorité.

Tout ce que nous produisons est entièrement testé. Si notre équipe QA interne est surchargée, nous avons une équipe offshore qui teste les projets. Ils ne sont pas aussi bons que notre équipe interne, mais c'est un sujet différent.

Les trois sociétés pour lesquelles j'ai travaillé au cours des 15 dernières années ont toutes passé des tests unitaires qui se sont déroulés automatiquement.

Dans deux de ces entreprises, j'ai insisté pour les présenter.

Au cours des 9 dernières années, je n'ai essentiellement rencontré que des tests d'acceptation / de régression. Il n'y a eu que quelques tests unitaires.

Oui.

La quantité de tests est proportionnelle à la fiabilité requise de l'application, ainsi qu'à la maturité de la culture du programmeur.

Les sites Web marchent souvent dans les trous de bogues (les liens cassés sont un défaut).

Les jeux vidéo sont souvent bogués.

Windows (enfin) est assez fiable.

Les routeurs sont très fiables

Les moniteurs d'hôpital "ne cassent pas"

Notez que le coût fiscal de la défaillance est également corrélé à la fiabilité.

En 10 ans, je n'ai jamais travaillé sur un projet avec des tests de code formels.

Dans mon travail actuel, nous n'avons que des tests fonctionnels.

Le problème est que personne dans la gestion ne connaît même les tests de code. Le département de test ne connaît même pas le test de code, il suit simplement les spécifications de haut niveau et vérifie si nous nous conformons d'un point de vue comportemental / fonctionnel.

Nous n'avons pas de leader logiciel qualifié qui nous oblige à bien coder. Le résultat est un code spaghetti, beaucoup de régressions, des horaires manqués et ainsi de suite ...

Nous sommes une société offshore de taille moyenne en Asie du Sud. Cependant, nous faisons toujours des projets basés aux États-Unis et travaillons directement avec les exigences envoyées par la société américaine.

Nous appliquons des tests méthodiques sur chaque application que nous créons. Peut-être que la qualité des tests n'est pas à la hauteur, mais nous les utilisons.

Autant le puriste en moi ne veut pas accepter qu'une certaine gestion des risques soit intégrée dans la décision concernant la rigueur avec laquelle vous testez ou si vous effectuez des tests formalisés. Pour les applications internes, qui, je le soupçonne, représentent un grand% des projets de programmation, le coût de la publication d'un bogue, puis de sa correction rapide après l'avoir remarqué, peut parfois être compensé par le coût d'une équipe de test complète. Bien sûr, cela dépend de l'application et du coût potentiel des échecs.

Cela dit, je ne pense pas que la planification de la gestion des risques soit la raison de l'absence de tests formalisés. Je pense que c'est davantage dû au fait que les gestionnaires non techniques ne comprennent pas la valeur qu'elle offre et ne voient que le coût.

Mon échantillon est très petit pour en déduire des pourcentages, mais c'est quand même le cas.

L'un était une entreprise de puces + micrologiciels sans usine, qui effectuait des tests fanatiques. Tests automatisés 24/7 sur des dizaines d'installations, chacun testant des dizaines d'unités en parallèle. Équipes logicielles dédiées au développement de logiciels de test. Équipes matérielles dédiées à la construction de bancs d'essai. Tests de compatibilité contre des dizaines de concurrents. Heck, ils ont même acheté une installation de testeur de puces de plusieurs millions de dollars pour développer et déboguer certains des tests que les fabs exécutent lorsque les puces quittent la fonderie.

Un autre était une banque. Celui-ci est un environnement complètement différent: pas de versions de produit, mais beaucoup de logiciels internes pour continuer à fonctionner en continu. Ces gars ont testé le cr * p de chaque changement qu'ils ont fait. Ils avaient une séparation très stricte des environnements DEV / QA / PROD, des tests de régression automatisés, des tests QA obligatoires approuvés par les utilisateurs finaux avant leur mise en production, etc.

Alors oui, les gens font des tests méthodiques. Mais comme vous pouvez le constater, je n'ai jamais travaillé dans un endroit qui expédie votre logiciel GUI typique pour l'utilisateur d'ordinateur typique.

J'écris actuellement un firmware intégré pour une petite start-up fabriquant des dispositifs médicaux sans fil. Nous sommes tenus de faire des tests rigoureux et d'avoir un service qualité complètement séparé dirigé par quelqu'un qui relève directement du PDG. Je n'ai jamais eu mon code testé aussi minutieusement auparavant par des testeurs distincts (la seule fois qui se compare, c'est quand je travaillais sur des systèmes de télévision par satellite il y a environ 15 ans.)

Nos résultats de test sont soumis à la FDA (jusqu'à présent, nous avons obtenu deux autorisations de la FDA - chaque soumission était d'environ 500 pages). Nos méthodologies de développement et de test font toutes deux l'objet d'audits périodiques.

Ce ne sont donc pas seulement les grandes entreprises qui font beaucoup de tests formels.

Remarque - Au cours de mes 25+ années de programmation / consultation sous contrat, j'ai également travaillé pour de nombreuses entreprises qui n'ont pratiquement pas effectué de tests formels. La plupart d'entre eux ne sont plus là.

Presque toutes les entreprises où j'ai été ont fait des tests méthodiques. Mon entreprise actuelle a quelques tests de base sur le style unitaire et ce n'est pas suffisant. Nous avons eu quelques problèmes de qualité à cause de cela. Je recommande fortement des tests approfondis indépendants sur tout projet qui sera utilisé par quelqu'un d'autre que vous-même. L'argent dépensé en vaudra la peine. Les applications qui ne fonctionnent pas ne sont pas utilisées. Cela vaut pour les faces internes et externes.

Au cours des vingt dernières années de ma carrière dans une dizaine d'entreprises, je n'ai jamais travaillé sur un projet qui ne faisait pas de tests. La quantité de tests différait dans chaque entreprise, mais chaque projet de développement professionnel sur lequel j'ai travaillé a fait des tests formels. Cela vaut également pour les petites et moyennes entreprises (où "petite" signifie moins de 10 employés et "moyenne" signifie quelques milliers d'employés ou moins).

Certaines entreprises n'avaient pas beaucoup de tests automatisés, d'autres pas beaucoup de tests manuels, mais ils en avaient au moins un ou l'autre.

Cela dépend des besoins du client. Dans une situation contractuelle, il existe probablement des tests d'acceptation. En interne est généralement une slapjob avec peu de tests. Les produits de consommation sont généralement très couverts de fonctionnalités fréquentes mais rugueux sur les bords.

Réponse courte: Oui

Longue réponse:

1. Je n'ai pas une bonne estimation pour la première catégorie (c'est probablement une certaine distance de zéro, mais combien?), Mais mon expérience corrobore en fait votre deuxième estimation. Il est difficile de donner des pourcentages significatifs, car la quantité et le type de test dépendent du type d'application en cours de développement, du calendrier disponible, ainsi que des compétences des développeurs et de la manière dont le projet est exécuté. Dans la pratique, l'obstacle le plus important pour les développeurs serait le test d'acceptation car il s'agit d'une étape importante à des fins de facturation. Mais c'est aussi le moment où l'inattendu peut se produire (plus d'exigences) et les développeurs peuvent être contraints de livrer et de se débrouiller avec tous les tests adhoc qui sont possibles et opportuns (à ce stade), en plus du temps nécessaire pour le dépannage et le dépassement L'innatendu.

2. J'ai vécu une variété de projets avec différentes combinaisons de facteurs mentionnés ci-dessus:

   • pas de tests unitaires formels, seulement des tests d'intégration et surtout des tests adhoc

   • très formel, allant des tests unitaires aux plans de test détaillés impliquant des ressources d'assurance qualité dédiées, des tests automatisés (tels que menés par les testeurs avec leur propre ensemble d'outils) et des rapports de couverture de code. Mais ceux-ci ne sont pas toujours significatifs pour les développeurs autant que pour les gestionnaires

Sur le plan individuel, je cherche à maintenir une compréhension de mes options en ce qui concerne la rédaction de tests appropriés appropriés à la technologie avec laquelle je traite, et à les exercer à ma discrétion. Fondamentalement, les choses qui sont réellement significatives et bénéfiques pour mon travail, et pas tellement les chiffres.