Merci de l'article qui est intéressant au-delà de donner des références bien utiles.
Au début des années '90 mon entreprise a mis sur le marché une collection de logiciels (24 titres, > 300000 copies vendues) et nous n'avons eu qu'1 seul bug répertorié causé d'ailleurs par une "amélioration" de dernière minute.
À titre de provocation ... nous ne faisions AUCUN test, du moins formalisé tel qu'il aurait fallu le faire. Par contre, tout ce qui était développé était mis en pratique immédiatement (le plus vite possible, dirais-je) et même si nous n'étions pas dans un environnement réseau (1989-1990, DOS 3.2 et 3.3), nos applications étaient complexes car elles "dialoguaient" les unes avec les autres : "« Je Gère Mes Factures » parlait à « Je Gère Mes Clients et Fournisseurs », « Je Gère Mon Stock », « Je Gère Mes Addresses », etc.
Nous avions appelé notre méthode de testing le "Testing chaotique".
Comme nous utilisions nos propres réalisations (Eat You Own Dog Food), tout ce qui n'avait pas été éprouvé par l'équipe de développement (3 personnes) était utilisé et donc ... testé dans la vie réelle par ceux à qui la solution s'adressait. La secrétaire utilisait la gestion de factures pour faire les factures aux clients, les commerciaux utilisaient la gestion des clients et fournisseurs pour faire leur travail, etc. Au fond, nous mettions à disposition de nos propres troupes ce qui avait été développé et laissions les bugs faire surface dans un environnement que nous contrôlions : notre propre entreprise.
Cela nous a d'ailleurs amenés à considérer le fait que nous avons ensuite labellisé sous l'acronyme "AMIS" : Anomalies, Manquements, Inadéquations et Suggestions.
Ne pas contraindre qui que ce soit à un plan de test permettait la découverte : l'utilisateur usait du logiciel comme il lui semblait naturel de le faire et ce qui est naturel pour l'un ne l'est pas pour l'autre. Cela nous amenait donc à découvrir des manières de faire que les développeurs n'avaient même pas envisagées au départ. Comme l'interaction avec nos utilisateurs était libérée de toute contrainte, nous avons été à même de collecter d'autres choses que les sempiternels bugs : des manquements (ce qui devrait se trouver dans le logiciel mais qui ne l'est pas), les inadéquations (ce qui fonctionne comme cela a été analysé mais qui n'est pas approprié) et les suggestions (de nouveaux développements à réaliser, des modifications, des améliorations). Il est clair que les tests E2E ne peuvent pas couvrir ces matières !
Et nous sommes parfaitement d'accord : les tests E2E sont extrêmement coûteux et, au plus profond de l'âme de l'équipe de développement, n'apportent aucune certitude supplémentaire par rapport aux tests effectués en amont.
Oui, effectivement mais le "Exploratory Testing" c'est grosso modo en 1998 que cela démarre réellement et que le smoke testing c'est entre 1979 et 1985 (avec une courbe d'adoption particulièrement plate). Nous, quand on démarre cela, on est en 1989.
Nous avons d'ailleurs établi une série de contraintes dans ce testing. Par exemple, il faut lui donner du temps. C'est un peu comme les robots de tonte de pelouse. Après un certain temps, on est sûr qu'ils ont tondu partout mais si on ne leur octroie pas ce temps, alors la tonte semble ... chaotique.
;-)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Merci de l'article qui est intéressant au-delà de donner des références bien utiles.
Au début des années '90 mon entreprise a mis sur le marché une collection de logiciels (24 titres, > 300000 copies vendues) et nous n'avons eu qu'1 seul bug répertorié causé d'ailleurs par une "amélioration" de dernière minute.
À titre de provocation ... nous ne faisions AUCUN test, du moins formalisé tel qu'il aurait fallu le faire. Par contre, tout ce qui était développé était mis en pratique immédiatement (le plus vite possible, dirais-je) et même si nous n'étions pas dans un environnement réseau (1989-1990, DOS 3.2 et 3.3), nos applications étaient complexes car elles "dialoguaient" les unes avec les autres : "« Je Gère Mes Factures » parlait à « Je Gère Mes Clients et Fournisseurs », « Je Gère Mon Stock », « Je Gère Mes Addresses », etc.
Nous avions appelé notre méthode de testing le "Testing chaotique".
Comme nous utilisions nos propres réalisations (Eat You Own Dog Food), tout ce qui n'avait pas été éprouvé par l'équipe de développement (3 personnes) était utilisé et donc ... testé dans la vie réelle par ceux à qui la solution s'adressait. La secrétaire utilisait la gestion de factures pour faire les factures aux clients, les commerciaux utilisaient la gestion des clients et fournisseurs pour faire leur travail, etc. Au fond, nous mettions à disposition de nos propres troupes ce qui avait été développé et laissions les bugs faire surface dans un environnement que nous contrôlions : notre propre entreprise.
Cela nous a d'ailleurs amenés à considérer le fait que nous avons ensuite labellisé sous l'acronyme "AMIS" : Anomalies, Manquements, Inadéquations et Suggestions.
Ne pas contraindre qui que ce soit à un plan de test permettait la découverte : l'utilisateur usait du logiciel comme il lui semblait naturel de le faire et ce qui est naturel pour l'un ne l'est pas pour l'autre. Cela nous amenait donc à découvrir des manières de faire que les développeurs n'avaient même pas envisagées au départ. Comme l'interaction avec nos utilisateurs était libérée de toute contrainte, nous avons été à même de collecter d'autres choses que les sempiternels bugs : des manquements (ce qui devrait se trouver dans le logiciel mais qui ne l'est pas), les inadéquations (ce qui fonctionne comme cela a été analysé mais qui n'est pas approprié) et les suggestions (de nouveaux développements à réaliser, des modifications, des améliorations). Il est clair que les tests E2E ne peuvent pas couvrir ces matières !
Et nous sommes parfaitement d'accord : les tests E2E sont extrêmement coûteux et, au plus profond de l'âme de l'équipe de développement, n'apportent aucune certitude supplémentaire par rapport aux tests effectués en amont.
Ce dont tu parles ressemble bien à du Exploratory testing et du Smoke testing.
Ca fait partie de la pyramide des tests.
Oui, effectivement mais le "Exploratory Testing" c'est grosso modo en 1998 que cela démarre réellement et que le smoke testing c'est entre 1979 et 1985 (avec une courbe d'adoption particulièrement plate). Nous, quand on démarre cela, on est en 1989.
Nous avons d'ailleurs établi une série de contraintes dans ce testing. Par exemple, il faut lui donner du temps. C'est un peu comme les robots de tonte de pelouse. Après un certain temps, on est sûr qu'ils ont tondu partout mais si on ne leur octroie pas ce temps, alors la tonte semble ... chaotique.
;-)