Archives de catégorie : QA

Estimer l’effort avant le début du projet

Vicente Merino demandait, dans le dernier post sur la complexité et l’effort de QA : « Comment estimer cet effort lorsque l’on ne dispose pas de code ?» et plus précisément « Est-il possible de décider, au début du projet, si celui sera suffisamment important pour nécessiter une équipe de QA indépendante et formaliser un plan de tests ? ».

Imaginons par exemple que vous êtes responsable des applications au sein d’une Telco. Il est donc de votre responsabilité que :

  • les clients puissent se connecter sur le site web pour consulter leur facture, leur nombre de points, acquérir de nouveaux services, un nouveau portable, etc.
  • les employés au service des clients puissent se connecter sur ce même site mais également à d’autres applications afin de vérifier le compte d’un client, un défaut éventuel de paiement, etc
  • et d’une manière générale, que les applications commerciales permettent de vendre et que les applications financières permettent de facturer. Continuer la lecture

Complexité et effort de test

Dans le post précédent, je posais la question ‘Qu’est ce qu’une grosse application ?’ et je proposais deux tables de mesures, basées sur le nombre de lignes de codes (LOC) ou le nombre d’objets afin de catégoriser les applications en ‘simple’, ‘moyenne’, ‘grosse’ et ‘très grosse’.

Evidemment, comme je m’y attendais, la discussion sur les forums traitant d’analyse de code ou de métriques software s’est immédiatement orientée sur les points de fonction, sur la définition de ce qu’est une application (unité de code ou unité organisationnelle) ou sur le type de mesure utilisée par chacun afin d’estimer la taille d’une application. Les nombres que j’ai avancés n’ont pas prêté à discussion.

Cette semaine encore, un autre ‘quizz’ du même type : ‘Qu’est ce qu’une application complexe ?’ et surtout ‘Est-il possible de prévoir l’effort de test en fonction de la complexité d’une application ?’.

Continuer la lecture

Crowdsourcing and Crowdtesting

Vous avez peut-être entendu parler de Crowdtesting, une pratique qui génère actuellement pas mal de ‘buzz’ et qui consiste à confier une application à une communauté de testeurs externes afin qu’ils en vérifient la robustesse.

A l’occasion du post de la semaine dernière, je me suis demandé si la situation rencontrée dans ce cas ne justifierait pas le recours à cette technique. Continuer la lecture

Cherchez l’erreur (2/2)

Le bug présenté dans notre précédent post a attiré un grand nombre de commentaires tous plus intéressants les uns que les autres.

Donc d’abord, un grand merci à tous ceux qui nous ont fait part de leur point de vue, puisque c’était justement l’objectif de cette publication.

Mon expérience de consultant est plutôt orientée ‘best practices’ en matière de cycle de vie de projet (ex-développeur, ex-chef de projet, puis dans le Configuration Management et la qualité de code). Je ne suis donc pas un expert en QA.

Mais je travaille régulièrement avec de bons professionnels de QA et j’étais très curieux de l’opinion de personnes plus expertes que moi dans ce domaine … avant de formuler quelques hypothèses dans ce second post.

Continuer la lecture

Cherchez l’erreur (1/2)

En tant que consultant Qualité, je n’adore rien de plus que de trouver des bugs.

Rien de plus plaisant que d’analyser le code d’une application et de trouver un ou plusieurs bon gros bugs impardonnables, comme un ‘Break’ en ABAP (instruction utilisé en mode debug et qui va stopper instantanément le programme), un OPEN / CLOSE de fichiers dans une boucle (instructions coûteuses en temps système, á réaliser hors de la boucle, évidemment) ou un accès direct à la base de données depuis une page JSP. Pas besoin d’être spécialiste pour savoir qu’il s’agit de défauts graves.

Il y a pourtant une situation dans laquelle je détester trouver des bugs : en tant qu’utilisateur d’une application.

Continuer la lecture