Lack of Appetite to Test
The most debilitating and possibly biggest challenge I face when it comes to load testing is the lack of appetite to load and performance test from the senior project stakeholders.
Lack of Appetite to Test
Before you can begin to improve software testing in your organisation, you need to refresh yourself as to why testing is so important. It’s very easy to take things for granted; take your car for example, you get in, start it up and drive. You never think it’s not going to start or breakdown. There was a time though when cars were poorly made, forever breaking down and a real source of disappointment. Now, cars are largely fault free thanks to advanced engineering and software design and of course very thorough testing. There are millions of lines of code in each modern vehicle, and each line of code has been tested many, many times under many conditions to ensure a fault free drive. Some cars, as I write this article are achieving Level 3 Car autonomy - drivers are still necessary in level 3 cars, but are able to completely shift "safety-critical functions" to the vehicle, under certain traffic or environmental conditions.
As you might have realised the modern world is moving and developing at an alarming pace, change within our daily life is rapid, and just about everything we do in some way has been enabled by a computer and each application has been developed and (hopefully) tested. The desire to do more and do it quickly for less is forever in demand. Change is here to stay and organisations need to be ready to cope with the ever-increasing mandate for speed of delivery and first-class quality.
It’s fair to say we’ve all been in a situation where we’ve encountered a regression issue; whether that be taking your Christmas lights out the box having not used them for a year, only to discover a tangle of wires, you unpick one tangle and that leads to another one forming, or when you tick the box for paperless bills from your well-known utility company only to still receive paper bills…. some two years later.
When testing, there are specific project phases, these are all very well-known and well documented. However, software testing is not a single activity per se, but a concatenation of planned activities that need to be executed, along with the software development activities to ensure that a product is delivered to cost and time, without any errors. The following article aims to explain how testing fits within the life cycle of a project and the benefits of early testing and shifting left the quality as early as possible in the software testing life cycle. The following provides a high-level overview as how to plan your testing activities.
Adoption of new working practices and methodologies has meant that organisations are constantly challenging themselves to get products and services to market faster than ever and in doing so are now having to think very hard how this can be achieved. We all know that first to market gets the spoils, so there is a lot at stake getting the delivery model right. Test Automation is just one way of speeding up your project delivery and in doing so building up a regression pack of test scripts that can be run with little effort in a short amount of time.
Tis the season for scary stories. Halloween brings us plenty to be scared of, especially if you work in IT and especially if you’ve not taken testing seriously…..seriously..!!!
So, what exactly is a disaster? The word ‘Disaster’ is widely used in our modern-day language, Crystal Palace FC would use it to sum up their first four games of the 2017 season, people of America use it to report on Hurricane Irma and Bake Off would use it to describe a soggy bottom…. So, when we come to talk about software the same rules seem to apply. Whether a software bug disrupts an End Users ability to perform their everyday tasks, or a bug makes your online retail outlet fail to deliver goods, or worse still your data is compromised like what we have seen with the Equifax and their 143 million customers. In all cases these software disasters could have been prevented by better testing.
To explain the difference between Black Box Testing and White Box Testing, simply put, if you think about a car, you have two types of people, the driver (black box) and the mechanic (white box). The driver doesn’t really need to understand how the engine works to drive, just press a few buttons and levers and turn the wheel and you are off. The mechanic however, lifts the hood and tinkers with the engines to make the car go, looking at the internal mechanisms, following the flow of petrol into the engine right through to the output gases from the exhaust.