Common Quality Standards in SDLC

If Common Quality Standards for an Software application is followed or practiced in the Quality Process then a lot of bugs and cost can be avoided.
It has been some time working with a software firm in the Quality Assurance Team and over the period of time could notice that there were some known bugs while delivering the product to the client and one of the reason being communication gap, since we were a small team then could not realize them but when we started growing we had all these problems cropping up.

So we took up the challenge to create a process which involves quality from the beginning of the SDLC which yielded results and would like to share with all of you and this is not a generalized one i.e all the process are dependent on the company so feel fee to change them where ever you want and us it.

We all know that in a Software Development Life Cycle we have different phases and also different models or methodologies being followed like water fall, iterative, Rapid, Agile and V Model to name a few. In any methodology if we do not ensure some method of quality in each phase than we end up creating more bug than which ought to have if any.

Below are the different phases of development and what all should be there in each phase from a QA perspective

Requirements gathering Phase

During this phase the gathered requirements should be verified to see that they are true and meet the user/client needs.

The requirements captured are to be Complete, Correct, Precise, Unambiguous and clear, Consistent, Relevant, Testable.

Analysis Phase

It is always better at this stage to suggest any changes or add a new feature which will help improve the application (without affecting the estimates and cost of the project). This will help a lot in reducing many of the bug’s the QC/Client’s reports later. To do this, the Team’s should be well knowledgeable in the project and requires thorough analysis of the project.

Design Phase

During this phase the design/prototype should be verified to see that the design achieves the objectives of the requirements as well as the design being effective and efficient by design walk throughs, design inspections.

The QA team should come up with the Test Plan mentioning all that will be carried out in testing

Coding Phase

During this phase all the laid down coding standards should be followed strictly, following of UI standards, naming conventions to be accurate.

The QA should come up with test cases using the requirements and also following what is been said in the test Plan

Testing Phase

All the Test Cases should be executed for carrying out functional/integration/regression testing primarily and mark in the Test cases whether “Passed” or “Failed”.

Conclusion

If the two groups work closely together, the high level of risk at a project’s inception will decrease to an acceptable level by the project’s conclusion.

For further more detailed information on this topic look up
Quality Standard for a Software Project

How to address the issue of changing requirements during Testing Phase?

I have noticed that a lot of times there are changes to the FRD/BRD even after planning phase. This really is not a very good approach if the FRD is updated and sent to the QA team. There would be a lot of rework in the Test Scenarios and Test Cases and a lot of time is involved in this process. This may seem fine as long these changes are taking place in the Planning phase but imagine if the requirements keep on changing.

During the execution phase then there are many chances that the requirements may not be fully tested and a lot of UAT defects may arise. To avoid all these there are some measures given below which have been successfully implemented and saw the result which resulted in the UAT defects being decreased.

1. The QA team needs to make sure that the FRD received is the final approved version from the Business/Development team.
2. Any cosmetic changes can be accommodated during the planning phase.
3. Any functional changes should come as Change Request and should be taken care by during planning phase.
4. It should be communicated to the business or Development team that the FRDs should not be just updated for functional changes if this is the process then it should be intimated to the QA team
5. During execution phase any type of changes should come as Change Request. These changes can be by business to enhance any requirements or because of the defects raised by the QA team some functionality needs to be changed. This should not be changed in the FRD and the defect should not be cancelled.
6. Instead all the changes should come as Change Request and QA should estimate the  effort for planning and execution and should be taken care after the execution phase. The process may defer from company to company.

Conclusion: Any type of changes in the requirements should not hamper the work of the QA but should come in the forms of CRs so that QA team can analyze and have additional time to test.

Testing Activities in Different Phases of Software Development

Different types of Testing Activities take place at different phases in a Software Development Life Cycle (SDLC).

Most of the time in software development even after testing the application there is a lot of scope for the client to find bugs and report back which often makes the Testing team a scape goat at the time of reporting and later investigation reveals that there are flaws in the development, flaws in testing etc and at this time different teams question each other and causes a havoc kind of situation. In order to avoid these the following testing activities should be performed during the phases so that the final delivery is as expected by the client.

Requirements Analysis

Determine correctness
Generate functional test data.

Design

Determine correctness and consistency
Generate structural and functional test data.

Programming/Construction

Determine correctness and consistency
Generate structural and functional test data
Apply test data
Refine test data

Operation and Maintenance

Retest

The above mentioned are different phases and what a QA/QC can do in each phase to see that the application/software being developed is delivered in a stable and reliable way so that there are minimum bugs being reported by the client.

For complete information on each topic in detail please look
Testing Activities in Different Phases of Software Development