Meilleures pratiques en Agile pour l'assurance qualité

L'assurance qualité dans le développement de logiciels n'est pas comme tester le produit en couvrant les exigences de l'entreprise, mais ressemble au processus d'assurance qualité que vous mettez en œuvre et génère-t-il le retour sur investissement. Aujourd'hui dans l'industrie du logiciel, le client est toujours à la recherche de déploiements fréquents et itératifs. Si vous êtes une personne chargée de l'assurance qualité, vous devez tester un système dont les exigences changent fréquemment ou que de nouvelles exigences arrivent rapidement, ce qui entraîne des changements fréquents de code. En tant que ressource d'assurance qualité idéale, vous devez intervenir du premier au dernier jour du cycle de publication, en vous assurant que tous les membres de l'équipe et les clients sont sur la même longueur d'onde tout au long du développement et des tests.

En implémentant Agiles dans notre pratique quotidienne, nous pouvons préparer le processus d'assurance qualité, nous pouvons programmer et exécuter toutes les activités de test pour les différentes phases de développement. Il existe de nombreuses façons d'implémenter Agile, je parle ici de Scrum. Dans la mêlée, l'organisation suit souvent la version itérative de 2 à 3 semaines appelée Sprint . Vous trouverez ci-dessous quelques points qui seront très utiles à toute personne chargée de l'assurance qualité pour augmenter la productivité en Agile. . En tant que QA, vous mettez en place le point de l'histoire en vous assurant que toutes vos activités de test seront terminées dans le délai imparti. Vous pouvez calculer le point de l'histoire en parcourant l'histoire en profondeur et en analysant les zones impactées. Parfois, il peut être possible pour l'équipe de développement qu'il s'agisse d'un changement simple mais l'impact est sur tous les modules du système, en ce sens que vous devez être très prudent lorsque vous proposez des points d'histoire. Décider des points d'histoire en fonction de la séquence de Fibonacci est le moyen le plus populaire, ici nous élevons le point d'histoire en utilisant les nombres de Fibonacci, 0, 1, 1, 2, 3, 5, 8, 13, 21. Si la taille de l'histoire est grande puis de la même manière, nous sélectionnons le nombre de manière ascendante.

Prioriser l'histoire/les exigences du sprint

Dans tout sprint actif, nous devons travailler sur plusieurs histoires et bugs, à ce moment-là, décider de la priorité pour chaque tâche peut être très difficile, étant un QA, vous pouvez considérer les points ci-dessous lors de la hiérarchisation.

• Assurez-vous que tous les changements majeurs doivent être sélectionnés au début du sprint afin que les tests puissent être terminés dans le temps défini et au cas où si un problème de blocage survient, nous avons suffisamment de temps pour nous y attaquer.
• Lors de la sélection de l'histoire pour un sprint particulier, assurez-vous de choisir la combinaison optimale en fonction de la priorité. Par exemple. Si vous avez dix histoires, cinq devraient être une priorité moyenne, trois devraient être faibles et deux devraient être une priorité élevée.
• Au début, assurez-vous que vous choisissez les éléments de débordement du sprint précédent. [19659020]Suivi des backlogs

  Les backlogs de produits ont souvent de nouvelles histoires d'utilisateurs, des demandes de modification par le client pour des fonctionnalités existantes de même, nous avons des éléments en attente dans les backlogs que nous n'avons pas encore sélectionnés en raison d'autres développements en cours. En tant qu'agent d'assurance qualité, il est de votre responsabilité principale de continuer à examiner les arriérés et de devoir également discuter avec les développeurs et les clients afin que si nous avons la bande passante dans le sprint actuel ou à venir, les éléments puissent être sélectionnés dans les arriérés et cela aussi vous aide à vous débarrasser du plus grand nombre de backlogs. au reste de l'équipe. En tant que QA, vous devez toujours être au premier plan en mettant à jour votre statut de travail et vos bloqueurs si vous l'avez fait, en vous assurant que vous avez une communication régulière avec l'équipe de développement pour que tout le développement réponde aux exigences de l'entreprise. Souvent, les réunions de mêlée quotidiennes durent 15 minutes, généralement, la discussion tourne autour des trois points ci-dessous. ?

Travailler conjointement avec le client

C'est l'une des principales responsabilités d'une personne chargée de l'assurance qualité de communiquer constamment avec le client et de fournir son expérience de test sur le système. En outre, vous pouvez suggérer toute nouvelle idée ou toute amélioration pouvant faciliter l'accès du projet aux utilisateurs. Vous pouvez planifier la démo si une exigence est remplie et parler au client qu'après ce nouveau changement de code, le comportement du système sera différent et prendre les commentaires pour confirmer que ces changements répondent ou non à leurs exigences. demandez s'ils ont besoin d'un nouvel addon à ce sujet, et vous pouvez planifier la même chose avant la sortie.

Participer à la réunion rétrospective

En tant que ressource d'assurance qualité progressive, assurez-vous de toujours assister à la réunion rétrospective et mettre toute votre expérience/rétroaction sur le sprint, vous pouvez décrire votre expérience en En suivant trois critères ci-dessous.

• Qu'est-ce qui s'est bien passé dans le sprint ?
• Qu'est-ce qui pourrait être amélioré ?
• Qu'est-ce qui n'a pas fonctionné ?

]Vous devez vous assurer que, quels que soient les bloqueurs/problèmes auxquels vous avez été confronté lors du dernier sprint, s'il apparaît à nouveau dans le nouveau Sprint, vous avez la solution pour cela et vous pouvez continuer votre mission. PARTAGEZ-LE