SQA Planning
Planning is one of the most important aspects of Software Quality Assurance. The entire operation of the SQA team depends on how well their planning is done. In smaller businesses, planning might not really dictate the flow of SQA but in larger businesses, SQA Planning takes on center stage. Without it, each component or department that works on the application will be affected and will never function.
In gist, SQA Planning tackles almost every aspect of SQA’s operation. Through planning, each member and even non-member of the SQA team is clearly defined. The reason for this is very simple: when everyone knows their role and boundaries, there is no overlapping of responsibilities and everyone could concentrate on their roles.
But SQA Planning is not only a document that tells who gets to do the specific task. The stages in are also detailed. The whole SQA team will be very busy once the actual testing starts but with SQA, everyone’s work is clearly laid out. Through planning, the actual state of the application testing is known.
Again in smaller businesses, the planning maybe limited to the phase of the application testing but when outlined for corporations, the scenario changes and only through planning that everyone will know where they are and where they are going in terms of SQA.
SQA Planning is not just a simple document where objectives are written and stages are clearly stated. Because of the need to standardize software development ensuring the limitation of error, a scientific approach is recommended in developing an SQA plan. Certain standards such as IEEE Std 730 or 983.
SQA Plan Content
An SQA Plan is detailed description of the project and its approach for testing. Going with the standards, an SQA Plan is divided into four sections:
• Software Quality Assurance Plan for Software Requirements;
• Software Quality Assurance Plan for Architectural Design;
• Software Quality Assurance Plan for Detailed Design and Production and;
• Software Quality Assurance Plan for Transfer
In the first phase, the SQA team should write in detail the activities related for software requirements. In this stage, the team will be creating steps and stages on how they will analyze the software requirements. They could refer to additional documents to ensure the plan works out.
The second stage of SQA Plan or the SQAP for AD (Architectural Design) the team should analyze in detail the preparation of the development team for detailed build-up. This stage is a rough representation of the program but it still has to go through rigorous scrutiny before it reaches the next stage.
The third phase which tackles the quality assurance plan for detailed design and actual product is probably the longest among phases. The SQA team should write in detail the tools and approach they will be using to ensure that the produced application is written according to plan. The team should also start planning on the transfer phase as well.
The last stage is the QA plan for transfer of technology to the operations. The SQA team should write their plan on how they will monitor the transfer of technology such as training and support.
SQA Planning Standards
A special section for standards should be dedicated in SQA Planning. Before anything else the “rules” for checking the application should be laid out. When the standards are laid out, everyone will have a reference for checking the application.
The following are the standards that should be laid out in SQA Planning:
Documentation Standards – The SQA team should establish the standards on how the documents should be built.
Design Standards – The SQA team should identify the design and approach the developers will be using in developing the application. Since they are not the once who will be determining this standards, they have to work closely with developers.
Coding Standards – The developers will inform the SQA team regarding the coding. Using this, the SQA will know if the application was built according to the actual code.
Commentary Standards – A special section should be dedicated to the comments inserted in the code.
Testing Standards – The software and tools that will be used to test the application is written here. Aside from the software and tools, the approach on how the tests will be conducted is also laid out.
Metrics – The measurement that will be sought after the application is detailed here. The SQA team should clearly lay out what are the metrics they will be using in SQA.
General Approach – Lastly, the SQA team will write in general how they will monitor the development of the application to ensure compliance with the expected standards.
SQL Plan Style, Responsibility and Medium
The SQA Plan is basically a report that tells the clients who will receive the application what the SQA team will do to ensure that the application will live up to their expectations or maybe more. The output of SQA Planning is a written report distributed to the client made by the SQA team of the software development company.
The responsibility of creating the report is of course made by the SQA team. Depending on who handles the SQA for the application, the client should be able to communicate effectively to the SQA team so that they can update them regarding their expectations from the application.
The written report should be distributed either through paper or electronic transmission. The client and the development team should have a copy of the SQA plan. Because of this, the client will have a clear view of what to expect from the application. Developers on the other hand will also have an idea on what will be the actual benchmark in developing the right application.
Through the detailed SQA Plan, everyone involved in the project will know in advance how the application will work in the actual environment. From the planning to the technology transfer stage, the SQA team will set the benchmark on what the application should be. Through the detailed plan, everyone will know what to do and what to expect from the application if they are done according the written plan.
