If others testing team members are interested, i’m using this template for the verification process in redmine, i think it’s self-explanatory:
GENERAL WORKFLOW
1. status of test box and list of packages/groups currently installed
2. replicate problem in detail
3. install new package
4. repeat testing above (2nd line)
5. fixed/not fixed based on new testing, conclusion: VERIFIED or TRIAGED
6. Misc Notes (Documentation Impact, other..)
VERIFICATION TEMPLATE
+System and Package Version installed+
...
Package Installed: ...
Other Package installed: ...
+Test Original Problem+
...
+Install Updated Package+
<pre>
yum --enablerepo=nethserver-testing update ...
</pre>
+Test Results after update+
...
+Verified Or Reopen+
...
+Note+
...
AS AN EXAMPLE:
+System and Package Version installed+
[description of test system (version, installation methods, upgrade history. etc).
Package Installed: [rpm -qa <package name>]
Other Package installed: [yum grouplist | sed '1,/Installed/d;/Available/,$d']
+Test Original Problem+
[Reproduce bug if you can, showing steps taken]
+Install Updated Package+
[Update to new package, show steps taken]
<pre>
yum --enablerepo=nethserver-testing update ...
</pre>
+Test Results after update+
[Repeat steps carried out under TESTING above.]
+Verified Or Reopen+
[Problem fixed, then VERIFIED - not fixed, then TRIAGE]
+Note+
[Documentation Impact]
[Other]
note: maybe to comply the point 2 of the workflow, it would be nice that when a new bug is opened it contains
status of test box and list of packages/groups currently installed
yes, really good point. I like it it’s better and more detailed of what i’m using now.
a little update based on sme_qa and on the template i’m currently using:
GENERAL WORKFLOW
1. status of test box and list of packages/groups currently installed
2. replicate problem in detail
3. install new package
4. repeat testing above (2nd line)
5. fixed/not fixed based on new testing, conclusion: VERIFIED or TRIAGED
6. Misc Notes (Documentation Impact, other..)
VERIFICATION TEMPLATE
+System and Package Version installed+
...
Package Installed: ...
Other Package installed: ...
+Test Original Problem+
...
+Install Updated Package+
<pre>
yum --enablerepo=nethserver-testing update ...
</pre>
+Test Results after update+
...
+Verified Or Reopen+
...
+Note+
...
AS AN EXAMPLE:
+System and Package Version installed+
[description of test system (version, installation methods, upgrade history. etc).
Package Installed: [rpm -qa <package name>]
Other Package installed: [yum grouplist | sed '1,/Installed/d;/Available/,$d']
+Test Original Problem+
[Reproduce bug if you can, showing steps taken]
+Install Updated Package+
[Update to new package, show steps taken]
<pre>
yum --enablerepo=nethserver-testing update ...
</pre>
+Test Results after update+
[Repeat steps carried out under TESTING above.]
+Verified Or Reopen+
[Problem fixed, then VERIFIED - not fixed, then TRIAGE]
+Note+
[Documentation Impact]
[Other]
note: maybe to comply the point 2 of the workflow, it would be nice that when a new bug is opened it contains
status of test box and list of packages/groups currently installed