Changes

Not all bugs require code fixes but a substantial part of them do. An important part of the QA process is verifying the issue addressed in a bug is fixed when code is changed.

Not all bugs require code fixes but a substantial part of them do. An important part of the QA process is verifying that the issue addressed in a bug is fixed when any of the code is changed.

We try our best not to overlook things but we might do, proper verification is important to reduce the risk of such things slipping through. Therefore we try and stick to a certain work flow when doing verification.

We try our best not to overlook things but it can happen, proper verification is important to reduce the risk of such things slipping through. Therefore we try and stick to a certain work flow when doing verification.

Since the development team and resources are rather limited it is already hard to try and fix all bugs raised, let alone also verify them. Since you do not need to be a developer to verify the fixes we make this guide is written to help people from our community to help us in the process of verification.

Since the development team and resources are rather limited it is difficult enough to try and fix all bugs raised, let alone also verify them. Since you do not need to be a developer to verify the fixes that have been produced this guide is written to help all members of our community to help us in the process of verification, it is a vital part of the ongoing maintenance of SME Server.

===General work flow===

===General work flow===

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:

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:

#. Describe the environment briefly

#. status of test box

#. Show the installed versions of affected packages before upgrading

#. description of the bug

#. Show you can reproduce the problem as reported in the bug

#. list new package fixing the problem

#. Short synopsis of the resolution of the problem

#. check which package is currently installed

#. Update the affected packages

#. replicate problem in detail

#. Show the problem is fixed (and no ill side affects have appeared)

#. install new package

#. Suggestion of the release note information

#. check that new package has been installed

#. Final conclusion: VERIFIED or REOPEN

#. repeat testing above (5th line),

#. fixed/not fixed based on new testing, conclusion: VERIFIED or REOPEN

===Template===

===Template===

====Environment====

====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) we need to make sure you are doing verification using the proper environment. Most of the times it would be something like the following:

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

  SME Server 8.0 fully updated, no contribs installed

====Original problem====

====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 accurate and methodological 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.  

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 make your test as extensive as required but on the other hand try and keep things as clear and dense as possible.  

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.  

{{{Note box|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.}}}

{{{Note box|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====

====Resolution====

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

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

  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).

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

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:

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

Fixed in package-name

  * Thu Nov 25 2010 John Doe <jdoe@fqdn.org> x.y.z-r.sme

  * Thu Nov 25 2010 John Doe <jdoe@fqdn.org> x.y.z-r.sme

  - Short description of the fix [SME: bugnumber]

  - 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:

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:

====Verified or Reopen====

====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.

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 motivate this briefly.

When REOPENING the bug, please justify this briefly.

 

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

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