Lately I'm been thinking...

At what point do you consider a code change as "tested"?

By "code change", I mean any new feature, bug fix, or any code update apply to a product. You added a new feature to project "X" and you've done your manual developer testing. You also may have created a few test cases for QA.

Is it tested now?

Eh, not yet! Now it's time to pass it on to Quality Assurance (or whatever you call your testing group). Now they manually test the change using your test cases. They hopefully will also a few more test case as the QA team should have thought of more scenarios. Most of the time the QA engineer will think of things that the developer had not considered. The QA team goes back and forth with Development until all test cases pass.

So what about now, is it tested now?

Eh, nope! What, why not? All the test cases have been ran and they all passed. What gives?

Well let's say your code change was a very simple change. You had a few test cases that both development and quality assurance both execute and validate that, yes, the code change is accurate and works.

Who is going to come back and rerun these test scenarios on the following releases?

No one... because there is not enough time in the day to execute all previous created test cases.

This brings me to my point. From this day forward the principle of "it's not tested until it's automated" is going to be one of my core principles. I will be ensuring I live by this principle in both my personal and professional life.

It is not TESTED until it is AUTOMATED

That's right, no more saying a code change is tested if it has not been automated, integration, and / or unit tested. These test will ensure this code change continues to work in future releases.

If we have automation tests then we can execute all previous ran test cases for any future releases. This ensure the product continues to operate as expected and that new bugs are not introduced.

Rock on and Become EPIC!