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.
I am very fortunate to have spent time on many projects/products with lots of customers and so I wanted to write a series of articles to go through my experiences and what I have seen. This blog is the first in the series and will look at modern development, Quality Assurance and Quality Control.
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.
Testing quite simply is the backbone of every project, whether you agree or not it’s not hard to state that testing has a place in each part of the System Development Life-Cycle. Employing a poor testing methodology will lead to the production of an unstable product and most likely one that will cost you more money and development time. Whether you decide to go Waterfall, Agile or DevOps it is essential to have a plan, especially a test plan, in place to ensure that the product is delivered in a robust and stable state, on a predictable timeline.
In an ever changing and fast paced world, things need to be done quicker. Not only to save costs but consumers need products and services at a touch of a button and assurances that they all cater for their needs first time without fail. Companies are faced with many dilemmas; costs, do a project on the cheap and risk delivering a shoddy project. Time, do it right but take too long and your market saturation will be behind your competitors. Quality, rush a project out the door and risk introducing operational and productions defects. So, is there another way?
Performance testing is simple, right? Well, those who do it will beg to differ. There are some performance testing basics you need to get right first before embarking on the journey.