Tierce Recette Applicative Automatisée

Synthèse Processus de Tierce Recette Applicative Automatisée

Etape 1 : Modélisation des usages via MaTeLo Editor

L'éditeur de modèle d'usage utilisé par AGGIL permet de simplifier l'ensemble du processus de modélisation du test. Grâce à son interface utilisateur ergonomique, les ingénieurs de test AGGIL peuvent facilement concevoir le modèle de test, y associer les exigences, définir les fonctions de test et les résultats attendus, calibrer les profils de test et gérer efficacement toutes les activités nécessaires à la réalisation du modèle.

Modéliser pour optimiser

Modélisation des usages fonctionnels à partir des spécifications fonctionnelles

La phase de modélisation permet de garantir l'identification systématique de cas d'utilisation non connus. Par rapport à une approche classique, la modélisation permet de découvrir des cas d'utilisation qu'on n'aurait pas pu nécessairement imaginer. On est obligé de se poser les bonnes questions. Ce qui permet même d'identifier des manques ou erreurs dans les spécifications. La formalisation a aussi comme avantage, par rapport à l'approche empirique, de pouvoir être revue et corrigée, pour l'adapter à une évolution des exigences par exemple. Le modèle est une représentation abstraite et partielle des comportements attendus d'un logiciel ou d'un système.

Architecture du model de test Modèle de test : les chaînes de Markov

Modélisation des usages fonctionnels en Model-Based Testing

Le modèle de test consiste essentiellement en un ensemble d'états et de transitions qui représente l'usage possible du système. Il peut être interprété comme une définition formelle de toutes les actions possibles, définies par des stimulations appelées "inputs" et associées par les transitions. Les transitions intègrent également des résultats attendus définis par les "expected results".

Modèle de test amélioré : chaînes de Markov améliorées L'architecture du modèle peut être implémentée avec de nombreux niveaux, grâce aux "macro chaînes". De plus, les objets améliorés tels que les "conditions" et les "événements asynchrones" permettent au concepteur du modèle d'implémenter facilement des modèles plus complexes et plus puissants.

Etape 2 : Stratégie de test via MaTeLo Editor

Profils et stratégie de test

Configuration des probabilités d'usage dans des profils de test

Un profil de test est principalement conçu pour qualifier le modèle. Si la qualification se fait dans le but d'établir une stratégie de test, on parle de profil de test ; si le profil de test représente l'usage du système, on parle de profil d'usage. Un profil de test définit l'ensemble des données de probabilité du modèle pour les transitions et les inputs. Il peut être défini en tant que "profil d'usage" pour mesurer la fiabilité ou en tant que "profil personnalisé" pour gérer une stratégie de test personnalisée.

Les Stratégies de tests adoptées par AGGIL Contrairement à la plupart des stratégies de test utilisées aujourd'hui et qui consistent essentiellement à corriger le maximum de bugs possible, notre principal objectif est de réduire le risque de défaillance du système lors de son activité. Pour cela notre approche de recette se divisera en deux parties distinctes.
> La phase de debuging : Le nombre de cas de test effectués sur une fonction précise est optimisé en essayant de réduire le nombre de cas de test OK qui n'augmentent pas la fiabilité de la fonction. Notre stratégie consiste en premier lieu à prioriser les cas de test qui sont le plus sujets à l'erreur et à stopper l'activité de test lorsque le taux de cas de test OK devient trop important. C'est pourquoi le premier critère de priorisation présente le risque qu'un cas de test puisse être NOK. La considération ci-dessus peut être pondérée par le fait que, du point de vue de la fiabilité, il n'est pas impératif de découvrir le maximum d'erreurs logicielles. Le plus important est de découvrir les « bonnes » erreurs, c'est-à-dire celles qui sont le plus susceptibles d'occasionner des problèmes opérationnels (fort taux de rappel en raison de ces erreurs) ou les erreurs qui sont suffisamment critiques pour être éliminées, même si la probabilité pour qu'elles se produisent est faible. C'est pourquoi il existe deux autres critères de priorisation qui représentent la criticité d'une faute pouvant se produire lors de l'exécution d'un cas de test. Le critère d'arrêt de cette phase repose sur l'idée que « lorsqu'une campagne de test n'est plus capable de révéler assez de bugs, il est certainement temps de l'arrêter. »
> La phase de qualification Lors de la phase de qualification, AGGIL utilise MaTeLo pour générer des cas de test orientés usage. Le nombre de cas de test à lancer est optimisé par l'utilisation d'une réduction de classes d'équivalence. Le critère d'arrêt de cette phase est atteint lorsque la fiabilité opérationnelle estimée est acceptable.

Les différents plans de test MaTeLo Testor propose plusieurs approches permettant de générer automatiquement les cas de tests nécessaires à l'atteinte des objectives qualités ainsi que les contraintes du planning projet. AGGIL configure les algorithmes de génération pour tester au plus juste rapport qualité de couverture /délai.

Etape 3 : Automatisation des tests fonctionnels avec Selenium QTP ou autre automate d'exécution

Exemple avec Selenium web driver

Le script d'exécution de test est généré automatiquement par l'outil MaTeLo

Les outils d'automatisation de tests fonctionnels (Selenium, QTP, TestStand,..) permettant d'exécuter des scénarios d'interactions utilisateur avec une application web, client lourd, ou système embarqués. Ces outils permettent notamment de vérifier la non-régression d'une application et est un gage de qualité supplémentaire. AGGIL utilise MaTelo pour générer automatiquement les scripts d'exécution de test fonctionnels. Pour cela les ingénieurs automaticiens d'Aggil intègrent dans le modèle d'usage de l'outil MaTeLo des scripts génériques qui seront instanciés lors de la génération des tests, et en fonction des profils et stratégie de test sélectionnés. La maintenance des scripts se trouve dés lors beaucoup plus aisée, par la simple modification du modèle.

Etape 4 : Exécution des tests manuellement

Les plans de test générés par l'outil MaTeLo peuvent être exécutés à la main.

Certains tests ne pouvant être automatisés, il est nécessaire de faire intervenir un testeur manuel AGGIL, qui réalisera les plans de tests générés par MaTeLo, et renseignera les résultats de la campagne dans Quality Center ou Testlink. 2 cas de figures sont possibles :
>Le testeur AGGIL manuel suit les scénarios de tests, générés par Matelo, sur Quality Center,
>L'exécution est hybride (manuelle & automatique), une IHM indique les tests manuels à réaliser au sein du processus automatisé avec Selenium ou autre outil d'automatisation.

Grâce à ses plate-formes offshore, AGGIL est en mesure de réaliser les campagnes de tests manuels à moindre coût sur ses sites Vietnam et Tunisie.

 

Etape 5 : Analyse des défauts

Les campagnes de test automatiques ou manuelles sont analysées avant insertion des anomalies dans le système de tracking.

L'ingénieur AGGIL de qualification des défauts, avec sa connaissance fonctionnelle et technique de l'application, valide les problèmes remontés par l'automatisation de test. Son objectif et ses principales tâches sont : Indicateur d'analyse Des rapports contenant les résultats des tests seront extraits à l'aide de l'outil MaTeLo et intégrés par l'équipe TRA dans Quality Center. Ceci permettant d'avoir une vision globale sur les indicateurs de test présenté sous différentes formes Tableau, Dashboard, graphique…Pour assurer le suivi des tests par les équipes du client. Des indicateurs permettent d'apprécier une situation sur un axe Assurance Qualité : Le calcul de scoring (S) de non-qualité se mesure en additionnant le scoring des anomalies observées : ∑ Mi x Gi x Ri x Pi avec :

>Importance (M) : la fonctionnalité peut être indispensable, attendue, utile
>Gravité (G) : la gravité d'une anomalie dépend du degré observable de nuisance de l'anomalie. Il peut être bloquant, majeur, mineur, trivial
>Risque (R) : il dépend de la probabilité d'apparition d'un événement et de son impact. Ce paramètre dépend du niveau de maturité observable sur le plan du projet et de son organisation. Un environnement de faible maturité verra ce paramètre égal à 1. ->Priorité (P) : elle définit l'ordre de traitement. Elle peut être haute, moyenne, basse. Dans une organisation de forte maturité en termes de gestion des exigences, et des cas de tests, il peut être égale à 1. En effet, il découle de l'importance (M) de la fonctionnalité que le test couvre.

Complément de qualification du défaut Rejouer les étapes permettant de s'assurer de la reproduction du défaut, et compléter si nécessaires les informations utiles à la bonne définition du problème rencontré. ->Proposition de solution Proposition des solutions préliminaires à étudier donnant des indications au développeur sur les raisons pouvant engendrer un défaut et les moyens de le supprimer, ou de le contourner.
>Aiguiller le défaut Les défauts sont analysés afin d'aiguiller la correction du défaut par l'équipe de développement ou de maintenance la plus adaptée. Afin de réduire les temps de correction des défauts, l'ingénieur de qualification des défauts affecte le défaut à l'équipe la plus apte à le corriger.

Contactez nous au 01 47 90 81 27 ou cliquez pour une demande de renseignement ou de devis !