Après les tests fonctionnels, de performance, de compatibilité et d’utilisabilité au sens ISO – 25 010, je m’attaque dans cet article à la famille des tests de fiabilité afin de savoir exactement à quoi correspond la « fiabilité » dans le cadre de la qualité logicielle.
Pour avoir plus d’informations sur la norme ISO – 25 010, je vous invite à lire ou relire mes autres articles sur le sujet.
Les tests de fiabilité sont une famille de tests peu connu et encore trop peu utilisé, leur rôle est pourtant très important afin de connaitre la qualité d’une application sur des points souvent rédhibitoires.
En effet, qui supporte une application qui n’est pas fiable ? Par fiabilité j’entends une application sur laquelle je peux compter quand j’en ai besoin c’est-à-dire disponible ou lorsqu’elle ne l’est pas, savoir qu’elle le sera de nouveau rapidement afin d’être sûr que je pourrai faire ce que je souhaite en temps et en heure.
Les tests de fiabilité ont pour but de vérifier les points cités ci-dessus au moyen de 4 types de tests qui sont les tests de maturité, de disponibilité de robustesse et de récupérabilité.
Comme vous pouvez le voir avec l’image ci-dessus, la famille des tests d’utilisabilité contient, d’après la norme ISO – 25 010, 4 types de tests spécifiques, chacun ayant un rôle bien définit :
- Les tests de maturité
Le produit correspond-il bien au besoin et plus particulièrement au besoin pour les opérations courantes des utilisateurs ? Cela ressemble à des tests du niveau 4, c’est à dire d’acceptation mais cela est primordial pour les utilisateurs. Si une ou plusieurs fonctionnalités indispensables pour les utilisateurs ne sont pas présentes ou ne correspondent pas au besoin des utilisateurs le produit n’est pas assez mature et rencontrera difficilement du succès (sauf si mise à jour rapide avec ces besoins). Un produit mature va donc être un produit qui répond aux besoins des utilisateurs dans la grande majorité des cas.
Les tests de maturité sont là pour s’assurer que la couverture des besoins des utilisateurs est bien là.
- Les tests de disponibilité
Qui utilise un logiciel lorsqu’il sait qu’il y a de forte chance que lorsqu’il veuille y accéder ce dernier ne soit pas accessible ? Ce type de problème fait d’ailleurs régulièrement l’objet d’article pour des sites webs qui se retrouvent inaccessibles pendant plusieurs heures ou minutes suite à des pics de charge ou le dysfonctionnement de certains serveurs (on a eu l’exemple en début d’année avec l’ensemble des blogs hébergés par overblog).
Ces tests ont pour but de s’assurer que le produit proposé est bien disponible pour les utilisateurs lorsqu’ils en ont besoin.
Ces tests regroupent évidemment des tests permettant de vérifier que les partenaires indispensables à l’application sont disponibles et que si ce n’est pas le cas l’application a un back-up. Il est également possible de mettre en place des tests vérifiant que l’application peut absorber des pics de charge dans le cas des applications qui peuvent en rencontrer régulièrement (par exemple les sites web lors du début des soldes).
- Les tests de robustesse
Les erreurs comme les erreurs de saisies sont fréquentes lorsque l’on travaille sur un logiciel. Afin de limiter de potentiels bugs, une application doit savoir limiter l’impact de ces dernières.
L’application va-t-elle crasher si je fais une erreur ? L’application va-t-elle continuer de fonctionner normalement ? L’application va-t-elle me prévenir d’une erreur de saisie ? Tout ceci peut être soumis à des tests qui permettront d’avoir une visibilité sur le niveau de robustesse d’un logiciel.
Ces tests sont souvent appelés des « tests négatifs » où l’on teste la réaction de l’application suite à une erreur. Dans une application mail on peut par exemple se tromper ou oublier un destinataire, mettre des PJ trop grosses ou trop de PJ. Tous ces scénarios doivent être reconnus et l’utilisateur doit en être informé. Plus personne n’accepterai que son application mail crash à cause d’une erreur de saisie dans le mail d’un destinataire !
- Les tests de Récupérabilité
Une application vit. Quelle que soit sa qualité il arrivera un moment où elle ne sera plus disponible (même les offres de très haute disponibilité ne s’engagent pas sur du 100%). Dès lors il est particulièrement important de pouvoir corriger cette erreur et rendre le logiciel de nouveau disponible le plus rapidement possible.
Les tests de Récupérabilité sont là pour ça. Ils permettent de vérifier, lors de certaines erreurs combien de temps il faut pour rétablir et remettre en état de marche l’application.
Les utilisateurs sont compréhensifs et savent qu’une application peut ne pas être disponible à certains moments. Ils le sont par contre beaucoup moins si lorsque l’application tombe il savent qu’ils ne pourront plus l’utiliser pendant plusieurs jours !
Les retours sont particulièrement négatifs lorsque les utilisateurs trouvent que l’application n’est plus disponible pendant un temps très long alors qu’ils peuvent même être positif quand l’application est remise sur pieds au bout de quelques minutes, ils peuvent alors parler de bonne réactivité.
Source ISO – 25 010
Syllabus ISTQB fondation 2018 Lien anglais car non disponible en français à la date d’écriture
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
Une réponse