Skip to main content

The 5s Methodology to Testing

This morning I finally got round to start reading a new book, a book I've been saying that I'll read for a while, actually this could apply to 2 books, as I've also started reading a non work related book in Game Of Thrones, which I thought might fill up some time between the series starting up again... Game Of Thrones is amazing, you should most definitely read it... however I digress, the book that prompted this blog post is Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)

Obviously having only started reading it this morning, there's a specific excerpt that caught my attention and one that has made me want to write a blog post... and apologies it's been a while... However, the book talks about the 5S Methodology they apply it to coding principles, and whilst that's still useful for this blog, I wanted to try and apply it to testing principles, so here goes...

For those not familiar with the 5S Methodologies, they are 5 Japanese words, and I've listed them here (copied from Wikipedia): seiri, seiton, seiso, seiketsu and shitsuke.

Now the fun part, applying these to some solid testing principles:

  • Seiri (Sort)

How can this be a testing principle you may ask? Well, it can be used to explain how test cases should be visible. They should have relevant naming, the test/check should clearly state what it is testing/checking, both automated checks and manual tests. All too often I have seen test case names as 1 words with no real description of what the test is doing how it's to be run etc. In some cases this may be okay (I can't really think of one though), but not when we are talking about acceptance tests that other people may be required to run. (Clean Code does talk about naming conventions for variables etc. I'll probably write more about this at a later date)...

  • Seiton (Systemic Arrangement)

They should be where one expects to find them. This applies to both automated checks and manual tests, if it is an automated test, then ideally they should live with the solution/code they are testing, if they are manual tests, then they should be organised in such a way that "makes sense", they should be easy to find and structured accordingly. It's about making other testers lives easier if they wish to view test cases, it should be instinctive where to find the tests for a certain piece of software.

  • Seiso (Shine)

The test cases and checks should be kept up to date, whether automated checks or manual tests, they need to be run regularly and fix any failing tests, remove out of date tests, apply the boy scout principle,  "Always leave the campground cleaner than you found it" by applying this to our tests, we're talking about refactoring broken/failing tests, we can only do this if they are run regularly. If they're not run regularly we're not refactoring a handful of tests/checks, but probably fixing a large number of tests/checks.


  • Seiketsu (Standardisation)

This can be applied to tests/checks (ensuring standard naming conventions are used) but it also applies to toolsets, when having multiple teams on projects, it's important that teams use the same approaches for testing. This is for automated checks (e.g. teams shouldn't be using different tools to automate UI checks) as well as for storing of test cases, reporting bugs. Otherwise it becomes un manageable, if teams start using google docs for tests (don't get me started on that one) and another team is using Microsoft Test Manager, how can anyone have a reasonable idea of what coverage is where across a project.

  • Shutsuke (Sustain)

This is related to ensuring that the above are maintained, being able to reflect on the work you have done and ensure it is up to a standard and meets the appropriate principles that you employ and of course about having the discipline to do all of this.  Don't be too proud, admit mistakes and work on improving them and making sure it doesn't happen again. We are all human, we all make mistakes, grow from it and ensure that you learn from it.

So there we have it, the 5S Methodology applied to testing. I'm sure you could interpret them differently, if you have/can, please comment. I'm interested in hearing what people think.

As I delve further into the book, I'm sure it will prompt more blog posts, so you have that to look forward (?) to :)




Comments

  1. Hey Gareth Waterhouse, i have just bumped into you blog and I must admit that I am in love with it. Your style of writing as well as the information provided if just on another level.

    ReplyDelete

Post a Comment

Popular posts from this blog

What is a PBI?

After my last post, I had the question of what is a PBI... so I thought i'd write a short blog post about what they are and why they are used.

A PBI is an acronym for Product Backlog Item. It is a description of a piece of work that your SCRUM team will develop and deliver. When you have a list of Product Backlog Items, you then refer to that collective list as a Product Backlog.

The product backlog is often prioritised and yourteam will work through each PBI, and release on a regular schedule... I am however going deep into the world of Agile development, which isn't entirely what this post is about, so I will stop myself now.

A Product Backlog Item is made up of the following:

Title - This is often a one liner that gives the team an idea of what the PBI is about, although it can just be an ID for the item and the team work off of that.

Description - Breaks down the PBI in a bit more detail, and can be written in any style, however I prefer it to be written as follows: 



By writin…

Dealing with Selenium WebDriver Driver.Quit crashes (Where chromedriver.exe is left open)

We recently came across a problem with Selenium not quitting the webdriver and this would then lock a file that was needed on the build server to run the builds.

We were using Driver.Quit() but this sometimes failed and would leave chromedriver.exe running. I looked around and found this was a common issue that many people were having. We (I say we, as we came to the solution through paired programming), came up with the following, that would encapsulate the driver.quit inside a task and if this task takes longer than 10 seconds, then it will clean up any processes started by the current process, in the case of the issue on the build server, it would kill any process started by Nunit.

[AfterTestRun]
        public static void AfterTestRun()
        {
            var nativeDriverQuit = Task.Factory.StartNew(() => Driver.Quit());
            if (!nativeDriverQuit.Wait(TimeSpan.FromSeconds(10)))
            {
                CleanUpProcessByInheritance();
            }
       }

        private s…

Advantages of using Test Management tools

Before I start talking about test management tools, let me clarify what I mean by the term test Management tools...  I am not taking about your office excel program where you store your test cases in. I'm talking about bespoke test Management tools, your quality centers or Microsoft test manager...
In the strict case of the term test Management tool, Microsoft Excel can be used as such, but heck, so could a notepad if used in the right way... For the sake of this blog post I am talking about bespoke test Management tools.
Firstly, what test tools are out there? There are many more out there today than when I first started in QA over 5 years ago. When I started the market was primarily dominated by a tool called Quality Center, this would run in a browser (only Ie unfortunately) and was hosted on a server.. Nowadays it's market share has somewhat dwindled, and there are some new kids on the block. 
One of the more popular tools is that of Microsoft Test Manager, it's big…