Programmez: Entretien avec Daisy Draté ingénieure qualité sur l’application AVoKa

Dans cet article, Marc Hage Chahine et Benjamin Butel  nous proposent de faire  l’éloge des différents contributeurs à un logiciel de qualité au travers d’une interview journalistique d’un produit fictif. Depuis quelques années, le manger local, sain, avec des produits frais refait surface et les gens se remettent de plus en plus au jardinage. PourLire la suite Programmez: Entretien avec Daisy Draté ingénieure qualité sur l’application AVoKa

Ce que nous apprend la mythologie sur les tests: Cassandre

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

Principes SOLID simplifiés (1/5): Responsabilité unique

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

Grâce à qui un produit est-il de bonne qualité ?

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é ?

Un testeur…. bah il teste…

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…

La phase de Retest

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

Tests : le facteur humain.

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.