Aller au contenu

Utilisation du BDD avec Robot Framework dans Squash AUTOM – Rédaction des cas de test

Rédaction des cas de test

Annita
Administratrice Squash TM
Pravash
Product owner
Fabrice
Testeur fonctionnel
Antonine
Automaticienne
Configurer Squash TM
Rédiger les exigences
Rédiger les cas de test
Transmettre les cas de test
Récupérer les cas de test
Automatiser les cas de test
Fournir les cas de test automatisés
Indiquer que l’automatisation est effectuée
Exécuter les tests automatisés

Pendant les sessions de raffinement (grooming), Pravash explique à toute l'équipe (Scrum master, développeurs et Fabrice) les fonctionnalités qu'il souhaite intégrer au produit. Pour chaque fonctionnalité, les développeurs et Fabrice demandent des détails à Pravash (cas nominaux, cas d'erreur, cas limites…). Ensuite, l'équipe définit ensemble un ou plusieurs cas d'utilisation et les rédige en utilisant la syntaxe Gherkin. Cela garantit que tout le monde partage la même compréhension de ce qui doit être mis en œuvre et que cette compréhension est capitalisée.

Un aperçu de la syntaxe Gherkin

  • Given (Etant donné) : Décrit un prérequis, c'est-à-dire une condition préalable pour que le scénario soit applicable. Toutes les conditions préalables définissent l'état initial (ou du moins la partie pertinente de l'état initial) du système avant le début du cas d'utilisation.
  • When (Quand) : Décrit une action effectuée pendant le test. Les actions sont exécutées dans l'ordre spécifié.
  • Then (Alors) : Décrit un résultat, c'est-à-dire une postcondition, qui doit être remplie à la fin du test. Tous les résultats définissent l'état final attendu (ou du moins la partie pertinente de l'état final) du système après la fin du cas d'utilisation.

Certaines conjonctions peuvent être utilisées pour éviter de répéter les mots précédents (elles ont la même signification que la répétition du mot) :

  • And
  • But

Exemples :

Scenario: Un utilisateur retire de l'argent de son compte bancaire
    Given Eric possède une carte de débit basique valide  
    And le solde de son compte est de 100 $  
    When il insère sa carte  
    And il retire 45 $  
    Then le distributeur doit lui donner 45 $  
    And le distributeur lui rend sa carte
    And le solde de son compte est de 55 $

Scenario: Un utilisateur tente de retirer plus d'argent qu'il n'en a sur son compte
    Given Vsevolod possède une carte de débit basique valide  
    And le solde de son compte est de 20 $
    When il insère sa carte  
    And il retire 40 $  
    Then le distributeur affiche alors une erreur  
    And le distributeur lui rend sa carte
    But le solde de son compte reste de 20 $

Les Doc Strings peuvent être utilisées pour définir un grand morceau de texte. Elles sont délimitées par trois guillemets doubles.
Exemple :

Then le distributeur affiche le message d'erreur suivant
 """
 Retrait refusé
 ================
  Votre carte de débit ne vous permet pas de retirer plus d'argent que le solde de votre compte courant.
  Veuillez contacter votre conseiller bancaire.
 """

Les Data Tables peuvent être utilisées pour définir une liste de valeurs dans une action. Exemple :

Given les cartes de débit existent :
  | nom      | découvert autorisé     | durée maximale du découvert (jours) |
  | basique  | 0 $                    | 0                                   |
  | gold     | 500 $                  | 15                                  |
  | platinum | 3000 $                 | 42                                  |

Il est possible de regrouper des scénarios ayant les mêmes actions, mais des valeurs différentes en utilisant un Scenario Outline et des caractères de remplacement entre < et >.
Exemple :

Scenario Outline: Un utilisateur retire de l'argent à un distributeur
    Given <Nom> possède une carte de débit basique valide
    And le solde de son compte est <SoldeInitial> 
    When il insère sa carte     
    And il retire <MontantDuRetrait>
    Then le distributeur devrait lui donner <MontantDuRetrait>  
    And le distributeur lui rend sa carte
    And le solde de son compte est <NouveauSolde>

    Exemples :
      | Nom    | SoldeInitial    | MontantDuRetrait | NouveauSolde |
      | Eric   | 100             | 45               | 55           |
      | Gaurav | 100             | 40               | 60           |
      | Ed     | 1000            | 200              | 800          |

Un exemple de scénario noté par Fabrice :

Create an account, then check login and personal data

Given I am on the AccountCreation page
When I fill AccountCreation fields with gender <gender> firstName <first> lastName <last> password <password> email <mail> birthDate <birth> acceptPartnerOffers <offers> acceptPrivacyPolicy <privacy> acceptNewsletter <news> acceptGdpr <gpdr> and submit
And I go to the Home page
And I sign out
Then I can successfully sign in with email <mail> password <password>
And The displayed name is <display>
And My personal information is gender <gender> firstName <first> lastName <last> email <mail> birthDate <birth> acceptPartnerOffers <offers> acceptPrivacyPolicy "no" acceptNewsletter <news> acceptGdpr "no"
Examples: 
  | gender | first     | last        | display             | password     | mail               | birth        | offers | privacy | news  | gpdr  |
  | "M"    | "John"    | "Doe"       | "John Doe"          | "mypassword" | "jdoe@example.com" | "1990-01-02" | "no"   | "yes"   | "yes" | "yes" |
  | "F"    | "Jane"    | "Doe"       | "Jane Doe"          | "123&µ"      | "jane.doe@oo.com"  | "1992-01-02" | "yes"  | "yes"   | "yes" | "yes" |
  | "U"    | "Camille" | "Bertillon" | "Camille Bertillon" | "£→µ$¤11"    | "cb@gmail.com"     | "1968-02-10" | "yes"  | "yes"   | "no"  | "yes" |
  | "U"    | "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz" | "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz" | "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz" | "012345678901234567890123456789012345678901234567890123456789"    | "012345678901234567890123456789012345678901234567890123456789@oo.com"     | "2022-02-10" | "yes"  | "yes"   | "yes"  | "yes" |

Fabrice enregistre ces scénarios Gherkin comme des cas de test BDD dans Squash TM et les lie aux exigences telles que définies dans la documentation Squash TM :

test case definition

test case definition

test case definition

Transmission des cas de test

Annita
Administratrice Squash TM
Pravash
Product owner
Fabrice
Testeur fonctionnel
Antonine
Automaticienne
Configurer Squash TM
Rédiger les exigences
Rédiger les cas de test
Transmettre les cas de test
Récupérer les cas de test
Automatiser les cas de test
Fournir les cas de test automatisés
Indiquer que l’automatisation est effectuée
Exécuter les tests automatisés

Une fois qu'un cas de test a été revu et approuvé (voir documentation Squash TM), Fabrice le signale comme éligible à l'automatisation (voir Squash TM documentation) et, éventuellement, définit une priorité d'automatisation. Il peut maintenant transmettre le scénario de test en cliquant sur la flèche :

test case transmission

La transmission du cas de test a deux effets :

  • le fichier robot est généré et est poussé vers le dépôt Git distant quelques minutes plus tard ;
  • le cas de test apparaît dans l’Espace Automatisation.