Test ISTQB en ligne, niveau Avancé - Automatisation de test

1. Extensive-Minded Test Engineering (Ingénierie de test approfondie)
2. Equivalent Manual Test Effort (Effort de Test Manuel Équivalent)
3. Etendue des Moyens de Traitement des Erreurs
4. Essai de Modélisation des Tests par les Evénements

2 - De quelle expression 'automatisation des tests' est-elle généralement un raccourci ?

1. Automatisation de la conception des tests
2. Automatisation de l'exécution des tests
3. Automatisation du reporting des tests
4. Automatisation de la stratégie de test

1. Il n'est possible d'automatiser des tests que s'ils peuvent être réalisés manuellement au préalable par l'équipe
2. Tous les tests manuels ne peuvent pas être automatisés
3. Les tests automatisés peuvent réaliser des tests exploratoires
4. L'automatisation des tests n'implique aucun investissement initial

4 - Lequel de cet aspect n'est pas un facteur de réussite de l'automatisation des tests ?

1. La maintenabilité de la TAS
2. La pertinence de la stratégie d'automatisation des tests
3. La testabilité de la TAS
4. La facilité d'utilisation du TAF

5 - La maintenabilité du code de test est importante pour plusieurs raisons. Laquelle n'en fait pas partie ?

1. Il y a parfois autant de code pour les tests que de code au sein du SUT.
2. Le SUT subit des changements au fil du temps.
3. Les données présentes dans le SUT subissent des changements au fil du temps.
4. Les défauts ont tendance à se regrouper dans certaines zones du SUT.

1. Plus les testeurs découvrent de détails concernant l'implémentation du SUT, plus le niveau d'intrusion est élevé.
2. Plus il y a d’adaptations requises sur le SUT, plus le niveau d’intrusion de l'approche d'automatisation des tests est élevé.
3. Le niveau d'intrusion fait référence aux tests de sécurité (notamment les pentests) exécutés sur le SUT.
4. Plus les développeurs s'impliquent dans le projet d'automatisation des tests aux côtés des testeurs, plus le niveau d'intrusion est élevé.

1. Une approche d’automatisation de test complexe et ultra-flexible pour tester un SUT petit et simple.
2. Une approche d’automatisation de test complexe et ultra-flexible pour tester un SUT très vaste et complexe.
3. Une approche d’automatisation de test simple pour tester un SUT petit et simple.
4. Une approche d’automatisation de test simple pour commencer à tester un SUT très vaste et complexe.

1. Un SUT testable doit être observable, contrôlable et avoir une architecture clairement définie.
2. Une TAS qui permet de détecter un grand nombre d'anomalies, mais au prix d'un effort de maintenance extrêmement important, est efficace mais pas efficiente.
3. Une bonne testabilité profite aussi bien à l'automatisation des tests qu'aux tests manuels.
4. La démarche d'automatisation des tests ne peut être entreprise que lorsque le SUT est disponible.

9 - Tommy a développé un composant de TAS qui peut vérifier à lui seul deux formulaires différents ; un formulaire de saisie de produit et un formulaire de saisie de client.
L'une des variables de ce composant s'appelle nomProduitOuNomClient. Elle correspond à un champ 'Nom' présent sur les deux formulaires, et qui répond aux mêmes exigences : le nom du client et le nom du produit sont des données obligatoires qui doivent tenir en moins de 100 caractères alphanumériques.
Les exigences du produit évoluent et le SUT doit désormais empêcher la saisie de caractères numériques dans le champ 'Nom' du formulaire de saisie de client. D'autres règles de gestion voient le jour, qui rendent les deux formulaires de plus en plus différents.
Tommy doit donc revoir le composant qu'il a développé et y ajouter de la complexité, ou bien diviser ce composant ; les deux actions vont lui prendre du temps qu'il ne pourra pas consacrer à l'automatisation de nouveaux tests, ou à des sessions de test exploratoire.
Quel principe aurait permis d'éviter cette situation ?

1. Conception de test, Implémentation de test, Exécution de test et Interfaçage de test
2. Génération de test, Définition de test, Exécution de test et Adaptation de test
3. Evaluation de test, Analyse de test, Exécution de test et Communication de test
4. Découverte de test, Planification de test, Exécution de test et Intégration de test

11 - Laquelle des affirmations suivantes sur la conception des TAS est fausse ?

1. Une bonne gestion de la configuration de la TAS permet de tester plus facilement une version antérieure du SUT après un rollback.
2. L'abstraction augmente la portabilité des artefacts de test.
3. Toute TAS comporte les 4 couches de la gTAA.
4. Plus une TAA utilise l'abstraction, plus elle est flexible, mais plus les investissements initiaux sont élevés.

1. L'estimation basée sur l'expertise est une estimation basée sur l'analogie.
2. Constructive Cost Model (COCOMO) n'est pas un modèle d'estimation mais une somme de bonnes pratiques de développement.
3. L'analyse des points de fonction est une estimation basée sur la taille.
4. Le planning poker fournit une estimation de groupe.

13 - Laquelle de ces affirmations au sujet des approches pour automatiser les cas de test est vraie ?

1. L'approche capture/rejeu est l'approche qui garantit le maximum de maintenabilité pour les automates de test.
2. Les scripts linéaires sont modulaires et réutilisables.
3. La technique de scripting structuré est basée sur la technique de scripting piloté par les données.
4. Avec une approche de scripting structuré, le deuxième test est plus court à automatiser que le premier.

14 - Laquelle de ces affirmations au sujet des approches pour automatiser les cas de test est fausse ?

1. Un des objectifs de l'approche pilotée par les mots-clés est de permettre aux tests d'être définis en terme d'actions de haut niveau sans référence aux étapes détaillées.
2. Le test basé sur les modèles (MBT, Model Based Testing) permet la génération automatique des cas de test.
3. L'approche capture/rejeu fournit un niveau d'abstraction supérieur à celui de l'approche de scripting structuré.
4. Le choix d'une approche dépend des aspects liés au SUT (aspects produit), mais aussi d'autres facteurs (aspects projet).

15 - Les interfaces de test doivent-elles être supprimées avant la release du produit ?

1. Oui, systématiquement, pour éviter tout risque de perte ou d'exposition intempestive de données.
2. Oui, car elles ne peuvent être utiles qu'aux personnes en charge des tests.
3. Oui, car elles complexifieraient inutilement le code de production.
4. Oui, si et seulement si un risque lié à la sécurité est avéré.

1. Le développement de la TAS, de par sa nature (code de test VS code de production) se distingue des autres projets de développement et dispense ainsi de réaliser certaines activités, typiquement les revues par les pairs.
2. La TAA découle de la TAS.
3. Le cycle de vie des tests automatisés gagne à être indépendant du cycle de vie du SUT.
4. La TAS doit se soumettre à deux grands types d'exigences : les exigences qui traitent du développement de la TAS comme un système logiciel (comment la TAS va vérifier), et les exigences de test du SUT par la TAS (ce que la TAS va vérifier).

17 - Une entreprise B2C, Cagoutech, souhaite réaliser un projet pilote afin de mettre en oeuvre un outil de tests automatisés pour la première fois dans son système d'information. Parmi les suivants, quel SUT choisiriez-vous pour mener à bien ce projet pilote ? Admettons que le développement de tous ces SUT démarre ou ait démarré en même temps.

1. CagouCore, le coeur du logiciel de gestion global de l'entreprise, qui doit subir une importante refonte aussi bien dans ses interfaces que dans son fonctionnement en back-office, avec un planning très serré.
2. CagouFriend, le mini-site interne de gamification de l'arrivée des nouvelles recrues, développé en mode hackathon lors du dernier team-building de Cagoutech.
3. CagouTech.nc, le nouveau site vitrine de l'entreprise, qui présente les différents produits de Cagoutech et respecte désormais les mêmes standards que les autres applications web de l'entreprise.
4. CagouLabel, l'utilitaire de gestion des étiquettes produits, un applicatif assez sensible, qui utilise une technologie que désormais seuls les anciens de Cagoutech maîtrisent.

18 - Le projet pilote est un succès ! Il est temps désormais de déployer la TAS au reste de l'organisation. Parmi les choix suivants, quelle est la bonne pratique ?

1. Déployer la TAS à l'ensemble des projets simultanément afin que les problèmes d'initialisation puissent tous être traités en même temps.
2. Laisser les nouveaux utilisateurs de la TAS établir leurs propres lignes directrices et rédiger à leur propre initiative de la documentations, si souhaité.
3. Contrôler et surveiller l'utilisation de la TAS, si possible de manière automatisée.
4. Organiser une rétrospective, qui implique uniquement l'équipe à l'origine de la TAS, à savoir le(s) TAM et le(s) TAE.

19 - Laquelle de ces affirmations au sujet des différents types de maintenance est erronée ?

1. La maintenance perfective consiste à optimiser la TAS et à corriger des problèmes fonctionnels de celle-ci.
2. La maintenance corrective consiste à effectuer des modifications pour corriger les défaillances de la TAS.
3. La maintenance préventive consiste à effectuer des changements pour que la TAS supporte plusieurs types de tests, le test sur des interfaces multiples, le test de plusieurs versions du SUT ou permette des tests automatisés pour un nouveau SUT.
4. La maintenance adaptative consiste à prévoir le support de nouveaux systèmes logiciels lancés sur le marché.

1. La TAS peut avoir comme avantage indirect de permettre la détection de davantage de défauts par les tests manuels.
2. La plupart du temps, il est préférable de documenter la TAS une fois que celle-ci a été entièrement développée.
3. Pour assurer l'indépendance des tests, le contenu du matériel de la formation de la TAS ne doit pas se baser sur la documentation, même si celle-ci est bien écrite.
4. Un des avantages majeurs de l'automatisation des tests est que les TAS ne nécessitent quasiment pas d'effort de maintenance.

Test ISTQB niveau Avancé - Automatisation de test – Ingénierie en ligne