Testing the Waterhouse

Being positive is becoming increasingly difficult, in a world where negativity is all around us in the form of News reports, just looking at a popular news feed a large portion of the articles are of a negative nature or in a negative tone, then there's the fact that people love to moan or gossip about someone not doing what they are supposed to do and similarly people are far more likely to leave a negative review for a product or service than they are a positive one! So how can I be more positive and why does it matter? All I do is test? Firstly, never ever say or think "All I do is test" , you do so much more, and we all do so much more, it's about showing everyone just how awesome we can be and how great we are! Secondly, why does it matter? Well a Tester can have every attribute that is needed to be a Tester, but if they have a negative attitude it can all be for nothing. I've found that by merely having  a positive attidue it can take an Okay Tester and ...

I've blogged elsewhere about what I look for when hiring QA Engineers, and it's full of useful things that I think are important in being a good QA Engineer/Tester. One thing that is often overlooked and probably not really spoken off much, especially when hiring or looking for a new job, is something that is potentially extremely important when it comes to being a successful Engineer, and that is the ability to find out information. For most people this is being able to "Google" for something, or use Stack Overflow to find out a solution to a problem. You could argue (and rightly so) that the ability to Problem Solve is what we are talking about, and you'd be right, but this is specifically really about being able to use Google effectively to find the answer you are looking for. Why is being able to Google important? There are a number of reasons for this: 1- Being able to structure your search query appropriately is important and can save time sifti...

So it's been a tad difficult to do the challenges over the weekend (had school fete, kids parties etc!), so I've changed things up slightly and am going to do challenge 2, 3 and 4 today... So, first things first, a photo of work... Whilst this wasn't today, the premise is still the same, this was of a QA++ training session, where we were going through YAGNI and DRY principles (You Aint Gonna Need It and Don't Repeat Yourself) with regards to Software Development, however these principles can easily be applied to Testing, if you don't need to Test for something then don't do it and if you communicate effectively then there's no need to repeat yourself, so it's an art for sure! For the listening to the Testing Podcast, I'm going to listen to the latest Testing in The Pub Episode  on my way home from work, so will no doubt include that in my next update! And finally, to share a Testing Blog with a Non Testing Person... I've chosen th...

I've decided to attempt to do the Ministry Of Testings 30 Days of Testing Challenges over the month of July, which will be erm... challenging! (duh!) For those that don't know what it is, you can read about it here  and the challenges are below: The first challenge is to read a Testing Book, the book I've chosen is " Dear Evil Tester " by the one and only Alan Richardson. So I will start reading that on Friday and then take it from there! I'll try and write some posts that will update, but if you're reading this, and it sounds interesting to you, then my advice to you is to do it! It's only 30 days, you'll learn loads of stuff and it's fun! Remember, a quote from Empire Records, "I do not regret the things I have done, but those I did not do"

I thought it might be interesting to some people to start doing some posts about my day to day job as a QA Lead! I often get asked what it is that I do, how do I do it, what skills are important and just what is difficult about the job, so what better way than to just start a diary documenting all of this!? In writing this, I've figured it would be a good idea to get others to do the same across the different levels and teams, as we very often get asked in interviews "What will my day to day role be?" So hopefully this will serve as a useful piece of information. So lets begin (on a Friday as this idea came to me on a Friday!) Friday June 17 : 8AM : It's Friday, and it's Summer, so you know what that means (or maybe you don't, but you will now)... It's Summer hours here! So a 3PM finish today! I got in early today to make up for the England game yesterday where no work was completed for obvious reasons (what a result!), I have to catch up on emails...

Apologies for the lack of blog posts, but for those that don't know me, not only am I a struggling Tester, but also a struggling Parent! I have 2 kids, a 2 year old and a (soon to be) 5 year old! They are my world, and they're also the inspiration for some blog posts that I tend to write, this latest one is no different... My 2 year old daughter has begun to question a lot of what I say to her. "Please don't climb up the slide" "Why?" "Because the slide is slippery and you might hurt yourself" "Why?" "Because it rained last night" Ad infinitum! My 5 year old said to me and Jess the other day "We mustn't ask "Why?" must we because that is answering back" I thought to myself, I don't want him to stop asking Why? to stop asking "What If?" This is a massive skill and something we as Testers should definitely have and encouraged. So I had to explain to him that it's ...

Who doesn't love a Super Hero? Talk to my son, and he'll tell you how much he loves them, talk to many adults and they'll say the same! Deep down, we all love to be the Super Hero, we all want to save the day! However, I want to talk about the flip side of Super Heroes, the Super Villains... I often play Imaginext with my son, and I (unfortunately?) am nearly always the Super Villain! Be it Lex Luthor, Joker, Two Face, Mr Freeze or The Riddler! These are all great characters and great Super Villains, but why would I want to write about Super Villains? A while ago where I worked, we had a few Super Heroes, people who would be able to come in and "fix" things that had broken and help deliver projects on time. We then shifted, we decided to do away with the Super Hero culture and try and prevent from being in that position in the first place, whilst we didn't go as far as wanting to hire Super Villains, it's definitely a story that has stuck with me and t...

All through our lives we get told by people you get out of anything that you undertake what you put in. How can it apply to me as a Tester or as an Engineer? Well lets start with a rather less than subtle drawing, the above shows that if you put poop (in case my 4 year old son reads this one day) into something you will most probably get poop out. It doesn't matter what that task is, it directly effects the outcome. How does this apply to me as a Tester? Lets look at a PBI with no COAs? If we took that into a sprint, chances are we will end up with a rubbish outcome, it most probably won't be what the Product Owner wanted and it probably would be littered with bugs, and the time taken to even develop and test that thing would have been far greater than it perhaps should have! Lets flip it, what if we had a Product Backlog Item (PBI) with well defined, testable and understood Conditions Of Acceptance (COAs) the chances are that what would come out at the end of a spr...

Many of the teams I work with sometimes struggle to understand why working together as a team is important. There have been comments like "You're not technical enough to be involved this early" etc. from a dev to a QA, and I strive to get everyone involved as early as possible, reasons being: Helps people understand things from the start - if a decision is made early on, then at least they know why it was made Everyone is on the same footing, you're not just throwing something over the fence when it's been developed or even when it's been groomed to the QAs to understand how to test something. By having them involved early they can start thinking just how they are going to test something. It helps people bring value from the start- especially from a testing background, if a tester can start testing things early, even requirements, then value is coming straight away, and it's far easier to change a requirement than it is to fix a bug in code ...

Recently I was watching Zoolander (it's an amazing film, and one I can highly recommend), and Derek Zoolander (Ben Stiller) plays a dumb male model in it, but it's hilarious. One scene however got me thinking, and it's this scene here: "Did you think I'd be too stupid to know what a eugoogly is?" It shows Derek not knowing something and being too afraid to ask for fear of looking stupid. It's something that unfortunately I still see, and one of the reasons why I believe that Testers need to understand what they are testing, but all too often, I see Testers scared to ask questions. If a Tester is scared to ask questions, then that raises alarm bells on multiple fronts: - Firstly, is the team a safe environment for the Tester to ask any questions? Do they feel confident and comfortable in front of their fellow team mates. - Secondly, if the Tester doesn't truly understand something, then how do they know how to test it? What test cases to w...

A few weeks ago I went to DisneyLand Paris with the family, and it's the first time I've been to a theme park and really took advantage of the Fast Pass system they have! I have to say it's really great! Especially with kids! For those that don't know the fast pass enables you to "book" a time to come back to a ride and go on it, it's invaluable with kids especially as it meant we'd spend less time queueing, and as good as my kids are at queueing (we are British after all!) it's not the best way to spend a holiday! Luckily for us it wasn't too busy and the longest time we queued was probably around 30 minutes. It got me thinking and wondering how it went, which is generally a Testers mindset, asking How is this even possible? Why is this happening? How does it work? Anyway, I did a bit of googling, and sure enough someone else had asked on Stack Overflow of all places how it works, and it's a way of scheduling rides for people...

I was talking to a good friend of mine and she was discussing how she's started the year and a new year resolution was for her to not say "No" to things, much like the "Yes Man" movie, unless she physically can't do something, she is trying to say "Yes" to everything that is asked of her. Whilst this may lead to a busy and stressful time, I also think it's a very positive and good outlook to take. I have to steal a line from one of my favourite movies, Empire Records, being this: For those that haven't seen it  I can strongly recommend watching it, it's an easy to watch film and has an amazing soundtrack! However, I digress, there are always a million reasons not to do something, so it's very easy to say "No" to something. Yet, if we all take a "Yes" attitude, so much more would be done. Where is this leading? Well I had a "Yes" moment a few months ago, when I volunteered to speak in front ...

Apologies for the lack of posts recently, I spent last week in Disneyland Paris having a truly awesome time. I am going to be writing another blog post about that at a later date... however as a stop gap... I was rewatching The US Office for the umpteenth time yesterday and was watching this episode which made me laugh, as I've met some people in Testing/QA (not getting into that debate right now), who this would be perfectly applicable to! They've come into testing just to get paid and are lacking some of the fundamental skills, and do the bare minimum to get by.... And whilst this video in particular is not related to Technology, but I still thought it was funny! I must admit it is becoming less and less as times move on, maybe it's because I know what I am looking for when hiring good QAs so I tend to cross paths with these people less and less, or maybe (and perhaps far more likely :) ) there is a shift in recognizing QA/Testing as a valuable Career Path so...

I got into work this morning, and was looking at some CI Builds, and had a thought that it might be useful to have a bug raised automatically (through an API) when a test that is running on CI failed.... I tweeted about it to get peoples opinion(s)... I got a few responses on twitter, and one which made me rethink why this might be a good idea and that was: It could easily lead to and incredible amount of noise if we are raising bugs against every failed test, and also 1 failed test case != 1 bug, in that if 3 automated tests on CI fail then we don't necessarily need 3 bugs. It could also potentially (as my reply states) devalue what a bug actually is, meaning that if a tester raises a bug then it might get ignored/lost in all the noise.  I also asked our internal QA Slack channel, responses were informative, and again helped lead me away from this potentially noisy and crazy idea. Both of these points are extremely valid, and if you make it the number...

I finally got round to watching the new Star Wars (that's what it's like having 2 kids at home, babysitters are at a premium!!!), and (no spoilers here) but I was interested to see the following line being muttered again during the film! It reminded me of a series of blog posts I done a while back around famous movie quotes that have been said in films and applying them to Software Engineering/Testing... This particular quote has been said in every single Star Wars film so far! (Star Wars trivia for you there!) But for the purpose of this blog post, how does it apply to Software Engineering?  Well, as Testers on a development team/project we get to see things that others perhaps don't get to see, we get to speak to everybody about the product that is being developed, we see it from a technical standpoint, from a business standpoint and from a customer standpoint, we really are in a truly unique position, and this is one of the things I love most about Testing. As a...

At Asos we have a large testing team (30+ testers), they all work within their development teams, and the way development teams work can vary and understandably so. Helping the 30+ testers we have a number of Test Leads, of which I am one, recently we (the leads) all got together to come up with a plan of things that we feel we need to work on/define/have an idea of how to approach them for the next year to help improve our testing standards across the boards and improve the skillset of testers within the teams. To help with this we got together and came up with a mindmap, the plan going forward is for us to take ownership of one of the areas and come up with a strategy/approach/implement actions to help improve the areas and define whatever is needed. There's a lot there, and I'll probably write seperately about each one, and what we're doing, as it's always good to share ideas and get feedback... so watch this space!