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.
So, what is the best software testing technique for my project? Hmmm, tricky one to answer without looking more closely at your project. There are many factors that determine the software testing techniques you’ll need to employ.
One of the most common causes of software failure and the reworking of code is poor requirements. Implementation of best practice for requirements analysis, specification and validation can have a major impact on application delivery schedule, budget and overall quality.
How do you know if your testing is meeting your business objectives? Not having production incidents may be a success factor but that’s only a small part to testing. Conducting an assessment of your existing testing procedures and practices is key to establishing the actual current state of testing within your business. Doing this will provide you with a tangible roadmap for implementing recommendations to meet your company’s quality objectives.