La MOA pragmatique du SI (Business Analysis, Analyse d'Entreprise, Maitrise d'Ouvrage)

Aller au contenu | Aller au menu | Aller à la recherche

mercredi, octobre 2 2013

Ecrire un livre via Leanpub - Maîtrise d'Ouvrage du Système d'Information en pratique

Attention, auto-promo à l'intérieur de ce billet :) !

Cela faisait longtemps que je n'avais pas écrit sur ce blog ! Je vais essayer de contribuer plus régulièrement.

J'ai profité de cette absence sur ce blog pour co-écrire un livre sur la maitrise d'ouvrage du SI. Pour cela, nous avons utilisé la plateforme Leanpub qui permet d'écrire un ouvrage de manière collaborative, en suivant les principes du Lean. L'idée c'est donc d'écrire une première version du livre que l'on publie assez tôt afin d'obtenir un retour rapide des lecteurs.

Donc si vous êtes intéressés par les sujets évoqués sur ce blog, vous aimerez ce livre qui présente des techniques très utiles pour réussir en tant que MOA. Il y est notamment question de : gestion des exigences, valeur métier, Minimum Viable Product, vision, business case, modélisation UML, story-board, maquette, user story, Behavior Driven Development, Acceptance Tests Driven Development, conduite du changement, rétrospective... En téléchargeant ce livre maintenant, vous pourrez l'avoir pour 0€ et en plus vous pourrez influencer son contenu en nous faisant vos commentaires sur ce qu'il faut étoffer, ajouter ou corriger. 

Si vous souhaitez plus d'information, c'est par ici :


lundi, mai 24 2010

Comment diminuer la charge des activités de test ?

Que ce soit la préparation (définition de la stratégie de recette et des plans de test) ou son exécution, une recette consomme beaucoup de ressources. J'ai souvent vu des projets sur des systèmes critiques pour l'entreprise avec des tests de validation qui représentaient 20% de la charge globale du projet. Ainsi il est important d'optimiser les activités de test.

Demandez à votre MOE un rapport d'exécution des tests unitaires et tests d'intégration

En plus de l'application à tester, votre MOE doit vous livrer un rapport d'exécution des tests unitaires et tests d'intégration. De nombreux outils existent pour faciliter le développement et le reporting de tests unitaires. Il peut être très coûteux de mettre en place des tests unitaires pour une application existante, il faut donc y penser dès le commencement du projet et que les charges de développement prennent en compte le temps nécessaire à la réalisation des tests unitaires. Pour cela, la MOA doit être prête à sponsoriser cette surcharge de travail.

Plan de test

Il faut utiliser un outil ou a minima un fichier Excel pour consigner les plans de test et les réutiliser. Cela doit permettre de spécifier le plan de test, planifier les campagnes de test, suivre l'exécution des tests et effectuer un reporting sur l'avancement des tests. Les tests des nouvelles fonctionnalités deviennent ensuite des tests de non régression, et on peut les réutiliser.

Tests fonctionnels automatisés

Et pourquoi ne pas aller plus loin et essayer d'automatiser les tests fonctionnels ? Voici un article intéressant vu sur le blog d'Octo Technology : Démarches de tests fonctionnels. Il y est question de deux outils qui permettent d'automatiser les tests fonctionnels et même de documenter les fonctionnalités du système (d'où le terme de "spécifications exécutables") :

Le principe de ces outils est de décrire le plan de test dans un Wiki sous un format semi structuré (des tableaux). Les données composant le jeux d'essai, les fonctionnalités du systèmes, les résultats attendus, tout est décrit dans un Wiki ce qui est censé offrir de la flexibilité pour documenter et une facilité de prise en main qui permet aux MOA d'écrire les scripts de test. Une fois les tests décrits, il suffit d'exécuter le script de test et la page va s'agrémenter de vert ou de rouge en fonction des résultats des tests. Mais ce n'est pas magique, et il faut coder des "Fixtures" afin de faire le lien entre des outils et les applications à tester. Donc il reste une charge de travail non négligeable côté MOE, à faire en plus des tests unitaires "techniques".

Behavior Driven Development

Le Test Driven Development consiste à commencer par écrire des tests qui vont échouer avant même de développer la fonctionnalité. Au delà de cette approche, Dan North a inventé le concept de Behavior Driven Development :

My response is behaviour-driven development (BDD). It has evolved out of established agile practices and is designed to make them more accessible and effective for teams new to agile software delivery. Over time, BDD has grown to encompass the wider picture of agile analysis and automated acceptance testing.

Introducing BDD - DanNorth.net

Cucumber par exemple est un framework qui permet de décrire en langage naturel comment le système devrait se comporter :

Il existe des applications plus riches qui permettent de décrire les Feature et Scenario plus facilement, comme par exemple Lowdown :

http://lowdownapp.com/

Vous pouvez consulter ce billet sur le blog d'Octo Technology : Cucumber pour la MOA pour aller plus loin.

Testeur - Un vrai expert

Finalement, on se rend compte que les techniques de test sont aujourd'hui nombreuses et parfois complexes. Le métier de Testeur est donc devenu un métier en lui-même où l'expertise est dure à obtenir. Si votre structure est trop petite pour avoir une équipe dédiée aux tests, alors il ne faut pas hésiter à faire appel à un expert externe pour aider à la mise en place de bonnes pratiques pour une démarche de test qui doit être intégrée à tout le cycle de vie d'un système.

dimanche, janvier 17 2010

Quels sont les cinq points clés pour réussir une recette ?

1) Définissez la stratégie de la recette.

En plus de la description de l'organisation et des moyens mis en œuvre pour la recette, n'oubliez pas de décrire l'objectif de cette recette. Recetter une application, ce n'est pas vérifier que l'application n'a pas de bug. Recetter, c'est vérifier que le système répond aux exigences fonctionnelles et non fonctionnelles par rapport aux coûts et à la qualité attendue. Définissez donc en amont quelle est la criticité des fonctionnalités du système et le niveau d'acceptabilité pour chaque criticité. Par exemple, on acceptera peut-être un bug bloquant sur une fonctionnalité "cosmétique" alors que pour une fonctionnalité très critique, aucun bug bloquant ou majeur ne sera toléré. 

2) Pensez aux tests avant tout.

Test Driven Development, Behavior Driven Development, Acceptance Test Driven Development... Beaucoup de méthodes prônent la conception par les tests. Sans forcément passer par des concepts complexes, penser "tests" dès la conception fonctionnelle permet souvent d'expliciter sa pensée et de se concentrer sur les objectifs du système.

3) Coordonnez et planifiez la recette.

Même si tous les tests ne sont pas exécutés par la MOA, coordonnez. De la mise à disposition des environnements de test, à l'exécution de tests de performance, en passant par les tests utilisateurs, vous devrez coordonner des équipes aux contraintes très différentes. La recette est souvent un projet en elle même.

4) Outillez vous.

Que ce soit pour la description des plans de test et le suivi de l'exécution des campagnes, utilisez des outils pour industrialiser vos tests (du classique avec HP Quality Center, ou du plus original comme FitNesse à base de Wiki). Au minimum, utilisez un fichier Excel pour décrire vos scénarios et cas de test ainsi que pour en suivre l'exécution.

5) Soyez pugnace.

La recette n'est pas une activité simple. Bien que souvent pénible et répétitive dans son exécution, c'est un moment clé du projet. On est souvent tenté de rogner sur la charge prévue pour cette activité car à la fin d'un projet, il ne reste plus grand chose à arbitrer ! Et pourtant, c'est le dernier rempart avant la mise en production. La négliger pourrait être une erreur fatale.