Power of Ticketing

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.

My 'Building' Experience

Few years back, I was working in a project as a single tester. That project was developed from scratch and everything is from India only. One of the additional responsibilities came to me is to 'build' the project through a tool call "Anthill". Since I was relatively new to industry I was excited and began to play with this. Since there was no proper planning,there were major fixes every day and I as a tester (who is having additional responsibility of 'building' with the latest fix) started taking builds on daily basis. In addition, for every bug I filed I started getting calls from programmers to 'check in the latest build..just to ensure..'.I was able to file bugs only after getting the latest code.

Point here is it will take at least one-two hours for me to take the latest build and if I find any showstopper, I stopped testing and started to wait for the fix and after the fix I again started 'building'.

There is no another tester and there is no change in this process, no comment from PM (since I didn't have test manager) and I was surrounded by developers.

After a while, I was finding only few bugs that too show stoppers and concentrating on improving the Anthill's build.xml to make quicker builds , which was lauded as good solution by few developers. In this, around 50% of my time went for running anthill / waiting for build / improving the anthill process.

All went fine until one morning when my client found one 'Critical bug' not 'show stopper' in one of the previous build (few days old), and obviously developers started saying to check in the latest build which he refused and filed the bug. The answer from him is albeit there may be some fix in the coming builds, this bug has been found in 'xyz' build and that is true and so I am filing the bug. Later we can change the status of the bug accordingly.

After this incident, I took the backseat and STOPPED building the code and made a build cycle. I made clearly that I myself as a tester will take the build every Wednesday and I will file bugs based on the build (irrespective of whether they are fixed in the later builds) and then I realized there were many Critical/Major serious bugs are there in the product which should have been caught long long back.

But my actions were taken at the end of the project and as expected our estimation went terribly wrong and blame came to me also as a tester (in fact I got a lion's share...:-( ).

Moral: (i) Decide / Negotiate about  the build cycle/ interval between builds at the early stage of the testing and follow the rule religiously (unless its very critical fix).
(ii) If you as a tester took additional responsibility of either build engineer, document writer , whistle blower in CMMi process or whatever, be clear to give priority to testing and then go for others.