« Maintenant, on va automatiser les tests. »
La première fois que vous avez entendu cette phrase, vous avez certainement pensé que ce serait une bonne idée et que cela permettrait de consolider durablement la qualité des applicatifs concernés. Dans la plupart des cas, vous aviez raison. Mais à ce moment-là, pensiez-vous déjà à toutes les émotions que vous ressentiriez au cours de ce périple ?
Ce qu’apporte le crowdtesting ? En tout premier lieu, un entraînement d’élocution, car c’est un des mots les plus rugueux que vous aurez à prononcer dans votre vie (mais pour votre bonheur, vous trouverez dans cet article des propositions alternatives plus francofluides).
Aujourd’hui, pour répondre à cette question, nous nous plaçons du côté des éditeurs. Cela regroupe à la fois, certes, les sociétés éditant des logiciels, mais aussi les organisations ayant fait développer un site ou une appli, en interne ou par un prestataire.
A l’heure où cet article est publié, une partie importante de la population mondiale vit confinée. Le coronavirus est de toutes les conversations, il modèle notre quotidien et habite nos pensées à tout moment. Difficile de relire les 7 principes généraux du test logiciel sans que le parallèle avec la situation actuelle ne saute aux yeux…
Cet article est aussi l’occasion pour toute l'équipe Hightest de vous souhaiter bon courage en cette étrange période, où que vous soyez.
Dans l’article précédent, nous proposions quelques ressources pour (mieux) appréhender le Behavior Driven Development. Mais quid de l’implémentation de cette méthodologie dans le cadre de projets dont le code historique (ou legacy) représente une part très importante ? Florent Vaution, Software QA Manager chez Ouest-France, a tenté l’expérience et présente ici son témoignage.
Le Behavior Driven Development : vous connaissez « de nom, de loin, vite fait », ça a l’air bien mais il vous manque des précisions. Cet article est votre chance d’y remédier !
Si le BDD fait déjà partie de votre quotidien, vous trouverez peut-être aussi des points de clarification, ou des éléments historiques qui donneront de la profondeur à votre pratique.
Les longs récits de conférence n’intéressent personne, nous ne vous dirons donc pas à quel point TestBash Australia 2019 a été stimulant, merveilleux et inspirant ! En revanche, nous voudrions partager avec vous un atelier proposé à cette occasion par Mark Winteringham (merci à lui !), et que vous pourriez avoir envie de réaliser avec votre équipe.
How Google Tests Software (de James Whittaker, Jason Arbon et Jeff Carollo, 2012) est à nos yeux un ouvrage de référence. Il ne s’agit certes pas d’un référentiel de pratiques de test à appliquer à la lettre, mais nous avons été agréablement surpris de voir qu’il regorge d’idées intéressantes pouvant être adaptées à des entreprises de toutes les tailles. Ce qui nous a d’ailleurs inspiré un article sur les plans de test.
Nous avons le plaisir de vous dire que cet article a été écrit à quatre mains, avec Brice Roselier. Expérimenté en test, il a mis en place des KPI afin de suivre la progression de la qualité des activités de test dans son contexte.
Dans notre article précédent, nous donnions des pistes pour organiser le contrôle des tests par des instances extérieures à l’équipe de test. En effet, il n’est pas rare d’avoir à rendre des comptes sur les activités de test, et cela peut même être une bonne opportunité pour roder un peu mieux ses pratiques.
On dit que les cordonniers sont les plus mal chaussés. Qu’en est-il des testeurs ; sont-ils les plus mal testés ?
De la qualité des tests découle en partie la qualité des applications. Une application de qualité est souvent une application qui a été bien testée. Les tests permettent d’avoir une idée de la qualité des applications, mais qu’est-ce qui permet d’avoir une idée de la qualité des tests ? En quelque sorte, comment tester les tests ?