Bug review - reducing WAD bugs and Sharing with team what the best bugs are like?

As the key output of test teams, we have to monitor our bug quality, reducing WAD bugs, invalid bugs (raised dur to invalid set up, incorrect understanding to requirements, etc). Moreover, bug severity is very important for us and product team, we should monitor bug severity, incorrect severity level will mislead team, eventually have side impacts on project progress.

For example, if one defect didn't lost functionality of one feature, just have some impacts on end users, you shouldn't raise the defect as a major bug. In other hand, if the defect lead to lose the major functionalities of the feature, that should be a major issue, SW team should respond it within 24 hour, and keep the fixing progress once a day.

So if you are a test leader, test manager, a big responsiblity is that you have to coach your team to raise approprate bugs, and that is our topic today. We always drive another series of activities - Best CRs competetition. That is a good thing for test team, through each activity, your team will know what kind of issues you or SW/Product team really care, and what kind of defects really improve our product quality. We provided a little gife - movie tickets or cake coupons to thos guys who won the competetition.

BTW, not all WAD CRs are bad, some of them are very good to product, just SW team follow up requirements or their technique design, so they reject to fix them. By this case, we have to look for help from SW management team or QA team, maybe the defect can't be fixed on this product for schedule reason, but that can be considered on next product if they really bring major benefits to our consumers.

In summary, that is a routine task, you have to put our energy, passion and effors to make them well done.

Good luck, guys.

How do you design your test case? How many steps, and how long is better to execute a test case?

Hi, recently we got feedback on test case quality, some complains on lots of expected results per a test case, that bring a deep discussion on that.
Did you think about the question? What is better for a test case with 5~6 steps and exepected results or just with 1~2 expected results? When you are designing test cases for new features, what should be considered to make sure good quality, easy to maintain, and good coverage, and good productivities to execute them?
I proposed several types of what we meet often, let's check what is the best?
- 5~6 steps Vs 5~6 expected results, each of which should match each step.
Benefits: Can do a completed functionality of a phone, including several interactions, like sending SMS/MMS, or Alarm event, etc;
Weakness: A little complicated, need tester have a full understanding before start to execute, and the coverage is defined from designer's head.

- 3~4 steps Vs 1~2 expected results, just check key points according to requirements, ignoring the common sense points, or minor points to end users.
Benefits: Easy to know the test coverage to requirements, traceable;
Weakness: Didn't deep dive, not enough to check some hidden defects

- 1~2 steps Vs only one exepected result, per my understanding, just check basic functionalities, or sanity test?

Anyway, I personally preferred the 2nd type as main test case model, and sometimes we can use the 3rd type as sanity test in order to quickly go through phone basic functionalities. In most cases, we have to do part regression test after new fixes are built in, or new features are integrated, we can use the 2nd type case with some exploratory test cases.

So what my next question is? How to design an exploratory test case? Any guideline or tips? How to know it meet your expectations? In other words, in black box test, are most of findings from test case executors or from case developers? Why?

Thanks,
Gaochuang