Tom Peruzzi's thoughts on digital, innovation, IT and operations

It does not depend on whether we talk about testing for software, hardware, configuration all of them or processes. You will either have no/less time, resources, money or the will to do so. Interesting to see that the more they talk about why they cannot test, the more they misuse time in talking about it.

And QA/test is part of the management team. If you don’t live QA and testing, why should your employees then do so? If you don’t give them time to make all the houskeeping stuff and keep code clean and tidy why should they use their extratime for doing so?

2 things on testing, do it whenever you change anything relevant for you, your IT, your department, your business! Second: If you test think about how and why? It does not make as much sense to test the resilience of a known working cluster instead of testing the new code and how business processes are built in.

This leads me to the last point, the acceptance criteria. If you start a project, think about how the desired goal should look like. I don’t talk about the gui, I talk about the functionality. At end test, whether functionality is met or not. It is very often really hard to find correct numbers and values for acceptance criterias but the longer you run your QA, the better you will be.

QA consists of many more, an adequate test environment (near live), systems and routines, unit testing ,functional testing, integrational testing, load testing and and and. But if you don’t start, you will never come to that point of thinking about which test you need when and why.

Continual improvement is the key to successful QA!