Wiki Fan de Test
Vous n'avez pas de compte ?
S'inscrire
S'inscrire
dans : Pages utilisant des liens magiques ISBN, Heuristique

Heuristiques de test

Se connecter pour modifier

Une heuristique pour simplifier[]

Traditionnellement, les heuristiques sont faites pour trouver une réponse partielle à un problème mais qui suffit par la rapidité de sa réponse [1].

Dans le domaine du test, la combinatoire des actions et valeurs à vérifier est exponentielle ; aussi, le Testeur passe-t-il son temps à utiliser des heuristiques pour simplifier les possibilités. Parmi les méthodes les plus connues, on trouve notamment [2]

  • l'approche par le risque pour adresser les tests les plus critiques (RBT)
  • tester fréquemment et au plus tôt de petites livraisons en adoptant une approche agile plutôt que tout un stock de spécifications à valider après des mois
  • l'utilisation du test par paire pour simplifier les tableaux orthogonaux des tables de décisions [3]
  • l'utilisation du test par paire pour alléger la couverture de décision "MC/DC"

Une heuristique pour y penser[]

Une autre approche des heuristiques dans le test est de permettre au Testeur de proposer des listes afin de ne rien oublier par exemple, en proposant une routine telle que proposée par Stephen Vance [4] :

  • Test des cas nominaux
  • Test des cas alternatifs (variations des cas nominaux)
  • Test des cas d'erreurs
  • Test des permutations des données
  • Tests des valeurs aux limites
  • Test des contraintes dynamiques
  • Test des anomalies
  • etc.

Mais bien que pertinente, cette heuristique ne permet de trouver que des problèmes fonctionnels, c'est pourquoi on a recours à des standards tels que l'ISO9126 - ISO25010, aussi appelée "SQuaRE", est LE standard promu par l'ISTQB qui est souvent utilisé pour traiter la question de stratégie de test et embrasse différentes caractéristiques de la qualité logicielle [5] :

  • Capacité fonctionnelle
  • Fiabilité
  • Performance
  • Utilisabilité
  • Sécurité
  • Compatibilité
  • Maintenabilité
  • Transférabilité

Évidemment, en creusant le sujet on peut se rendre compte que ces découpages sont simplement des tentatives qui sont à adapter au contexte du projet (voir le principe #2 de l'ISTQB - "Les tests dépendent du contexte" [6]) et à ce titre, on pourra trouver des approches complètement adaptées au contexte du métier comme

  • la norme IEC61882 surnommée "HAZOP" [7] qui est utilisées sur les installations chimico-industrielles [2]
  • ou encore la norme IEC60068 [8] qui définit une liste de tests vibratoires à appliquer sur un produit afin d'assurer son fonctionnement dans certains milieux
  • et plus proche du test logiciel, l'entreprise TestInsane [9] fournit plusieurs dizaines de carte mentales autour d'idées de test dans différents contextes.

L'énorme diversité de tests possibles vient évidemment donner une des explications à ce principe de contextualisation des tests et pour aider nos pauvres esprits humains à identifier des idées de tests partagées au travers de méthodes empiriques (et éprouvées), les heuristiques.

On notera que cette approche est d'autant plus pertinente lorsqu'on se trouve en situation de test exploratoire car les idées de test doivent venir assez rapidement d'où la présence de listes

  • au moment où l'on écrit la charte,
  • ou durant l'exploration elle-même.

A ce titre, Karen Nicole Johnson [10] a réuni quelques heuristiques sous la forme de mnémoniques parfois prononçables, avec comme source principale, James Bach et cet article en apportera d'autres, avec un classement proposé.

Heuristiques sur les caractéristiques de qualité attendues sur le produit[]

  • FURPS [11] - Ce modèle nous vient de chez Hewlett Packard et donne une approximation de l'ISO25010
    • Fonctionnalité, Utilisabilité (UX), Robustesse, Performance, Supportabilité
  • FURPS+[12] avec le "+" qui contient les domaines d'exigences suivants
    • Design
    • Implémentation
    • Interface
    • Physique
  • CRUSSPIC STMPL [13] de James Bach propose des caractéristiques de qualité produit
    • Operational Criteria: Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility
    • Development Criteria: Supportability, Testability, Maintainability, Portability, Localizability
  • HICCUPPSF [14] (James Bach) donne des lignes directrices de critères de qualité produit
    • History, Image, Comparable Product, Claims, User Expectations, Product, Purpose, Standards and Statutes, Familiar Problems
  • FEW HICCUPS [15] : c'est une heuristique améliorée de la précédente par Michael Bolton de sorte à vouloir dire "Quelques hoquets" - avec
    • Explainability
    • World
  • SFDIPOT [16] : Pour couvrir un produit - Mnémonique : "San Francisco Depot"
    • Structure, Function, Data, Interfaces, Platform, Operations, Time

Heuristiques sur l'approche du test par rapport à l'environnement[]

  • CIDTESTD (Kid Tested) [13] de James Bach propose des caractéristiques liées à l'environnement du projet
    • Customers, Information, Developer Relations, Team, Equipment & Tools, Schedule, Test Items, Deliverables

Heuristiques de techniques de tests[]

  • DUFFSSCRA (FDSFSCURA) [13] de James Bach propose des techniques de test
    • Domain, User, Function, Flow, Stress, Scenario, Claims, Risk, Automatic
  • SACKED SCOWS [17] (James Bach) est une heuristique de test basé sur l'apprentissage
    • Scouting Obsessively, Authentic Problems, Cognitive Savvy, Knowledge Attracts Knowledge, Experimentation, Disposable Time, Stories(Contrasting Ideas, Skepticism, Critical thinking, Lateral thinking), Other Minds, Words and Pictures, Systems Thinking
  • SLIME [18] (Adam Goucher) - Mnémonique pour identifier les tâches de test
    • Security, Languages, RequIrements, Measurement, Existing
  • RCRCRC [19] (Karen N. Johnson) - mnémonique pour choisir ses tests de régression
    • Recent, Core, Risk, Configuration, Repaired, Chronic
  • GRATEDD SCRIPTS [20] (Jared Quinert) - mnémonique pour établir une stratégie de test
    • Budget, Goals, Risks, Approach, Dependencies, Environments, Data, Stakeholders, Coverage Models, Resources, Information, Prioritization, Tradeoffs, Tooling, Schedule
  • MR.Q COMP GRABC R&R [21] de Jon Bach (le frère de James) donne une liste de compétences et approches pour les tests exploratoires
    • Modeling, Resourcing, Questioning, Chartering, Observing, Manipulating, Pairing, Generating/Elaborating, Refocusing, Alternating, Branching/Backtracking, Conjecturing, Recording, Reporting
  • FCC CUTS VIDS [22] (Michael D Kelly) donne un mnémonique (il signifie quelque chose comme "Censures des vidéos par la Commission Fédérale de la Communication") pour parcourir l'application dans différentes directions
    • Feature Tour, Complexity Tour, Claims Tour, Configuration Tour, User Tour, Testability Tour, Scenario Tour, Variability Tour, Interoperability Tour, Data Tour, Structure Tour
  • CORRECT [23] (Andrew Hunt) - Mnémonique pour imaginer des données de tests en fonction du type de données
    • Conforme, Ordonné, Région, Référence, Existence, Cardinalité, Temps
  • Right BICEP [23] (Andrew Hunt)
    • Are the results right? Boundary conditions, Inverse relationships, Cross-check using other sources of truth, Error conditions, Performance characteristics

Heuristiques pour les tests de charge[]

  • FIBLOTS [24] (Scott Barber) donne un modèle pour effectuer des tests de charge
    • Frequent, Intensive, Business Critical, Legal, Obvious, Technically Risky, Stakeholder Mandated
  • CCD IS EARI [25] (Scott Barber) donne des axes autour de principes sur le test de charge
    • Context, Criteria, Design, Install, Script, Execute, Analyze, Report, Iterate
  • IVECTRAS [26] (Scott Barber) fournit une classification des tests de performance
    • Investigation or Validation of End-to-End or Component Response Times and/or Resource Consumption under Anticipated or Stressful Conditions

Heuristiques pour la qualification d'un bug et le reporting[]

  • RIMGEA [27] de Cem Kaner (le co-fondateur du Context-Driven Testing avec James Bach) donne un mnémonique pour qualifier un bug
    • Replicate it, Isolate it, Maximize it, Generalize it, Externalize it, And Say it Clearly and Dispassionately
  • FAILURE [28] (Ben Simo) - Mnémonique (il signifie "échec") pour traiter les bugs
    • Functional, Appropriate, Impact, Log, UI, Recovery, Emotions
  • MCOASTER [29] (Michael D Kelly) donne un mnémonique pour établir un rapport de test pertinent
    • Mission, Coverage, Obstacles, Audience, Status, Techniques, Environment, Risk

Heuristiques de tests pour mobiles[]

  • RSTLLL [30] (Karen N. Johnson) - tests d'application d'envois de SMS
    • Reply, Sender, Timestamp, List, Links, Language, Length
  • I SLICED UP FUN [31] (Jonathon Kohl) - tests d'application mobiles
    • Inputs, Store, Location, Interactions/Interruptions, Communications, Ergonomics, Data, Usability, Platform, Function, User Scenarios, Network
  • PAOLO [32] (Maik Nogens) - tests à réaliser sur les changements d'orientation (portrait / paysage) du mobile
    • Portrait, Audio, Objects, Landscape, Overlay
  • SPIES [33] (Nancy Kelln) - tests multilingues (i18n) et culturel (localisation l10n)
    • Special Characters, Pages & Content, Integrations, Error Messages, Special Formats


Heuristiques sur les exigences[]

  • MUTII [34] (Jonathon Kohl) axes d'identification de bases de tests
    • Market, Users, Tasks, Information, Implementation
  • WWWWWH/KE [35] (Darren McMillan) - Analyse et feedback sur les exigences
    • Who, What, When, Where, Why, How, Knowledge, Experience
    • les "W" sont aussi surnommé les 6W ou en français "l'hexamètre mnémotechnique de Quintilien" [36] souvent appelé "QQOQCP" qui est tout aussi difficile à mémoriser, aussi peut-on préférer "QQCOQP" qui prononcé avec la voix de Johnny Hallyday s'entend "Coucou, c'est occupé" [2]

Heuristiques d'automatisation des tests[]

  • FIRST [37] - attributs d'automatisation
    • Fast, Independent, Repeatable, Self-validating, Timely
    • C'est l'acronyme le plus connu et souvent appliqué aux tests unitaires mais complètement utilisable sur n'importe quel type de test automatisé.
  • MuFFed [38] (Xavier Pigeon) - mnémonique pour l'audit d'une stratégie d'automatisation des tests
    • Missing, Fake, False negative
    • En Français : absent, truqué, faux-négatif
    • Cet acronyme, qui signifie raté en Français, désigne les critères relatifs au niveau 0, le plus bas, de maturité des tests automatisés, sur l'échelle de valeur des tests du framework méthodologique GOST.
  • RaFFISH [38] (Xavier Pigeon) - mnémonique pour l'audit d'une stratégie d'automatisation des tests
    • Redundant, Fragile, Fanciful, Incognizant, Slow, Heavy
    • En Français : redondant, fragile, fantaisiste, ignorant, lent, lourd
    • Cet acronyme, qui signifie canaille en Français, désigne les critères relatifs au niveau 1 de maturité des tests automatisés, sur l'échelle de valeur des tests du framework méthodologique GOST. Le niveau 1 concerne les tests hérités (legacy tests en Anglais).
  • A TRIP [23] (Andrew Hunt) - ("un voyage") attributs d'automatisation
    • Automatique, Très détaillé, Répétable, Indépendant, Professionnel
  • SEED NATALI [39] (Albert Gareev) - (littéralement "Graine Natali") donne un mnémonique pour automatiser un test d'IHM
    • Synchronize, Exists, Enabled, Displayed, Number of Arguments, Type of Arguments, Log, Investigate
  • SPIFFy [40] (Industrial Logic)
    • Small, Precise, Isolated, Fast, Frequently Run
  • TERMS [41] (Albert Gareev) - mnémonique sur les critères d'automatisation
    • Tools & Technology, Execution, Requirements & Risks, Maintenance, Security
  • CRUMBS [42] (Albert Gareev) - mnémonique (miettes de pain) sur les critères d'automatisation
    • Confirmation, Coverage Criteria & Complexity, Risk, Robustness, & Reliability, Usefulness & Usability, Maintainability & Manual Effort, Basis & Bias, Span, Separation, & Security

Une heuristique de plus ![]

Pour ajouter une heuristique à cette longue liste d'heuristiques, la méthode est simple mais le chemin est long. Il est directement lié à l'évolution que vous ferez dans l'évolution de votre approche du test.

On peut commencer par une "approche analytique" ou "réactive" [43] afin de découvrir votre base de test et par votre expérience, vous remarquerez probablement des points d'attentions qui reviennent régulièrement. Avec le temps, la nécessité vous amènera certainement à établir une checklist que vous allez méthodologiquement dérouler à chaque fois : vous tenez une heuristique de test applicable à votre produit. Avec un peu d'imagination, vous lui trouverez un sigle, un acronyme ou un acrostiche [44] pour rendre cette checklist "évidente". Pour que cette heuristique devienne significative, vous pourrez alors partager cette astuce sur d'autres produits similaires et adresser un métier (comme avec la norme IEC60068) et éventuellement devenir un standard voire une norme comme l'est l'ISO25010.

Une fois que votre nom est connu de tous, il ne vous reste plus qu'à modestement ajouter votre nouvelle heuristique dans la taxonomie [45] présentée dans la section précédente...

Tests pilotés par les heuristiques - "One to rule them all"[]

On le comprend, cette notion d'heuristique est en fait incontournable dans le test si un minimum d'efficacité est demandé et de part notre nature humaine : on n'est pas des machines ! Il s'avère aussi que cette question d'efficacité est aussi liée à un contexte : tenter d'appliquer les fameux 4 quadrants du test de Lisa Crispin [46] du jour au lendemain avec tous les tests en "ITE" qui existent tient de la gageure !

Cette réalité rend nécessaire de concevoir la stratégie de test dans le temps, c'est la notion de "Master Plan" présentée par l'ISTQB [43]. Elle propose un déroulé temporel sur l'application de la stratégie.

Une vision plus agile peut être amorcée par la vision de James Bach sur une vidéo de 2 minutes [47] avec comme résultat, une heuristique pour une stratégie de test sous la forme d'une "Quality Story" [48] à partir de

  • l'environnement du projet
  • des élément-projets à tester
  • des critères de qualité
  • on déduit les techniques tests applicables

James fait appel à une heuristique sur chacun de ces 4 axes pour concevoir une Story Qualité adaptée au sprint, un moyen rapide pour établir une stratégie de test pertinente sans la nécessité d'une lourde documentation.

En suivant ce chemin, nous pouvons "créer" une nouvelle technique qu'on appellera par exemple "le TPH" (Test Piloté par les Heuristiques) ou en anglais pour le côté hype : le "HDT" - Heuristic-Driven Testing). Notre "nouvelle" approche du test sera basée sur une heuristique nommée à partir de ces 4 mots Environnement / Projet / Critères / Technique (EPCT).

Compte-tenu que nous avons à tous les niveaux des heuristiques, on peut substituer le terme "Technique" par "Heuristique", ce qui nous donnerait "EPCH". Pour le côté mnémonique, ce sigle rappelle facilement le mot anglais "EPoCH" (époque ou période).

Voici donc le "HDT" avec la "EPoCH Story" qui sera constituée d'heuristiques afin d'adresser chacun des axes E/P/C. Ces 3 axes devront s'enrichir de catégories d'heuristiques pour compléter le tableau de façon transverse comme le choix de l'heuristique de traitement des exigences (ou US, Features, Capabilities, Epics...[49]), des anomalies voire de la communication sur le feedback relatif aux tests du produit.

Il ne manque plus qu'une belle approche marketing, des produits dérivés, et le monde du Test n'a plus qu'à revoir sa documentation basée sur la seule approche des 4 quadrants ! :-P

Autres heuristiques trouvées après l'écriture de cette page[]

- http://www.testingreferences.com/functional_testing_heuristics.php

Références[]

  1. ↑ https://en.wikipedia.org/wiki/Heuristic_(computer_science)
  2. ↑ 2,0 2,1 et 2,2 Christophe Moustier - "Le test en mode Agile" - ENI - 2019 - ISBN 978-2409019432 - https://www.amazon.fr/test-en-mode-Agile/dp/2409019439
  3. ↑ https://latavernedutesteur.fr/2018/11/15/techniques-basees-sur-les-specifications-6-7-pairwise/
  4. ↑ Stephen Vance "Quality Code: Software Testing Principles, Practices, and Patterns" - Addison-Wesley. - 2013 - ISBN-13: 978-0321832986
  5. ↑ Le François - "Cours IUT - Université de Nice" - 2014 - http://miageprojet2.unice.fr/@api/deki/files/2221/=Qualite_Logicielle__-_Lefrancois_-_IUT_Nice_-_2014_(1).pptx
  6. ↑ https://latavernedutesteur.fr/2018/01/12/principe-6-les-tests-dependent-du-contexte/
  7. ↑ https://fr.wikipedia.org/wiki/HAZOP
  8. ↑ https://webstore.iec.ch/preview/info_iec60068-3-8%7Bed1.0%7Db.pdf
  9. ↑ http://apps.testinsane.com/mindmaps/
  10. ↑ Karen Nicole Johnson - "Testing Mnemonics as a card deck" - 2012 - http://karennicolejohnson.com/2012/07/testing-mnemonics-as-a-card-deck/
  11. ↑ https://en.wikipedia.org/wiki/FURPS
  12. ↑ https://www.ibm.com/developerworks/rational/library/4706.html
  13. ↑ 13,0 13,1 et 13,2 http://www.satisfice.com/tools/satisfice-tsm-4p.pdf
  14. ↑ http://www.developsense.com/blog/2010/05/transpection-transpected/
  15. ↑ https://www.developsense.com/blog/2012/07/few-hiccupps/
  16. ↑ James Bach et Michael Bolton - "Rapid Software Testing - A Context-Driven Methodology" - v4.0.3 - 2018
  17. ↑ http://homeedmag.com/HEM/266/interview-james-marcus-bach.php
  18. ↑ http://adam.goucher.ca/?p=200
  19. ↑ http://www.testingreflections.com/node/view/8333
  20. ↑ http://www.software-testing.com.au/blog/2009/07/21/thinking-about-test-strategy-a-mnemonic-device/
  21. ↑ http://agile2010.agilealliance.org/files/Telling%20Your%20Exploratory%20Story%20Agile2010.pdf#page=42
  22. ↑ http://www.testingreflections.com/node/view/2823
  23. ↑ 23,0 23,1 et 23,2 Andrew HUNT et David THOMAS – « Pragmatic Unit Testing in Java with JUnit » - The Pragmatic Bookshelf – 2007 – ISBN 978-09745140-1-7
  24. ↑ http://www.testingreflections.com/node/view/5870
  25. ↑ http://www.testingreflections.com/node/view/5448
  26. ↑ http://www.testingreflections.com/node/view/5792
  27. ↑ http://searchsoftwarequality.techtarget.com/tip/Software-testing-is-improved-by-good-bug-reporting
  28. ↑ http://www.questioningsoftware.com/2007/08/failure-usability.html
  29. ↑ http://michaeldkelly.com/blog/2005/8/19/coming-up-with-a-heuristic.html
  30. ↑ http://searchsoftwarequality.techtarget.com/tip/Testing-SMS-texting-applications-Key-steps-and-considerations
  31. ↑ http://www.kohl.ca/articles/ISLICEDUPFUN.pdf
  32. ↑ Http://hanseatictester.info/?p=229
  33. ↑ http://www.unimaginedtesting.ca/blog/603
  34. ↑ http://www.methodsandtools.com/archive/archive.php?id=65
  35. ↑ http://www.bettertesting.co.uk/content/?p=857
  36. ↑ https://fr.wikipedia.org/wiki/QQOQCCP
  37. ↑ https://github.com/ghsukumar/SFDC_Best_Practices/wiki/F.I.R.S.T-Principles-of-Unit-Testing
  38. ↑ 38,0 et 38,1 Xavier Pigeon - Gears Of Software Testing (GOST) - Legacy Tests - https://gearsoftesting.org/legacy-tests.html
  39. ↑ http://www.quicktestingtips.com/tips/2010/06/seed-natali-gui-step-automation-heuristic/
  40. ↑ https://elearning.industriallogic.com/gh/submit?Action=PageAction&album=theBasics&path=theBasics/whatisamicrotest/keywordMicrotest&devLanguage=Java
  41. ↑ http://automation-beyond.com
  42. ↑ http://automation-beyond.com
  43. ↑ 43,0 et 43,1 ISTQB - "Advanced Level Syllabus Test Manager" - 2012 - https://www.istqb.org/downloads/summary/10-advanced-level-syllabus-2012/54-advanced-level-syllabus-2012-test-manager.html
  44. ↑ https://fr.wikipedia.org/wiki/Acrostiche
  45. ↑ https://fr.wikipedia.org/wiki/Taxonomie
  46. ↑ https://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/
  47. ↑ https://www.youtube.com/watch?v=SNHWCD2qg3U
  48. ↑ James Bach - "Heuristic Test Strategy Model" - 2019 - https://www.satisfice.com/download/heuristic-test-strategy-model
  49. ↑ https://www.scaledagileframework.com/features-and-capabilities/
Sauf mention contraire, le contenu de la communauté est disponible sous licence CC-BY-SA.

Fan Feed

More Wiki Fan de Test