Life can often get quite hectic for QA engineers when we have multiple releases lined back to back. The mind boggles with ‘Was this feature to be tested for this release or can I put it on the back burner?’. We need all the help we can get to keep track of our to-do list.
Typically, a RFE (Request For Enhancement) is filed in the bug management system to implement a new feature for the product. The task gets assigned to a developer who figures out all the work flows, codes it and also when it suits their fancy, writes unit tests. Meanwhile, the hapless QA person keeps checking the RFE/bug status every day and then goes back to other tasks, like creating test cases, documenting the test plan/strategy, or working on other projects. Then, two hours before code-freeze, the bug is suddenly marked RESOLVED-FIXED, which pushes the QA person to hit the panic button.
So, what went wrong here?
1] the QA person did not have a specific bug assigned to them for testing the new feature. They were only CCed to the RFE bug assigned to the developer. So they have to keep checking the RFE bug assigned to developers.
2] the QA engineer was not able to raise a red flag when the feature was not delivered on time for testing.
3] In case only a part of the feature is implemented (and to be tested) for a given release, the bug descriptions are often not precise on the details.
So how can we re-wire the system so as to prevent all of the above problems? Consider the following alternative:
1] The development-manager creates a RFE bug in Bugzilla for the developer
2 ] The developer eventually marks the RFE fixed/closed
3 ] The development-manager will then create a new bug entry (or multiple bug entries) assigned to QA to test the feature. These QA bug(s) will be linked to the RFE bug entry.
This methodology encourage accountability, since the QA team member is held responsible for a precise set of testing tasks that he/she needs to complete for any given release; having bugs they need to resolve before a release is shipped keeps the QA engineers on their toes.
The practice is also very relevant in managing staggered releases for a major feature, where the feature is completed over multiple releases, and for each release the QA team needs to test only specific components of the overall feature. The QA team will have distinct bugs entries for each sub-component.
