7 test automation mudas for lean quality management

Enterprises worldwide struggle with the growing complexity of solutions, ever shorter release cycles, and the ever-increasing dependence on digital technology. Business leaders’ continued focus on optimizing product development costs is pushing everyone to rethink the product development methods. This reality has also affected test engineers and has forced them to reinvent their test development approach and other related testing activities. Lean software development and lean quality management are some of the significant steps that have been taken to make the testing and development processes more efficient. Testing groups have already started implementing lean QA concepts by removing non-essential activities from the overall testing process. Test automation is playing a vital role in the process of eliminating these wastes (also known as mudas). Let us take a deeper look at lean quality management and the role of test automation in it.

Lean quality management and test automation

Lean quality management encourages removing the waste from QA processes by applying various lean principles, testing the system holistically at regular intervals, and improving its quality. “Anything that adds no value” is a waste and should be eliminated from the overall process, and one of the major wastes in the testing process is “defect”. Poka-Yoke (error proofing) is a quality assurance technique used for preventing defects. It is a synonymous term, but it means eliminating product defects by preventing unintentional human errors. The concept was first introduced by Shigeo Shingo within the Toyota Production System (TPS).

Test automation is the primary means of poka-yoke as part of lean quality management, where test scripts are executed during development, thus preventing defects from occurring later in the software development lifecycle. It has also become a cornerstone of agile methodology, where shift-left and progressive development are widely practiced. Test automation supports almost all lean quality management principles in one way or another. It is considered as a development activity where QA engineers develop one or more applications (frameworks, utilities, or tools) to test the main product.

Test automation has made quality assurance activities as lean as possible by reducing waste from the testing processes. Can this test automation process be made leaner by applying lean principles, removing waste from within, using advanced or intelligent automation concepts? This lean test automation is the future of test automation and lean quality management. Let us take a deeper look at the waste in this process and come up with some ideas for eliminating this waste.

7 mudas of test automation

As per the lean quality management principles, the 3Ms (Muda, Mura, and Muri) collectively describe the wasteful practices to be eliminated.

• Muda means the activities that utilize the resources, without generating any value for the customers.
• Mura means unevenness, non-uniformity, and irregularity. It is the reason for the existence of any of the seven wastes, so Mura is the reason for Muda.
• Muri means overburden, and it can result from Mura, and in some cases, it is caused by the excessive removal of Muda.

Test automation can generate mudas, which need to be balanced during automation development. The seven mudas of lean automation that must be carefully monitored and supported by lean quality management to optimize test automation are:

1. Inventory
Partially developed framework features or test scripts add no value to the overall test development process until they are complete and integrated with the main test solution and start testing the product for quality assurance. Partially done work keeps resources occupied and increases investments, which are yet to produce results. For example, detailed documentation of framework requirements that have never been implemented. Another example could be of people trained in a particular skill, with that skill not being utilized or required in the project. Commercial tools that were considered and purchased during feasibility to be used for test automation in the future but lie idle as part of the inventory are also another example of a complete waste of resources.

A well-planned and well-thought test automation strategy can reduce inventory size significantly. A feasibility study before the actual project:

• finalizes the automation tool
• decides the framework type, its features, and architecture
• identifies the training requirement for automation
• ultimately reduces this muda from the automation process, thus striving for lean quality management

2. Overproduction
Too much automation will add little value to quality but at a higher cost. Is it legitimate to invest a lot of money to ensure quality up to a small extent? The Pareto principle applied to testing says that 80% of bugs can be found in 20% of the more vulnerable application modules. 20% of the application area is the best candidate for test automation. Application risk assessment and its business priority can help the automation engineer identify 20% of the application area, which is either more crucial for the business or more prone to failure and ultimately, is the probable automation candidate to be focused on during test scripting.

Over-automation requires more effort but gives less value to the product quality and ultimately increases cost and maintenance. Often, teams do not utilize all scripts for testing because execution takes longer, which is sometimes not possible for fast delivery. Overproduction in the framework feature that is not required by the end-user and does not add any value to the testing process should also be considered under this category. It will increase the code complexity and could be a potential failure point in the future. It might also become obsolete before the team starts using it. Since overproduction is also a catalayst for the six other wastes to appear, it must be carefully monitored.

3. Over processing
This refers to spending extra time and effort on a task that has a very simple solution. The evergreen design principle of KISS (keep it simple, stupid) reduces this muda. A perfect example of this type of muda in test automation is writing manual test cases before they are converted into automation scripts. Ideally, it must be vice-versa; documentation of the test cases should be generated from automated test scripts, if required, and should be traced back to the original requirements. These automated scripts can further be associated with the business requirements documents (BRD), technical requirement documents (TRD), functional requirement documents (FRD), development code, and defects to complete the traceability.

Another example of overprocessing is about the extra management and planning activities. Inefficient or unnecessary additional process steps that add no value should be removed from the process or activity. Getting advance information about the application‘s vulnerable areas (like much before actual test execution) can reduce the unnecessary execution of test scripts for the already stable modules. It also reduces the execution cycle time and expedites the delivery speed.

4. Transportation
Transportation normally includes unnecessary movement of parts and materials. With respect to test automation, it is mapped to the multiple tasks of switching and losing productive hours. If one task is being divided between multiple team members, it would require handover and context switching. Every time a full stack tester switches between tasks, significant switching time is incurred to gather the thoughts and re-orient to the new task. Studies have shown that each time a team member is interrupted and his flow is broken, it takes another 15 minutes to re-focus on it. It has also been observed that approximately 20% of a programmer’s time can be lost in context switching whenever a new project starts. All this can be avoided in test automation by having a core team for framework development and a separate team for script development. By having a focused group on one area only, this context switching can be completely prevented. The core team can maintain a standard approach and architecture to support multiple automation teams in the organization by adding or removing features and customizing the automation framework as per their requirement. Another dedicated team for script development can focus exclusively on designing application-specific test scripts.

5. Waiting
This is probably the easiest waste to identify. A very common example of this waste in test automation is the time lost in waiting for the environment to be configured and in setting up the test data for script execution. Often, a test automation engineer has to waste a significant amount of time in just getting sign-offs from a BA on the probable automation candidate to merge scripts into the main solution, even after the review and final approval on the created test scripts. This further impacts other related activities and provokes task switching. These delays mean that the customer is unable to realize the value of tasks as soon as he/she can. This waste can be reduced by ensuring that before we begin, we must first have a decision on the best approach for automation and for establishing the standard guidelines and best practices for scripting.

6. Motion
During testing, unnecessary meetings which do not add value, and the time spent for re-gathering the knowledge required to perform a task are examples of this waste. Whenever a script task is handed over from one team member to another, information (knowledge) is lost. Therefore, learning that again takes more effort and is considered a waste. It is important to explore or learn new things, but it is also essential to keep them up-to-date and make them easily available, whenever required.

7. Defects
The amount of waste caused by a defect is equal to the impact of defect, multiplied by the time it remains undetected. It is well-known that expenses incurred on fixing a defect detected during the initial stages are significantly lesser than on fixing those which are detected after the product has been delivered. For a test automation engineer, it is vital to know the faulty scripts as soon as possible and fix those, since these scripts ensure the product quality and have the responsibility of quicker delivery. For such cases, self-healing approach can be considered, which is an advanced and intelligent concept that can be applied to the scripts, where scripts can identify the failure cause and heal themselves without human involvement.

Conclusion

Test automation has become a major tool for lean quality management. It drives continuous quality and efficiency to shape the digital future of testing. From a lean perspective, anything that does not add value is wasteful and test automation not only eliminates waste from the testing process but along with a few advanced approaches, it also reduces the overall rework in testing activities. This “Benefit Driven” approach leads towards a “Lean Automation”, where everyone focuses on its business benefits, without aiming at processes and other related waste. Lean test automation could be a new term for the testing community, but truth be told, neither can lean quality management ignore its crucial role in the overall processes nor can the testing society sidestep its benefits.