5S on code

What is 5S on code?

The “5S” approach was invented at Toyota, between the 50’s and 70’s and popularized in the 80’s [Miller 2017-2] and some 5S experts define its origin in the XVIth c. with Venetian Arsenal  [Miller 2017] [Cruz 2018] which would have supposedly demonstrated to King Henry III of France their ability to build a ship in 2hrs [see https://www.quality-assurance-solutions.com/History-of-5S.html].

“5S” is a Lean Management technique which takes care of an asset.

For more detail about this notion, please refer to 5S on test cases.

Impact of 5S on code on the testing maturity

Naturally, applying 5S to the production code and test scripts is something which should be promoted in the organization; however, regarding test scripts, it is extremely precious for scripts that are responsible for flaky tests also known as False Positive (FP). FP’s are issues from the test scripts which stop the integration pipeline and require the Developer to fix the issue, just like the Line Operator in an automated plant.

Actually, FP occur 72% of the time whenever an issue is raised, mostly due to script issues (with 46%) [Philipp 2019]

‍

Here are 4 examples that demonstrate the 5S usage on test scripts:

• FP’s prove that Test scripts reliability improvement is major. 5S is a way to improve this because it aims to handle non reliable tests.
• This is the same with “gray” test scripts whose result may be white while it is actually black or vice versa, reducing thus the reliability of the delivery pipeline.
• Slow scripts should also be handled during a 5S session in order to launch them in an offline pipeline which will run asynchronously from the Dev code commits which must be run within 10’.
• When a script has no longer been launched for a while, the script may experience issues from product changes. Maintaining such scripts will inevitably lead to decommissioning because the ROI will not be worthy any longer. 

Therefore, garbaging useless scripts with a 5S, is useful regarding the pesticide paradox [ISTQB 2018] since test cases do not trigger bugs anymore; and ideally, tests should be automatically tagged from the test execution, notably thanks to the pipeline or the test automation platform. These tags can then be used to sort and group items. They provide clear information about any script so that teams can plan or take the appropriate improvement action while visiting the script.

Agilitest’s standpoint about 5S on code

As a script editor capable of managing test scripts, Agilitest proposes a tagging feature. This is a great support to implement a 5S on the test cases. Moreover, the tool proposes tags to be gathered in groups to enable a bird view on this testing asset.

If you wish to enable tag generation from the running of a script, ask for some support from Agilitest.

‍

To discover the whole set of practices, click here.

‍