Do Regression Testing: RCRCRC
Regression Testing: "Something in the system changed - code, configuration, environment - so now we must re-check things to make sure the change didn’t accidentally break what used to work".
So much to test, so little time. Unit, API, and higher-level automated tests help a lot, but they are never a guarantee that everything works 100% right. How do you approach additional Regression Testing?
How do you make a quick test plan and execute it under tight deadlines?
Consider using Karen N. Johnson's RCRCRC1 mnemonic:
Recent: new features, new areas of code are more vulnerable
Core: essential functions must continue to work
Risk: some areas of an application pose more risk
Configuration sensitive: code that’s dependent on environment settings can be vulnerable
Repaired: bug fixes can introduce new issues
Chronic: some areas in an application may be perpetually sensitive to breaking
Focus on a subset of these 6 software aspects, and then either:
Executed existing scripted tests
Perform Exploratory Testing
Calculator Example
Assuming a desktop calculator app written in Java (thus requiring a Java Runtime Environment installed on the machine), here is a sample regression test plan based on the mnemonic.
Recent
Re-test the newly added square root (√) and power (x², x^y) functions.
Core
Verify basic arithmetic operations (+, −, ×, ÷) still work correctly.
Risk
Check division by zero handling to ensure no crash or incorrect result.
Configuration-sensitive
If the software was re-built using a higher level Java version (e.g., Java 17 vs Java 21), test it on different Java Runtime versions
Repaired
Re-execute tests for a bug fix in percentage calculation to ensure it now produces the correct result.
Chronic
Verify decimal precision issues that have historically caused rounding errors.
(e.g., 0.1 + 0.2 resulting in 0.30000000000000004)
Sources
Last updated