Tutorials SQAAnalysis is not just seeing the numbers and drawing conclusions from them. Like the developers, the SQA team should also take care of their documentation.
The SQA team should not only look at the application but also its documentation. Through the developer’s documentation, SQA team are given a glimpse of what the application is all about and how it is written. The notes attached to the documentation are especially scrutinized as it describes each specific function. The documentation is analyzed if they go with the actual written functions of the application.
But besides analyzing the application, the SQA team also has their documentation to deal with. In their documentation they place their analysis in actual test cases. The documentation is usually done while doing testing and once they found the problem; they place it in their documentation.
The documentation tells the actual effect of the problem they have found. Through this documentation, the magnitude of the problem of analyzed. Sometimes, the problem could easily be remedied but the eventual effect of the error is big. Using test cases, SQA should easily give the developers a picture on how dangerous an error could be.
Test cases are the most efficient tools for analysis. Using test cases, everyone could see how important or dangerous a single glitch could be.
Two documentations – the developers’ documentation will give the SQA team a glimpse of the actual application. On the other hand, their test cases are the concrete example and result of their careful analysis the documentation and the actual application.
Analysis is always found in every stage of the application development. But that does not mean analysis needs to have the same intensity all over. The SQA team needs to work on the plan on the start. In this stage, they would just work on what will be the effect of the standard rules and applications they will have to do.
It is just a light consideration between developers and the SQA team. As we have said, the discipline of quality assurance especially in the software has been developed for years. Any applications that are being considered already know what standard tools, applications and standardization will be used.
The serious analysis comes in when the actual coding of the application starts. The SQA team works closely with the development team. Although the SQA does not have any direct influence from the developers, they basically look out on everything the developer does to the intended application.
If they see something wrong about the development of the application, they show it in writing by creating a case study. Through the case study, they can actually show how it could get really bad based on the actual problem of the application.
Generally, analysis in SQA comes in really easy, and then it gets hard because of the application ending with a simple conclusion. If the actual analysis of the application becomes too simple such as telling them what is wrong and what should be done, they are going against the principle of getting the right application for the user. Through test cases, they show their concern not only for the company but to the intended users as well.
First Page: SQA Analysis
