Testing the Waterhouse

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