Testing the Waterhouse

I was recently watching a TED Talk by Simon Sinek: How great leaders inspire action ... It's a truly inspiring video, and one that I highly recommend you watching it. Like any great video/speech it got me thinking and trying to apply it to my life/world. As you know a lot of my life/world is around testing and so naturally I started asking myself the following questions: - What helps makes great testers? - What makes people really appreciate the value of testers? Now in the video Simon mentions what he calls "The Golden Circle" which you can find a neat little diagram of below: Using this he helps explain what makes leaders/businesses great, it's not the What of what they are doing? Nor is it necessarily the How ? It is in fact the Why of what you are doing.   If people can connect and resonate with the Why of what you are doing they are going to follow you, they are doing to buy into your product and appreciate the value you bring even you more so. Thi...

I recently (though it seems a long time ago now... as I've just got round to writing this!) had the pleasure of attending the Unicom - 12th NextGen Testing Conference in London, I was lucky in that I won free tickets, so a free conference is definitely appealing! :) I thought it would be good to write a blog post detailing the conference, what I learnt, what I got out of it and if I enjoyed it... The conference itself was chaired by Donald Firesmith , he was over from Pittsburgh, and was chairing the conference and also giving a talk about the Many Types of Testing & Testing Philosophies. Many Types of Testing & Testing Philosophies This was a very interesting talk, and possibly one of my favourites, it opened my eyes a bit, and I've been in testing for 8 years, but there were some types of testing in there that I had not heard about, and even some that I knew of that weren't included (which I had a chat with Donald about afterwards and agreed that they shou...

We were in a meeting the other day, and someone in the meeting, said something that is one of my pet hates, "It's not my job" ... This confused me, we are talking about delivering quality software as part of a team, and anyway that someone can add value in that team to deliver the ultimate goal is important, regardless of what their job title is. This then lead me to think about how testing has changed over the past 5 years, and how I see it as a constantly evolving role, and it reminded me of something that I read about recently and wanted to blog about called Holocracy , it is about a method of running organizations and so it's given me a kick up the backside and here's the blog post.  It has some core principles, and these are: Flexible Organisation Structure - With Clear Roles defined around the work and not about the people. People can often take on a number of Roles in a company.... More Autonomy to Teams & Individuals - Teams and individuals solv...

We recently held a community session where we completed a little exercise to get people to think about the different layers of testing, and the different types of testing in the hope that it would get their brains thinking and applying it to real life scenarios in their project and team work. The exercise was one we had done before many years ago, but seeing as we had new starters, and not many people left from all those years ago, I felt it would be appropriate and useful to do it again. It was to take a set of instructions for the assembly of a chair and look at the different types of tests that we could apply to it to ensure it worked as expected. The instructions were these: It was a pairing exercise, to carry on the theme from previous sessions, and to get people collaboratively working together with people they might not normally work with, and I gave them the instructions and told them how would they test it, what types of tests would they perform and where. I was exp...

Here @ASOS we're trying to build a community for testing, and dare I say it, but it is slowly happening, over the past couple of months we've been getting real traction with regards to a community feel, attendance at our meetups but not just attendance but people voicing opinions and being passionate and wanting to improve themselves.  Anyway, at the last meeting it was suggested that we do some coding challenges, some quick challenges that anyone can pick up and do, I understand that not everyone understands or knows how to write code, but by adopting a pairing approach it was hoped that everyone would get something from it. Anyway, a colleague sent me this website:  https://projecteuler.net/archives  it has a long list of coding challenges that people have completed and whatnot, so I took about the task of finding a suitable coding challenge for the meeting. It was important to choose something that wasn't going to: a) take too long to complete b) be too hard to...

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 w...

My 3 year old son has been watching A Bug's Life recently, and he seems fascinated by it, and rightly so, it's an awesome film. For those that haven't seen A Bug's Life, it's about an ant called Flik who goes away to try and save his colony from evil invaders (Grasshoppers), I won't spoil it for you by revealing the outcome of the film, but it's a thoroughly enjoyable film! It got me thinking this morning, about a different type of bug, the bug that we're all aware of, one that is a bug in software... How can this film relate to testing? Well, I like to think of myself (and other Testers) as Flik, someone who is trying to prevent bugs (Grasshoppers) from spoiling software (Flik's colony), whilst I don't find a circus, I do have a team of testers who I trust to help prevent the bugs from making it to live, and to help improve processes for the future to help prevent bugs before they're even coded. What other films can you think of...

So I recently had a discussion at work to define how my role works and the responsibilities and what it entails. I thought it would be good to open that up to the wider audience here, as I often hear that there is no need for a Test Manager/Test Lead in an Agile environment. Whilst there is no need for what we would see as an old school test manager, being one that manages test resources and allocates testers to projects, there is still a need for a test manager/test lead, and I'll explain my thinking here. In the past my role has been around fighting fires and helping teams out when testing resource is needed, which don't get me wrong I have enjoyed as it's meant getting my hands dirty and improving things from the ground level. However, I wanted my role to be clearly defined as we have gone through structural changes since it was last defined, and some of the responsibilities aren't necessarily valid still. Drive testing within teams  Directly or by working c...

I'm currently working with a new team who haven't really worked in an Agile way before, nor do they have much experience of what types of testing you can do on an application, so in preparation I tried to come up with simple definitions on the above types of tests. I thought it would make a good blog post, as it's somethign that I would undoubtedly find useful at a future point... So here goes: To define a Unit Test it's a simple test that tests a single piece of code/logic. When it fails it will tell you what piece of code is broken. An Integration Test is a test that tests the combination of different pieces of an application, when it fails it will tell you that your system(s) are not working together as you thought they would. An Acceptance Test is a test that tests the software does what is expected by the customer/user of the software. When it fails it tells you that your application is not doing what the customer/user thought it would do or even what it sh...

It's important when writing automated tests to remember that the code you write should be up to production standards, meaning any conventions that you have in place should be adhered to and that it should follow good design patterns. Too many people often say why does it have to be as good as production code, it's "Only" a test, so long as it passes then that's fine... To answer this we need to look at why we want our tests to be written in such a structured and efficient manner: - Maintainability - by making the test code structured and efficient, it becomes far easier to maintain and in doing so changes in the future can happen quickly as the test isn't linked to anything that it shouldn't be and it's easy to understand for a new set of eyes. - Durability - Again by making the tests structured they should be resistant to changes, if you change a variable name for instance then it shouldn't effect the unit test unless it absolutely has to....