The History of Lean Methodology
In the 1950s, the renowned carmaker Toyota faced severe problems in its production line. The manufacturing chains were too complex and lengthy, and customers were not getting their orders on time. Toyota had to reinvent its approach or lose out to its competition. As a result, Lean quality assurance or lean methodology was invented and implemented, also known as the Toyota Production System (TPS). TPS was based on Jidoka, Kaizen, and Just-in-Time manufacturing philosophies. Toyota used it to efficiently produce top-quality vehicles that would fully satisfy their constantly growing customer base. Jidoka is Japanese for “Human aided automation.” In a production line, whenever there is a deviation from the normal, the principle of Jidoka instructs the production to be stopped to identify the problem. The problem is then rectified via human intervention, and only then is production resumed. Improvements from the learning as to what caused the issue and what’s needed to prevent it from occurring again are incorporated into the go-forward standard workflow model (Kaizen or continuous improvement).
Just-in-Time is the idea of producing what’s needed when needed and then only in the amount needed. By eliminating waste, uneven workload distribution, and unreasonable requirements, profitability is enhanced. TPS or the Lean Methodology has a basic set of principles that can tailor to the production of almost anything, even software. Even today, TPS is being fine-tuned by Toyota’s production divisions with improvements to ensure its continued evolution.
The Four Pillars of Lean Quality Assurance
A natural extension of the Lean principles outside of manufacturing is in the Agile methodology, which, like TPS in manufacturing, optimizes the software development process. Software development is similar to manufacturing as it follows a defined process, has defined conditions for acceptance, and delivers a tangible value to the customer.
1. Continuous Improvement
Software teams following Lean methodology should be agile and organized. Often in Lean, the primary goal is to eliminate waste to make the process more efficient. While that’s true, there is a better way to view this principle. Lean quality assurance is about value creation. How do software teams create value? To answer that, you need to know what the customer needs and doesn’t. Yes, there are software requirement specifications, but as we all know, the true test of the software is when it reaches the hands of the customer or the end-user. The trick is to deliver often and get feedback quickly. In this way, we will observe what the customers need, do not need, or need changes in. We facilitate continuous improvement by implementing the feedback in the next delivery cycle and the standard procedure. Although every one of us would like to be right on the first attempt, Lean does not necessitate it. It instead emphasizes continuous learning and progressive maturity. Lean promotes innovation and can be viewed as a form of risk management.
2. Respect for frontline workers
Lean is a key proponent of the idea that employees closest to the product, who work with it every day, know it best and are the carriers of valuable ideas that could make the product better and the customer happier. Traditionally, in most organizations, ideas trickle down from the top management. But in Lean, you value the people who work on your products. As a result, you are motivated to think of ways to make the process more efficient, improve productivity and create more value to the customer and, in turn, for your organization. This helps organizations capture the best ideas, put them to the test, and eventually reap benefits.
3. LEAN leadership
Boosting the role of your frontline employees requires subtle modifications to the traditional leadership model where the leader instructs what should be done, when, and how. Lean empowers employees to ask key questions: Why do I need to do this? What value does it provide to the customer? And through the answers to these questions, the workers know if their efforts in performing a task are indeed worthy. In Lean, the leader defines the goal and allows his talented troop to shine. The employees decide the best course of action to achieve the goal. The leader isn’t sidelined, though. The leader is always there to guide when needed, solve any obstacles that impede progress and extract the best out of the team. Lean leadership does not believe in micromanagement.
4. Lean QA
Traditionally, testing is a phase. But in Lean, testing is a responsibility shared by everyone in the team, right from the PO, the BA, the developer, DevOps, and of course, the QA. In Lean quality assurance, quality is a team sport. Quality in Lean is a skill that is expected out of everyone involved in the software development process. Lean compels you to move out of the “Test for quality” mindset and reshape towards “Build for quality.” By instilling this mindset, quality comes much more easQuality tester price.
12 Best Practices involved in Lean Quality Assurance
The true goal of Lean is to do only what’s valuable to the customer. Eliminating waste from each process involved in the SDLC is an important step in achieving that goal. Since QA is typically affected by all earlier processes, we need to eliminate waste from the chain of events that lead QA to avoid wastages during testing.
1. Ensure you define “Waste.”
Before initiating any project, it’s imperative that the customer, internal stakeholders, and frontline resources collaborate, list out the wastages in the existing process, and decide on ways to cut costs without sacrificing quality. Do not hesitate to remove traditional steps in your processes, such as detailed status reports and excessive documentation. As a result, the resources will have time to work with the product and add value to the customer, which counts by the end of the day by relegating these.
2. Migrate to Shift Left Testing in Lean Quality Assurance
Shift left testing involves lean quality assurance from the get-go — from requirement gathering through the design phase, developer unit testing until delivery. It reinforces the trait of continuous testing throughout the SDLC. Testers evaluate requirements and user stories (Static Testing) to raise valuable questions to plug gaps and address any issues before the design phase. Brainstorming the requirements with practical use cases is a great way to avoid future problems.
In the design phase, testers constructively scrutinize wireframes and report anything that doesn’t sit well with the defined workflows. Test cases are prepared and delivered to developers in advance, based on the unit test cases. The mantra of shift left testing is to test early, test often, and test continuously, and if done right, it can drastically reduce future costs and effort.
3. Employ Risk-based Testing
Testing every single scenario isn’t wise or necessary. Risk-based testing considers likelihood and impact to users in prioritizing test cases. Determine those test cases that score high on both fronts and mark them as high, medium, or low priorities. It is wise to test high and medium-priority ones alone and leave lower priority ones untested. In Lean, you employ unit tests and automated tests, which can cover a number of these low priorities. A low-priority workflow has a remote chance of being experienced by the end-user, and even if he does encounter it, its impact would be minimal. So comparatively, the cost spent on executing all low priority scenarios, reporting issues, fixing and then retesting them would be greater than fixing the specific low priority issues reported by end-users after the release.
If your application is data-intensive, employ equivalence partitioning, Boundary Value Analysis, and Pairwise testing to cover tests cleverly. Ensure that lean quality assurance metrics are designed so that the quality of issues found has precedence over quantity.
4. Don’t Automate Everything in Lean Quality Assurance
One of the most important aspects of automation is Return on Investment (ROI). The client gives you money to write code that would test something that’s already been unit tested and manually tested. It is not a wasted expenditure because you can do away with manual regressions once automation is integrated with CI/CD. For example, if there’s a bug fix build, you need not perform a sanity test. Instead, you execute your automated sanity test suite. Regression suites can be run on a nightly basis. But you cannot try to automate everything in your product.
The approach to picking automation workflows is similar to risk-based testing with a few additions. Estimate the business priority of the workflows, the functional impact if a workflow doesn’t behave as expected, and the likelihood of a workflow being used by end-users. Then, automate wisely for significant ROI over some time. Extreme cases with high impact and negative ones can also be relegated from the manual testing scope once and for all — bridging the development and the automated test suite pipeline in a CI/CD environment.
5. Don’t Try To Find Every Bug.
Every product ever released has had bugs. No one can truthfully claim that their product is entirely bug-free, yet it is also easy to misinterpret the statement of not trying to find all the bugs.
Bugs that fall in high-priority business areas are highly likely to occur, and of course, those that would adversely impact user experience should be identified and rectified. Lean methodology tries to avoid the excessive costs involved in finding issues that are difficult to reproduce or those related to corner cases that are rarely used. Look at the visualization below to observe how the cost of finding and fixing a high vs. low priority bug is reduced ten times. Instead of finding every bug, it is more efficient to find all the easy-to-find/easy-to-counter bugs that fall into the high/medium risk category and ensure they are properly fixed.
6. Avoid Excessive Documentation
Most often, QA engineers, rather than approaching testing from different angles, waste a good chunk of time elaborately documenting test cases. Test cases can be shrunk into well-written, clearly worded one-liner scenarios that can still do the job. Multiple test cases can be clubbed into a checklist. Test data can be embedded into the scenarios, and if the scenario is cleverly worded, there is no need for a separate expected result. Doing this will silently save a considerable amount of time — neither Lean nor Agile demand excessive documentation.
Invest the saved time on session-based exploratory and negative scenario testing where the tester’s skills are further honed. It also gives a greater chance of finding valuable issues. Invest the saved time to test the application’s performance and security aspects to stride beyond functional excellence to achieve wholesome quality, which is the hallmark of any great product. Cross-browser testing, compatibility testing, accessibility, and UX testing are also worth their effort.
7. Automation is Essential in Lean Quality Assurance
You cannot be truly agile or Lean if your QA practice involves automation. By performing manual regressions, there is no way to quickly build a quality product and deliver it to the customer, especially with increasing product complexity and feature list. So do automation wisely, relieve your QA from manual regressions, and avoid excessive effort.
8. Never Make the Same Mistake Twice
Lean strategies make the best use of insights gathered from historical data to avoid further inefficiencies due to repeated mistakes. After all, Lean’s core ideology of Kaizen aims to continuously improve the process by implementing valuable additions to the established process. For example, in the case of QA reporting an issue, the developer should properly study the fix’s impact. As a result, the replenished code shouldn’t cause the reopening of the same defect or report new or previously closed issues in related modules.
9. Improve Code Quality to Reduce QA efforts
In Lean, quality assurance should be treated as a luxury. Bad code is treated as a waste of time. Remember that Lean advocates “build with quality” rather than “testing for quality.” So the mindset of quality should be ingrained within the developers who write the code. ATDD, BDD, TDD are good processes to ensure quality code. One should conduct proper code reviews before delivering the code to QA. Developers must have written and tested unit integration tests when the latest functionality integrates with existing functionality. Actual testing should be carried out only after observing that all unit tests have been successfully passed. Also, it’s wise to ensure that code is written to allow for scalability and future integrations of new functionalities. Using automated code review tools such as Blackduck to manage security and license compliances and analyzing code quality risks ensure better code. The image below clearly explains how Lean ensures the breakdown and distribution of quality assurance responsibilities to different personnel within the team.
10. Continuous Integration and Continuous Deployment in Lean Quality Assurance
Without CI/CD, there is no way project teams can deploy, test, and provide quality deliverables rapidly. One should build automated deployment pipelines and trigger automated smoke tests. We must execute automated regression tests after delivering each new QA build or code merge on specific environments as nightly builds.
11. Establish Proper Branching and Prescribe Specific Automation Approaches
The project team should establish proper branching and merging processes to avoid redundant tasks originating from improper code merges and missing code. Appropriate comments should be provided for each commit and merge. Code reviews, manual and automated, should be performed before each commit and merge. Finally, appropriate testing techniques should be applied to the code in each branch to avoid overburdening of the QA resources.
12. Continuous Customer Involvement in Lean Quality Assurance
In Lean, the customer should always be engaged throughout the project’s lifecycle. Please find below a few steps to remember that are sure to improve the odds for success:
- Send proofed requirement documents and user stories to the customer for feedback before wireframing.
- Review the resulting wireframes with the customer before starting actual development.
- After clearly outlining the available capacity of team members and documenting the customer stories for development, establish sprint meeting schedules.
- Continuously send test plans, acceptance test criteria, test scenarios, automated test results, and performance test results to the customer for feedback.
- Systematically demonstrate the functionality that QA has signed off at the end of each sprint for customer validation and official signoff approval.
Constant feedback is one of the best aspects of Lean. Gathering feedback at the end of each sprint and implementing the desired changes as the project progresses incrementally is much easier than waiting until the end, where the costs of delayed implementation and testing delays are exponentially higher. Transparency and honesty with the customer are core components of Lean, and quite simply, it makes for better business.
To conclude, implementing a time-tested, continuously evolving, and customizable process such as Lean is an easy and effective way to make your products better and your customer happier. Payoda Technologies is a global IT solution provider that can help an organization implement the best QA practices into Intelligent production. If you would like to know more about how we can help you, get a free consultation now!
