Regression testing is something that sounds so simple, so logical and an activity that should be obvious to what it entails. Yet time and time again, it is something that can cause problems for projects and software delivery. Usually in the time it takes to run the tests, inappropriate tests being used for regression or the very fact that there may be no regression suite to even execute.
A functional requirement specifies a function that a system or system component must be able to perform. Probably the easiest way to explain ‘non-functional’ requirements is that they specify all the remaining requirements not covered by the functional requirements. Non-functional requirements specify the system’s ‘quality characteristics’ or ‘quality attributes’. Two products could have the same functions, but their attributes can make them entirely different products. A Rolls Royce has more or less the same functionality as a Lada but many different attributes!
The Agile manifesto states that you should value working software over comprehensive documentation, but as we all know, this does not mean no documentation. If you’re following an Agile approach for your programme of work or project then we would always recommend considering and documenting your Agile Test Strategy. Here are three things to consider when creating yours.
Within every organisation there are a number of documents that have a hieratical order. When it comes to testing you would expect to find the Test Policy document at the top of the tree; this document is only a couple of pages long but does at executive level spell out the quality needs of the organisation and gives the vision of what is expected of every project. This document is owned by the CIO or IT Director and should be mandated to ensure every programme and project works to the same expected standards every time.
Ever heard the expression ‘More speed, less haste’? Acting too quickly and without due diligence, focus and attention to detail will result in avoidable mistakes and thus require even more time to complete the task satisfactorily.
What if Entry Criteria for Load and Performance Testing are not met?
A little while ago I wrote a blog called ‘What are the entry criteria for Load Testing?’.
As we rapidly approach the new spring season with vigour, there's never a better time to revisit areas in our work/home lives and look at applying a fresh approach to make improvements.
The same can be said for software testing and exploring fresh ways of being innovative in the use of processes, tools and methodologies applied. The new financial year can bring new opportunities to invest in improvement initiatives and the fresh new spring season can often give rise to renewed energy, open mindsets, renewed commitment to try and apply new strategies and look to reduce none value-add activities.
Even with the best will in the world, we all forget to do something at some point in time. Whether that be something trivial like putting out the bins to forgetting to pick up the kids after school…. Yep, that has happened…
For all those budding chefs out there, the question will always be, do you follow a recipe for your meal or do you make it up as you go along? Now, creative and seasoned chefs will throw in the ingredients to produce delightful food, however for us less talented would-be-cooks, our results will be vastly different, and that’s the point. To get predicable results you’ll need to follow a process (recipe) to gain the greatest chance of success - just like adopting an automation test framework.
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.