I am not sure whether this practice is followed across companies in industry. At least I am sure that few projects are not following this system.
We are aware of filing Bugs against the AUT (Application Under Test). Sometimes the issues filed in Bug tracking system all are not bugs, but some may found to be a Enhancement (Nice to have feature), some are simply 'Task' PR which is assigned against developers.
This Task PR (meaning that particular task has to be done by Assignee of the bug) can be very efficiently used by Test Manager to keep track of the tasks to be done by Testers.
Imagine in a testing module both Manual and Automation testers are working and at the beginning of the testing life cycle many things are discussed as 'to be done' and the way they are tracked is through emails, task requests in Outlook and simply by "Managers". We can use the bug tracking system for this purpose and Manager can raise 'Task' tickets against Testers for all the tasks he wanted tester to do. Or even tester can themselves can create and assign to themselves.
Examples for those task bugs are
(i) Creating new test cases for the new features (and getting sign off from product management and developers). This issue is considered as 'Completed' only when Peer Review/ Product management Review/Developers review/ Second level review is completed. We can create the workflow in our bug tracking system accordingly.
(ii) Select test cases from manual test case repository in order to automate and get sign off from Automation engineer.
(iii) Automate all the selected manual test cases in a feature and get Peer / Client sign off.
(iv) Finish self review for Performance appraisals.
(v) Verify all the bugs for this release.
(vi) Publish the Performance numbers between last release and this release
(vii) Clean the test cases (delete all the obsolete test cases) ..Criteria => Test cases written in past 3 years.
(viii) Complete the knowledge transfer session (this task issue is considered to be completed only if the person who is getting KT has given the reverse presentation and signing off the documents)
(ix) Do 5 interview before 30-Feb
and many more.
All these are treated as open Bugs and considered as important criteria in testing signoff of the particular release.
We can create separate areas in bug tracking systems, such as "Manual Testing Work" , "Automaton Testing work" etc This is analogous to IT help desk ticket but internal to testing team. How diligently we follow this reflect the success.
We are aware of filing Bugs against the AUT (Application Under Test). Sometimes the issues filed in Bug tracking system all are not bugs, but some may found to be a Enhancement (Nice to have feature), some are simply 'Task' PR which is assigned against developers.
This Task PR (meaning that particular task has to be done by Assignee of the bug) can be very efficiently used by Test Manager to keep track of the tasks to be done by Testers.
Imagine in a testing module both Manual and Automation testers are working and at the beginning of the testing life cycle many things are discussed as 'to be done' and the way they are tracked is through emails, task requests in Outlook and simply by "Managers". We can use the bug tracking system for this purpose and Manager can raise 'Task' tickets against Testers for all the tasks he wanted tester to do. Or even tester can themselves can create and assign to themselves.
Examples for those task bugs are
(i) Creating new test cases for the new features (and getting sign off from product management and developers). This issue is considered as 'Completed' only when Peer Review/ Product management Review/Developers review/ Second level review is completed. We can create the workflow in our bug tracking system accordingly.
(ii) Select test cases from manual test case repository in order to automate and get sign off from Automation engineer.
(iii) Automate all the selected manual test cases in a feature and get Peer / Client sign off.
(iv) Finish self review for Performance appraisals.
(v) Verify all the bugs for this release.
(vi) Publish the Performance numbers between last release and this release
(vii) Clean the test cases (delete all the obsolete test cases) ..Criteria => Test cases written in past 3 years.
(viii) Complete the knowledge transfer session (this task issue is considered to be completed only if the person who is getting KT has given the reverse presentation and signing off the documents)
(ix) Do 5 interview before 30-Feb
and many more.
All these are treated as open Bugs and considered as important criteria in testing signoff of the particular release.
We can create separate areas in bug tracking systems, such as "Manual Testing Work" , "Automaton Testing work" etc This is analogous to IT help desk ticket but internal to testing team. How diligently we follow this reflect the success.
0 opinions:
Post a Comment