As a QA an important part of your tasks consists of continuous improvement of your Test and delivery process. Being a key member of your organisation you will have to participate in different workshops, meetings and trainings in order to figure out the best balance you and your team can achieve within the classic challenges of Cost Time and Scope

What is PDCA ? SQA ?

According to Wikipedia : PDCA (plan–do–check–act or plan–do–check–adjust) is an iterative four-step management method used in business for the control and continual improvement of processes and products. It is also known as the Deming circle/cycle/wheel, control circle/cycle, or plan–do–study–act (PDSA).

Software quality assurance (SQA) consists of a means of monitoring the software engineering processes and methods used to ensure quality.[citation needed] The methods by which this is accomplished are many and varied, and may include ensuring conformance to one or more standards, such as ISO 9000 or a model such as CMMI.

Based on the definitions above it is obvious that the PDCA method is — regardless of your organisation strategy — a good fit for your overall quality assurance approach to improve the delivered products.

PDCA Cycles

Below each cycle Plan — Do — Check — Adjust will be explained

Plan

The first thing to do is to collect and analyse data by collecting information from multiple projects in order to identify the positive and negative points of each project at every phase ( design, development, testing…). For each negative point, a root cause analysis is performed in order to determine the problem source then each problem source is listed and attached within a category (Management, Skills, Communication…).

Once your document with all the problems is defined and fixed, it is the subject of another meeting to discuss the suggested solution with details on how they can be achieved. Please note that in most of cases it is recommended to define low or short term steps in order to invest less in the solution instead of wasting time/money on a solution that may not have a bigger impact.

At this point each of your Problems is linked to a Root Cause which is linked to an Action or a solution. You shall have now an actions list that is planned with expected targets within a fixed time.

Congratulations you have just crossed a major step

Do

This step includes a lot of communication with the stakeholders in matter of the implementation of each solution. all the roles and person who are involved in our action plan must execute and implement the suggested solutions, actions with a reference to our document.

The ‘DO’ step may usually take longer depending on which phase the actions are considered however each person intended to participate must be supervised by another person or team in order to make sure that actions are implemented.

Check

Now it’s time to verify that the implemented actions and solutions resolved the problems. In order to verify that it is mandatory measure and compare with precise KPIs the new performance or efficiency compared to the old ones collected in the data of the step ‘Plan’.

But please remember before even starting comparing the results , make sure that these results are based on the implementation of the new actions and not due to external conditions or deviations from action plan.

Adjust

Once all data and actions are verified, you will usually end up with OK or KO results. For positive results it’s time now to the management to standardize document and apply these actions in the overall process and make sure that these actions are implemented when necessary.

For KO actions then they will be considered for the Next/First step again which is plan in order to be improved and enhanced.

A complete example :

There is nothing better than a complete example to master the cycles . Let’s assume the following : The client has declared that he found many defects in a project that were not found by the testing team, therefore the problem is : high bugs rate is discovered by the client.

Plan

With the root cause analysis and bug reviews to decide in which phase the bugs could have been detected, we found that the testing team lost partially control on the software due to multiple modifications by developers in the last minute within a tight deadline. The second problem is that other issues are runtime bugs within specific conditions causes the system to break down.

To sum up this was the result of plan section

• Problem 1 : Deliveries not fully tested -> Major last minute commits -> Action 1: Automated regression testing. Action 2 : Project manager must organize tasks and planning to avoid major modification by the end of development.
• Problem 2 :Specific inputs break down the system -> Only functional testing is run -> Action 3 : Use of code analysis tools Action 4: Code reviews are mandatory Action 5 : Implement a data driven testing process.

Do

Communicate Action 1, Action 5 to testing team and assign a moderator to ensure a follow up.

• Action 2 must executed by project manager and verified by development team and also by quality department or operations manager.
• Action 3 and Action 4 are handled by development team and a senior developer or software architect must supervise this action.

Check

At this point the software has been delivered to the client and a feedback is received. Now it is possible to measure and compare the rate of bugs found by the client in this version compared the bugs found in the previous version without our actions.

For example the client has still found some defects, but after analysis only bugs with specific inputs were found. Basically the Action 3,Action 4 and Action 5 did not resolve our problem and we only resolved 50% of problems which is somehow good as a start.

Adjust

At this point the management and testing leaders must standardise the automated regression testing (Action 1) for each similar project and the management must be compliant in their planning to the action 2 and prevent major commits at the last minute.

For the rest of the actions, it’s the job of another Plan phase.

Conclusion

There is no perfect guideline to reach the highest quality product with the lowest cost and delivered within the shortest delivery time. However with multiple workshops and “Digging” into your current process with an intention of improvement sooner or later you will reach a balance or reference process that is achievable by your company with the consideration of Cost Time and Scope.