The Software Development Life Cycle (SDLC) is changing beyond all recognition. This has been driven by the increasing pressure on banks, insurance companies and other institutions to be digitally innovative and to deliver quicker. This is having a direct bearing on the SDLC.
In the past, the ‘test cycle’ was an essential part of any project normally taking place after development was considered complete and before handing over to the User Acceptance Testing (UAT) teams. The testing cycle would normally take a number of months but as project delays occurred, the test cycle was normally the part squeezed between development delays and a delivery date.
There was a time when delivery dates were more ‘fluid’ and these dates might be stretched to give the testing cycle the time it needs to complete, however, with delivery cycles in the digital age, this is no longer an option. Now delivery dates are generally a ‘drop dead’ date upon which an organization will expect to deliver without fail. Failure to deliver can result in serious reputational damage but what does this then mean for the level of testing that is required?
Ultimately the testing cycle must become merged with the development cycle such that existing code is tested continuously for errors as changes are made and changes are made as soon as possible after they are implemented and is a key to offering agile delivery.
This testing needs to cover functional and non-functional areas.
The goal at all times is to have a set of software that is continuously being developed that can be released at will, however, prior to that release, a final ‘validation’ is done to ensure that what is being released is ready for show time.
So we come to Software Validation as being a key step in the agile (and even non agile) SDLC. Software will move through the gate from prototyping to development (including continuous testing) based on a proof point. This proof point is the validation of the software deliverable moving into the development process.
When a minimum viable product is ready, the next gate is to user acceptance testing. Again, the software is validated prior to being accepted by user acceptance.
Once this cycle is completed once, a continuous delivery process can be maintained by new requirements entering development and development providing a validated set of software to UAT when a release is deemed necessary which could be at any time. As the cycle is repeated, greater levels of trust are built up by this validation exercise.
So is validation just testing?
It could be, but should involve a lot more than simply functionally testing that the software passes all the functional tests:
- Non-functional testing: does the software react well to error situations that may arise?
- Systems Usage Reports: is the software still using back office IT systems in a valid manor?
- Capacity Planning Reports: what load will the new or changed applications place on the back office IT?
These are also key components of how well any new or changed software will be accepted by its users. Ostia’s Portus technology enables automated and comprehensive validation of software that goes beyond just testing.
See case studies, whitepapers and more on our resources page.
Learn more about what we offer on our solutions page.