SQA Approaches and Methodologies
A scientific approach should have methods. As a scientific process, a stage or a step should be established or used to ensure the final product is according to the user’s specifications. The method is usually determined through the wishes of the clients, the available manpower and circumstances.
It is not that the clients specify the actual method for a scientific approach but the client’s provider takes into consideration the need of the clients. Using the facts and data provided by the client, the method for developing a product will be established. Using the experience and available data a method is determined and executed.
In SQA, the client’s need for a better application is established. But a good application is not the only need of the client. There are metrics that an application should meet and anything below par is not good for business. The SQA team should ensure the metrics are reached by constantly monitoring the development process while giving feedbacks to the developers. The SQA team is there to ensure that the process is done correctly to reach the needed metrics.
To ensure that a proper SQA is done, the SQA team should select a proper methodology. Selecting the proper methodology is quite a challenge. However if the proper facts is laid out, the SQA team should be able to select a good SQA methodology. On the other hand, the factors are also determined before hand so that the methodology will be known. Since SQA is an evaluating process, it reacts to the available information.
Why Not to Use a Methodology
On the other hand, there are SQA and software engineers who have doubts on the importance and use of an SQA methodology. Their reason comes from the fact that the SQA methodologies and approaches are very specific. Since there are very specific and strict, it does not give any room for additional information.
There are also developers and SQA managers who develop their own type of software quality assurance methodology based on their present situation. Again, the reason for that is that the methodologies are to strict that any creativity of software development is not allowed.
A waste of time is also a major source of disregard from software developers. Instead of determining the methodology, the developers focus their time on other things. The proof of the usability of the methodology of SQA is almost non-existent. There are a few who have tried to prove that having an SQA methodology makes worth more efficient but they are usually associated with the general information and a small part of the text is dedicated to the methodology.
Last but not the least, the methodology for SQA is just a waste of time. This is true especially when you’re trying out a new methodology for software development. It’s always a gamble to try out something new even though they have been tested in simulated environments. It all goes back to the fact that the SQA methodologies are very specific and the possibility of going out of what is written is not a good thing.
The doubts about methodologies always comes back to the fact that SQA methodologies are very specific and they can’t go out of other functions or adapt to new things.
SQA Methodologies/Approach Factors
Any SQA company could select an approach of their own. However, the team should consider some factors before they could use an approach. The quality of the evaluation could be questioned and ineffective when these factors are not considered.
Software Development Life Cycle (SDLC) Methods – The SDLC methods dictate how the application will be developed. Each SDLC have their own set of applications and recommended frameworks for software development. The SQA team should take note of this factor above everything else since this will reflect how they will approach the SDLC as well.
Cost – If the SQA team is given a free range of budget, they could employ some of the most powerful testing tools developed. This will enable faster software development and ensure better checking of the application. But that is not the case; everyone has to live on a budget including the SQA team. They have to look for the ideal tool for proper evaluation at a better price. If nothing comes up, they have to prepare and ensure adjustments to the approach are made so that the expected performance is met.
Expertise – Last but not the least, the SQA team should know their capacity in handling the tools they will be using. Some of the tools are GUI based that it could be easily handled by any SQA however; the most efficient tools are also the most complicated. So the SQA team should know what they could do. Most SQA methods employ specific tools for the methodology to be very efficient.
Types of Methodologies
Analysis and Static Defect Detection – this approach looks for the possible defects of the application by collecting invariants related to their purpose to the application. Invariants are standard information that will execute in the application. Invariants are functions, values and additional information that instruct the application what to do. Using this approach the SQA team should know which invariant might not work. The tools look for the executable functions and invariants to test them for stability.
Prototype Testing and Checking – In this case we do not look for the bad thing about the application but actually the good thing. Negating the reason for checking could work especially when you are building an application wherein user input is very important. By checking the application response the SQA team will know if the application actually works.
Theory Testing – As the saying goes, “get them while they’re young”. Before the application is implemented, the theory and the thought of the developers regarding the application are scrutinized. Checking the usual format of their development plan, the facts presented are compared against previous information. Through this, the information is verifiable and results could be predicted. Regular testing tools are implemented. The only downside of this is the requirement of experience from the SQA team with corresponding documentation.
