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:
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)...
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.
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.
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.
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 :)
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 :)
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