Comment décidez-vous quels défauts sont acceptables pour la mise en service du logiciel?

how do you decide which defects are acceptable

Software Go-Live est toujours un grand événement pour tout logiciel. Il est important de s'assurer absolument que tout fonctionne et que nous sommes mettre à disposition des utilisateurs un logiciel de qualité .

Un produit défectueux ou prématuré ou instable ou difficile à utiliser peut entraîner de nombreuses pertes financières et pourrait également faire perdre confiance à l'utilisateur dans la marque elle-même.

Souvent, nous entendons dire que les tests doivent être effectués jusqu'à ce que nous remplissions les critères de sortie. Nous entendons également dire que les défauts doivent être corrigés à un niveau acceptable.

Bien que ces lignes directrices sonnent bien, elles sont vagues.

Pour être plus précis:

• Quel pourcentage de défauts est acceptable pour la mise en service du logiciel?
• Comment décidez-vous des défauts ouverts avec lesquels le logiciel peut être mis en service?
• Quoi types de défauts sont plus sérieux que les autres?

Lecture recommandée => Quand arrêter les tests?

Avez-vous déjà eu ces questions? Ensuite, cet article va vous aider à y répondre. Continuer à lire…

Les logiciels complexes ne sont pas exempts de défauts et c'est une histoire de poule et d'oeuf sur la fermeture des défauts par rapport au logiciel de travail.

Plus vous corrigez les défauts, plus il y a de chances qu'un nouveau défaut ait été injecté lors de la fermeture du défaut. Alors,

• Comment décidez-vous de l'étendue des défauts et du type de défauts avec lesquels vous pouvez aller vivre?
• Comment basez-vous le logiciel à déployer pour la mise en service?
• Comment les coordinateurs UAT appellent-ils à la mise en service ou non?
• Sur quels paramètres les logiciels doivent-ils être jugés?
• Comment répondons-nous - Le logiciel est-il adapté à l'utilisation et apportera-t-il de la valeur aux parties prenantes?

La mise en production est une étape majeure pour le client ainsi que pour le fournisseur car elle est généralement liée aux étapes de paiement. Tous deux ont la responsabilité égale de garantir le succès des grands projets de transformation.

Mon expérience montre que les clients veulent un bon rapport qualité-prix et ont critère de sortie pour UAT à mettre en service.

Lesdits critères de sortie définiraient plus ou moins l'étendue acceptable des problèmes dans tous les domaines de l'application, tels que:

1. Fonctionnel
2. Performance et charge
3. Convivialité
4. Sécurité
5. Intégration avec des systèmes externes
6. Rapports
7. Migration de données

Je crois que chacun de ces types de défauts doit être expliqué plus en détail. Et c'est exactement ce que nous allons faire maintenant:

comment ouvrir le fichier jar exécutable

#1. Défauts fonctionnels:

Si le logiciel est créé selon les spécifications données par le client, il doit répondre aux exigences. Tous les écarts sont enregistrés comme des défauts fonctionnels.

Défauts fonctionnels sont ensuite classés selon gravité et priorité .

Les considérations suivantes sont importantes:

• Les défauts de gravité élevée et de priorité sont généralement ceux qui auraient un impact sur l'utilisation quotidienne du logiciel. Ces types de défauts sont ceux qui doivent être corrigés avant la mise en service. Aucune exception.
• Parfois, les défauts fonctionnels sont classés comme des demandes de changement car ils ne faisaient pas partie des exigences initialement données. Ces CR, qui sont indispensables pour que les entreprises fonctionnent après la mise en service, sont également indispensables à mettre en œuvre.
• La classification des défauts et la priorisation des défauts fonctionnels sont effectuées par les coordinateurs UAT en collaboration avec les utilisateurs métiers et les analystes métiers. Habituellement, le client a un critère de sortie indiquant le pourcentage de défauts pouvant être mis en service.

# 2. Défauts de performance et de charge:

Défauts de performance sont importants à prendre en compte lors de la mise en service et plus encore si le logiciel doit être utilisé par des utilisateurs externes.

Si le logiciel est lent pour un nombre donné d'utilisateurs, les utilisateurs éviteront d'utiliser le logiciel car le chargement prend beaucoup de temps. Les utilisateurs ont tendance à se déplacer vers le site du concurrent si le logiciel est très lent, perdant ainsi des affaires.

Parfois, les parties de l'application qui ne sont pas destinées au client peuvent également avoir un impact sur les performances.

Par exemple: S'il y a un traitement par lots qui s'exécute à la fin de chaque journée et si le temps de réponse de l'application en souffre pendant ce temps, les performances du lot sont également un facteur à prendre en compte.

• Les performances sont généralement mesurées en termes de temps de réponse des écrans pour rendre et devenir disponibles pour les utilisateurs alors qu'il y a un certain nombre d'utilisateurs simultanés sur le système.
• Les tests de performance sont effectués à l'aide d'outils tels que LoadRunner , WebLoad , Neoload etc.
• Les performances du logiciel à une charge donnée et à une charge future prévue sont généralement documentées dans le contrat et doivent être démontrées avant la mise en service.
• Les écrans ou parties de l'application les moins utilisés par les utilisateurs sont reportés aux évaluations après la mise en ligne.
• Les performances dépendent également du type de matériel et des conditions réseau sur lesquelles le logiciel est déployé.
• Les tests de performance sont effectués pendant l'UAT dans le matériel spécifié à l'aide d'outils de performance et leurs défauts sont suivis d'une manière similaire à celle des défauts fonctionnels. Ils sont également hiérarchisés et un consensus est atteint sur le respect des critères de sortie pour la mise en service.
• Habituellement, les tests de performance et de charge dans UAT sont effectués une fois que l'UAT fonctionnel par les utilisateurs métier est terminé et qu'un critère de sortie acceptable pour les défauts fonctionnels est atteint.

# 3. Défauts d'utilisabilité:

Le logiciel créé devrait être facilement utilisable par les utilisateurs finaux en utilisant différents raccourcis clavier, raccourcis, le nombre minimum de navigation d'écran, pagination etc. Le logiciel doit être intelligent et intuitif.

S'il y a trop de mouvements de la page avant de passer à l'écran approprié, les utilisateurs manifestent généralement moins d'intérêt pour l'utilisation du logiciel.

• Des directives d'utilisabilité sont créées avant la construction du logiciel. Le logiciel doit adhérer à ces directives.
• Il peut également y avoir des restrictions d'outils lors de la création du logiciel qui doivent être surmontées intelligemment avant que le logiciel ne soit utilisable par les utilisateurs finaux.
• Avec un logiciel hautement utilisable, un utilisateur final peut saisir des données jusqu'à 5 fois le logiciel normal.
• L'aspect et la convivialité du logiciel doivent être nets et les problèmes juridiques doivent être résolus avant la mise en service.
• Plusieurs fois, un consultant en convivialité est nommé pour assurer une expérience d'utilisation fluide aux utilisateurs.
• La documentation qui doit accompagner l'application logicielle doit également respecter des directives d'utilisation strictes car elles peuvent être utilisées légalement.
• Les défauts d'utilisabilité enregistrés par les testeurs UAT / testeurs externes sont également considérés comme des défauts fonctionnels et de performance et doivent répondre aux critères de sortie pour la mise en service.

# 4. Défauts de sécurité:

Sécurité du logiciel est un problème brûlant car l'application logicielle peut être piratée et les données sensibles des clients peuvent être volées en un rien de temps.

Par conséquent, un logiciel fiable ne devrait pas permettre même à un pirate informatique très compétent d'accéder à l'application sans les privilèges appropriés.

• Les tests de sécurité sont effectués dans UAT avec des entrées spécifiques dans le logiciel pour s'assurer qu'il n'est pas piratable.
• Les tests de sécurité sont effectués par des pirates légaux qui tentent de pirater le logiciel pour vérifier s'il est vulnérable.
• Tous les défauts de sécurité doivent être fermés avant la mise en service du système.
• La sécurité signifie également la connexion et les rôles et privilèges accordés à divers utilisateurs (externes et internes) pour utiliser différentes sections des applications et également pour créer et approuver des données.

# 5. Intégration avec des systèmes logiciels externes:

En règle générale, une application logicielle qui doit être déployée sur le site du client doit s’interfacer avec tout logiciel existant qui pourrait déjà y exister.

Par exemple: Avec le système d'impression, ils ont utilisé ou il pourrait s'agir de systèmes externes tels qu'une application de facturation ou des systèmes d'écran de données. L'application logicielle déployée doit s'intégrer de manière transparente à ces systèmes externes. Toutes les entrées et sorties de ces systèmes doivent fonctionner de manière synchrone. La technologie englobe aujourd'hui les applications mobiles et les différentes plates-formes logicielles que l'application doit être compatible avec .

La vérification de l'interfaçage du système externe doit être effectuée de manière approfondie pendant les étapes du système et de l'UAT. Cela devrait être un must sur les critères de sortie qui devraient être satisfaits avant la mise en service.

# 6. Rapports:

Les rapports de l'application logicielle sont un moyen essentiel de montrer que les données à l'intérieur de l'application correspondent.

Par exemple: toutes les données relatives à la facturation doivent correspondre aux soldes créditeurs et débiteurs.

• Toutes les données du logiciel doivent se réconcilier. Cette réconciliation des données au sein du logiciel est indiquée par des rapports et ils doivent fonctionner comme prévu.
• Cela est particulièrement vrai si la migration des données d'un ancien système vers un nouveau système est l'objectif principal de la version actuelle.

#7. Migration de données:

Si un ancien système est remplacé par un nouveau, les données de l'ancien système sont déplacées vers le nouveau (une fois qu'une date limite est établie en utilisant le nouveau système). Les données migrées doivent être prises en charge par le nouveau système tel que défini lors de la collecte des besoins.

Toutes les anciennes données peuvent ne pas être disponibles dans le nouveau système; cependant, un instantané des anciennes données pourrait être disponible dans le nouveau système. Ces données devraient être disponibles comme convenu.

Remarque : La liste ci-dessus n'est pas exhaustive. En fonction du type d'application, il se peut que vous deviez valider plus de choses ou que tout ce qui précède ne soit pas applicable. Ainsi, une compréhension approfondie du logiciel, de l'objectif commercial, des attentes des utilisateurs et des dépendances architecturales ou matérielles est indispensable pour développer des critères de sortie complets.

Un exemple de critères de sortie pour la mise en service:

C'est juste un exemple. Cela peut varier d'un projet à l'autre.

• 100% des défauts de priorité 1 sont fermés (gravité critique et priorité 1)
• 90% des défauts de priorité 2 sont fermés (gravité élevée et priorité 2) avec une solution de contournement logique disponible pour le reste des 10% des défauts. Et, un plan est disponible pour fermer le reste des 10% des défauts.
• La liste de contrôle du déploiement et de l'intégrité de la production est prête.
• L'équipe de support à la production a été formée et prête à fermer les tickets.
• 70% des défauts de priorité 3 sont fermés et un plan est en place pour fermer le reste des 30% de défauts faibles.

Quelques points à noter:

• Toutes les définitions de gravité et de priorité sont décidées lors des réunions d'affaires entre le client et le fournisseur au début du programme.
• Une fois tous les défauts UAT enregistrés et tous les autres défauts fermés, les coordinateurs UAT et les sponsors commerciaux se réunissent pour faire le point sur les défauts en suspens et ouverts. Si tous les défauts requis pour la mise en service du premier jour sont résolus, les sponsors commerciaux constatent qu'ils sont prêts pour la mise en service et mettent le logiciel en production.

En conclusion

Nous espérons que cet article vous a donné un aperçu de certaines des considérations importantes liées à la création de critères de sortie solides comme le roc qui protègent le logiciel contre d'éventuelles pannes de production.

A propos de l'auteur: Il s'agit d'un article invité de Krishnan Venkatraman. Il a près de 18 ans d'expérience dans les tests de logiciels. Il a travaillé sur de nombreux projets de tests logiciels importants et complexes.

N'hésitez pas à poster vos questions / commentaires ci-dessous.

lecture recommandée

• Meilleurs outils de test de logiciels 2021 (Outils d'automatisation des tests QA)
• Emploi d'assistant QA en test logiciel
• Cours de test logiciel: à quel institut de test logiciel dois-je adhérer?
• Choisir les tests logiciels comme carrière
• Travail d'indépendant de rédacteur de contenu technique de test de logiciels
• Quelques questions d'entretien intéressantes sur les tests de logiciels
• Commentaires et évaluations du cours de test de logiciels
• Programme d'affiliation d'aide aux tests de logiciels!