KPI/ways to identify areas in need of testing

Question

My Problem:

I am in a situation where there is no immediate demand to test any feature (no new features in need of testing, or no new changes made)

This makes it difficult to identify areas that are potentially highly buggy, but there are no clear signs of that (such as recent constant crashing, customers sending tickets, or failing tests).

My question:

How do I prioritize areas of the product under test for adding tests (KPI, rules of thumb, general regression sweeps) in the absence of new feature development? Or am I overthinking it, and maybe other tasks (such as automation/process improvement) should be higher priority?

Answer 1

You're actually in a reasonably good place, if the application is stable enough that there aren't a lot of defects reported and it isn't undergoing major development.

Some suggestions:

• Survey historical defects - Since you don't have any current data on where the app is most fragile, the historical defect record is your main tool to find this data: you'll be looking for clusters of defects that follow either a feature development or a bug fix. That will give a clue to the more fragile parts of the system.
• Find the 20% - The 80/20 rule is that 80% of user interactions are performed in 20% of the system. You need to know what that 20% is, because chances are you'll get more forgiveness of defects in the rest of the system than you will in the 20%. Focusing automated regression on the 20% rarely goes astray.
• Find the critical functionality - The critical functionality will often overlap a lot with the 20% that gets most use, but not always. For example, password reset and forgot password functionality is critical to users, but is typically not frequently used. Similarly, some setup activities are critical, but once completed aren't used often. This should be your next priority target.

Those three sets of data should give you enough information to focus on for a long time.

Answer 2

Following can be one of choosing factor for testing areas when you have no change or new feature in current release:

When defects raised during functional testing get fixed, we do regression testing for checking the IMPACT of fixing of those defects.

During regression we again raise defects and those would get fixed. But we do not check IMPACT of defect fixing this time i.e. the impact of defect fixing for the defects raised in regression testing.

You can identify the critical or important areas of last testing run of previous release and can apply above mentioned scenario to those areas.

This can be said as second level regression testing.