Réponse

Historique de la question :

Les tests des aspects non fonctionnels ont émergé lorsqu'il est devenu évident qu'une fonctionnalité fonctionnant parfaitement sur le plan logique peut être inconfortable, lente ou inaccessible pour certains utilisateurs. Ces défauts sont difficiles à détecter automatiquement, c'est pourquoi les testeurs manuels jouent ici un rôle clé.

Problème :

Les testeurs se concentrent souvent uniquement sur la fonctionnalité, ignorant la performance, l’ergonomie et l'accessibilité. Les défauts non fonctionnels sont difficiles à formaliser et à expliquer, leur subjectivité complique l'obtention d'une évaluation claire.

Solution :

Lors des tests, il est important de consacrer du temps conscient aux vérifications non fonctionnelles. Pour la performance, enregistrez le temps de réponse (par exemple, avec un chronomètre), pour l’ergonomie décrivez les inconvenances et donnez des exemples, pour l'accessibilité utilisez des check-lists ou des outils (par exemple, en activant un lecteur d'écran).

Caractéristiques clés :

Nécessitent une formulation claire des critères d’acceptation.
Les résultats d'évaluation sont souvent subjectifs, il est donc important d’argumenter les rapports.
Tous ces défauts ne sont pas acceptables avant une version – certains sont critiques.

Questions pièges.

Tous les défauts non fonctionnels doivent-ils être signalés par un rapport de bug par le testeur ?

Pas toujours. Si le problème est subjectif, il peut parfois suffire d’en discuter avec l'équipe et de le documenter comme une amélioration (demande de fonctionnalité).

Le testeur doit-il définir ses propres métriques de performance ?

Seulement si elles ne sont pas spécifiées dans les exigences ou le cahier des charges, sinon s'y référer.

Est-il obligatoire d'avoir un logiciel ou des outils spéciaux pour les tests non fonctionnels ?

Non, des vérifications de base peuvent tout à fait être réalisées manuellement (par exemple, mesurer le temps manuellement, analyser l'accessibilité avec une check-list).

Erreurs typiques et anti-patters

Ignorer les critères non fonctionnels.
Rapports subjectifs sans preuves mesurables.
Titres et descriptions de bugs trop généraux ou vagues.

Exemple de la vie réelle

Cas négatif

Le testeur a remarqué que la page du catalogue mettait plus de 10 secondes à se charger, mais n’a pas signalé de bug, pensant que “c’était probablement le cas pour tout le monde”.

Avantages :

N'a pas encombré l'équipe avec des tickets discutable.

Inconvénients :

Expérience utilisateur diminuée, les clients sont déçus, la direction a appris le problème par les plaintes.

Cas positif

Le testeur a soigneusement documenté que la page du catalogue se chargeait en 12 secondes lors de la première connexion, a joint une capture d'écran du chronomètre et proposé des options d'optimisation possible.