Explore All About Corrective Actions Preventive Action (CAPA) Including Some Examples and Case Studies for Real-Life Applications:
Many times, we hear the terms Corrective Action and Preventive Action (collectively called CAPA) being used interchangeably but in reality, they are not the same. The definition and intent of each of these actions are very specific in the application.
What You Will Learn:
- What Is Corrective Action Preventive Actions (CAPA)?
- Corrective Action
- Preventive Action
- Difference Between Corrective And Preventive Actions
- CAPA Similarities
- When To Use Each?
- Processes To Identify Corrective And Preventive Actions
- Basic Process Of CAPA
- Tracking Corrective Or Preventive Actions To Closure
- Tester’s Perspective
What Is Corrective Action Preventive Actions (CAPA)?
In this article, we will discuss Corrective Action And Preventive Action in more detail – we will define each of these with examples, deep dive into the specifics, and look at some case studies for real-life applications.
As defined in the Merriam-Webster dictionary, the word corrective is defined as “intended to correct (to make or set right)”. Therefore, true to the definition, Corrective Action is a task that is identified to correct or fix a present ongoing issue or problem.
For those readers who are a part of any software development and delivery team, the most common Example of corrective action is the decision to deploy a hotfix on production to fix a production incident caused by the most recent production deployment.
As defined in the Merriam-Webster dictionary, the word preventive is defined as “something that prevents (to keep from happening or existing)”. Therefore, Preventive Action is defined as a task identified to prevent an issue or problem to occur in the near or distant future.
For Example, the process of providing impacted areas to the testers could prevent any unintended bugs to creep into production especially in the components that were otherwise deemed out of scope during the requirement planning.
Difference Between Corrective And Preventive Actions
|Corrective Action||Preventive action|
|Addresses a current problem.||Addresses a problem that can occur in the future (near or distant).|
|Intention here is to fix/resolve the problem.||Intention here is to stop this problem from occurring in the future.|
#1) Both Preventive and Corrective Actions are created to deal with issues of the past, present or future.
#2) The inception of Preventive or Corrective Action is from the same underlying processes as:
- Risk analysis and management process
- Root cause analysis process
- Retrospective process
- Reviewing organizational process assets like historical lessons learned, etc.
We will discuss these processes in detail in the next section.
When To Use Each?
Each problem or risk identified may have a corresponding CAPA. While looking to identify if a resulting action would be corrective or preventive – the rule of thumb to understand here is the intent of this action.
- If the intent is corrective in nature i.e. if the meaning is designed to fix the present issue then that would be called Corrective Action.
- If the intent is preventive, i.e. if the meaning is designed to prevent such issues to occur in the future then that would be called Preventive Action.
Processes To Identify Corrective And Preventive Actions
#1) Risk Analysis And Management Process
Risk is essentially the probability of a negative occurrence.
While performing a risk analysis, a project or activity is evaluated to identify the associated risks and the impact of that risk on the project/activity. This analysis is done as a part of the overall risk management wherein an appropriate mitigation strategy is created based on the impact and the probability of this risk occurring.
Each identified risk may or may not have a preventive or corrective action associated with it. The identified risks are mapped and grouped based on their impact and probability of occurrence. Priority is given to the risk that falls under high impact and high probability of occurrence bucket.
Let us consider an example to understand this further.
Let us assume that your team is about to release a new website and based on the unresolved bugs, and short delivery timeline, the team identified the following risks to the project if released:
- Risk #1: Search functionality on the website takes too long to respond and eventually will time out. Customers will see an error message indicating the timeout.
- Risk #2: The logo on the contact us page is not mobile responsive.
- Risk #3: The account registration process is not working. New users are not able to sign up
- Risk #4: IE9 customers (less than 4% amongst all customers) are not able to click on the Home page icon.
To prioritize the resolution, your team then maps these identified risks on the Risk Matrix as shown below.
In practice, Risk # 1 and 3 would be prioritized over Risk #2 and 4, as they are more critical due to their high likelihood of occurrence and impact.
Let us now develop risk mitigation strategies for the identified risks!
Risk Mitigation for Risk #1
- Optimize the Search stored procedure to return the results in less than 2 seconds. Assign additional dev resources, or reassign resources to complete this task before the release.
- Add pagination to the search results page, so that only 25 products matching the criteria are loaded at a time, thereby reducing the load on the server.
Risk Mitigation for Risk #2
- Fix the defect if the dev resources are available.
Risk Mitigation for Risk #3
- Assign dev resources, or reassign resources to fix this defect.
Risk Mitigation for Risk #4
- Fix the defect if dev resources are available.
#2) Root cause Analysis Process
Root cause analysis is done to identify the root cause of the past or existing problem. My all-time favorite method to determine the root cause is the 5-Why method.
What is the 5-Why method?
The 5-Why method is a common interrogative technique where the root cause is identified by repeating the question “Why”. This technique is very popular even in the manufacturing industry and was initially used in Toyota Motor Corporation during the progression of its manufacturing practices.
Let us consider this example:
Problem: Build failed in production and had to be rolled back.
Customers were not able to add items in cart to checkout.
Build deployment issue: One of the required stored procedures was not deployed. This impacted the add to cart functionality.
The instructions to deploy this particular stored procedure were missing in the manifest.
Developer responsible for that stored procedure development forgot to add the instructions in the manifest.
- Add correct and accurate instructions in the manifest for build deployment.
- Test the deployment of the complete build package as per the instructions in the manifest on another test environment and perform a regression test to ensure if the build is working fine.
- Introduce process for the Dev leads to review the complete deployment package plus manifest, at least 1 day prior to the production release.
#3) Retrospective Process
A retrospective is a review of past events and uses these events as an opportunity to learn from them. With regards to software development and project management, a retrospective can be done either at the end of a major release or at the end of a sprint or at any milestone of the project.
Based on the review, a number of relevant Preventive or Corrective Actions that would help to mitigate the risks associated with similar future projects may be identified.
#4) Reviewing Organizational Process Assets As Historical Lessons Learned
The explanation here is the same as the above point for the Retrospective process. The idea here is to learn from past mistakes or problems and apply an identified improvement to similar future projects.
Basic Process Of CAPA
Regardless of the processes used to identify the Corrective or Preventive Actions, the basic process or the approach remains the same. Let’s discuss the basic step by step process with an example from our everyday life.
Now let us apply this process to a real-life Example.
Almost every time I do dishes, I end up knocking off the dishwashing soap i.e. it spills over and the soapy liquid is all over the floor. The soapy spill is not easy to clean and is tiresome!
Tracking Corrective Or Preventive Actions To Closure
After an action, is identified as to whether Corrective or Preventive, the work is not over yet. The action still needs to be executed and finally completed and closed.
Tracking action points to closure is something that the teams often struggle with.
Provided below are some useful tips that can help you and your team in Tracking and Execution of the identified actions.
- Always identify the person accountable to execute the identified action point, and the person responsible to drive the entire initiative. Example: If the action is for a software project, then the person executing can be a developer and the person driving it could be the project leader.
- Ensure that there is a way to track the progress of the action. Depending on your organization, the way to track can range from line items in excel to using dedicated licensed software to track all the ongoing actions.
- Create guidelines for reporting Overdue action items. The guideline can be simple like if an action is not completed till or after 7 days of the agreed on the due date, then a formal report would be sent to the management team about this and the project team would be called upon to provide justification for why the action was not completed within the stipulated timeframe. More tiers can be added onto this rule based on the hierarchical structure of your organization.
Click here, to access the Corrective and Preventive Action Plan Template with sample data.
As testers, we contribute to the success of a project in a number of ways. The ability to identify risks and contribute towards identifying CAPAs is an important skill that we can develop and use to our advantage.
Corrective and Preventive Actions can be easily applied to the testing process as well and can help in improving the test effectiveness and overall quality. These actions can be identified by the Test leads, QA leads, Project Managers, etc. and executed by the Testers and even the other team members.
Corrective action is a task identified to correct or fix a present ongoing issue or problem. Preventive action is defined as a task identified to prevent an issue or problem that can occur in the near or distant future.
Although the intention is different for both, Preventive and Corrective actions are created to deal with the issues of past, present or future.
Risk analysis, Root cause analysis, Retrospectives, etc., are all processes that can be used to identify Preventive and Corrective Actions. After an action, is identified as to whether corrective or preventive, the work is not over yet. The action still needs to be executed and finally completed and closed.
The ability to identify risks and contribute towards identifying the Corrective and Preventive Actions is an important skill that we testers can develop and use to our advantage.
I hope this article would have clarified all your queries on Corrective Action and Preventive Actions (CAPA)!!