What is a Testing Centre of Excellence?
A Testing Centre of Excellence (TCOE) can be many different things with different objectives and its scale and reach will vary from company to company. Generally speaking, it’s an internal organisation that provides various testing and testing related services to its internal customers. Although internal, it can be set up and delivered by a third-party external organisation. The TCOE can be onshore or offshore and geographically dispersed but, by definition, will always be managed centrally. 

Today we welcome back our popular guest author, Renée Elizabeth Mineart. 

I realised this week that I have a character flaw. Probably, one of many, if I’m being honest, but let’s just focus on the one for now.

In my last post, I shared the steps I go through to understand what an organisation is trying to achieve through testing and how their current testing model is being implemented. In this, the final blog in the series on increasing test maturity, I want to discuss how I get to the end goal of a mature test model that does what it needs to do.

This blog is the third in a little series where I write about my thoughts on increasing test maturity. Previously, I went into a bit of detail on the importance of wining the hearts and minds of the various stakeholders impacted by the change in approach.

In my last post I wrote about winning the hearts and minds of those people affected by the operational and organisational change that’s needed to increase test maturity. I discussed the emotional and psychological impact of change and how, in my experience, the behaviour of those people impacted by the change but who don’t support it, tends to follow the model proposed by Kübler-Ross. This model was originally hypothesised to recognise the series of emotions experienced by terminally ill patients after being told of their prognosis but has more recently been adopted by the change management community.

The thing I most enjoy about my job as a Test and QA consultant is delivering organisational change. This usually involves increasing test maturity and I’ve been extremely fortunate to have had the opportunity to do this kind of work with many clients - from multinational investment banks and utility suppliers to small software houses. Delivering organisational change allows me to be creative, operate on a macro scale, influence decisions and work with people on an emotional level. This is very different to, and is a refreshing change from, the regular testing, test planning and test management that is the bread and butter of a test consultant. I find it fun, interesting and challenging.

I hope you don’t mind if I divert slightly from the topics of User Acceptance Testing, Sprint Cycles and other software testing subjects, to discuss the very important topic of keeping up morale while in lockdown (a.k.a. being a bit silly).

User Acceptance Testing (UAT) is a vital step in the successful release of any new software. But why; why is this one stage so important?

We’re fortunate in testing that we generally follow a well-defined process, have clear role definitions and test tools to support us. Our test tools record activity, manage planned and current activity, and support communication between teams and individuals. This is in the form of bugs and passed & failed tests. The process is there to steer us safely through difficult periods of a project when many people around us may be making irrational decisions.

I’m not sure why but automated security testing is, without doubt, the poor relation to all other types of automated testing. The software testing industry has been trying super hard to automate functional testing for well over 20 years – and the results have been patchy at best. I see all sorts of attempts but it’s rarely questioned as a sensible aspiration, even in situations when the return on investment (ROI) is nowhere to be seen. We relish the thought of automating unit tests and even have whole conferences dedicated to test driven development. Automated integration testing is considered an absolute necessity for DevOps and Continuous Integration (CI). We absolutely love to have automated build, deploy test capability. Unless performance and load testing are automated we don’t even consider doing it. We even have automated code review tools. Why is it then that whenever I recommend automating security testing to my clients, it feels like I really have to sell the idea. More often than not, they choose to do it manually. And I’m always surprised when they do.