Le principe de base de l’approche “shift left” consiste à tester plus tôt dans le cycle de développement logiciel qu’après la construction et le déploiement de la nouvelle version ou du Minimum Viable Product (MVP) en environnement de recette.

Il est aussi important de savoir que le fait d’entreprendre une approche dite « shift left » n’est pas une simple modification d’ordre des étapes ou des rôles, mais implique un véritable changement de culture et de stratégie.

Afin d’éviter les mauvaises surprises, voici le top 3 des bonnes pratiques à appliquer dans votre démarche de transformation de vos processus développement et QA.

1- Moins de cloisonnement, plus de collaboration et de communication

Dans une conception traditionnelle d’un projet informatique, les différents intervenants sont cloisonnés et la livraison du logiciel suit un processus linéaire. La mise en place de l’approche “shift left” nécessite la suppression des barrières entre les différents acteurs du projet. Cette opération de décloisonnement permet l’amélioration de la communication interne, une meilleure compréhension du besoin et donc la mise en place des tests adéquats pendant la phase de conception.

La réussite de cette première étape permet une amélioration notable de la productivité et de la qualité des livrables comme les bugs sont détectés de plus en plus en amont et donc les développeurs possèdent plus de temps pour un traitement efficace des différents retours.

Du coup, l’aspect humain est très important à prendre en compte dans cette première phase de transformation et le succès sera donc, conditionné par le degré d’implication de l’ensemble des intervenants du projet (développeurs, testeurs et métiers).

2 – La technologie au service de l’automatisation

La réussite de la mise en place de l’approche “shift left” nécessite également la multiplication de cycles d’automatisation des tests le plus en amont possible dans une démarche devops (industrialisation du pipeline CI/CD).
Côté démarche de projet, il est fortement recommandé d’accompagner cette tendance d’automatisation par les pratiques suivantes :

  • Diversification des scénarios et des types de tests (unitaires, fonctionnels, sécurité, performance, montée en charge et ergonomie).
  • Audit continu du code de l’application à l’aide d’outils comme SonarQube, Veracode ou Fortify on Demand.
  • Maintien régulier des environnements et des plateformes ciblées pour les tests (mobile, pc, appareils connectés, etc.) pour qu’ils soient toujours disponibles et à jour.
  • Analyse des rapports de test afin de contrôler la qualité du livrable et donc l’efficacité des tests automatiques.

3- Les sources des scripts de tests automatiques doivent rester vivantes

Comme les logiciels sont dynamiques, la maintenance évolutive du code source de la pile des tests automatiques est indispensable afin que la couverture reste pertinente et adaptée aux changements réalisés au niveau du système applicatif. Pour cela, il est très important de veiller à ce que l’ensemble du code des scripts de test reste intégré au niveau de la chaîne CI/CD et donc bénéficie d’une validation et de build réguliers.

L’équipe QA doit continuellement réduire l’écart entre les scénarios de tests automatisés existants et les changements effectués au niveau des applications testées. Ce travail de fond n’est pas du tout évident à maintenir pour plusieurs raisons notamment le caractère urgent de certaines demandes commerciales, les hotfixs en production,  l’optimisation du budget SI, voir même le manque de ressources hautement qualifiées pour le faire. C’est dans ce cadre précis que nos consultants QA et automatisation de test, chez Experts Du Test, pourrons vous apporter le maximum de valeur ajoutée comme ils ont déjà l’habitude de ce type de chantier de transformation et donc leurs expériences vous permettront de franchir le cap avec beaucoup de sérénité et au meilleur coût. Parlez-nous de votre besoin ?

En conclusion, les bénéfices d’une mise en place du “shift left” testing sont multiples, mais ce chantier représente un vrai challenge pour les décideurs IT car il suffit de manquer de moyens, d’organisation ou d’implication et toute la pratique n’apportera pas tous les bénéfices escomptés.