Say Uncle … how to script with an automated testing tools and also if you could give me some good practices pleaaaaaase?

5 02 2009

Hum … and you do not want to 100 dollars and a chocolate? In short, I feel you are impatient  when listening so…

I will try to explain how to automate the functional test. I will talk about QuickTest Pro (QTP) and other selenium. Robots used for functional testing, test scenarios and test users.

There are two ways to script in QTP, it is good … and good!
Let me explain, as you might think that I do make a quick and sterile wink sketch of the “inconnu” (to our English friends: group of French comic of 90 years).

But before reviewing the ways of scripting ask what we can serve these famous robots that could be the miracle solution to testing (or not …).

Automata theory tests:
On a website (for example) QTP records your actions (recording of mouse movement, mouse clicks, etc.). And plays and replay at will. You can execute an infinite number of scenarios to test all the evening and the morning after your coffee in peace consult performance reports.
This definition is an urban myth spread by the publishers a few years ago when the automated tests were not known to clients. Since then and until now, unfortunately, it is always the thought that most customers…

Other important principles of automated tests:

  • Automatic test function by recognition of GUI objects (buttons, dropdowns, etc.). It stores in a directory called sometimes « repository »
  • During registration, they capture the interactions carried out on items needed during the course of the test. It generates a VB script (for QTP)
  • During implementation, they replay the test from the script

Automatic testing in real life:
The only true part in the theory definition is « QTP records your actions and will play it!
The rest is only possible with very little customer with a significant level of maturity in the automation of tests. In short, there are two ways to script:

The scripting for recording and reworking:
– The tester has the GUI and script directly
– It runs the script identifies and corrects errors
– Once the script is complete it must be validated by a tester and make a cross-checking (very important to finalize the scripts)

Scripting mode programming descriptive and reworking:
– The tester has no GUI and must work from technical and functional specifications. But this is very rare among customers. Furthermore this means that the specifications are complete, validated and stable… (it is good to laugh sometimes)
– It runs the script identifies and corrects errors
– Cross-checking

Important points to consider:
Principle: We automate the testing for application on a MATURE and STABLE application! Otherwise, the loss of time and masturbate to Mammoth (sorry but this is the central idea)!

– Principle: 100% of manual tests are not automatable:

  • You should know prioritize, make smart choices, use of the law of Paretto (80 / 20)
  • Explore the benefits of automation, etc.

– Principle: a feasibility study to determine the value of automated tests and technical feasibility (see another article in this subject)
– Return on investment (ROI): the automated test campaigns are profitable from only three or four iterations of automatic test campaign (from a curve ROI over three years)
– Creating scripts:

  • the burden of creating scripts is more important than the creation of manual tests
  • The difficulty is not in the capture of the script but in the choice of criteria and means of control of outcome
  • there must be synchronization points or between two actions to avoid times out on the occurrence of outcome
  • Good practice for a single scenario (better robustness of the scenario = recover under the same conditions as when you save the script):

– Preparation and application environments
– Generation of tests data
– Testing the application
– Cleaning and application environments
– Test data:

  • think about generating tests data by the automate before the execution scenarios

– Execution of scripts: load auto run is less important than manual execution
– Maintenance script: good methodology and good practices are to be applied before the start of automation to minimize the burden of maintenance scripts (standards for the organization, naming, version management scripts, etc.).
– Maintenance of scripts: it is necessary to maintain competence of automation to make the adaptations and changes in scripts if developments in the application

I finish by asking you to ALWAYS coupler and where possible automate your repository (tests management tool) with your test! This will:
– Store the description of scenarios to automate
– Store the QTP scripts in QC and associated repository
– Planning for the implementation of automated test campaigns
– Store the results of test campaigns

Publicités




Critères de choix d’un outil de référentiel de tests

23 01 2009

Cet article doit pouvoir vous aider pour choisir un outil de référentiel de tests dans la sérénité. Pourquoi ? Car chez certain client les choses ne sont pas aussi facile que l’on peux le croire. Exemple : un client possède déjà un outil de chez HP (QC) et en même temps utilise Entreprise Architect (EA) pour gérer ses exigences. La question est « Est-ce que l’on utilise quality center ou EA ? ». A partir de cette question il y a eu des remous sur le choix à faire. Et la politique inter-services et le frein de certains utilisateurs n’aidant pas le stand-by fut prononcé… Jusqu’à que la liste ci-dessous soit apportée.

Elle n’existe que pour apporter des informations FACTUELLES sur les fonctions principales devant être remplies par un outil de référentiel de tests. Comme vous pourrez peut-être le constater elle n’est pas orienté pour que Quality Center soit choisi (je tiens à dire que ce n’est pas de l’ironie).

Un référentiel de tests doit pouvoir gérer (uniquement les fonctions de bases) :

Fonctions de niveau 1
Gérer les exigences de tests :

  • Aide à la création
  • Multi-utilisateurs : Partage aisé entre tous les acteurs du projet
  • Modification aisé
  • Lien facile entre exigences > Fiches de tests > Anomalies
  • Génération d’une matrice de couverture exigences ==> campagne / scénarios
  • Analyse du taux de couverture
  • Impression facile des listes
  • Gestion des versions des exigences

Gérer les fiches et cas de tests :

  • Aide à la création
  • Modification aisé
  • Possibilité de joindre des documents
  • Multi-utilisateurs
  • Gestion des versions

Gérer les cahiers / dossiers / plan de tests :

  • Aide à la création des scénarios
  • Multi-utilisateurs
  • Gestion des versions

Aide au pilotage des tests :

  • Etat d’avancement de la conception des tests
  • Etat d’avancement de l’exécution des tests
  • Etat d’avancement global d’une campagne de test
  • Impression de rapport déjà renseigné et formaté
  • Multi-utilisateurs

Fonction de niveau 2 :
Gérer les anomalies :

  • Outils de création de worflow des anomalies
  • Création et renseignement complet d’une fiche d’anomalie
  • Possibilité de pièces jointes, captures écrans, etc.
  • Moteur de recherche intégré
  • Lien facile et direct entre une fiche / cas de tests et une anomalie
  • Notification par mail des anomalies vers les acteurs du projet
  • Multi-utilisateurs
  • Impression de rapport déjà renseigné et formaté avec chiffres et statistiques par modules / fonctions, etc.

Interfaçage et pilotage directs des :

  • Automates de tests fonctionnels
  • Automates de tests techniques (performance)
  • Anomalies (si pas intégré)




Dis tonton… comment on script avec un automate de tests et si tu pouvais aussi me donner quelques bonnes pratiques steuplé ?

1 12 2008

Hum… et tu ne veux pas non plus 100 euros et un Mars ? Bref, je te sens piaffer d’impatience alors écoute donc…

Je vais tenter de vous exposer comment les automates de tests fonctionnent. Je vais parler des QuickTests Pro (QTP) et autre Sélénium. Des automates utilisés pour les tests fonctionnels, les scénarios de tests utilisateurs, etc.

Il y a deux façons de scripter dans QTP, il y a la bonne et… la bonne !

Je m’explique car vous pourriez penser que je ne veuille faire qu’un rapide et stérile clin d’œil au sketch des Inconnus (à l’attention de nos amis anglophone : Inconnus = groupe de comique français des années 90).

Mais avant de passer en revue les façons de scripter demandons nous à quoi peuvent servir ces fameux automates qui pourraient être la solution miracle aux tests (ou pas…).

Théorie des automates de tests :

Sur un site Web (par exemple) QTP enregistre vos actions (enregistrement du mouvement de la souris, des clics de souris, etc.) et les rejoue à volonté. Vous pourrez ainsi exécuter à l’infini les scénarios de tests tout les soirs et, au matin, après votre café, compulser dans la tranquillité les rapports d’exécution.

Cette définition est un mythe urbain répandu par les éditeurs il y a quelques années lorsque les automates de tests étaient peu connus des clients. Depuis et jusqu’à ce jour, hélas, c’est toujours ce que pensent la plupart des clients…

Autres grands principes des automates de tests :

  • Les automates de tests fonctionnent par reconnaissance des objets des IHM (boutons, listes déroulantes, etc.) qu’il stocke dans un répertoire nommé parfois « repository »
  • En mode enregistrement, ils capturent les interactions réalisées sur des objets nécessaires lors du déroulement du scénario de test. Il génère un script en VB (pour QTP)
  • En mode exécution, ils rejouent le scénario de test à partir du script


Les automates de tests dans la vraie vie :

La seule partie vraie dans la définition théorique est « QTP enregistre vos actions et les rejoue à volonté » !

Le reste n’est possible que chez très peu de client ayant un niveau de maturité important dans l’automatisation des tests. Bref, il y a deux manières de scripter :

Le scripting par enregistrement et reworking :
– Le testeur dispose des IHM et scripte directement
– Il lance le script, relève les erreurs et les corrige
– Une fois son script terminée il doit le faire valider par un autre testeur et ainsi procéder à un cross-checking (notion très importante pour finaliser les scripts)

Le scripting en mode « programmation descriptive » et reworking :
– Le testeur ne dispose pas des IHM et doit donc travailler à partir de spécifications techniques et fonctionnelles. Mais cela est très rare chez les clients. De plus cela impliquerai que les spécifications sont déjà exhaustives, validées et stables… (il est bon de rire parfois ;- )
– Il lance le script, relève les erreurs et les corrige
– Cross-checking

Points importants à prendre en compte :
Principe : On automatise que sur une application STABLE et MATURE ! Sinon, c’est de la perte de temps et de l’onanisme pour Mammouth !
– Principe : 100% des tests manuels ne pas automatisable :

  • Il faut savoir prioriser, faire des choix intelligents, utilisation de la loi de Paretto
  • Étudier l’intérêt d’automatiser, etc.

– Principe : mener une étude de faisabilité pour déterminer l’intérêt d’automatiser les tests et la faisabilité technique (voir article sur le sujet)
– Retour sur investissement : des campagnes de tests automatisées ne sont rentables qu’à partir de trois, voir quatre itérations de campagne de tests automatiques (à partir d’une courbe de ROI sur trois ans)
– Création des scripts :

  • la charge de création des scripts est plus importante que la création des tests manuels
  • la difficulté n’est pas dans la capture du script mais dans le choix du critère et du moyen de contrôle du résultat attendu
  • il faut mettre des points de synchronisation ou d’attente entre deux actions pour éviter les times out sur l’apparition de résultat attendu
  • bonne pratique pour un scénario isolé (meilleure robustesse du scénario = se remettre dans les mêmes conditions que lors de l’enregistrement du script) :

– Préparation des environnements et application
– Génération des JDDT
– Tests de l’application
– Nettoyage des environnements et application

– Jeux De Données de Tests (JDDT) :

  • penser à générer les JDDT par l’automate avant l’exécution des scénarios

– Exécution des scripts : la charge d’exécution automatique est moins importante qu’une exécution manuelle
– Maintenance des scripts: la bonne méthodologie et les bonnes pratiques sont à appliquer avant le début de l’automatisation afin de minimiser les charges de maintenance des scripts (normes pour l’organisation, le nommage, la gestion des versions des scripts, etc.).
– Maintenance des scripts: il faut maintenir une compétence d’automatisation pour réaliser les adaptations, évolution des scripts en cas d’évolution de l’application

Je finirai en vous demandant de coupler TOUJOURS et autant que possible votre automate avec votre référentiel de tests ! Ce qui permettra, entre autre, de :
– Stocker la description des scénarios à automatiser
– Stocker les scripts QTP dans QC et les repository associés
– Planifier l’exécution des campagnes de tests automatiques
– Stocker les résultats des campagnes de tests





Dis tonton… comment faire une étude de faisabilité avant d’automatiser mes tests ?

1 12 2008

Principe : mener une étude de faisabilité pour déterminer l’intérêt d’automatiser les tests et la faisabilité technique. Ci-dessous le sommaire type d’une étude, avec quelques indications pour vous aider à remplir ce document.

1- En tout premier lieu il faut valider les aspects techniques de l’automatisation : vérifier que l’automate peut se prêter d’un point de vue technique à l’automatisation de l’application (sur un échantillon de scénarios du lot à automatiser)

  • Utiliser les documents de pré-requis des automates

    2- Prononcer le GO / NOGO

    3- Procéder au Prototypage :

    – Identifier des scénarios représentatifs en utilisant des scénarios existant manuels :

    • Scénario de complexité « Simple
    • Scénario de complexité « Moyenne »
    • Scénario de complexité « Complexe »

    – Mise en place des scénarios dans Quality_Center_TESTLINK_Salome et QuickTests Pro_SELENIUM :

    • Automatisation des scénarios (exemple de critères de sélections des scénarios) :
    • Périmètre : automatiser sur des fonctions stables (test de non-régression et pas de tests automatique sur les évolutions)
    • Fréquence : automatiser les tests sur des fonctions à tester régulièrement
    • Criticité : automatiser les fonctions critiques
    • Estimer la durée de l’automatisation pour chaque scénario
    • Estimer l’exécution manuelle des scénarios (pour comparer les charges)
    • Estimer le coût de maintenance des scénarios en cas de montée de version

    – Dresser les prémices du ROI :

    – Identifier les « Best Practices » à implémenter

    • Librairie de fonctions de l’application, fonctions VB réutilisables, gestion des objets, etc.
    • Se reporter à l’article sur comment automatiser et les bonnes pratiques

    – Identifier le mode de gestion des jeux de données

    – Faire des préconisations sur la gestion des versions de scripts.

    Ci-dessous un petit exemple d’un rapport de faisabilité.

    Sommaire du document :

    • Objectifs de l’étude

    Client_xxx et votre_société on convenu de mener une étude de faisabilité afin de déterminer si une automatisation des campagnes de tests est possible.

    Ce qui pourrait permettre d’obtenir des gains de temps conséquent. Ainsi qu’une réutilisabilité par des tiers autre que les équipes votre_société.

    L’objectif de cette étude est donc de savoir :

    Quels sont les différents modules / parties automatisables ?

    Avec quels moyens (logiciels, outils) automatiser ces tests ?

    Les gains obtenus sont-ils significatifs ?

    • Comment avons-nous procédé ?

    Un premier choix a tout d’abord porté sur l’automate (QuickTests Pro_SELENIUM) au vue des contraintes et besoins de Client_xxx.

    Ensuite, à partir des scénarios présents dans (Quality_Center_TESTLINK_Salome) nous avons sélectionné quelques tests semblant significatifs.

    Puis nous les avons « Enregistré et scripté » à l’aide de l’automate.

    Pour illustrer le plus clairement possible les explications : la vidéo ci après montre un exemple concret d’automatisation de test pour l’application AAA, avec l’automate yyyy (nom de la fonctionnalité).

    L’automate teste automatiquement :

      1. Pas 1
      2. Pas n

    Joindre la vidéo de l’action de l’automate (outils existant sur Internet et gratuit).

    Il est important de prendre un exemple concret sinon l’impact auprès du client en sera amoindri et moins percutant.

    • Résultats de l’étude

    L’étude de faisabilité a montrée que :

    La plupart des applications sont compatibles avec l’outil d’automatisation xxx. Cette compatibilité a été vérifiée grâce au document « ddd », fourni en annexe.

    Une grande partie des scénarios sont automatisables par Selenium :

    · Le module « mmm1 », qui consiste à vérifier le bon fonctionnement de xxx

    · Le module « mmm2 »

    Les parties non automatisables concernent les échanges de flux entre les différents modules :

    · Batchs

    · Echange (problème de détection des objets par xxx), etc.





    Best practices and test repository

    22 10 2008

    Say Uncle, you can give me some best practices pleaaaaaaaaaaase?
    The first good practices are:
    – Good sense
    – Organization,
    – Reflections.

    Nothing but magic, properly implemented, will guarantee the proper use of a benchmark test. I will expose them as a question to ask the good moments:
    Management requirements or requirements:
    – Uniqueness?
    o This is the only item on this test?

    – Clarity?
    o Reflect on the tree to establish,
    o The need is expressed clearly enough and is there no gray area or ambiguities on the understanding?
    o What are the requirements implicit and not listed in the expression of needs (for example), but we must still consider?
    – Accuracy?
    o The requirement is it enough to be measurable and quantifiable targets via specific test?
    – Validity?
    o The document led to the requirement is updated and validated by the customer?
    – Testability?
    o Is it possible to create one or more relevant cases to effectively test all aspects of this requirement?

    Managing the card catalog test or the Test Plan:
    Fundamental:
    – Each sheet test should be linked to one or more requirements or you can say goodbye to the test coverage
    – Once the test sheet drafted a trick is to check if all the cards are connected at least once a requirement, otherwise you have holes in your racket!
    – Depending on the strategy, the Test Plan should be prioritized according to the functional, organizational or business customer
    – The tree test plan must:
    o Be easy to understand by functional
    o In order of business process / application client (use numerical codes to manage the directory eg
    o be determined at the outset between all actors
    o 4 to 5 levels MAXIMUM directories otherwise you watch the madness
    – Provide care tabs « Details » and « Design steps:
    o Enter a clear description of the common people for the purpose of the test card
    – Provide care to the tab Design steps:
    o Be sufficiently precise and detailed to avoid any ambiguity and interpretation at runtime
    o Display data to be used and their origins
    o = A STEP ONE ACTION
    o Inform the expected outcome (RA) so precise and clear because the result will be compared to the result (RO) during execution

    Good questions:
    – Uniqueness?
    o A target = sheet test
    – Clarity?
    o The stages of the procedure are clearly identified, no-til no gray area or ambiguities on the way forward?
    – Data?
    o All representative data needed for testing are they identified?
    o Have data that are:
    consistent
    Clarifies
    Representative
    Prepared
    – Coverage?
    o The modus operandi of the sheet test is relevant and complete the objective identified?
    – Generic?
    o No test sheet valued unless a value is hard in the test

    Design and execution of test campaigns or Test Lab
    – Cash?
    o Environment to conduct any tests available?
    o The application to test it is installed with the correct version (versioning policy of the client)?
    o The access (login / passwords) to applications and other servers valid?
    – Preparation?
    o The test cards are up to date or she date a year ago?
    o Automated test scripts are identified and in the right directories?
    – Clarity?
    o The names of campaigns and test sheets are quite explicit for your next tier include?
    – Data?
    o At’on all the data needed to run the cards?
    – Coverage?
    o The entire campaign covers happens objective identified?

    Good practices during the execution of the test sheets:
    – Have environments, platforms and networks available
    – Availability of the coffee machine effective
    – During the execution of steps:
    o Follow the procedure in the « description » on LETTER!
    o The tests outside the marked paths are BANNED!
    o Compare the result (RO) with the field Expected Result (or expected outcome (RA)).
    o

    Management of anomalies or Defects:
    Fundamental:
    – Have a workflow defined anomalies that is known, validated, shared and clear. This is for all players
    – If yes, do all the players are aware of their roles and responsibilities?
    – If the execution proceeds failure:
    o Verify that the specified outcome is correct
    o Enter the result as clearly as possible
    o Check that the anomaly is reproducible integrator or ridicule you and not take into account the anomaly
    o Open an anomaly
    o Describe the anomaly as clear as possible otherwise your work will not help and you will lose a lot of time in explanation
    o ALWAYS associated with a sheet test

    – Reproducibility?
    o The anomaly is it reproducible under the same conditions?
    – Compliance?
    o The abnormality has been detected by following the procedure laid down in the sheet test?
    o expected results included in the file are updated?
    – Uniqueness?
    o The anomaly detected is not already open?
    To do this, ask your colleagues and your manager is a good start
    Use filters and search fields
    o Is not there already opened a ticket on a subject almost identical?
    Clarity?
    – Gravity?
    o What is the level of severity of the anomaly?
    Critical
    Major
    Minor

    A final practice for the road? Make a copy and paste the above practices in an Excel file, the file named « Checklist guaranteeing the quality of the test repository ». You do not have:
    – Go to request and ask a bonus to your manager ;-)
    – And submit your client to be finally a real example of industrialization of testing tools

    And for the record, know that putting into practice every day these recommendations will make the implementation of this tool CMMI level 3 (see article on CMMI3 and QC).





    Survival Manual on Quality Center for testers!

    22 10 2008

    In the world of test, everybody talks about Quality Center (QC for his nickname) from HP Mercury. Everyone talks about the client to the service, from engineers who swear by this fabulous QC … What wonderful world that ours in which all players share the same project, share and use same benchmark test and ensure that business requirements are at the heart of everyone … But … The reality is less glamorous!
    Indeed, among the thousands of engineers only a few really know QC and use it properly.

    So I write this article in aim to present the basic tool and make some good practices to implement when using a testing repository (I will not write on the administration part of this tool).

    Say Uncle, what is a testing repository ?
    Or « How from minimum to maximum effort? « . For the answer see the article on the subject.

    Say Uncle, there is what in QC?
    Before explaining what is inside it clear that it is just a tool shared management of activities test, that his name was former Test Director (or TD).
    The interface of QC is relatively « user friendly » (adapted from users) and practice.

    In this tool there are 5 tabs (or parts). Each of these tabs is an important part for each test project. But see more detail each of them:
    – Management of requirements
    – Management of the test catalog or Test Plan
    – Design campaigns to test or Test Lab
    – Management of “anomalies” (French term) or Defects
    – Management releases (not explained in this article because I want to preserve the suspense)

    With tabs for each common features include:
    – Reports & Graphics
    – Review
    – The ability to attach screenshots, documents, etc..
    – Printing
    – Administration

    The logic of use is as follows, first on developing the test strategy and matrix of coverage (tabs requirements and Test Plan). Then we plan executions (Test Plan and Test Lab), when executions are created sheets anomalies through which we validate the corrections.
    Finally, it updates the tests and repeats the cycle of tests.

    Dives us in QC:
    Management requirements:
    It is to identify the test requirements (based on business requirements and other specifications), to structure the test plan and specify future test sheets.
    Small reminder: requirements may be the expression of needs or the list of features to be tested. Thus, all test requirements define the scope to cover. These requirements are also common among the records of specification and testing to be performed.
    Take into account to ensure traceability between the design and execution. Finally, the requirements are support for impact studies of the evolution of specifications on the plans and test sheets.

    This tab can also see all the details of requirements and see the status of the results sheets covering a test or its requirements.

    Finally, it can be entered manually requirements is to use a macro to use on import documents to Word or Excel. Either in the form of addin or internal development or customer service company.

    Managing the test catalog or the Test Plan:
    It is designed to test sheets, define scenarios and prepare the reporting (in collaboration with the Lab Test). It is also to create the tree test sheets and sheets and create links between requirements and test sheets.
    The Test Plan represents all the test sheets, being built or operational.

    Design and execution of campaigns or Test Lab test:
    It is the creation and planning campaigns to test. The performance takes place on this tab, whether automated or manual.
    Remember that:
    – A test campaign is a combination of scenarios (composed of sheets of test)
    – A test may be part of several campaigns
    – Following the implementation of the various shock, a form of test is considered PASSED status, if and only if all stages composing on the same status
    – If at least one of these steps is in FAILED status or not completed sheet will test the same status

    Management of anomalies or Defects:
    After implementation scenarios / sheets test is to describe the anomalies and reporting information campaign.

    Read the article following called « Best practices and test repository »





    …Quels sont ces fameux critères d’arrêts des tests ?

    20 10 2008

    C’est une question souvent abordée lors des formations aux tests, parfois posée par les clients et jamais abordée par les équipes de testeurs lors des projets ! Étrange n’est-ce pas ?

    Les critères d’arrêt des tests ne sont surtout pas à confondre avec la question « A-t-on assez testé ? ».  Car ceci est un autre sujet concernant la couverture des tests et leurs exhaustivité (entre autre).

    Définition des critères d’arrêt des tests pour ISTQB :
    « Critère de sortie : l’ensemble des conditions génériques et spécifiques, convenues avec les responsables, pour permettre de terminer officiellement un processus. L’objectif d’un critère de sortie est d’éviter qu’une tâche ne soit considérée comme achevée alors qu’il y a encore des parties de cette tâche qui n’ont pas été terminées. Les critères de sortie sont utilisés dans le test pour faire des comptes rendus et pour planifier l’arrêt du test. [D’après Gilb et Graham] ».

    Certes cette définition est peu claire, et c’est pourquoi je tente de lister les critères les plus fréquents :

    Critères d’arrêt commun à tous les types de tests :

    • Tous les scénarios (SCN) ont été exécutés (performance, fonctionnels, etc.)
    • Tous les dossiers, fiches et cas de test ont été joués avec succès
    • Toutes les anomalies critiques ont été résolues et les Tests de Non-Régressions (TNR) déroulés
    • Votre client à signer le PV de recette, le bilan présenté et il vous reste à ranger vos affaires
    • Après 252 livraisons l’intégrateur est incapable de corriger et le client décide d’arrêter le projet
    • Les plateformes, environnements, réseaux, etc. ne sont plus disponible
    • Atteinte du taux d’anomalie maximal découverte pendant les campagnes (définition et atteinte d’un seuil préalablement défini). Ce type de critère est souvent mis en œuvre chez les clients ayant un haut niveau de maturité des activités de test ou imposant des contraintes contractuelles très forte. Cela peut être également réparti par domaine fonctionnels. Exemple :
    • Arrêt des tests si détection de plus de 50 anomalies majeures
    • Épuisement des ressources des tests :
    • Fin du budget
    • Départ des ressources humaines
    • Fin de la durée / charge prévue
    • Véritable épuisement physique des ressources
    • Les SCN de recevabilité / testabilité / Pré-requis sont bloqués ou en NOK

    Critères spécifique à certains types de test :
    Techniques :

    • Tous les connecteurs et « jobs » (cela désigne : les jobs, jobstreams et les batchs) planifiés ont été lancés et tournent

    Lecteurs, si tu en connais d’autre je te propose de nous en faire part afin d’en faire dons à la communauté des testeurs et teuses. Merci.