Last week we completed our discussion of how the proposed solutions to the Malthusian Catastrophe are only postponing the inevitable. Unlike development which can always go forward and create new code, testing always has a regression component for any code that integrates with existing applications. This adds to the testing effort but doesn’t necessarily add value.
The proposal we outline here is not entirely new although we are carrying it to another level. Portions of this are being done and have been done for years. However, we are suggesting a more intense and more rigorous application.
Today, we find many people integrating applications to build something. They can borrow code or entire applications and make something new from it. The statement “there is an app for that” has never been more mainstream. However, everything that is borrowed or utilized may (not always) need to be tested to some level so we can trust that it does what it says it does and operates the way we need it to in our new configuration. Add to that Security concerns dealing with applications that are not under our control and may not have been built to the same level as we need and the chance of our new application failing increases substantially.
We are recommending that a library of code pieces are created that have the following characteristics:
- They carry out a known function under known conditions.
- They have been tested thoroughly by an independent entity to prove number 1.
- They are secure from being compromised.
Number 2 above may have levels of testing just like there are levels of code today depending on the risk of the application for which they are being used but the same process applies.
People developing applications would be able to use this library secure in the knowledge that the three points above are guaranteed.
Next series: Communication in Testing,
Leave a Reply