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


25

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.


Grande question, merci d'avoir pris le temps de reformuler!

@Mark Trapp: Merci. Je pense que c'est assez basique mais je peux en poser quelques autres (sur la base de la série de questions précédente)
Robert Koritnik

Réponses:


8

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é.


J'ai légèrement modifié ma question. Pourriez-vous également fournir vos estimations?
Robert Koritnik

Presque tous les projets (80% +) auxquels j'ai participé ont été testés méthodiquement, mais j'ai ensuite fait presque exclusivement des applications stratégiques d'entreprise.
Martin Brown

Je travaille pour une société pharmaceutique. Je dirais que 80% des applications sont testées par des testeurs et développeurs professionnels. Ces 20% sont des applications à faible risque comme une présentation promotionnelle sur iPad. mais même celui-ci est vérifié ad-hoc par quelqu'un.
yoosiba

5

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.


J'ai légèrement modifié ma question. Pourriez-vous fournir vos estimations du marché professionnel du développement. Parce que vos projets sont passés au crible. Et vos tests sont-ils automatisés ou non?
Robert Koritnik

Qui est cette équipe offshore? Pourriez-vous leur donner une recommandation?
Martin Brown

Habituellement, les grandes entreprises ont des centres de R&D dans d'autres pays (principalement en Asie). Où se fait le développement offshore. L'objectif du développement offshore est de réduire les coûts de développement (une partie de celui-ci).
Nipuna

2

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.


J'ai légèrement modifié ma question. Pourriez-vous également fournir vos estimations sur les tests de logiciels sur le marché professionnel?
Robert Koritnik

@Robert: Je n'ai pas assez changé d'emploi pour donner une estimation générale. D'après le peu que je sais, les choses s'améliorent. Mais alors, c'était moi qui poussais pour des tests unitaires automatiques dans deux des trois cas dont je vous ai parlé ...
sbi

Mais vous parlez à d'autres développeurs d'autres sociétés, n'est-ce pas?
Robert Koritnik du

2

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.


J'ai légèrement modifié ma question. Pourriez-vous également fournir vos estimations des tests de logiciels sur le marché professionnel?
Robert Koritnik

2

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é.


2
Je suis fortement en désaccord avec vous - vous n'avez jamais vu un routeur tomber en panne? Les jeux Xbox, Playstation et Wii se bloquent-ils? Avez-vous déjà eu un écran bleu ou «L'application ne répond pas» dans Windows?
JBRWilkinson

@JBRWilkinson Je pense que vous manquez ses modificateurs de gravité ainsi que la possibilité d'ingérer la grande majorité des jeux PC qui, comme le dit Paul, sont souvent bogués. Quoi qu'il en soit, la liste pourrait probablement utiliser une certaine amélioration, mais le sentiment est correct: la fiabilité est souvent corrélée aux pertes fiscales associées à l'échec.
Jay Carr

1

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 ...


Merci pour votre réponse honnête. Quelles sont vos estimations (vérifiez ma question modifiée)?
Robert Koritnik

Mon estimation pour l'Italie est inférieure à 10% des tests de code formels. Peut-être presque uniquement du code critique pour la mission.
Wizard79

J'ai travaillé en Irlande, en Angleterre, en Écosse et en Slovénie et, il semble que l'Italie ne semble pas différente.
Robert Koritnik

1

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.


Ces tests seraient-ils automatisés ou principalement manuels? J'ai légèrement modifié ma question. Pourriez-vous également fournir vos estimations des tests de logiciels sur le marché professionnel?
Robert Koritnik

La plupart de nos tests sont effectués manuellement.
Shamim Hafiz

1

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.


2
J'entends ce que vous dites, mais c'est difficile à justifier. Des études ont montré que plus un bogue passe longtemps inaperçu, plus il coûte, de façon exponentielle. Le coût des bogues qui parviennent au client est énorme, et les corriger entraîne souvent de nouveaux bogues, si un cadre de test unitaire n'est pas en place (un scénario probable lorsque ce type de mentalité de «correction et correction» est présent). Par conséquent, une utilisation judicieuse des outils et des méthodologies de test peut s'avérer bien moins coûteuse que le correctif et la correction.
Robert Harvey

3
Je suis de plus en plus sceptique à l'égard de ce dogme, en particulier de la façon dont il est universellement appliqué. Je suis sûr que c'est vrai parfois, mais tous les bugs ne sont pas créés de la même manière, pas plus que toutes les applications. Je trouve qu'il est très difficile d'avaler qu'un bogue dans une application interne utilisée par 10 personnes est beaucoup plus cher à corriger s'il est trouvé pendant les tests unitaires que dans une version de correctif. Cela peut être exponentiellement plus embarrassant, mais pas plus coûteux, sauf si vous ignorez les coûts réels du temps passé par un testeur à trouver le bogue.
JohnFx du

2
Je me demande également si ces statistiques n'étaient pas plus applicables aux projets massifs (par exemple, les systèmes d'exploitation) à partir desquels ils ont été créés et ne se traduisent pas dans les applications de type CRUD que la plupart d'entre nous construisons pour gagner leur vie.
JohnFx

Je suis d'accord avec vous deux et j'ai vu les deux cas. Mais j'ai certainement l'impression que ma part des coûts exponentiels que Robert décrit, en particulier lorsqu'un bug a été dans le logiciel si longtemps que d'autres fonctionnalités commenceraient à se casser s'il était corrigé. Avec un codage frénétique assez médiocre avec des gens qui travaillent autour des problèmes assez longtemps et des bogues qui restent à l'intérieur assez longtemps, 1 + 1 n'est pas 2. C'est 7. Et si ce n'est pas 7, tout s'effondrera.

1

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.


1

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à.


Je suis également dans une entreprise de dispositifs médicaux et l'introduction aux BPF (bonnes pratiques de fabrication, parler de la FDA pour un processus de conception / test contrôlé) a été assez ouverte pour moi. Cela a fait de moi un meilleur ingénieur (et un expert en docbook malheureusement)
Bill Gribble

0

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.


J'ai légèrement modifié ma question. Pourriez-vous également fournir vos estimations des tests de logiciels sur le marché professionnel?
Robert Koritnik

@Robert: Je ne comprends pas votre question "estimations des tests de logiciels". Vous me demandez mon avis sur le nombre d'entreprises testées? Mon estimation serait peut-être de 90% ou plus en fonction de ce que j'ai vu de mes propres yeux. Les tests font partie intégrante du développement professionnel.
Bryan Oakley

0

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.


0

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.