If you were using metrics from the bug-tracking database to measure your progress or success at testing, why would just counting the number of bugs you find per day or computing your average find rate be an insufficient measure?
A1:
It doesn't tell the entire story. You could be testing the most complex area of the software. Your area could have been written by the most experienced programmer. It could have been written by the least experienced programmer. The code you're testing may have already been tested or may be brand new.
2:
Given your answer to question 1, list a few additional software metrics that could be used to measure more accurately and precisely your personal progress or success at testing.
A2:
Average number of bugs found per day. Total bugs found so far. Ratio of fixed bugs to all bugs found. Ratio of Severity 1 or Priority 1 bugs to all bugs found. Average time from the Resolved state to the Closed state.
3:
What would a database query look like (any format you want) that would extract all the resolved bugs assigned to Terry for the Calc-U-Lot v3.0 project?
A3:
Product EQUALS Calc-U-Lot AND
Version EQUALS 3.0 AND
Status EQUALS Resolved AND
Assign TO EQUALS Terry
4:
If the bug-find rate for a project was decreasing like the one shown in Figure 20.8 and everyone was excited that the project was getting close to releasing, what might be a couple reasons why this wouldn't be true, that the numbers were lying?
A4:
It's possible that the software was released to testing in phases and not all the software was tested yetit might only be leveling off for the current phase. The testers might be busy regressing and closing bugs and not looking for new ones. It could have been a very warm and sunny week or the testers might be out on vacation.
