Outils de gestion des exigences

Produits	Société	Détails
Analyst Pro	Goda Software	Outils pour la spécification des exigences.
Doors	Telelogic	Telelogic DOORS ® est une base éprouvée pour déterminer et prioriser les besoins des clients, assurer la conformité aux exigences et le maintien de la conformité réglementaire. Le résultat final: produits, systèmes ou logiciels sont livrés à la satisfaction du client, générer une valeur accrue pour l’entreprise.
Caliber	Borland	L’interface intuitive et de puissantes capacités d’aide à la décision de CaliberRM peux aider les équipes sur les principales étapes du projet. CaliberRM permet également de répondre aux besoins des ‘utilisateurs finaux en permettant à tous les intervenants du projet: équipes marketing, analystes, développeurs, testeurs, et les gestionnaires de collaborer et de communiquer la voix du client dans l’ensemble du cycle de livraison logiciel.
Gatherspace	Gatherspace.com	C’est un outil de gestion des exigences en mode hébergé (en mode ASP).
Requisite Composer		IBM ® Rational Requisite Composer ® est un outil pour aider à définir des exigences en collaboration avec les fonctionnels / métiers
Requisite Pro	IBM	IBM ® Rational Requisite Pro ® est une solution pour gérer  des exigences pour les équipes projet.

Proverbes et petites phrases

Quelques reflexions assez amusantes ou a utiliser dans vos présentations aux clients :

Einstein :

1-Une personne intelligente résout un problème, une personne sage l’évite

2- Les problèmes importants auxquels nous sommes confrontés ne peuvent être résolus par le même niveau de réflexion que celui de la personne qui la créé.

Léonard De Vinci :
Ne pas prévoir c’est déjà se lamenter

Jerry Weinberg :
Quel que soit le problème, c’est toujours un problème de personnes

Blagues :
Combien faut-il de testeurs pour changer une ampoule ?
Un seul suffit pour remonter l’information et attendre dans le noir !

Different kind of tests

Below is a list of types of tests that can be implemented by a team of recipe. I will discuss this article through the famous “white and black boxes”.

1.1-white box
Test type “white box” or test structural visibility of the component under test, test games are produced by analyzing the source code. Tests such as “white boxes” are called so because one must read and enter the code to design and run the tests (or otherwise designated as “put your hands in the dirty”).
Some examples of tests “white box” all roads have been travelled at least once, the true / false have been validated, the loops are implemented correctly. But the limits are set correctly; the internal data structures are valid and if there is no memory leak, etc.
1.1.1-Code review
The code review is a systematic review of the source code of computer software, the goal is to find anomalies to correct errors in design to improve the quality and safety software.
It is therefore to read the code, which involves reviewing thousands of lines in Java or C for example. To do this there are many tools to do almost automatically.
Thus, it inserts into the tool coding standards and management. Then, the tool parse (trades language describing the review of the code, for example), applications to display a report highlighting the deficiencies.

The review code becomes increasingly an integral part in any development process and software including agile methods known as Extreme programming.

Examples of such activities during a code review may be checking rules programming or verification of compliance of the Code in relation to document detailed engineering design.

1.1.2-Unitarian Tests
They independently test the various elements that make up the system or a portion of a program.
They are used to demonstrate that each module (class, loop, etc.). Performs any service provided and only this function. Can be distinguished in these tests of logic tests (search for error, checking the correct sequence of branches covered). As the test calculation (verification of the results of calculations, performance, accuracy algorithms).

The most widely used to perform unit testing is JUnit (Java context).

1.1.3-integration tests – with “vision developer”

They are testing the various elements that make up the system and their interactions between them.
They are used to demonstrate that each module (class, loop, etc.). Performas any service provided and only this function.

Figure: Integration Tests
1.1.4-test charges

To begin you must know that there are still several meanings in “testing charges for customers or consultants. According to the definition change. They are listed in order to provide clarification.
During performance tests (response time, duration of treatment) must verify the performance of the software meet the requirements in different conditions (normal or gradient):
Example: if it is anticipated that a website is accessed simultaneously by 500 users, the pages are displayed in less than 2 seconds.

During load a test is to measure the behaviour of the system and to deal with an operating environment limits by simulating several simultaneous sessions and / or volumetric data to monitor the maintenance performance.

The surcharge on tests intended to understand the functioning and system failures when overloaded (beyond the limits of charge).

Tests with a degraded mode verify the stability of the reaction outside the normal cases of use (duplicates, empty, empty selection, the wrong format…).

My experience returns show that 100% of the load tests are treated as performance benchmarks. These are described below.

As a general test performance and expenses to meet a number of questions like “What are the risks of performance problems in production? “” Is what applications and infrastructure support the expected number of users? “How to measure the load / quality of service rendered in connection with the means and goals? “, Or” the response time of the application for No users are conforming to specifications? “.
Tests charges can be several times the life cycle of projects such as:
at the beginning of the project to analyze the behavior of a solution: software to integrate, prototype, to identify the limits of the solution, the potential charge and the hardware scale depending on the charge assessed in time (capacity planning), ongoing project to test the dynamic behavior of the solution in production on the problems of inter-locking, consumption of resources and memory management, end-of-project to validate the final solution to verify its performance characteristics and identify the real capacity and attitudes to climb up and peak use. These tests also maximize the final architecture by adjusting the parameters systems, finally during maintenance to ensure non-regression performance characteristics of the solution and identify its capacity and in attitudes about changing mounted charge and use pics.

A typical process of load testing involves four to five phases with pre-requisite to verify.
The pre-requisite to check about the campaign load test, which can only be achieved on the basis of an application stable and validated during a phase of functional and technical preliminary.
Prior to conducting performance tests of the application, the following must be carried out and validated: the machine should be available with provision of access (user / password), generic or not, on the application environment and software (NT, Oracle, permits networks, etc.). the application installed and available (technically, operationally and in terms of integration and recipe) with provision of access (user / password) and data set. But we must also have an application in running and stable, in a configuration iso-production of preference and / or close to reality and links with other applications in running and available.

The nature and volume of data base must be identical and / or close to production. Moreover, the application must be accessible from the platform load testing.
The four phases of tests are:

1 – Pre-study and launch:

The first step before any use of a tool (HP Mercury LoadRunner for example) is to achieve a phase of preparation. This phase is divided into several stages which are a meeting of initialization / Shift and delivery of the specification test of the campaign.

2 – Preparation of testing and development scenarios:

This step addresses the items to install in order to establish the test environment.
The development phase the construction of test scripts and scenarios specified in the previous phase. This phase is broken down as follows:

• registration scripts,
• setting scripts,
• validation scripts by the MOE / MOA (sometimes)
• running scripts,
• calibration scripts.

3 – Campaign tests: Implementation – Analysis Report – Synthesis, Correction, Test confirmation:

This phase is an iterative process that allows you to run scenarios and analyze the results. It breaks down as follows: Creation of the test, and Shooting metric collection and analysis of results.

4 – Review:

Finally, the results describe the testing, analysis, improvements in the implementation and status of goals. This report is generated after the execution of all tests.
The test cycle may be iterative several times to take into account changes in the system.

1.1.5-Safety Tests

With the arrival of Web-type applications were developed safeties testing. The aim is to check security systems: data encryption, authentication tests, empowerment, data integrity, accessibility, access competitors…

1.1.6-operability

tests
Usability testing and verification at the Good Operability (Vabe) are tests that monitor the technical architecture requirements. Shown is the illustration in the world of French telecom:
It includes in the diagram below that test usability begin mobile phone from a client to finish at the entrance of the SI provider. Through all layers networks, supervision, etc.
There are also some performance tests that are executed.

1 – Types of test
Figure: Scope of usability tests in a French telecom operator
Figure (figure to come): Activities of type test usability in a French telecom operator.
Some other examples of test part of those usability:

• analysis of holding file,
• establishment of the configuration platform, configuration scheduling JCL,
• monitoring of operating
• the establishment of Job scheduling and data flow
• Oversight (Tivoli Unix, MVS AutoSys)
• scenario chronology
• set up batch case alert
• simulation of operating records, alert, log,
• audit logs,

• tests backup, restore, hot, cold, incremental, weekly, etc..
This type of test addresses many peculiarities and will be the subject of a forthcoming article.

1.2-black box

Tests such as “black box” or functional test does not require visibility of the component. Entries and results are expressed in terms of behavior of the software component of an external point of view, regardless of the internal structure of the component.

The black box tests are related to functional specifications. Regardless of the internal structure of the application (unlike the white box testing), they validate the functionality of the application. As the internal workings of the application is not known, the designer of sets of test should define the expected behavior (Expected Result – RA) and check if the application is consistent with this behavior (outcome – RO).
Tests type black box functional tests are implemented in phase recipe, they are designed to search for or validate compliance with the requirements, functions incorrect or missing. But inconsistencies in the interface, error data access and the initial conditions or final of a function.

1.2.1-Functional Tests

The functional (simply called recipe) is to receive a software and to verify the proper functioning before being put into service as well as its compliance with what was requested in the specifications.
The functional tests verify that the software works properly in the context of business-users during the functional, it does not programming software, but his behaviour and his functional Ergonomic (MMI and navigation) and or that the specifications (and any other media such as user manuals, data modeling…).
The tests lead to simulate the operation of the software through use case. It is necessary to have concrete scope and data to simulate a real context of use (data sets, test environment).
The tests verify aspects of the business (business function) with features non-conforming or missing the operation and management rules.
The functional tests also take into account ergonomics. These behaviours users (limit values, values unauthorized …), the preparation and presentation screens or navigation rules, etc.

1.2.2 Tests of non-regression

After a correction or a change that should be re-tested to ensure that the change has not deteriorated (done backwards) running the software and caused abnormalities on other modules not tested?
Any re-testing would be too costly and not test that changes to the component involves many risks.
We must therefore find a compromise and develop a strategy for non-regression (or TNR). These tests should not be provided regression after any modification of software to ensure that existing functionality was not affected by the changes. It is essential that the existing system continues to operate with the same quality level as the previous version.
Practice test for non regression means that the rest of the application has not lost functionality or reliability due to the addition of new functions or modification of existing functions. They are to determine whether defects were introduced into the application in the implementation of the new feature. They can also be used when changes in the environment of the application.
The non-regression tests are applicable to all phases of testing. Indeed, the prediction errors to determine the scope and extent of tests and monitor the system status changed.
If the non-regression tests with the different stages V, they are particularly suited to the latter stages. Thus, they are usually carried out under testing system recipe or integration.

Figure: Illustration of what the non-regression tests
Any information system is in perpetual evolution. But if each new change is validated it is not necessarily throughout the application in which it operates. This leads to anomalies, sometimes blocking (or butterfly effect). Tests of non-regression (often equipped) can increase the coverage tests; the tests will produce, reduce expenses and tested to optimize the execution time.

Example – ARIANE 501

On 4 June 1996 launch of Ariane 501 and a few seconds after the launch of self destruction is pronounced. Late ARIANE 501 (about € 500 million).

Why?
After analysis it is that bad choices were made when defining the strategy of non-regression tests. Indeed, components of Ariane 4 were tested but not used because “They worked perfectly before!”.
(Source IEEE Computer 01/97)
Example – EOM E_F draft xxx

1.2.3-case studies to illustrate:

Strategic Issues: Market opening in 2007 – to the growing competence of the team – define the methodology and tool dedicated to recipe.
Director: Audit activities recipe EOM (fundamental project, process and means of revenue on VABF)> Recommendations> action plan> Training> Accompaniments project manager and analyst.
Gain score: Training and support its teams – professional activities of revenue – increased control of quality – steering dedicated to the recipe – respect for commitments integrators
Technologies: Portal – Software L_r – Batch – Flow – Business Intelligence (BO)
Exposure of the case: Closer to home, in 2007, during a mission in E_F advice I have implemented the strategy of non-regression tests next.

Figure: lie in the various stages of testing
During the audit phase here is what I advocated a strategy in two phases located at the design stage of testing. It was to train and raise the competence in team activities revenue of the EOM on non regression testing. To do this he had to be put in place a strategy in 2 times (ownership gradually facility): a non-regression manual and automated non-regression.
No manual regression:
It took gather plans tests of other players as the group (inclusive type TMA) and the MOA. Then write those of the EOM collecting information:

• Tests of non-regression of the grouping,
• Tests of non-regression of the MOA.

It took write the summary and analysis of information on the concepts of non-regression tests EOM via:

• testing features and flows paramount,
• tests of the MMI L_R (menu …)

• testing load curves, charts, reports.
No automated regression:

Figure: Test Automation of non-regression – “Royal Way”
Once the non-regression testing an advanced manual, you can automate these tests. Through a 5-day study on the feasibility of such automation.
Then (after selection of robots and validation of client), said a pilot using both tests not written regressions upstream can be defined and played.
Then, after reading and analysis of test reports this phase of automation has been validated.
Status:

• cell MOE: no recipe book for the NRR – TNR played “on the fly”
• MOA cell: a recipe booklet with 3 scenarios but very incomplete,

• crew Métiers: none of the existing – TNR played “on the fly.”
After the audit strategy Tests No Regression (TNR) was used to establish a workshop. Then, following the workshop with pilots and cell E_F EOM the solution was to use the recipe books of the MOA, to enrich and organize workshops with the crew Métiers to finalize specifications Recipe of TNR.
In collaboration with the MOE cell we developed a table listing the benefits to implement this strategy TNR. Benefits for 3 teams. This list has also been used to communicate / sell “the TNR to various actors.

1.2.4-testing integration with logic “recetteurs”

In the event of changes to at least two applications, it is appropriate not only to test each of them, but also to verify that communications (upstream / downstream) provided still work (or, d A new relationship, that it is operational).
From the perspective of the method, achieving a recipe calls for integration of information on each application must be amended prior to be functional: one speaks fluently of functional “unit” and basic concepts outlined in the guide are applicable to this case.
Then he must clarify the relationship between applications, carried out a second time, introduces a level of complexity that requires a strategy and specific (coordination, monitoring where appropriate, suitable platform…) and even setting up a dedicated tool for framing, the ’strategy of integration “. This allows sharing between different actors in the recipe key elements of the project constraints (planning, resources, goals), description of the platform, timing of work, etc..
Finally, the issue of integration strategy must contain scenarios and test files “shared” needed to verify the integration and the precise timetable for their passage. Games common test should be made to verify the chain.
They are to assemble several units and testing errors interactions between these units (and possibly to detect errors not detected burn unit level).
Special 1.2.5-test software
The test software such as ERP (or PGI) are special because part of testing the most complex to implement. For the following reasons as the need for identification requirements, business objects and rules. As the impact from one version to another, the recurring tests, the need for non-regression testing or interfacing with the SI system.

But also complex because there are many specific development, migration / recovery data SI history to the package, volumetric issues, platforms owner more or less open.
The complexity is also due to the richness functional thrust (predefined process trades and adapted to the job), a specific setting or developments complementary to each company, a process of development outside standard.

Sometimes, complexity from differentiations to be made between standard and specific. This level of development and testing. Indeed, developments standards are often part of a package already defined with the customer, while developments and specific tests are subject to contract amendments.
Finally, the complexity of software testing is problematic due to flow management inter-application to problems of configuration management and the difficulties of controlling the data.
Apart from the above-mentioned problems there are also those related to the design of scenarios and completeness. Below is an example scenario following the logic of an “end user”.

Figure: Example of a test of a module R / 3
The software tests are complex and require a first team experience on one of the modules of the ERP target.
Take an example to illustrate from a mission from an insurer on a SAP Finance module. The process established to identify and prepare the tests was: it was necessary to identify the main processes (and business applications) and test scenarios associated, and then identify the management rules, study the messages impacting and identify SAP transactions (or transport order) by flows and processes (the study of processes and prototypes developed during the design of the application).
Then it took specify the test scenarios and test sheets, bringing SAP scenarios provided in standard methodology ASAP (light testing methodology own SAP), define the scenarios used and specify the test case.
Finally, it took analyze coverage tests via the matrix of test cases and analyze and specify the data needed.
I will elaborate in a forthcoming article the strategy for carrying out tests on ERP.

Best practices and test repository

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!

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”

La jungle des acronymes : COBIT, ITIL, CMMI, TMM…

A longueur de journée on utilise ces termes, ils sont citées 10 fois par articles minimum dans les journaux spécialisés et on abreuve les clients, (qui simuleront une excellente connaissance du COBIT pour éviter de passer pour des êtres rétrogrades et has been), de ces termes pour leurs vendre des offres et des services qui son forcément compatibles avec le COBIT, ITIL et autres acronymes de types CMMI. Mais que signifient-ils réellement ?

Pour ce premier article sur le sujet je vais commencer par tenter de vulgariser le tout. Ci-dessous “l’ordonnancement” et les “places” des acronymes (termes génériques pour les COBIT, etc.) vis à vis du client final.

Place des acronymes vis à vis des clients

Tout d’abord il faut différencier les normes et les bonnes pratiques !

Quand je parle des normes j’évoque celles ayant une résonnance internationale et ayant des organismes valideurs officiels. A ce jour je ne compte que les normes ISO (la SOX ou Sarbannes Oxley étant « juste une loi »).

Par contre, les référentiels de bonnes pratiques sont pléthoriques mais on peut les trier par cible pour s’y retrouver un peu.

Ainsi, le COBIT via des audits (SOX, sécurité, etc.) permet de dresser un état des lieux de la GOUVERNANCE des SI. ITIL est LA bible pour tout ce qui est production, et supports (help desk par exemple).

Enfin le CMMI permet d’évaluer (ou audit) une organisation, un projet, etc.

Et le test dans tout cela ? Et bien il oscille entre ITIL et CMMI avec des bonnes pratiques comme TMM, TMAP (méthodologie de tests universitaire acheté et marketé par Sogeti) ou T2M (méthodologie de test créé par Stéria et peu connu du commun des mortels au grand dam de la SSII).

Pour chacun de ces acronymes vous avez un certain nombre de processus définis comme clés à l’intérieur desquels se trouve des services / domaines. Chacun de ces services ayant ses propres activités.

• COBIT : 34 processus et 4 services
• ITIL : 25 processus et 5 services
• CMMI : 25 processus et 4 services

Pour tout ces acronymes il s’agit en fait de règles de bon sens et de bonnes pratiques à mettre en œuvre et à « adapter » pour chaque société. Ceci est la théorie. Dans la vraie vie aucune n’est réellement implanter correctement.

Ceci car le parti du « On verra plus tard (synonyme de « jamais ») » ou des « On va perdre du temps à suivre tous ces processus » remporte haut la main la bataille !

Voilà pour la partie présentation des acronymes. Prochainement sur vos écrans (dès que j’ai le temps) la suite et les détails de chacun avec des focus particulier sur comment ces acronymes aborde le sujet des tests.

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

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.

Bonnes pratiques des référentiels de test

Dis tonton, tu peux me donner quelques best practices steuplé ?
Les premières bonnes pratiques sont :

• Bon sens,
• Organisation,
• Réflexions.

Rien de magiques mais qui, bien appliquées, seront les garants de la bonne utilisation d’un référentiel de test. Je vais les exposer sous forme de question à se poser aux bons moments :
Gestion des exigences ou requirements :

Unicité ?

• Cette exigence est-elle la seule concernant ce point à tester ?

Clarté ?

• Mener une réflexion sur l’arborescence à mettre en place,
• Le besoin est-il exprimé suffisamment clairement et n’y a-t-il pas de zone d’ombre ou d’ambiguïtés sur la compréhension ?
• Quelles sont les exigences implicites et non listé dans l’expression des besoins, (par exemple), mais dont on doit tout de même tenir compte ?

Précision ?

• L’exigence est-elle suffisamment explicite pour être mesurable et quantifiable via des objectifs de test précis ?

Validité ?

• Le document à l’origine de l’exigence est-il à jour et validé par le client ?

- Testabilité ?

• Est-il possible de créer un ou des cas pertinents pour tester efficacement l’ensemble des aspects de cette exigence ?

Gestion du catalogue des fiches de test ou Test Plan :
Fondamentaux :

• Chaque fiche de test doit-être reliée à une ou plusieurs exigences sinon vous pouvez dire adieu à la couverture de test
• Une fois la fiche de tests rédigée une astuce est de vérifier si toutes les fiches sont reliées au moins une fois à une exigence, sinon vous avez des trous dans votre raquette !
• En fonction de la stratégie définie, le Test Plan doit-être hiérarchisé selon les critères fonctionnels, métiers ou organisationnels du client

L’arborescence du plan de test doit :

• Être facile à appréhender par des fonctionnels
• Dans l’ordre des processus métier / applicatif du client (utiliser des codes numériques afin de gérer l’ordre des répertoires par exemple
• Être déterminée au départ entre tous les acteurs
• 4 à 5 niveaux MAXIMUM de répertoires sinon la folie vous guettera

Apporter un soin particulier aux onglets « Details » et « Design steps » :

• Saisir une description claire par le commun des mortels pour le but de la fiche de test

Apporter un soin particulier à l’onglet « Design steps » :

• Être suffisamment précis et détaillée, pour éviter toute ambiguité et autres interprétation au moment de l’exécution

• Indiquer les données à utiliser ainsi que leurs provenances
• Un STEP = UNE SEULE ACTION
• Renseigner le résultat attendu (RA) de manière précise et clair car le résultat sera comparé au résultat obtenu (RO) lors de l’exécution

Les bonnes questions :
- Unicité ?
o Un objectif = une fiche de test
- Clarté ?
o Les différentes étapes du mode opératoire sont-elles clairement identifiées, n’y a-til pas de zone d’ombre ou d’ambigüités sur la marche à suivre ?
- Données ?
o Toutes les données représentatives nécessaires aux tests sont-elles identifiées ?

o Avoir des données qui soient :

- Cohérentes
- Précise
- Représentatives
- Préparées
- Couverture ?
o Le mode opératoire de la fiche de test est-il pertinent et complet pour l’objectif identifié ?
- Généricité ?
o Pas de fiche de test valorisée sauf si une valeur est en dur dans l’application à tester

Conception et exécutions des campagnes de test ou Test Lab :
- Disponibilités ?
o L’environnement permettant d’effectuer les tests est-il disponible ?
o L’application à tester est-elle installée avec la bonne version (politique de versionning du client) ?
o Les comptes d’accès (login / mots de passes) aux applications et autres serveurs sont-ils valides ?
- Préparation ?
o Les fiches de test sont-elles à jour ou datent-elles d’il y a un an ?
o Les scripts des tests automatisés sont-ils identifiées et dans les bons répertoires ?
- Clarté ?
o Les noms des campagnes et fiches de tests sont-ils assez explicites pour votre voisine de palier comprenne ?
- Données ?
o A-t’on toutes les données nécessaires pour exécuter les fiches ?
- Couverture ?
o L’ensemble de la campagne couvre-t’il l’objectif identifié ?

Bonnes pratiques pendant l’exécution des fiches de test :
- Avoir les environnements, plateformes et réseaux disponible
- Disponibilité de la machine à café effective
- Pendant l’exécution des steps :
o Suivre le mode opératoire contenu dans le champ « Description » à la LETTRE !
o Les tests hors des chemins balisés sont INTERDITS !
o Comparer le résultat obtenu (RO) avec celui du champ « Expected Result » (ou résultat attendu (RA)).

Gestion des anomalies ou Defects :
Fondamentaux :
- Avoir défini un workflow des anomalies qui soit connu, validé, partagé et clair. Ceci pour tous les acteurs
- Si oui, est-ce que tout les acteurs sont au courant de leurs rôles et responsabilités ?
- Si l’exécution produit un échec :
o Vérifier que le résultat attendu spécifié est exact
o Saisir le résultat obtenu le plus clairement possible
o Vérifier que l’anomalie est reproductible sinon l’intégrateur vous ridiculisera et ne prendra pas en compte l’anomalie
o Ouvrir une anomalie
o Décrire l’anomalie le plus CLAIREMENT possible sinon votre travail ne servira à rien et vous allez perdre beaucoup de temps en explication
o TOUJOURS associer à une fiche de test

- Reproductibilité ?
o L’anomalie constatée est-elle reproductible dans les mêmes conditions ?
- Conformité ?
o L’anomalie a-t-elle été détectée en suivant le mode opératoire inscrit dans la fiche de test ?
o Les résultats attendus inscrits dans la fiche sont-ils à jour ?
- Unicité ?
o L’anomalie détectée n’est-elle pas déjà ouverte ?
- Pour cela, questionner vos collègues et votre responsable est un bon début
- Utiliser les filtres et champs de recherche
o N’y a-t-il pas déjà un ticket ouvert sur un sujet quasi identique ?

- Gravité ?
o Quel est le niveau de gravité de l’anomalie ?
- Critique
- Majeure
- Mineure

Une dernière bonne pratique pour la route ? Faite un copier / coller des pratiques ci-dessus dans un fichier Excel, nommé ce fichier « Checklist garante de la qualité du référentiel de test. ». Il ne vous restera plus :

• qu’à aller demander une augmentation à votre manager ;-)
• qu’à la présenter à votre client qui aura enfin un réel exemple d’industrialisation des outils de test

Et pour la petite histoire, sachez que mettre en pratique tout les jours ces préconisations fera de le mise en oeuvre de cet outil un niveau CMMI 3 (voir article complémentaire sur CMMI3 et QC).

Manuel de survie sur Quality Center !

Dans le monde du test tout le monde parle de Quality Center (QC pour son petit nom) de l’éditeur HP Mercury. Tout le monde en parle, du client à la société de service, en passant par les ingénieurs qui ne jurent que par ce fabuleux QC… Quel monde merveilleux que le notre dans lequel tout les acteurs d’un même projet partagent, échangent et utilisent le même référentiel de test et font en sorte que les exigences métier soient au cœur des priorités de chacun… Mais… La réalité est moins glamour !
En effet, parmi ces milliers d’ingénieurs seuls une petite poignée connaissent réellement QC et l’utilisent correctement.
Ainsi j’écris cet article afin de vous présenter les fondamentaux de l’outil et apporter quelques bonnes pratiques à mettre en œuvre lors de l’utilisation d’un référentiel de test (je ne m’étendrai pas sur la partie administration de cet outil).

Dis tonton, qu’est-ce qu’un référentiel de test ?
Ou « Comment à partir du minimum d’effort faire le maximum ? ». Pour la réponse reportez-vous à l’article sur le sujet.

Dis tonton, il y a quoi dans QC ?
Avant d’expliquer ce qu’il y a dedans précisons juste que c’est un outil partagé de gestion complète des activités de test, que son ancien nom était Test Director (ou TD).L’interface de QC est relativement « user friendly » (adapté aux utilisateurs) et pratique.

Dans cet outil il y a 5 onglets (ou parties). Chacun de ces onglets représente une partie importante pour chaque projet de test. Mais voyons plus en détails chacun de ceux-ci.
- Gestion des exigences ou requirements
- Gestion du catalogue des fiches de test ou Test Plan
- Conception des campagnes de test ou Test Lab
- Gestion des anomalies ou Defects
- Gestion des releases (non expliqué dans cet article car il faut savoir préserver le suspens)

Avec pour chaque onglets les fonctionnalités communes suivantes :
- Rapports & Graphiques
- Bilan
- La possibilité de joindre des captures d’écrans, des documents, etc.
- Impression
- Administration

La logique d’utilisation est la suivante, tout d’abord on élabore la stratégie de test et la matrice de couverture (onglets exigences et Test Plan). Puis, on planifie les exécutions (Test Plan et Test Lab), lors des exécutions on crée les fiches d’anomalies via lesquelles on fait valider les corrections.
Enfin, on met à jour les tests et on réitère le cycle de tests.

Plongeons nous dans QC :
Gestion des exigences ou requirements :
Il s‘agit d’identifier les exigences de test (à partir des exigences métier et autres spécifications), de structurer le plan de test et spécifier les futures fiches de test.
Petit rappel : les exigences peuvent être l’expression des besoins ou la liste des fonctionnalités à tester. Ainsi, l’ensemble des exigences de test définissent le périmètre à couvrir. Ces exigences sont aussi le point commun entre les dossiers de spécification et les tests à exécuter.
Les prendre en compte permet d’assurer la traçabilité entre la phase de conception et celle d’exécution. Enfin, les exigences sont le support aux études d’impact des évolutions des spécifications sur les plans et fiches de test.
Cet onglet permet également de voir tout les détails des exigences et de voir le statut des résultats des fiches de test couvrant une ou ses exigences propres.
Enfin, on peut soit entré manuellement les exigences soit utiliser une macro d’import à utiliser sur des documents aux formats Word ou Excel. Soit sous forme d’addin ou de développement interne au client ou la société de service.

Gestion du catalogue des fiches de test ou Test Plan :
Il s’agit de concevoir les fiches de test, définir les scénarios et préparer le reporting (en collaboration avec le Test Lab). Il s’agit aussi de créer l’arborescence des fiches de test ainsi que les fiches et créer les liaisons entre les exigences et fiches de test.
Le Test Plan correspond à l’ensemble des fiches de test, en cours de constitution ou opérationnelles.

Conception et exécutions des campagnes de test ou Test Lab :
Il s’agit de la création et de la planification des campagnes de test. L’exécution a lieu dans cet onglet, qu’elles soient automatisés ou manuel.

Rappelons que :
- une campagne de test est une combinaison de scénarios (composés de fiches de test)
- une fiche de test peut faire partie de plusieurs campagnes
- a l’issue de l’exécution des différentes épates, une fiche de test est considérée en statut PASSED, si et seulement si TOUTES les étapes la composant on ce même statut
- si au minimum une de ces étapes est en statut FAILED ou NOT COMPLETED la fiche de test aura ce même statut

Gestion des anomalies ou Defects :
Après exécution des scénarios / fiches de test il s’agit de décrire les anomalies et renseigner le reporting de campagne.

La suite de l’article concerne les bonnes pratiques

Testeurs = Super héros ?

IBM prépare actuellement son show du 14 octobre à Paris (France) sur leurs outils de test RATIONAL (entre autre).

Pour l’occasion IBM a crée une vidéo qui met en scène une équipe projet dont un testeur et cela est fais avec beaucoup d’humour et de recul, ce qui est très plaisant et glorifiant pour nous autres testeurs et teuses.

J’adore !

Au-delà de la joyeuse poilade les ateliers sont plutôt intéressant. Je vous fais un compte rendu si je peux y faire un tour.

Lien vers la vidéo.