Assurance qualité (QA)

Lors de l'implémentation de fonctionnalités (c'est-à-dire de fonctions qui sont exécutées par un utilisateur), l'assurance qualité (QA) fait partie de la réception. Jusqu'à présent, tu as appris que ton code doit être revu avant d'être approuvé. Maintenant, le QA doit avoir lieu avant la création de la pull-request.

Pour effectuer le QA, tu peux demander à l'un de tes interlocuteurs (tout le monde peut et devrait faire des QA) de tester ta fonctionnalité. Le testeur doit utiliser ta fonctionnalité sans être guidé par toi. Ainsi, le regard du testeur reste impartial et les problèmes UI/UX sont plus rapidement visibles. Ainsi, si ton collègue pose beaucoup de questions sur l'utilisation de la fonctionnalité, il se peut que ton front-end ne soit pas assez convivial.

En outre, le testeur doit tester les entrées utilisateur de manière approfondie. L'objectif du QA est de s'assurer que ta fonctionnalité est étanche et que tous les cas d'erreur sont bien traités. Les entrées possibles sont :

saisie de très longues chaînes de caractères saisie de valeurs inattendues (par ex. un nombre au lieu d'une chaîne de caractères attendue) Saisie de nombres négatifs pour les champs numériques Déclenchement multiple de boutons (peut par exemple déclencher plusieurs appels au backend et entraîner ainsi des erreurs). Si ton testeur ne trouve pas (ou plus) d'erreurs, le QA est terminé avec succès. Ton ticket peut alors être mis en PR. Remarque : Si, par exemple, de nombreux codes sont rejetés/modifiés dans PR, le QA n'est plus valable pour la nouvelle version. Pour éviter cela, il est possible de procéder à une nouvelle acceptation (finale) après la fusion du PR. Cela n'est toutefois pas nécessaire dans le projet d'intégration.

auguste2003 / GeekHR-Connect

Assurance qualité (QA) #17