Syllabus ISTQB Automatisation de Test

3.2.2  Approches pour automatiser les cas de test (K2)

Les cas de test doivent être traduits en séquences d’actions qui sont exécutées sur le SUT. Cette séquence d’actions peut être documentée dans une procédure de test et/ou peut être implémentée dans un script de test. En plus des actions, les cas de test automatisés devraient également définir les données de test pour l’interaction avec le SUT et inclure les étapes de vérification pour vérifier que le résultat attendu est atteint par le SUT. Plusieurs approches peuvent être utilisées pour créer une séquence d’actions:

1. Le TAE implémente les cas de test directement en scripts de test automatisés. Cette option est la dernière recommandée car elle manque d’abstraction.
2. Le TAE conçoit les procédures de test et les transforme en scripts de test automatisés. Cette option a de l’abstraction mais manque d’automatisation pour générer les scripts de test.
3. Un outil traduit les procédures de test en des scripts de test automatisés. Cette option combine à la fois abstraction et génération de script automatisé.
4. Un outil génère les procédures de test automatisées et/ou les données de test depuis les modèles. Cette option a le plus haut degré d’automatisation.

Notez que les options disponibles dépendent fortement du contexte du projet. Il peut également être efficace de commencer l’automatisation de test en appliquant une des options les moins avancées, car  elles sont faciles à mettre en œuvre, et peuvent avoir une valeur ajoutée à court terme bien que cela résultera dans une solution moins maintenable.

Des approches bien établies pour l’automatisation des cas de test incluent:

• Approche capture/rejeu, qui peut être utilisée pour l’option 1
• Approche de scripting structurée, approche pilotée par les données et approche pilotée par les mots-clés, qui peuvent être utilisées pour les options 2 ou 3
• Test basé sur les modèles (incluant l’approche pilotée par les processus Métier), qui peut être utilisé pour l’option 4

Ces approches sont expliquées par la suite en termes de concepts principaux avec les avantages et les inconvénients.

Approche capture/rejeu 

Concept Principal

Dans l’approche capture/rejeu, les outils sont utilisés pour capturer les interactions avec le SUT lorsqu’une séquence d’actions définies par une procédure de test est réalisée. Les entrées sont capturées; les sorties peuvent également être enregistrées pour des vérifications futures. Pendent le rejeu des événements, il existe différentes possibilités de vérification, manuelles ou automatisées:

• • Manuelle: Le testeur doit regarder les sorties du SUT pour détecter les anomalies
  • Complète: Toutes les sorties du système qui ont été enregistrées pendant la capture doivent être reproduites par le SUT
  • Exacte: Toutes les sorties du système qui ont été enregistrées pendant la capture doivent être reproduites par le SUT au niveau de détail enregistré
  • Checkpoints: Seulement les sorties du système sélectionnées sont vérifiées à un certain moment avec des valeurs spécifiées

Avantages

L’approche capture/rejeu peut être utilisée pour les SUTs au niveau IHM et/ou au niveau API. Dans un premier temps, c’est facile à mettre en place et à utiliser.

Inconvénients

Les scripts de capture/rejeu sont difficiles à maintenir et à faire évoluer car l’exécution capturée du SUT dépend fortement de la version de SUT. Par exemple, en enregistrant au niveau IHM, les changements d’ IHM peuvent impacter le script de test, même s’il s’agit seulement du positionnement d’un élément graphique. Les cas de test basés sur la capture/rejeu sont très fragiles.

L’implémentation des cas de test (scripts) peut seulement commencer quand le SUT est disponible.

Scripting linéaire 

Concept Principal

Comme avec toutes les techniques de scripting, le scripting linéaire commence avec des procédures de test manuelles. Notez cependant que cela peut ne pas être des documents écrits – Savoir quels tests exécuter et comment les exécuter peut être connu par un ou plusieurs Analystes de Test.

Chaque test est exécuté manuellement pendant que l’outil de test enregistre la séquence d’actions et dans certains cas capture les sorties visibles à l’écran du SUT. Cela résulte en général dans un script (typiquement long) pour chaque procédure de test. Les scripts enregistrés peuvent être  édités pour améliorer la lisibilité (c.à.d., en ajoutant des commentaires pour expliquer ce qui se passe aux points clés) ou ajouter d’autres vérifications en utilisant le langage de scripting de l’outil.

Les scripts peuvent alors être rejoués par l’outil, faisant répéter à l’outil les mêmes actions que celles faites par le testeur quand le script a été enregistré. Bien que cela puisse être utilisé pour automatiser les tests d’ IHM, ce n’est pas une bonne technique à utiliser quand un grand nombre   de tests sont à automatiser et seront requis pour plusieurs versions du logiciel. C’est à cause des coûts de maintenance élevés généralement dus aux changements du logiciel sous test (chaque changement dans le SUT peut entraîner beaucoup de changements dans les scripts enregistrés.

Avantages

Les avantages des scripts linéaires se focalisent sur le fait qu’il y a peu ou pas de travail de préparation avant de pouvoir automatiser. Une fois que vous avez appris à utiliser l’outil, il n’y a  qu’à enregistrer un test manuel et à le rejouer (bien que la partie enregistrement puisse nécessiter une interaction supplémentaire avec l’outil de test pour demander des comparaisons entre les résultats obtenus avec les résultats  attendus  et  vérifier  que  le  logiciel  fonctionne  correctement). Des compétences en programmation ne sont pas exigées, mais sont généralement utiles.

Inconvénients

Les désavantages des scripts linéaires sont nombreux. La somme d’effort demandée pour automatiser une procédure de test donnée sera fortement dépendante de sa taille (nombre  d’étapes ou d’actions). Donc, la 1000ème procédure de test à automatiser prendra un temps proportionnellement similaire au temps passé à automatiser la 100ème procédure. En d’autres termes, il n’y a pas beaucoup de possibilités de diminuer le coût de fabrication des nouveaux tests automatisés.

Par ailleurs, s’il y avait un second script qui exécute un test similaire avec différentes valeurs, ce script contiendrait la même séquence d’instructions que le premier script; seule l’information incluse avec les instructions (c’est à dire les arguments d’instruction ou les paramètres) serait différente.  S’il y avait plusieurs tests (et donc les scripts) ils contiendraient tous les mêmes instructions, qui toutes nécessiteraient d’être maintenues lorsque le logiciel a un changement qui affecte les scripts.

Comme les scripts sont dans un langage de programmation, plutôt que dans un langage naturel,  les non-programmeurs peuvent les trouver difficiles à comprendre. Certains outils de test utilisent des langages propriétaires (unique à l’outil) donc cela prend du temps  d’apprendre le langage et  de devenir expérimenté dans celui-ci.

Les scripts enregistrés ne contiennent que des instructions générales dans les commentaires, quand il y en a. Les longs scripts en particulier sont mieux annotés avec des commentaires pour expliquer ce qui se passe à chaque étape du test. Cela rend la maintenance plus facile. Les scripts peuvent vite devenir de taille importante (contenant de nombreuses instructions) quand le test est composé de nombreuses étapes.

Les scripts ne sont pas modulaires et difficiles à maintenir. Les scripts linéaires ne respectent pas les paradigmes communs de ré-utilisabilité et de modularité et sont liés étroitement à l’outil utilisé.

Scripting structuré 

Concept Principal

La différence majeure entre la technique de scripting structuré et celle de scripting linéaire est l’introduction d’une bibliothèque de scripts. Elle contient des scripts réutilisables qui exécutent des séquences d’instructions qui sont habituellement requises par de nombreux tests. Un bon exemple de ces scripts sont ceux qui interfacent avec le SUT.

Avantages

Les bénéfices de cette approche incluent une réduction significative de la maintenance et des coûts réduits d’automatisation de nouveaux tests (car ils peuvent utiliser des scripts qui existent déjà plutôt que d’avoir à les créer de rien).

Les avantages des scripts structurés sont largement atteints par la ré-utilisabilité des scripts. Plus  de tests peuvent être automatisés sans avoir à créer le volume de scripts qu’une approche de scripting linéaire demanderait. Cela a un impact direct sur les coûts de maintenance et de fabrication. Le second test et les suivants ne prendront pas autant d’effort à automatiser car le  script créé pour implémenter le premier test peut être réutilisé à nouveau.

Inconvénients

L’effort initial pour créer des scripts partagés peut être vu comme un désavantage mais cet investissement initial devrait renvoyer des bénéfices si l’approche est menée correctement. Des compétences en programmation sont requises pour créer tous les scripts puisque simplement enregistrer n’est pas suffisant. La bibliothèque de scripts doit être bien gérée, c.à.d.. les scripts devraient être documentés et l’analyste Technique de Test devrait trouver les scripts requis facilement (donc une bonne convention de nommage serait pertinente ici).

Tests pilotés par les données 

Concept Principal

La technique de scripting pilotée par les données est basée sur la technique de scripting structure. La plus grande différence est comment les données d’entrée sont prises en charge. Les entrées sont extraites des scripts et places dans un ou plusieurs fichiers séparés (appelés fichiers de données).

Cela signifie que le script principal peut être réutilisé pour implémenter plusieurs tests (plutôt qu’un simple test). Typiquement, le script principal réutilisable est appelé script de contrôle. Le script de contrôle contient la séquence d’instructions nécessaires pour exécuter les tests mais les données d’entrée dans le fichier de données. Un test de contrôle peut être utilisé pour plusieurs tests mais cela est habituellement insuffisant pour automatiser une grande quantité de tests. Donc un nombre de scripts de contrôle sera requis mais ils ne seront qu’une fraction des tests qui seront automatisés.

Avantages

Le coût de l’ajout de nouveaux tests peut être réduit de façon significative par cette technique de scripting. Cette technique est utilisée pour automatiser plusieurs variations de tests importants, apportant une plus grande profondeur de test plutôt qu’une plus grande couverture.

Avoir des tests ‘décrits’ par les fichiers de données signifie que l’Analyste de  Test peut spécifier des tests automatisés simplement par un ou plusieurs fichiers de données. Cela donne à l’Analyste de Test plus de liberté pour spécifier les tests automatisés sans être très dépendant de l’Analyste Technique de Test (qui peut être une ressource rare).

Inconvénients

Un désavantage est la gestion des fichiers de données qui doivent être lus correctement par la TAS, mais cela peut se gérer de manière appropriée.

Des cas de test négatifs importants peuvent être oubliés également. Les tests négatifs sont une combinaison de procédures de test et de données de test. Dans une approche ciblant principalement les données de test, des «procédures de test négatives» peuvent être manquées.

Test piloté par les mots-clés 

Concept Principal

La technique de scripting piloté par les mots-clés est basée sur  la technique de scripting pilotée  par les données. Il y a deux différences principales: (1) Les fichiers de données sont appelés fichiers de ‘définition de test’ ou un nom similaire (p.ex., Fichier des mots d’Action); et (2) il n’y a qu’un seul script de contrôle.

Un fichier de définition de test contient la description des tests d’une façon qui permet à l’Analyste de Test de comprendre facilement (plus facilement qu’un fichier de données équivalent). Il contient habituellement les données comme le ferait un fichier de données, mais le fichier de mots-clés contient également les instructions de haut niveau (les mots-clés, ou ‘mots d’action’).

Les mots-clés devraient être choisis de façon à être pleinement compréhensibles par l’analyste de test, les tests étant décrits et l’application étant testée. Ils sont le plus souvent (mais pas exclusivement) utilisés pour représenter des interactions métier de haut niveau avec le système (par exemple, passer une commande). Chaque mot-clé représente un nombre d’interactions détaillées avec le SUT. Les séquences de mots-clés (incluant les données) sont utilisées pour spécifier les cas de test. Des mots-clés spéciaux peuvent être utilisés pour des étapes de vérification, ou les mots-clés peuvent contenir à la fois les mots-clés et les étapes de vérification.

La responsabilité de l’analyste de test comprend la création et la maintenance des fichiers de mots- clés. Cela signifie qu’une fois les scripts implémentés, les analyses de tests peuvent ajouter des tests ‘automatisés’ simplement en les spécifiant dans un fichier de mots-clés (comme dans un script piloté par les données).

Avantages

Une fois que les scripts de contrôle et que les scripts pour les mots-clés ont été écrits, le coût de l’ajout de nouveaux tests automatisés sera beaucoup réduit par cette technique de scripting.

Avoir les tests ‘décrits’ par les fichiers de mots-clés signifie que les analystes de test peuvent spécifier des tests ‘automatisés’ simplement en décrivant les tests par les mots-clés et les données associées. Cela donne aux analystes de tests plus de libertés pour spécifier des tests automatisés sans être très dépendants de l’analyste technique de test (qui peut être une ressource rare). Le bénéfice de l’approche pilotée par les mots-clés par rapport à l’approche pilotée par les données  est ici l’utilisation des mots-clés. Chaque mot-clé devrait représenter une séquence d’actions détaillées qui produisent des résultats compréhensibles. Par exemple, ‘créer un compte’, ‘passer une commande’, ‘vérifier le statut de la commande’, sont toutes des actions possibles pour une application d’achat en ligne qui chacune implique un nombre d’étapes détaillées. Quand un  analyste de test décrit un test système à un autre analyste de test, il y a de grandes chances qu’il parle avec les termes d’actions de haut niveau et non avec les étapes détaillées. Le but de l’approche pilotée par les mots-clés est alors d’implémenter ces actions de haut niveau et de permettre aux tests d’être définis en terme d’actions de haut niveau sans référence aux étapes détaillées.

Ces cas de test sont plus faciles à maintenir, à lire et à écrire car la complexité peut être cachée dans le mot-clé (ou dans les bibliothèques, dans le cas d’une approche de scripting structurée).  Les mots-clés peuvent offrir une abstraction de la complexité des interfaces du SUT.

Inconvénients

Implémenter les mots-clés reste une tâche importante d’automatisation par les ingénieurs de test, particulièrement si l’outil utilisé n’offre pas de support pour cette technique de scripting. Pour les petits systèmes cela peut entraîner des frais importants d’implémentation et le coût sera supérieur au bénéfice.

Il faut faire attention de s’assurer que les mots-clés corrects sont implémentés. De bons mots-clés seront souvent utilisés dans différents tests alors que des mots-clés pauvres ont de grandes chances d’être peu utilisés.

Scripting piloté par les  processus 

Concept principal

L’approche pilotée par les processus est construite sur la politique de script pilotée par les mots- clés à la différence que les scénarios représentant les cas d’utilisation du logiciel en test constituent des scripts paramétrés avec les données ou combinés en définitions de test de haut niveau.

Ces définitions de tests sont plus faciles à traiter, comme la relation logique entre les actions. Par exemple, “vérifier l’état de la commande” après “passer la commande” dans les tests de fonctions ou “vérifier l’état de la commande” sans au préalable “passer la commander” dans les tests de robustesse.

Avantages

L’utilisation de définition de cas de test basée sur un scénario semblable au processus permet aux procédures de test d’être définies comme un workflow. L’objectif de l’approche pilotée par les processus est de mettre en œuvre ces workflow de haut niveau en utilisant des bibliothèques de tests qui contiennent les étapes de test détaillées (voir aussi l’approche pilotée par les mots-clés).

Inconvénients

Les processus d’un SUT peuvent ne pas être faciles à comprendre par un Analyste Technique de Test et donc l’implémentation de ces scripts orientés processus, en particulier si aucun processus Métier logique n’est supporté pas l’outil.

Il faut également s’assurer que les processus corrects, par l’utilisation de mots-clés corrects sont mis en œuvre. De bons processus seront référencés par d’autres ce qui résultera en de nombreuses zones testées alors que des processus de mauvaise qualité n’apporteront pas grand- chose en terme de pertinence, capacité à détecter des erreurs, etc.

Test basé sur les modèles (MBT) 

Concept Principal

Le test basé sur les modèles se réfère à la génération automatique des cas de test (voir aussi le syllabus Model-Based Testing de l’ISTQB®) par opposition à l’exécution automatisée de cas de test en utilisant la capture/rejeu, le scripting linéaire, le scripting structuré, le scripting piloté par les données ou le scripting piloté par les processus.

Le MBT utilise des modèles (semi-) formels avec abstraction de la technologie de scripting de la TAA. Différentes méthodes de génération de test peuvent être utilisées pour dériver les tests quel que soit le Framework de scripting discuté précédemment.

Avantages

Le MBT permet grâce à son abstraction de se concentrer sur l’essence du test (en termes de logique métier, données, scénarios, configurations, etc.). Il permet également la génération de tests pour différents systèmes et technologies cibles, de telle façon que les modèles utilisés pour la génération de test constituent un testware sécurisé qui pourra être réutilisé et maintenu lorsque la technologie évoluera.

En cas de changements dans les exigences, le modèle de test doit être seulement adapté; un ensemble complet de cas de test est généré automatiquement. Ces techniques de conception de test sont intégrés dans les générateurs de cas de test.

Inconvénients

Une expertise en modélisation est requise pour réaliser une approche MBT efficacement. La tâche de modélisation par abstraction des interfaces, des données et/ou du comportement du SUT peut être difficile. De plus, les outils de modélisation et de MBT ne sont pas pour le moment très présents, mais gagnent en maturité. L’approche MBT demande un ajustement des processus de test. Par exemple, le rôle du concepteur de test doit être établi. De plus, les modèles utilisés pour  la génération des tests sont des éléments majeurs de l’assurance qualité d’un SUT et leur qualité  et leur maintenance doivent être vérifiées.

3.3.1  Introduction au développement de la TAS 

Le développement de la TAS est comparable à d’autres projets de développement d’autres logiciels. Il peut suivre les mêmes procédures et processus incluant les revues par les pairs par les développeurs et les testeurs. La synchronisation et la compatibilité avec la TAS sont spécifiques à une TAS. La conception de  la TAA doit le prendre en compte (voir Section 3.2) ainsi que le développement de la TAS.

Cette section utilise le cycle de vie de développement logiciel (SDLC) pour expliquer le processus de développement de la TAS et les aspects processus de compatibilité et de synchronisation au SUT. Ces aspects sont également importants pour tout processus de développement qui a été choisi ou est en place pour le développement du SUT et/ou de la TAS – Ils doivent être adaptés en conséquence.

Le SDLC basique pour une TAS est montré Figure 2.

Figure 2: SDLC basique pour une TAS

L’ensemble des exigences d’une TAS doit être analysé et collecté (voir Figure 2). Les exigences guident    la conception de la TAS comme définie par son architecture (voir Section 3.2). La conception est transformée en logiciel par l’ingénierie logicielle. Merci de noter qu’une TAS peut également utiliser des dispositifs de test matériels, ce qui est hors périmètre de ce syllabus. Comme tout autre logiciel,  la TAS  doit être testée. C’est typiquement fait par des tests de capacité basiques de la TAS, suivis par des interactions entre la TAS et le SUT. Après déploiement et utilisation de la TAS, des évolutions sont souvent nécessaires pour ajouter plus de capacités de test, changer les tests ou pour mettre à jour la TAS suite à des évolutions du SUT. L’évolution de la TAS requiert une nouvelle phase de développement en accord avec le SDLC.

Merci de noter que le SDLC ne montre pas la sauvegarde, l’archivage et la suppression de la TAS. Comme pour le développement de la TAS, ces procédures devraient suivre les méthodes établies.

3.3.2 Compatibilité entre la TAS et le SUT

Compatibilité des processus

Le test d’un SUT doit être synchronisé avec son développement – et, dans le cas de l’automatisation des tests, synchronisé avec le développement de la TAS. Par conséquent, il est avantageux de coordonner les processus de développement du SUT, de la TAS et du test. Un gain important est apporté quand le développement du SUT et de la TAS sont compatibles en termes de structure de processus, de gestion de processus et de support d’outil.

Compatibilité des équipes 

La compatibilité des équipes est un autre aspect de la compatibilité entre le développement de la TAS et   du SUT. Si la façon de manager et l’approche de la TAS et du SUT sont semblables les deux équipes obtiendront des bénéfices en faisant la revue des exigences de chacun, en concevant et/ou développant  les artefacts, en discutant des problèmes, et en trouvant des solutions compatibles. La compatibilité des équipes aide également à la communication et aux interactions entre elles.

Compatibilité Technologique

En outre, la compatibilité technologique entre la TAS et le SUT doit être prise en compte. Il est bénéfique  de concevoir et de mettre en place une interaction transparente entre la TAS et le SUT dès le départ. Même si cela n’est pas possible (par ex., parce que les solutions techniques ne sont pas disponibles soit pour la TAS soit pour le SUT), interagir de façon transparente par le biais d’adaptateurs, de surcouche ou d’autres formes d’intermédiaires doit être possible.

Compatibilité des outils

La compatibilité des outils pour la gestion, le développement et l’assurance Qualité de la TAS et du SUT doit être prise en compte. Par exemple, si le même outil pour la gestion des exigences et/ou la gestion des problèmes est utilisé, l’échange d’informations et la coordination du développement de la TAS et du SUT sera simplifiée.

3.3.3  Synchronisation entre TAS et SUT

Synchronisation des exigences

Après l’élucidation des exigences, les exigences du SUT et de la TAS doivent être développées. Les exigences de la TAS peuvent être groupées en deux groupes principaux d’exigences: (1) Exigences qui traitent du développement de la TAS comme un système logiciel, comme les exigences fonctionnelles de conception de test, de spécification de test, d’analyse de résultats des tests, etc. et (2) les exigences de  test du SUT par la TAS. Ces exigences de test correspondent aux exigences du SUT et reflètent toutes les caractéristiques et les propriétés du SUT qui doivent être testées par la TAS. Chaque fois que les exigences du SUT ou de la TAS sont mises à jour, il est important de vérifier la cohérence entre les deux pour vérifier que toutes les exigences du SUT qui doivent être testées par la TAS ont des exigences de test.

Synchronisation des phases de développement

De façon à avoir la TAS prête quand nécessaire pour tester le SUT, les phases de développement doivent être coordonnées. L’efficacité est meilleure quand les exigences, la conception, la spécification, et les implémentations de la TAS et du SUT sont synchronisées.

Synchronisation de la gestion des défauts

Les défauts peuvent être dus au SUT, à la TAS ou aux exigences/à la conception/aux spécifications. À cause des relations entre les deux projets, si un défaut est corrigé dans l’un, l’action corrective peut impacter l’autre. La gestion des défauts et les re-tests (confirmation) doivent traiter à la fois le SUT et la TAS.

Synchronisation des évolutions du SUT et de la TAS

Le SUT et la TAS peuvent évoluer en même temps pour adapter les nouvelles fonctionnalités ou en supprimer, pour corriger des défauts, ou pour traiter des changements dans leurs environnements (incluant les changements respectifs de la TAS et du SUT car l’un est un composant de l’environnement de l’autre). Tout changement appliqué à un SUT ou une TAS peut impacter l’autre donc la gestion de ces changements devrait concerner à la fois le SUT et la TAS.

Deux approches de synchronisation des processus de développement du SUT et de la TAS sont représentées dans la Figure 3 et la Figure 4.

La Figure 3 montre une approche dans laquelle les deux cycles de vie du SUT et de la TAS sont principalement synchronisés en deux phases: (1) L’analyse de la TAS est basée sur la conception du SUT, qui est lui-même basé sur l’analyse du SUT et (2) le test du SUT qui utilise les TAS déployées.

Figure 3: Exemple de synchronisation 1 du processus de développement de la TAS et du SUT

La figure 4 montre une approche hybride avec des tests à la fois manuels et automatisés. Chaque fois que des tests manuels sont faits avant que les tests soient automatisés ou chaque fois que des tests manuels  et automatisés sont utilisés ensemble, l’analyse de la TAS doit être basée à la fois sur la conception du  SUT et sur les tests manuels. De cette façon, la TAS est synchronisée avec les deux. Le second point majeur de synchronisation pour une telle approche est le même que précédemment: le test du SUT nécessite des tests déployés, ce qui dans le cas de tests manuels, peut juste correspondre aux procédures de test à suivre.

Figure 4: Exemple 2 de synchronisation des processus de développement de la TAS et du SUT

3.3.4  Mettre en œuvre la réutilisation dans la TAS

La réutilisation de la TAS se réfère à la réutilisation des artefacts de la TAS. (Pour tous ses niveaux d’architecture) pour les lignes de produit, les Framework de produits, domaines de produit et/ou familles    de projets. Les exigences de réutilisation résultent de la pertinence des artefacts de la TAS pour les autres variantes de produits, produits et/ou projets. Les artefacts de la TAS réutilisables peuvent inclurent:

• (Parties de) modèles d’objectifs de test, scénarios de test, composants de test ou données de test
• (Parties de) cas de test, données de test, procédures de test ou bibliothèques de tests elles- mêmes
• Le moteur de test et/ou le cadre de reporting de test
• Les adaptateurs aux composants du SUT et/ou ses interfaces

Alors que des aspects liés à la réutilisation sont déjà établis quand la TAA est définie, la TAS peut aider à accroître la capacité de réutilisation en:

• Suivant la TAA ou en la revoyant et en la mettant à jour quand nécessaire
• Documentant les artefacts de la TAS pour qu’ils soient facilement compréhensibles et puissent être incorporés dans de nouveaux contextes
• S’assurant de l’exactitude de tout composant de la TAS pour que leur utilisation dans de nouveaux contextes soit de grande qualité

Il est important de noter que bien que le concept de réutilisation concerne principalement la TAA, la maintenance et les améliorations de cette ré-utilisabilité se font sur tout le cycle de vie de la TAS. Cela demande un intérêt et un effort continus pour que la réutilisation se fasse, pour mesurer et démontrer la valeur ajoutée de la réutilisation, et pour évangéliser les autres à réutiliser les TAS existantes.

3.3.5  Support à une variété de systèmes cibles

Le support d’une TAS à différents systèmes cibles réfère à la capacité de la TAS à tester différentes configurations de logiciels. Ces différentes configurations concernent les éléments suivants:

• Nombre et interconnexion des composants du SUT
• Environnements (à la fois logiciels et matériels) sur lesquels les composants du SUT tournent
• Les technologies, langages de programmation et systèmes d’exploitation utilisés pour implémenter les composants du SUT
• Les bibliothèques et les packages que les composants du SUT utilisent
• Les outils utilisés pour mettre en œuvre les composants du SUT

Alors que les 4 premiers aspects impactent la TAS à tous niveaux de test, le dernier est  le plus pertinent  au niveau des tests de composant et d’intégration.

La capacité de la TAS à tester différentes configurations de produits logiciels est déterminée quand la TAA est définie . Cependant, la TAS doit être capable de prendre en charge les différentes variations et capable de gérer les fonctionnalités et les composants nécessaires à ces différentes configurations.

La prise en charge des différentes TAS en relation avec les différents produits logiciels peut être faite avec:

• La gestion de version/configuration de la TAS et du SUT peut être utilisée pour fournir les versions respectives de TAS et de SUT qui se correspondent
• Le paramétrage de la TAS peut être utilisé pour adapter une TAS à une configuration de SUT

Il est important de noter que si la conception de la variabilité  de la TAS concerne la TAA, sa maintenance  et ses améliorations se font sur tout le cycle de vie de la TAS . Cela requiert un intérêt et des efforts continus pour revoir, ajouter et même supprimer des options et des formes de variabilité.