Cette fois-ci, nous vous proposons une approche metier :

Nous avions insiste concernant la necessite une realisation de tests fonctionnels automatises qui est de mieux en mieux comprise par l’ensemble des prestations, mais nos besoins du metier sont rarement satisfaits ce qui ralentit des decisions et leur mise en place. Voici des pistes Afin de presenter, d’un point de vue metier, ces tests fonctionnels automatises.

Introduction

Avec des applications web et mobiles a toutes les enjeux i  chaque fois plus consequents, le besoin haut de gamme de ces applications croit egalement. Dans votre contexte, des tests fonctionnels automatises deviennent, petit a petit, un standard de l’industrie. Plusieurs niveaux de solutions seront proposees en fonction des besoins, de l’environnement technique et des ressources accessibles.

Les types de tests fonctionnels automatises

Avant de commencer, petit recapitulatif des types de tests existants :

Les principaux besoins metier

Qualite

Le principal besoin lorsque l’on fera des tests fonctionnels automatises reste d’assurer un niveau durable minimum constant de l’application a deployer. En utilisant une solution de tests automatises, on s’assure qu’un perimetre minimum de l’application est verifie systematiquement. On va pouvoir alors deployer en production avec plus d’assurance.

Couverture

Dans le cadre des tests fonctionnels, l’utilite d’essayer l’ensemble du perimetre est debattue. Les elements a prendre en compte sont :

• La duree d’execution des tests
• J’ai maintenabilite des tests
• Mes conditions d’implementation a toutes les processus d’integration continue.

Attention a garder votre socle minimum comprenant les smoke tests (tests detailles i  propos des parcours critiques) de l’application dans le but de garantir sa stabilite.

Reporting

L’execution des tests fonctionnels doit etre accompagnee de reporting permettant de visualiser les succes et erreurs rencontres. Pour nos erreurs, il convient que nos points necessaires Afin de analyser, reproduire et corriger l’erreur soient accessibles.

Escalade

Si des erreurs seront rencontrees au cours des tests, Il semble necessaire de prevenir les personnes concernees pour des analyser, prioriser et corriger avant leur mise en production. En fonction de l’organisation, ce qui pourra passer par des notifications par mail, par la creation/mise a jour de tickets… En cas d’erreur i  propos des plateformes en amont d’une production, le sujet du deploiement en production se pose. Le process en place doit prevoir quels seront les tri possibles. Dans le cadre d’une integration des tests fonctionnels dans les process CICD, La selection traditionnelle est souvent celui de stopper le deploiement en cas d’erreur et en prevenant l’equipe projet. Diverses scenarios peuvent etre envisages en fonction du type d’erreur rencontre.

Definition Plusieurs scenarios des tests fonctionnels

Le perimetre minimum des tests depend bien evidemment de l’application. Il existe neanmoins des elements de base a tester, de 2 types :

• Les elements de structure tels que le header, les elements de navigation et le footer. Ils paraissent indispensables a une agreable utilisation du website. Il est important de verifier leur teneur.
• Mes scenarios critiques tels que l’authentification, l’inscription, la recherche bien, l’ajout de produits aux paniers, le checkout…

Liste bbwdesire premium des elements principaux a avoir en tete

• Elements de structure
  • Composition d’la page d’accueil
  • Composition en page produit
  • Navigation
  • Footer
• E-commerce
  • Authentification (Avec ou sans SSO)
  • Creation de compte (Avec ou sans SSO)
  • Page de categorie
  • Lancer une recherche avec service
  • Lancer une requi?te sans resultat
  • Acceder a une page de detail service
  • Ajout au panier
  • Modification des quantites
  • Suppression d’article du panier
  • Achat sans login
  • Achat logue
    • en tant que premier achat
    • a partir du second achat
• Vitrine
  • Formulaire de lead
  • Fonctionnalites principales de l’application
  • Contact

Composition des scenarios

Avant de pouvoir creer les tests associes, chaque scenario doit pouvoir repondre a toutes les questions suivantes :

• Quel types d’utilisateurs (non identifies, identifies, droit particulier) ? Cela permet de connaitre les etapes prealables du test (ex : connexion/ deconnexion)
• Quelles etapes du parcours composent le test ?
• Quels sont les resultats attendus pour chacune de ces etapes ?