Testing the Waterhouse

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