Pourquoi les marques doivent utiliser une approche « shift left »
QA Lounge

Pourquoi les marques doivent utiliser une approche « shift left »

Dean Vittum • 22 septembre 2017

Le premier testeur trouve le bug.

Tester tôt. Tester souvent. C’est le mantra que beaucoup de marques suivent aujourd’hui en intégrant leurs tests plus tôt dans le cycle de développement de logiciel (le SDLC, qui vient de Software Development LifeCycle en anglais) - une pratique connue comme étant l’approche « shift left ».

Avoir une approche « shift left » vient en fait en réaction par rapport aux difficultés rencontrées par les entreprises ayant en place un système de retours plus traditionnel. Dans un système traditionnel, les options sont limitées. Une entreprise peut développer des fonctionnalités partielles, limitant les testeurs à ce qu’ils peuvent tester, dans le but de compléter le développement du logiciel. En ce qui concerne l’autre option de système de retours traditionnel, les développeurs font des versions itératives à chaque étape importante du développement qui vont ensuite aux tests de General Availability (GA). Dans ces situations, le travail n’est pas testé entièrement pendant des mois car les testeurs attendent que l’équipe de développement ait fini. Une fois le développement terminé, les testeurs sont confrontés à une bataille ardue et ont beaucoup de tests à réaliser. Les tests de régression en pâtissent le plus puisque les testeurs portent leur attention principalement sur les fonctionnalités les plus récentes du logiciel.

Les entreprises n’ayant pas un service de QA spécialisé sont particulièrement touchées par les bugs de logiciel. Ces marques sont obligées de faire appel aux employés de tous les services de leur entreprise pour tester les logiciels. Développeurs, ingénieurs, marketeurs, et autres sont en fait détournés de leur travail pour se focaliser sur des projets pour lesquels ils ne sont pas nécessairement qualifiés.

C’est une situation menant au désastre.

Les anomalies échappent à ces testeurs ponctuels, et les clients se demandent pourquoi ils trouvent des bugs dès la sortie du logiciel. Les clients peuvent même abandonner le produit immédiatement à cause d’une mauvaise expérience avec le logiciel. Sans les ressources adéquates, le temps nécessaire, ou l’organisation pour réellement répondre aux besoins de test, les marques limitent les chances de succès de leur produit digital.

Le manque de ressource et les difficultés à tester existent dans tous types de secteurs et d’entreprises, mais sont davantage fréquents dans les entreprises émergentes. Les startups n’ont pas toujours le budget à dépenser pour embaucher une équipe de QA spécialisée. Ils n’en ont aussi pas toujours le besoin. En effet, un professionnel de QA spécialisé dans une entreprise émergente teste une fois toutes les neuf semaines environ, puis attend que la prochaine version lui arrive. Avoir des testeurs qui attendent que le développement se termine avant de pouvoir travailler n’est donc pas une utilisation efficiente des ressources.

La solution pour les entreprises qui cherchent à améliorer leur efficacité et à accélérer le temps de mise sur le marché est d’opter pour une méthode plus agile. Introduire les tests plus tôt dans le cycle de développement du logiciel est une manière d’augmenter l’agilité. Plus les tests sont introduits tôt, plus les équipes de développement peuvent recevoir un retour rapide. Mais il y a certaines tâches essentielles qu’une entreprise doit réaliser avant de commencer l’approche « shift left ».

Tout d’abord, les entreprises ont besoin d’un plan d’action. Elles doivent réaliser des cycles de sprint avec des produits digitaux d’un certain niveau de qualité à tester chaque deux ou trois semaines. Le travail doit avoir impacté une partie considérable du produit dans un cycle de sprint pour que la phase de test soit réellement rentable.

Ensuite (et c’est le plus important), les marques doivent s’entourer de testeurs spécialisés - et ne pas seulement compter sur les employés travaillant dans d’autres services pour réaliser ses tests. Une entreprise ne peut pas systématiquement détourner des membres de l’équipe des tâches essentielles de leur travail quotidien pour leur faire tester un logiciel. Une telle organisation devient rapidement hors de contrôle et rend l’entreprise moins productive, sans pour autant que tous les bugs ne soient découverts.

La rationalisation des coûts et l’efficacité font partie des souhaits principaux de toutes les entreprises. Augmenter la fréquence des tests de régression et des tests de fonctionnalité avec des services de crowdtesting comme Applause peut vous aider. Nous sommes une extension des équipes de nos clients, prêts à tester instantanément pour vous permettre de tester tôt et souvent.

Crowdtesting for Agile

View this video to understand how Applause crowdtesting works for agile development

Watch Now