Previously, we looked at whether the system functions like it’s supposed to and now we’re going to be looking into more of the non functional testing aspects. We are looking at answering such questions as related to meeting the business objectives from a performance standpoint, and also testing load and stress in terms of how much the software can handle. The load includes number of processors, how many users, and then the stress aspect is what would happen if we exceed the load capacity, how does the software respond, what goes on when the software starts to fail. Other tests besides load and stress test are the following: tests of scalability, verification, interoperability, disaster recovery,simulation, privacy and user acceptance. These all fall under the non-functional types of testing.
Scalability testing: This type of testing is where we are looking at if the software environment is one in which the software can grow or is it limited to just the existence of the the existing structure. Obviously, we want to have a structure to allow for growth of the business and growth of our organization, so mostly we want to be forward thinking and create a software that allows forward momentum.
Verification testing: This type of testing is where we want to verify the security requirement. We want to check that the security is going to support the installation of the software, so that it can be implemented well.
Interoperability testing: This is the type of testing is associated with the fact that the application won’t exist in a vacuum and rather, instead that there are all kinds of other systems, functions and other applications as part of the overall. We want to find out if our application fits in well with the other components. One of the best ways to make sure your software is inoperable is by following standards. This is especially important when a company is trying to have their developers following proprietary methods rather than the methods which are more standard, then the software will have more difficult time associated and working with other components which are following the basic standards.
Disaster recovery testing: This type of testing is if we have a software failure, will we be able to recover the application and its data? So, it comes down to can we restore it quickly enough? Especially concerning is for the restore to be done quickly enough for it to be valid or does the organization suffer a loss because the downtime surpasses the tolerable levels. How many processes would be lost in the disaster environment before the restore can be accomplished. All these different aspects would have to be checked.
Simulation testing:In addition to the other forms of testing, we also have tests to run in a lab where we are checking on how it functions when out of production. The simulation testing is when we give as close to real-world conditions as much as possible. Then, to test for what it does and how it performs when no longer in a lab situation. We’re still trying to have controls on the product, by still having it at the lab, but get it as close to what it would be going through when on the production line and out to the user. But it’s a sure sign that I don’t have a good match when we have a software that flows well in labs but doesn’t do very well in production.Very obviously, there’s going to be some sort of variation between the lab environment and production environment.
Privacy testing:This is the type of testing that is meant for making sure the sensitive information of our user will be cared for properly, so that when we put the product in their hands and so when they working with the application, are the users being protected?
User acceptance testing: All other testing should be completed before turning it over to the user. So, we’ve gone through our unit testing, we’ve integrated, we’ve done our regression testing, really this is one of the final things that we do before turning over this product to production, is we do our acceptance testing. Often we want to make this as close to real-world usage as possible, because we want our users to have confidence and we want to have confidence in the product that we’re producing