A question I get asked a lot is ‘What are the entry criteria for Load Testing?’.
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.
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.