So, your great new idea has been turned into an app, well done!
Now you are ready to launch! Or are you?
What testing has been done? What proof is there? What scenarios have been considered?
Are you going to come out shining in glory, or hiding from glare of the spotlight?
Here at CIBIS, we take testing very seriously. All the code we develop and put into production is built using industry best practice and techniques built up over years, and this includes the lowest level of testing – unit tests. You don’t usually see this level of testing, but it is what makes CIBIS code and applications as reliable and secure as they are renowned to be.
Things don’t stop at the micro-unit level though. Good documentation is essential to good software development, regardless of whether you are using a waterfall or agile methodology. Two essential documents that evolve from the Business Analysis, Design and Project Management aspects of the development process are a Functional Specification, and a Detailed Requirements Specification.
The Functional Specification is a more high-level and sometimes broad-brush description of the software system from the outside perspective – what does it do, what does it look like, what happens when this occurs are all questions that should have an answer in the Functional Specification.
A good, detailed Functional Specification allows us to perform detailed Functional Tests, where we can demonstrate to you that the system behaves and operates exactly as it was described and is supposed to.
A detailed Requirements Specification is a lower level document, which describes (sometimes in great detail), what is required of the system. Commonly, a number of requirements go together to fulfil a functional specification.
A good, detailed Requirements Specification allows us to perform Requirements Traceability Testing. We can track every documented requirement to an individual test that demonstrates that the requirement has been met.
If your app is part of a larger system (and they usually are), we will also conduct integration testing to ensure that the functionally, your app and the integration pieces also perform as intended when communicating with other systems.
Finally, we might also recommend stress tests, or at least performance and load testing. While having your server go down under the load due to unexpected demand on launch day might sound like the sort of problem you would like to have, it is really only good for bragging rights. No matter which way you look at it, an event like that represents a lack of contingency planning, poor estimations, and an absence of the considerations of performance under load and can only result in “egg on face” and potential lost revenue.
Have your software developed by people who take a “cradle to grave” interest in their work, and whose professional approach ensures you will get exactly the result you wanted at a minimum by ensuring testing and proving “correctness” are an integrated part of the development process.