SQA Project Metrics
The application is only as good as its numbers. It is a harsh reality but everything has to come down to the numbers. Although we can enumerate tens or hundreds of features in a single application, it will all be for nothing if the metrics do not live up according to expectation. The SQA team should ensure that the expected metrics will be posted. At the same time, the SQA team should also select the right tool to gauge the application.
There are hundreds of applications that can measure the application but it is quite rare to find the right application to provide the right information.
To fully gauge the software’s ability, a number of metrics should be attained. A regular testing application will just show errors of the software as well its ability to withstand constant and heavy traffic. However when you take a closer look at the application, you will realize these are not the only numbers that you need to know if the application actually works. The SQA team should know the numbers that needs to be shown to the developers and to the management.
Metrics
In the previous chapter, the metrics provided were referred to the SQA’s ability to influence the application. This time, the metrics will only refer to the application alone. To gauge the actual application, the metrics are divided into four categories. Each category has attributes with specific metrics ensuring that the attribute is achieved.
Quality of Requirements – These set of metrics will show how well the application is planned. Among the requirements of quality first and foremost is completeness. Remember that requirements are geared to answer all the problems and concerns of the users. Therefore, its main aim is to answer all the concerns.
One of metrics found in this category is the completeness of the requirements. As this is in the planning stage, the ability to be understood is also important. The SQA team should gauge if the document are well written and useful.
Lastly, the requirements that were written by the developers and the intended users should be traceable. No one can just place a requirement out of whim since each of the requirements should have a logical root or explanation.
Product Quality – These set of metrics will gauge the ability of the developers to formulate codes and functions. The SQA team will first gauge how simple the application has been written. The software has to be written in a simple manner. It might sound contradicting that even a highly complex application could come in as simple.
What the SQA team is looking for from the application is the logical formulation of the codes. When the application is logically coded, it has two repercussions which are also gauged by SQA.
First is the maintainability. If the application could be easily understood, troubleshooting is very easy. Reusability of the application is also emphasized. Since the codes could easily be distinguished, developers can use parts of the application to be implemented to another program.
The documentation that supports the application is also gauged and the comment within the coding is also gauged. It is not important if there lots of comments but what is important is that the comments are clear and could be found in every function.
Implementation Capability – The general coding behavior of the developers is also gauged by the SQA team. The metrics used in this classification is based on the SDLC used by the developers. The SQA team will rate the developer’s ability to finish each action in the stage of the SDLC on time.
The staff hours are rated according to the need of the stage. Each phase of the SDLC will have their time requirement – some will just need a day or two while others will require a month to finish. The time required in every stage is set by the project manager.
Aside from the time required for completion, the developers are also rated if they ever finish a task at all. There are tasks that are necessary for the application to run while there are tasks that could be offset by another task. Although that’s a convenience, it will actually trigger a domino effect so the whole operation could be placed in jeopardy.
Software Efficiency – Last but maybe the most important is to ensure that the application do not have any errors at all. This is basically a major pillar to any application. Without errors, the software will never give any hackers a chance to infiltrate the system. Usually, the SQA team will develop test cases wherein the error is highlighted. The developers are then rated how fast they could locate the root of the problem and how fast they could built a fix to the problem.
These are the metrics that every software developer will have to go through. The better the rating, the better the application would work.
Selecting the Right Quality Model
There are so many quality models to choose from. Each of them has their own advantage and disadvantages. It is up to the SQA team to select which application that will give the clients a good idea how the application works.
In order to select a good Quality Model is no trick actually. Every application developed has a “core” or a feature that differentiates the application from other software.
The SQA team should just focus on that feature and look for the quality model that can fully gauge the feature. It is a very simple idea but will do wonders especially when the SQA team is trying to prove the validity of the application against the feature needed by the clients.
The only disadvantage of this technique is that the developers might be focusing too much in the feature. However, all of the Quality Models could easily gauge every aspect of the application. That means every SQA team can easily gauge the software without any problem.
Finding errors in the application is a great challenge to the SQA team. But with the right tools the software could be easily gauged and the application will work as expected.
