SME Server:Documentation:QA:Verification/fr

Languages:

English  • français

ASSURANCE QUALITÉ - Vérification

Tous les bogues ne nécessitent pas de correctifs de code, mais une grande partie d'entre eux oui. Une partie importante du processus d'assurance qualité (AQ / QA) consiste à vérifier qu'un bogue est résolu lorsque son code a été modifié. Nous faisons de notre mieux pour ne pas négliger les choses, mais cela peut arriver, une vérification appropriée est importante pour réduire le risque que de telles choses se passent. Par conséquent, nous essayons de nous en tenir à un certain flux de travail lors de la vérification. Étant donné que l'équipe de développement et les ressources sont plutôt limitées, il est assez difficile d'essayer de corriger tous les bogues soulevés, et encore moins de les vérifier. Étant donné que vous n'avez pas besoin d'être un développeur pour vérifier les correctifs qui ont été produits, ce guide est écrit pour aider tous les membres de notre communauté à nous aider dans le processus de vérification, il s'agit d'un élément essentiel de la maintenance continue du Serveur SME KOOZALI.

Déroulement général du travail

Comme mentionné précédemment, nous essayons de nous en tenir à un certain déroulé du travail lors de la vérification des bogues. En général, le processus peut être divisé selon les étapes suivantes :

1. . état de la boîte de test ;
2. . description du bogue ;
3. . lister un nouveau paquet corrigeant le problème ;
4. . vérifier quel paquet est actuellement installé ;
5. . répliquer le problème en détail ;
6. . installer un nouveau paquet ;
7. . vérifier que le nouveau paquet a été installé ;
8. . répéter les tests ci-dessus (5e ligne) ;
9. . corrigé / non corrigé sur le fondement des nouveaux tests, conclusion : VÉRIFIÉ ou RÉOUVERT ;
10. . détailler tout impact sur la documentation, c-à-d nouvelle base de données ou autre ;
11. . bref résumé de ce que le nouveau paquet a réalisé, par exemple corrigé ceci ou cela.

As already mentioned we try and stick to a certain work flow when verifying bugs. In general the process can be split in the following steps:

1. . status of test box
2. . description of the bug
3. . list new package fixing the problem
4. . check which package is currently installed
5. . replicate problem in detail
6. . install new package
7. . check that new package has been installed
8. . repeat testing above (5th line),
9. . fixed/not fixed based on new testing, conclusion: VERIFIED or REOPEN
10. . detail any documentation impact, i.e. new DB or whatever
11. . short summary of what the new package has achieve, eg. fixed this or that.

How upgrade the new packages

	Note:
	Of course we are doing good code but we can brake your system, so you are strongly advised for doing verification on a virtual SME Server.

The bug report will detail the exact package and version needed. These are normally in smeupdates-testing and can be installed by :

yum --enablerepo=smeupdates-testing update <package> 

for example

yum --enablerepo=smeupdates-testing update e-smith-ldap

As it is a manual step to move packages into smeupdates-testing the most recent packages will be in smetest and can be installed from there if necessary. for example

 yum --enablerepo=smetest update e-smith-ldap

or if you need several repositories :

 yum --enablerepo=smetest,smeupdates-testing,smedev update e-smith-ldap

Template

The above process is documented in the comment field of a bug using the following template, more information on the steps and the template sections can be found below.

VERIFICATION TEMPLATE

= ENVIRONMENT: 

= ORIGINAL PROBLEM:

= RESOLUTION:

= CURRENT VERSION INSTALLED:

= TESTING:

= UPDATED VERSION INSTALLED:

= PROBLEM FIXED:

= VERIFIED OR REOPEN:

= DOCUMENTATION IMPACT:

= SUGGESTED RELEASE NOTES:

AS AN EXAMPLE:

VERIFICATION

= ENVIRONMENT:
[description of test system (version, installation methods, upgrade history. etc).
If you have some non-core package installed, run /sbin/e-smith/audittools/newrpms and provide output]

= ORIGINAL PROBLEM:
[Summarise bug]

= RESOLUTION:
[Insert changelog for new package]
In example:
Fixed in e-smith-base
* Mon Apr 21 2013 chris burnat <devlist@burnat.com> 5.4.0-27.sme
- Fix the way '.' works in bash [SME: 7532]

= CURRENT VERSION INSTALLED:
[rpm -qa <package name>]

=TESTING:
[Reproduce bug if you can, showing steps taken]

= UPDATED VERSION INSTALLED:
[Update to new package, show steps taken]
and:
[rpm -qa <package name>]

= PROBLEM FIXED?:
[Repeat steps carried out under TESTING above.

= VERIFIED OR REOPEN:
[Problem fixed, then VERIFIED - not fixed, then REOPEN]
Note: if you may not have rights to toggle resolution, someone will do it for you

= DOCUMENTATION IMPACT:
[Does something need documentation, eg a db or new procedure? if affirmative, please provide details, someone will later punt to docteam for action]

= SUGGESTED RELEASE NOTES:
[Summary of what was fixed]

Environment

Since some bugs might appear in multiple versions of our products (e. g. SME Server 7.x as well as SME Server 8.x and now SME Server 9.x) we need to make sure you are performing the process of verification using the proper environment. Most of the time it would be something like the following:

SME Server 8.0 fully updated, no contribs installed

Original problem

This section is used to show that you can reproduce the original problem on your test machine. It is important that you do this as accurately and methodologically as possible as you will have to reproduce these steps after you have updated to the newer pacakage(s) to show that the problem is actually fixed. Make sure to conduct your testing as extensively as required but on the other hand try and keep things as clear and concise as possible. In the case of New Feature Requests (NFR) or if a previous version of the package with the reported bug is not available this step might be skipped.

Resolution

This section is used to briefly describe which steps are needed to be taken in order to upgrade to the fixed version, usually it will be something like this:

Install package1 and package2 from smeupdates-testing and/or smetest or patch xyz was applied to etc

After that it is time to actually upgrade to the new package(s).

Current version installed

When the bug is reported and diagnosed normally the package that should be fixed, as well as the version of the package might be documented, but certainly the package name and the version on which the issue was fixed is meant to be reported by the developer, it will be something like below:

Fixed in package-name

* Thu Nov 25 2010 John Doe <jdoe@fqdn.org> x.y.z-r.sme
- Short description of the fix [SME: bugnumber]

The version intended here is the version of the package with the bug present, usually the output of the rpm -q command will do, so most of the time this will look something like this:

[root@smetest ~]# rpm -q e-smith-base
e-smith-base-5.2.0-28.el5.sme
[root@smetest ~]#

Testing

Show in detail existing problem being fixed by new package

Updated version installed

This section is analogue to the Current version installed and is meant to show that the updated package(s) are in fact installed before verifying the bug has been fixed, usually a rpm -q for the updated package(s) would do.

Problem fixed

This is the heart of the verification process as here is where we show the problem is actually fixed. You can use the same steps for this as used in the Original problem section. Be sure to check that not only the problem is fixed, but also make sure no error messages are found in the logfiles or on the console when entering the comments. If errors are present please report them to the bug report if it affects the fix, or open a new bug when a new issue is discovered. Also make sure to test normal functionality related to the changes are still working properly.

Verified or Reopen

This is the section where we conclude on the verification process. If the fixed package works and there are no ill side effects we can conclude the package is VERIFIED, otherwise it might be REOPENED. If you have found other bugs in the process you can state them here (briefly) as well, but please keep in mind that new issues should be reported in a new bug report. When REOPENING the bug, please justify this briefly.

	Note:
	Please, do not forget to also set the status field, at the bottom of the comment field, to the proper value matching your conclusion.

Documentation Impact

Eg: is a DB variable created/removed?

Suggested release notes

If you feel capable please suggest the information we can put in the release notes in one or two lines, if you cannot please leave this empty, or for instance specify it is to be determined by specifying T. B. D..