7 Testing Principles for a beginner QA

1. Testing shows the presence, not the absence of defects.?

This is the best ‘out of jail’ card you can ever get as a QA. If you ever miss a defect by chance while testing, use this principle to defend yourself. Once I asked my good friend and a colleague after testing a new feature: “Can we call it thoroughly tested?”. His answer was: “No defects were found during testing in all selected cases”. Golden words.

2. Exhaustive testing is impossible.

Another cheat code to every new QA out there. Often, testing is done quickly. Especially at the end of the sprint/iteration or even more so while testing the bugfix for a blocker on PROD when the Client is breathing at your back. Smoke test, a quick regression testing and we are good to go.

3. Early testing saves time and money.

Saved money won’t reach your pocket easily, dear QA. Nonetheless, early testing will help eventually – you won’t need to waste YOUR precious time during the late night/weekend bugfix testing. But as I said, there won’t be extra money unless you have a mastermind plan to milk those hours as overtime.

4. Defects cluster together.

Another cheat code for a new QA. If a defect was found act paranoid and check the element in question through and through. Also, blame the developer who can’t fix it like a professional. Okay, no. Don’t do that.

5. Tests wear out.

This is correct in those cases when your application is being iterated often and the changes are being introduced constantly. Also, this principle implies that we MUST find new defects. Test cases are created when the user story is approved, and the acceptance criteria is clear. If the code in production isn’t touched, the test case will be valid and won’t wear out easily.

6. Testing is context dependent.?

In other words – testing is a creative gig. Context is changing constantly, occasionally modern technologies are being introduced, businesses are adapting to their client’s needs and reacting to the new and updated old local and international laws. Context will be the key factor when deciding the approach to testing.

7. Absence-of-defects fallacy.

By the definition in the latest ISTQB Certified Tester – Foundation Level Syllabus v4.0: it is a misconception to expect that software verification will ensure the success of a system. This principle was introduced to assure us, QA’s to not feel the guilt if the result is not working as expected. While we put hours, our hearts, and souls into catching all the bugs that we can, verification and the quality of released software is a matter for everyone involved – Client included.

?