> For the complete documentation index, see [llms.txt](https://practical-testing.gitbook.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://practical-testing.gitbook.io/home/testing-practices/do-regression-testing-rcrcrc.md).

# 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 RCRCRC<sup>1</sup> 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](/home/testing-practices/perform-exploratory-testing.md)

### 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.

<table><thead><tr><th width="236.72723388671875">RCRCRC Point</th><th>Sample Calculator Regression Tests</th></tr></thead><tbody><tr><td><strong>Recent</strong></td><td>Re-test the newly added <strong>square root (√) and power (x², x^y)</strong> functions.</td></tr><tr><td><strong>Core</strong></td><td>Verify <strong>basic arithmetic operations</strong> (+, −, ×, ÷) still work correctly.</td></tr><tr><td><strong>Risk</strong></td><td>Check <strong>division by zero</strong> handling to ensure no crash or incorrect result.</td></tr><tr><td><strong>Configuration-sensitive</strong></td><td>If the software was re-built using a higher level Java version (e.g., Java 17 vs Java 21), test it on <strong>different Java Runtime versions</strong> </td></tr><tr><td><strong>Repaired</strong></td><td>Re-execute tests for a <strong>bug fix in percentage calculation</strong> to ensure it now produces the correct result.</td></tr><tr><td><strong>Chronic</strong></td><td><p>Verify <strong>decimal precision issues</strong> that have historically caused rounding errors.</p><p>(e.g., 0.1 + 0.2 resulting in 0.30000000000000004) </p></td></tr></tbody></table>

### Sources

1. Karen's blog: <http://karennicolejohnson.com/2009/11/a-heuristic-for-regression-testing/>