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.
How to Keep Your Test Plan on Track With a Remote Team
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.
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.
Topics: Software Testing
Performance Testing Techniques - The Many Types to Consider
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.
Topics: Digital Transformation
How UAT Might Fit Into Agile
The Manifesto for Agile Software Development is based on twelve principles:
- 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
Regression testing is performed to verify that a code change executed in the software does not impact the existing functionality of the product. By regression testing you are making sure that the product works fine with new functionality, any bug fixes or changes with existing features. Previously executed test cases are re-executed in order to verify the impact of change has not adversely affected existing functionality.
Like other engineering principles, software engineers should be responsible for delivering high quality, bug free products that work under all conditions. I wholeheartedly agree that developers (and the whole team) should be accountable for product quality and there needs to be a mind, and culture, shift so that the responsibility of quality control is not abdicated to the testing team.