L’idée de cette série m’est venue suite à l’excellent article de Zoé Thivet. Présentation de la série Les mythologies ont de nombreux intérêts. Je note par exemple ces 2 points: l’intérêt historique permettant de comprendre ce que les personnes croyaient au moment où ces mythologies étaient des religions l’intérêt histoire qui nous conte des épopéesLire la suite Ce que nous apprend la mythologie sur les tests: Cassandre
Les principes S.O.L.I.D dans un contexte d’automatisation des tests L’acronyme S.O.L.I.D a été inventé par Michael Feathers à partir des principes de programmation orientée objet identifiés par Robert Cecil Martin, Ces principes visent à rendre le code plus lisible, facile à maintenir, extensible, réutilisable et sans répétition. L’automatisation des tests c’est un vrai projet de développement et lorsque les principes S.O.L.I.D ne sont pasLire la suite Principes SOLID simplifiés (1/5): Responsabilité unique
Qui faut-il féliciter lorsqu’un produit est un succès grâce à une bonne qualité et un public trouvé? La question peut paraître triviale, néanmoins il semble intéressant de la creuser! L’opérationnel ? L’opérationnel a un rôle essentiel (lorsque le produit requiert sa présence (pas besoin d’opérationnel pour un jeu Super NES)), il assure la disponibilité duLire la suite Grâce à qui un produit est-il de bonne qualité ?
Malgré le temps qui passe, la plupart des personnes voient le testeur comme une personne qui test…mais pas plus, et donc son importance sur ces alertes, sur son niveau d’information, sur sa qualification et son rapport de recette n’ont pas d’importance lorsqu’il s’agit de prendre des décisions sur la mise en production d’une application ouLire la suite Un testeur…. bah il teste…
Les tests aux limites: La locomotive roule bien sur les rails, par contre elle ne peut pas rentrer dans certaines gares. Couverture sans tests aux limites: On a donc ici toute une zone où le comportement de l’application est inconnu, et ce malgré un nombre important de tests. Les tests sont donc peu efficaces. CouvertureLire la suite Le test en image (4)
Le cycle de vie d’un bug comporte plusieurs étapes décrites ci-dessous : Dans ce cycle, une étape est malheureusement souvent négligée : La phase de Retest (ou de vérification). A quoi correspond exactement cette phase ? La phase de retest d’un bug a plusieurs buts : · Vérifier que le bug est bien corrigé : un travail est rarement parfait lorsLire la suite La phase de Retest
Cette idée d’article m’est venue suite à une discussion avec Rajae AOUCHI lorsque j’ai publié cette caricature. La question est simple: Qui est responsable dans ce cas? Afin d’avoir une réponse plus précise je vais préciser un contexte: Les tests sont effectués, tout va bien sauf un problème critique qui est détecté sur les freins.Lire la suite La faute à qui?
Il m’arrive régulièrement en discutant avec des collègues ingénieurs que ces derniers me disent : « Tu sais, pour les tests tout dépend du testeur ». Je n’aime pas cette phrase. Certes le métier de testeur est un métier à part qui requiert des compétences spécifiques, néanmoins ce facteur humain, bien que toujours présent doit être, au moinsLire la suite Tests : le facteur humain.
Les tests ont pour but de vérifier que l’application fonctionne comme il est prévu. Ces tests peuvent atteindre ce but uniquement s’ils sont à jour, c’est pourquoi il ne faut jamais négliger la maintenance des cas de test. Pourquoi les tests sont-ils amenés à évoluer ? Les cas de tests sont à mettre à jour carLire la suite La maintenance des tests
Introduction : Idéalement tout produit ou logiciel ne devrait pas avoir de bug. Malheureusement comme déjà vu dans mon article sur le logiciel sans bug la qualité a un coût. La qualité est donc un choix, tant au niveau d’un utilisateur (généralement le prix est un indicateur, un téléphone à 500€ sera de meilleure qualité qu’un téléphoneLire la suite La qualité est un choix
