Comment évaluer la qualité d'un produit logiciel

Question

J'ai un produit, X, que nous livrons à un client, C chaque mois, y compris des corrections de bugs, des améliorations, de nouveaux développements, etc.) Chaque mois, on me demande de « garantir » la qualité du produit.

Pour cela, nous utilisons un certain nombre de statistiques recueillies lors des tests que nous effectuons, telles que :

• taux de réouverture (nombre de bugs rouverts/nombre de bugs corrigés testés)
• taux de nouveaux bugs (nombre de nouveaux bugs, y compris les régressions, trouvés lors des tests/nombre de bugs corrigés testés)
• pour chaque nouvelle amélioration, le nouveau taux de bug (le nombre de bugs trouvés pour cette amélioration/nombre de jours)

et divers autres personnages.

Il est impossible, pour des raisons que nous n'aborderons pas, de tout tester à chaque fois.

Donc, ma question est :

Comment estimer le nombre et le type de bugs qui subsistent dans mon logiciel ?Quelles stratégies de test dois-je suivre pour m'assurer que le produit est bon ?

Je sais que c'est une question un peu ouverte, mais bon, je sais aussi qu'il n'y a pas de solutions simples.

Merci.

Answer 1

Je ne pense pas que vous puissiez vraiment estimer le nombre de bugs dans votre application.À moins d’utiliser un langage et un processus permettant des preuves formelles, vous ne pouvez jamais vraiment en être sûr.Il vaut probablement mieux consacrer votre temps à configurer des processus pour minimiser les bogues plutôt qu'à essayer d'estimer combien vous en avez.

L’une des choses les plus importantes que vous puissiez faire est de disposer d’une bonne équipe d’assurance qualité et d’un bon suivi des éléments de travail.Vous ne pourrez peut-être pas effectuer des tests de régression complets à chaque fois, mais si vous disposez d'une liste des modifications que vous avez apportées à l'application depuis la dernière version, votre personnel d'assurance qualité (ou personne) peut concentrer ses tests sur les parties de l'application qui devrait être affectée.

Une autre chose qui serait utile, ce sont les tests unitaires.Plus vous couvrez votre base de code, plus vous pouvez être sûr que les modifications apportées à un domaine n'ont pas affecté par inadvertance un autre domaine.J'ai trouvé cela très utile, car parfois je change quelque chose et j'oublie que cela affecterait une autre partie de l'application, et les tests unitaires ont immédiatement montré le problème.Les tests unitaires réussis ne garantissent pas que vous n'avez rien cassé, mais ils peuvent contribuer à accroître la confiance dans le fait que les modifications que vous apportez fonctionnent.

De plus, c'est un peu redondant et évident, mais assurez-vous de disposer d'un bon logiciel de suivi des bogues.:)

Answer 2

La question est de savoir qui vous demande de fournir les statistiques.

S'il s'agit de personnes non techniques, falsifiez les statistiques.Par « faux », j'entends « fournir des chiffres inévitablement dénués de sens, mais réels » du type que vous avez mentionné.

S'il s'agit de techniciens sans expérience CS, ils devraient être informés du problème d'arrêt, qui est indécidable et plus simple que de compter et de classer les bogues restants.

Il existe de nombreuses mesures et outils concernant la qualité des logiciels (couverture du code, complexité cyclomatique, directives de codage et outils pour les appliquer, etc.).En pratique, ce qui fonctionne, c'est d'automatiser autant de tests que possible, de demander à des testeurs humains d'effectuer autant de tests non automatisés que possible, puis de prier.

Answer 3

Je pense que garder les choses simples est la meilleure façon de procéder.Classez vos bogues par gravité et corrigez-les par ordre décroissant de gravité.

De cette façon, vous pouvez fournir la version de la plus haute qualité possible (le nombre de bugs importants restants est la façon dont j'évaluerais la qualité du produit, par opposition à certaines statistiques complexes).

Answer 4

La plupart des méthodologies agiles abordent assez clairement ce dilemme.On ne peut pas tout tester.Vous ne pouvez pas non plus le tester un nombre infini de fois avant de le publier.La procédure consiste donc à s’appuyer sur le risque et la probabilité du bug.Le risque et la probabilité sont des valeurs numériques.Le produit des deux vous donne un numéro RPN.Si le nombre est inférieur à 15, vous expédiez une version bêta.Si vous pouvez le ramener à moins de 10, vous expédiez le produit et poussez le bug pour qu'il soit corrigé dans une prochaine version.

Comment calculer le risque ?

Si c'est un crash, c'est un 5 si c'est un crash mais que vous pouvez fournir un travail, c'est un nombre moins de 5.Si le bug réduit la fonctionnalité, c'est un 4

Comment calculer la vraisemblance ?

pouvez-vous le reproduire à chaque fois que vous courez, c'est un 5.Si la solution fournie provoque toujours un crash, alors moins de 5

Eh bien, je suis curieux de savoir si quelqu'un d'autre utilise ce système et je suis impatient de connaître son expérience à ce sujet.

Answer 5

Quelle est la longueur d'une ficelle?Au final, qu’est-ce qui fait un produit de qualité ?Les bugs donnent une indication oui, mais de nombreux autres facteurs sont impliqués, la couverture des tests unitaires est un facteur clé dans l'OMI.Mais d’après mon expérience, le principal facteur qui détermine si un produit peut être considéré comme de qualité ou non est la bonne compréhension du problème à résoudre.Souvent, ce qui se passe, c'est que le « problème » que le produit est censé résoudre n'est pas compris correctement et les développeurs finissent par inventer la solution à un problème qu'ils ont développé dans leur tête, et non le problème réel, ce qui crée des « bugs ». .Je suis un fervent partisan de l'itération Agile développement, de cette façon le produit est constamment confronté au « problème » et le produit ne s'éloigne pas trop de son objectif.

Answer 6

Les questions que j'ai entendues étaient : comment estimer les bugs de mon logiciel ?et quelles techniques dois-je utiliser pour garantir que la qualité est bonne ?

Plutôt que de suivre un cours complet, voici quelques approches.

Comment estimer les bugs de mon logiciel ?

Commencez par l’historique, vous savez combien vous en avez trouvé pendant les tests (espérons-le) et vous savez combien ont été trouvés après coup.Vous pouvez l'utiliser pour estimer votre efficacité dans la recherche de bogues (DDR - Defect Detection Rate en est un nom).Si vous pouvez montrer que pendant une période de temps constante, votre DDR est cohérent (ou en amélioration), vous pouvez donner un aperçu de la qualité de la version en devinant le nombre de défauts post-version qui seront découverts une fois le produit publié.

Quelles techniques dois-je utiliser pour garantir une bonne qualité ?

L'analyse des causes profondes de vos bogues vous indiquera des composants spécifiques qui sont bogués, des développeurs spécifiques qui créent du code bogué, le fait que le manque d'exigences complètes entraîne une mise en œuvre ne correspondant pas aux attentes, etc.

Réunions d'examen du projet pour identifier rapidement ce qui était bon, afin que ces choses puissent être répétées et ce qui était mauvais et trouver un moyen de ne plus les répéter.

J'espère que cela vous donnera un bon départ.Bonne chance!

Answer 7

Il semble que le consensus soit que l'accent devrait être mis sur les tests unitaires.Le suivi des bogues est un bon indicateur de la qualité du produit, mais il n'est précis que par votre équipe de test.Si vous utilisez des tests unitaires, cela vous donne une mesure mesurable de la couverture du code et fournit des tests de régression afin que vous puissiez être assuré que vous n'avez rien cassé depuis le mois dernier.

Mon entreprise s'appuie sur des tests au niveau du système/intégration.Je vois beaucoup de défauts introduits en raison d'un manque de tests de régression.Je pense que les "bugs" où la mise en œuvre des exigences par le développeur s'écarte de la vision de l'utilisateur sont en quelque sorte un problème distinct qui, comme Dan et rptony l'ont déclaré, est mieux résolu par les méthodologies Agile.