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.

One of the perks I’ve enjoyed about being a consultant is that I’ve been able to work in a number of different organisations in a range of roles. I’ve had the pleasure of working in some very small private companies to massive companies with offices around the world, as well as a number of public and government organisations, again both large and small. One would think that each of these different environments would have their own unique challenges, and they do to a certain degree, but you’d be surprised how many things are exactly the same across the board.

So, the big question is ‘Why Test’? Let’s face it, we do take it for granted that things just work or at least should work all the time. But products, services and applications are generally all thoroughly tested before they reach you, giving you a great user experience. It’s very easy to take things for granted, like taking a flight; you simply book your flight online, print or download your tickets and you’re off… But in the background, there’s a million other things happening you probably don’t even realise. So let’s start with the basics, your plane will have been pre-scheduled and have a flight time allocated, but this is done months before you’ve booked your flight, so the number of passengers, meals, drinks, cabin crew, ground staff, the amount of aviation fuel required (based on plane weight incl. luggage etc.) the wind direction and general weather are all unknown until pretty much an hour or so before take-off. So, there’s a lot of variables that need to be monitored and taken account for before you jet off to sunnier climates.

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.

Change is amongst us, we must embrace the new Digital era and rather than see change as a challenge, reverse those views and see it as an opportunity to grow and expand. It’s a fact that Digital Transformation (DX) is at the top of every companies to do list. Whether that be a partial or full DX change, companies today are facing a dilemma; don’t change the way we work and the infrastructure we use or be left behind in a fast-changing world. Today we face a couple of big challenges, staying ahead and on top of new technologies but at the same time provide outstanding customer experience. To be clear, DX is the process of using new or modified business processes to meet the changing business and market requirements by the use of new and advanced technology.