Description du projet
TraduitNous exploitons un portail B2B utilisé chaque jour par nos partenaires et gestionnaires de compte, et nous expédions des mises à jour environ deux fois par mois. À chaque version, nous testons les mêmes chemins critiques à la main, cela prend une journée entière du temps d'un testeur manuel, et des choses échappent encore parce qu'un humain se fatigue et saute une étape. Nous voulons remplacer ce rituel par une suite de régression automatisée qui s'exécute avant chaque version et nous indique clairement si les scénarios principaux fonctionnent toujours.
La suite doit couvrir le flux de connexion avec des identifiants valides et invalides et un compte verrouillé, le chemin complet de soumission de demande depuis un formulaire vide jusqu'à un enregistrement confirmé, et l'accès basé sur les rôles afin qu'un partenaire ne voie jamais les écrans d'un gestionnaire et qu'un gestionnaire ne puisse pas accéder à la zone d'administration. Nous aimerions que les tests s'exécutent contre une copie de staging du portail, produisent un rapport lisible montrant quels scénarios ont réussi et lesquels ont échoué avec une capture d'écran au moment de l'échec, et soient lancés à la fois manuellement et depuis notre pipeline de construction avec un code de sortie clair.
Nous attendons un code de test propre et maintenable qu'un nouvel ingénieur peut étendre, des sélecteurs stables qui ne se cassent pas lors de changements mineurs de balisage, et de courtes notes écrites sur la façon d'ajouter un nouveau scénario. Les livrables incluent :
— scénarios de connexion couvrant le succès, le mauvais mot de passe et un utilisateur bloqué ;
— soumission de demande de bout en bout avec validation des champs ;
— vérifications de rôle et de permission pour partenaire, gestionnaire et administrateur ;
— un rapport lisible et un code de sortie compatible avec le pipeline.
La suite doit couvrir le flux de connexion avec des identifiants valides et invalides et un compte verrouillé, le chemin complet de soumission de demande depuis un formulaire vide jusqu'à un enregistrement confirmé, et l'accès basé sur les rôles afin qu'un partenaire ne voie jamais les écrans d'un gestionnaire et qu'un gestionnaire ne puisse pas accéder à la zone d'administration. Nous aimerions que les tests s'exécutent contre une copie de staging du portail, produisent un rapport lisible montrant quels scénarios ont réussi et lesquels ont échoué avec une capture d'écran au moment de l'échec, et soient lancés à la fois manuellement et depuis notre pipeline de construction avec un code de sortie clair.
Nous attendons un code de test propre et maintenable qu'un nouvel ingénieur peut étendre, des sélecteurs stables qui ne se cassent pas lors de changements mineurs de balisage, et de courtes notes écrites sur la façon d'ajouter un nouveau scénario. Les livrables incluent :
— scénarios de connexion couvrant le succès, le mauvais mot de passe et un utilisateur bloqué ;
— soumission de demande de bout en bout avec validation des champs ;
— vérifications de rôle et de permission pour partenaire, gestionnaire et administrateur ;
— un rapport lisible et un code de sortie compatible avec le pipeline.
Développement de logiciels Espèces, Virement bancaire
