In my last post I discussed how a Testing Centre of Excellence can reduce cost and create efficiency in an organisation. In this post I will discuss some of the other benefits of a TCOE.
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.
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.
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.
Topics: Software Testing
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.
There are many different types of performance test – sometimes referred to as performance testing techniques. It’s not always easy to know which you need so this article aims to give some guidance on the performance testing technique you might want to consider for your system.
- Customer satisfaction by early and continuous delivery of valuable software
- Welcome changing requirements, even in late development
- Deliver working software frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the primary measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximising the amount of work not done—is essential
- Best architectures, requirements, and designs emerge from self-organising teams
- Regularly, the team reflects on how to become more effective, and adjusts accordingly
It’s interesting that despite the first principle being; ‘Customer satisfaction by early and continuous delivery of valuable software.’ UAT, as we have traditionally known it, doesn’t fit well into an Agile delivery model. Many Agile teams dispense with UAT and rely more heavily on the Show and Tell session to get customer sign off. In Scrum, this is done in the Sprint Review Meeting and involves a demonstration of the user stories that have been delivered (according to the Definition of Done) in the sprint. One of the objectives is to elicit stakeholder feedback.This is good practice, fosters collaboration and creates a high level of discipline while also meeting the objectives of the first principle. Product demonstrations should be interactive so that stakeholders have the chance to provide feedback however, I often wonder “Is this enough?”. Participants in the ‘Show and Tell’ and the Sprint Review Meeting should include, amongst others, the Product Owner, Stakeholder and Sponsors and Customers. However, in practise, I tend to find two problems;