BDD (Behavior Driven Development) est une méthodologie qui attire de nos jours beaucoup d’attention. Si les principes de la méthode sont relativement simples, sa mise en place nécessite un travail constant d’ajustement lors des rédactions des exemples fonctionnels.

Depuis quelques mois maintenant, Hiptest utilise avec succès la méthode BDD, mais le succès de cette transition ne fût pas immédiat. Dans cette présentation, nous allons mettre en lumière les différents échecs auxquels nous avons fait face et les solutions mises en place afin d’assurer une vision commune du produit lors du développement de nouvelles fonctionnalités.

Nous présenterons aussi les avantages ressenti dans l’équipe suite à notre transition vers BDD. 

Les logiciels sont de plus en plus présents dans notre vie de tous les jours et doivent donc être testés.
Les tests fonctionnels ne sont plus suffisants c’est pourquoi les tests non fonctionnels font partie intégrante de l’avenir du test logiciel.
Cette conférence vous présentera le travail sur les tests de performances exécutés dans le cadre de CohérenSE un projet sur la voiture de demain.

Cette présentation introduit les principes de l’ATDD visuel. Les participants découvriront comment concevoir les tests de façon visuelle en lien avec l’expression des User Stories et des critères d’acceptation, en capturant les parcours applicatifs et les règles de gestion pour produire à la fois les tests d’acceptation et les tests de non-régression. Pour introduire une démarche concrète d’ATDD visuel, nous utilisons l’outil Yest® de Smartesting pour présenter les différentes étapes de conception des scénarios d’acceptation, d’implémentation des tests (en particulier des données de test) et d’automatisation des tests de non-régression.

Dans un monde ou l’agilité a pris le dessus sur les méthodes de développement conventionnelles, on parle de plus en plus d’automatisation d’intégration continue, de DevOps.

A-t-on, ou doit-on, abandonner les tests manuels ? La réponse et oui et non.

OUI les tests manuels, tel que nous les connaissons ne sont plus efficaces et sont amenés à représenter une part très faible voir nulles de nos campagnes de tests. Les tests automatiques vont prendre une part de plus en plus importante.

NON, les tests manuels doivent se transformer pour répondre aux problématiques d’efficacité et de rapidité demandées par les méthodes Agile,

Les tests exploratoires sont l’avenir des tests manuels

Dans cette présentation, nous vous expliquerons ce qu’est réellement les tests exploratoires, comment les mettre en place, quels sont les avantages, et les inconvénients, ainsi que les pièges à éviter.

Comme tout logiciel, une application mobile doit respecter des exigences fonctionnelles. Mais qu’en est-il des exigences non fonctionnelles ? Les attentes dans ce domaine sont bien réelles, même si elles sont bien souvent peu – ou pas du tout – formalisées. Pourtant une application mobile se doit d’offrir un usage fluide (exigence de temps de réponse) et être peu consommatrice de ressources matérielles (exigences relatives à la consommation de batterie, voire à l’empreinte mémoire, la consommation de données…). Mais en pratique, comment exprimer ces exigences puis en vérifier le respect ?

Nous verrons dans cette présentation comment intégrer ces notions dans une stratégie de test d’application mobile.

• les enjeux du non-respect des exigences non fonctionnelles pour une application
• comment identifier et exprimer ces exigences ?
• exemple 1 : performance : une application grand public (une banque mobile)
• exemple 2 : autonomie : cas d’usage sur une flotte métier (SNCF Cosmo)
• comment vérifier le respect de ces exigences lors des phases de test : tests manuels ou automatisés, quels types d’appareils, quelle connectivité, etc.
• exemple : intégration dans une stratégie de test d’une application (banque mobile).

La conception des tests en agile modifie les pratiques qui s’appuyaient sur des documents d’exigences bien définis. En agile, il s’agit pour le testeur intégré dans une équipe agile, en lien avec le Product Owner, de concevoir les tests d’acceptation de l’itération et de faire évoluer les tests de non-régression. Des approches faisant intervenir la conception des tests lors de la définition des User Stories, comme dans l’ATDD – Acceptance Test Driven Development – permettent de gagner en efficacité dans la clarification du besoin, et permettent d’utiliser les scénarios de test comme une documentation vivante du logiciel. Les données de test définies sur les scénarios logiques sont associées à des données concrètes pour l’exécution, en optimisant la gestion de ces données.

Lors de cet atelier, les participants découvriront comment concevoir les tests de façon visuelle avec l’outil Yest®, en capturant les parcours applicatifs et les règles de gestion pour produire à la fois les tests d’acceptation et les tests de non-régression. Le tutoriel est conduit de façon pratique et outillée, partant du backlog du produit pour une itération et permettant de découvrir une démarche concrète d’ATDD. La mise en pratique sera réalisée en binôme de façon à partager l’analyse des User Stories et discuter les bons choix de conception des tests d’acceptation et de non –régression, en visualisant les workflows métier couverts par les tests.

Durée : 1h30

Public visé : Tous les niveaux

• Pré-requis 1 – Avoir un PC pour pratiquer avec l’outil Yest® (ou un PC pour 2). L’outil sera fourni en début de session
• Pré-requis 2 – Il est mieux d’avoir suivi la conférence ATDD Visuel avec l’atelier, pour avoir une introduction au sujet.

L’Agilité est de plus en plus « à la mode ». Les clients, qu’ils soient grands-comptes, PME-PMI, start-up, se tournent de plus en plus vers une approche projet dite “Agile”.

Au travers des différentes expériences passées et en cours, un constat revient en permanence : Beaucoup de monde dit faire de l’agilité, mais la plupart s’y prennent mal.

L’Agilité remet en cause les organisations existantes, et surtout la façon de tester : le test n’est plus une phase, mais une activité. Sans cette remise en cause, le risque d’échouer est fort, ce qui arrive malheureusement trop souvent.

Le rôle et le travail du testeur sont complètement bouleversés, encore plus celui du test manager puisque l’équipe Agile est par définition autonome.

Aujourd’hui, la façon de tester en agile ; les techniques utilisées et les outils sont différents d’un cycle en V : Cela veut-il dire que le futur du test est un monde sans testeur ?
le testeur est-il mort dans l’agilité ?

Nous allons répondre à cette question au travers de cette conférence.

Problématique : Dans un environnement professionnel toujours plus changeant en terme de processus (cycle en V, agilité, intégration continue), de migration techniques, et de développement toujours plus réactifs par rapport aux demandes exprimées ; il apparaît clairement pour le responsable qualité qu’un tableau de bord de suivi s’impose.

Solution proposée :

Un tableau de bord incluant une liste d’indicateurs utiles, pour communiquer lors des réunions, pour les statuts de fin de validation, justifier et se conforter des actions entreprises pour améliorer le processus de validation en particulier, suivre l’évolution de la qualité du produit et/ou de la qualité du service rendu et enfin préciser la stratégie de test adoptée.

La qualité logicielle et plus particulièrement la qualité du code est un challenge constamment rencontré par les industriels qui développent et/ou maintiennent des logiciels. Pour assurer que les bonnes pratiques de programmation sont bien suivies, et permettent ainsi un développement et une maintenance de qualité, les industriels mettent en place des chaînes d’outils (Continuous Integration / Continous Delivery).

Ces chaines d’outils contiennent très souvent des outils d’analyse statique de code (Linter) et des outils de mesure de couverture de tests. Si ces outils apportent des informations essentielles quant à la qualité du code et des tests, il faut avouer que les développeurs sont encore trop souvent peu engagés à les utiliser. Le résultat est qu’ils n’exploitent pas complètement les avantages apportés par ces outils.

Pour faire face à ce manque d’engagement, nous avons proposé une approche proposant (1) d’apporter un retour individualisé aux développeurs quant à la qualité logicielle, et (2) d’intégrer une couche de Gamification visant à rendre la gestion de la qualité plus ludique.