Testing the Waterhouse

I was reading my good friend Helen Meeks blog on her end of year review, and thought I'd do something similar... It's been a long year, but an exciting and definitely positive one for me on both a professional and a personal front. As I write this I have been up for 2 hours with a crying baby, but strangely I still see her as a positive! I'll start with the professional positives, as that's what people come here for, to hear about my views on my profession, I'm not sure they're so interested to hear how many nappies I changed at the weekend etc... The biggest positive for me has to be my promotion to QA Lead, I've been striving for this promotion for a long time, and to finally get it was extremely exciting for me. It meant that I can influence people more and effect how they work and to try and make them work better and more effectively. It also means I get to work with more technologies and more teams, which I've wanted to do for a long time. ...

With Christmas upon us, I thought it might be good to write a Christmas themed testing article.  How could you achieve that you are probably asking? You might be of the opinion that working in IT and Christmas are 2 entirely different things, but I’m not sure I’d agree with that, so I would like to compare the build up to Christmas as a parent and how it compares to the build up to a release of a piece of software, and the similarities between the two. Firstly, for any release of a product, or any Christmas purchasing has occurred, as a tester or as a parent, you like to know what the business or the children want, for the software release this will come in the form of requirements and in the form of children, this will probably be a nicely written letter to Santa!  Childs letter to Santa/Requirements for a User Story...  both want the world, but neither will get it. You could argue that both will have holes in them, and missing requirements, or gifts that are...

Apologies for the lack of updates recently, I've been very busy (kids, work promotion), but I've also got a few blog posts lined up for the next month or so, which i think you'll enjoy, here's one of them for you! I was thinking the other day over what makes a tester happy, and I thought I'd write down my findings, and share them with you, this isn't necessarily what makes me happy, but more around what I think can make any tester a happy tester :) 1 - Grow with your testing - Always look to progress as far as you can, never stop challenging yourself. 2 - Relationships - Relate with your other team members, become personable with them and talk to them about day to day stuff and not just work. 4 - Extra Mile - Go that extra mile to make things work, people will respect you for it, and people will do the same for you if you ever need it. 5 - A difference - Making a difference makes you feel valued and makes you feel part of a team that is delivering goo...

Do you feel luck punk? Well.... Do Ya? I've spoke of it in my very first blog post, about a developer who blindly put their code live without any testing, without any consideration for the side effects that may have been caused by his changes. I've got to think that before he put it live, that he asked himself "Do I feel lucky?" there's no other explanation for why he did what he did! So now, if anyone were to come to me and say I'm putting this live, without any testing (ignoring the gates that he/she would have to go through in order to get anything live..) I'd have to say to them: You've got to ask yourself one question: 'Do I feel lucky?' Well, do ya, punk?

I think when testing we sometimes come across a showstopper of a bug, that would stop the release in its tracks, what we don't want to have is a problem where the product owner isn't approachable, or won't listen to the full effects of the bug... This is where the following quote from A Few Good Men comes into play... You want the truth? You can't handle the truth!! We need to be careful how we communicate bugs, and not just showstoppers, if we raise a bug that isn't really that severe, but paint a picture of it being an absolute showstopper, well then we could get into a situation of the boy who cries wolf. We don't want to be in the situation where the business can't handle the truth about a bug, and you end up disguising the severity of it for whatever reason.

Many people are unfortunate enough to be in a job that they don't like, I won't use the word hate, as that's a strong word, but I'm sure it applies to some people. I'm lucky, in that when it boils down to it, I do enjoy doing what I do, I enjoy coming to work (and not just to get out the house!) I recently spent time off from work for 3 and a bit weeks, I must say I missed work, I missed the routine, but not only that I missed the people, the actual work I do, the challenges and just keeping my brain active. Sure enough we have bad days where we don't want to come back to work, and maybe the fact that I enjoy QA so much is about the environment I am in, and the people I work with, but I'm lucky to have worked in a number of places and enjoyed almost every one for different reasons. Drilling down into specifics, "Testing and QA", I thought what is it I love about it? Hence this blog post.... When I first started out in testing about 6 years ...

I like to think of the above quote can be applied to newly formed agile teams starting up, and the relationships between the members of the team, the Developers, the QA members, the scrum master and anyone else connected to the team. Obviously not every team succeeds and blossoms into a beautiful relationship, but I don't think I've been on a team where there hasn't been at least the foundations of a good solid relationship in the team. Maybe I've been blessed, but I like to think that every one buys into what we are trying to do, and I also like to think that we all help members of the team come out of their shell by talking to them and discussing with them any problems that we have in a way that's not condescending and just generally a friendly manner.

We can all become better testers, only some of us lack motivation, or some of us have the motivation but just tend to lose interest... One way we can tackle this, is by attempting to become a better tester one day at a time. It's much easier to tackle each day, and do something each day that makes you a better tester, than it is to say in 1 month I want to be a better tester.  Firstly, it's hard to define how you can become a better tester, but for me, one thing that would make me a better tester is to read more blogs and learn from experiences of others. With this in mind, I've made it a challenge to read at least 2 blogs a day from a testing blog feed. This is far easier than if I had set a goal to read 60 blogs a month for instance, it's also more manageable. If I don't do it one day, it's not the end of the world, but it's important to not lose heart. Also, I find it good to establish a daily habit, I like to read 2 blogs en route to work on a mo...

I've recently been off work for a little while (and will be for a few more weeks), and been able to spend a lot of time with my 2 year old son and my newly born daughter (hence the lack of posts!) I've realised something over these past few days, that every child is born with a natural ability or an intrinsic ability to "test". Obviously I'm not talking about testing software :) This is more about testing their surroundings, testing what they can and can not do with their toys and just testing themselves to see what they are truly capable of (that last one is definitely apt for my new born daughter!) Unfortunately, I believe this "intrinsic ability to test" is lost when they reach school to a degree, they are encouraged to not push the boundaries of things and to conform to some form of normality. It's made me realise that I will try and help my children to never lose this ability, and not because I want them to grow up to be like their daddy, ...

It was a bad weekend for me, my fantasy team lost, with regards to the fantasy team, it has shown to me that no matter how well you prepare, how well you plan, there are things that are going to happen that you just can not predict. Which leads me onto the title of this post, you can never guarantee bug free software. You can highlight the areas of risk and highlight what you have and haven't tested, to make business owners aware of what issues may arise, but you just can't guarantee bug free software being released. There are far too many variables that affect what you can and can't test unfortunately. Software is an extremely complex system, and this is ignoring hardware, which makes it even more complex. Going to an extreme, NASA have shown that it's possible to make "virtually" bug free software, but mistakes are still made, which are sometimes unfortunately, fatal. One solution is, as I said, to highlight the areas of risk, highlight what you have ...

Nobody puts baby in the corner... Replace Baby with "a bug" and you've got it. My wife loves this film (Dirty Dancing), so I thought it's only fair that I include this one. Nobody should find a bug and put it away in a corner to be forgotten about, even if it's not going to get fixed, a bug should be identified and known about so that it doesn't just get lost. I suppose this is linked to Cool Hand Luke, in that "What we have here is a failure to communicate", but it's deserving of it's own post as it's not just about communication, but understanding what a bug is and the side effects of said bug.

When I was in university I played football, not the English type, although I had played that all my life, but the American kind, with "offense" and "defense"  and "special teams".  I played defense and special teams, and both of them had what is known as a playbook (as does offense). This playbook had a list of plays that we would run in different scenarios depending on what the situation was or how risks averse we felt. The NFL season kicks off soon (next weekend in fact), and with this in mind, I was thinking this morning about how this can be used in testing, how we can have a playbook of different tests almost  all depending on the situation that we as testers find ourselves. Just like in football we find that if we just use one "play"  or one form of testing the likelihood of being successful is slim. We need to mix things up a bit and use a wide array of plays or testing techniques in order to score or stop the other team from scori...

I was recently reading a good friend of mines blog  Helen Meek  where she discusses 3 zones that are related to how you work, i'll briefly explain them here, but you can read the blog to find out more: Comfort Zone: This is where you're effectively coasting along, not challenging yourself in your day to day job. Learning Zone: This is where you challenge yourself and are learning new things constantly. Panic Zone: Where there's just panic, you may be challenging yourself, but probably not having the time to learn new things. I think, that too many people in Engineering are stuck in the Comfort Zone. They are bored easily, but don't want to do anything to change that as it involves challenging themselves and what they know. I want to help get people out of the comfort zone, but doing so isn't necessarily easy. To me, like most people I would bet, I'm most happy when I'm in the Learning Zone, I get bored and restless in the Comfort Zone, and the P...

You're gonna need a bigger boat? How can that relate to Engineering? Firstly, let me ashamedly admit, that I've never seen the whole of Jaws all the way through. It's on my list of films to watch, but whether I get round to it, is another matter! Anyway, to apply this to engineering, it's almost like "you're gonna need more testers/developers"... We hear this all too often when trying to push releases out the door, let's throw men at it... However, as we all know, a bigger boat/more men... isn't always the answer, it's not a guarantee of quality, or even a guarantee of getting things done quicker. If you have a task that will take 2 hours, simply having 2 people work on it doesn't mean that it is halved, in fact often, the time taken to do the task remains at 2 hours, but the maintainability and the knowledge around that area is increased, so it's a price, in my opinion that is often worth paying.

I thought it might be a bit fun to do a series of blog posts where we take a famous movie quote, and apply it somehow to QA/Testing or even the software engineering life-cycle. This is one famous movie quote, and I think it applies greatly to Engineering in general (or anywhere in fact)! I don't think a week has gone by in my career where I couldn't have uttered the following: What we have here is a failure to communicate (Cool Hand Luke) I saw this quote (although I haven't seen the film), and I don't even think it needs any explanation.... But I'll explain anyways! I would say that 80% of problems that are in a workplace are down to a failure in communication, if a bug is found, a failure to communicate the effects of the bug properly can lead to a false severity, or a false priority. That's not the only time when a failure to communicate can be damaging, especially for QA, but a failure to communicate when understanding requirements or when explain...

I've recently looked into creating a QA forum, at a request of a number of team members, where members of the QA community inside where I work can post questions or blog posts and share them with others. The benefits of using something like this over email is that it keeps everything in one place, it stores the questions for ever, so if we have new starters and they have a question they can look at these sites first before sending out an email. I've suggested OSQA as the question exchange software and we are just going to use a standard wiki for the blog post /information storage. I got asked how can we ensure that its kept up to date? As it will only really be useful if it is kept up to date. The simple answer is, that if it's not kept up to date then obviously people aren't using it so it's not that much of an issue if that is the case. If people are using it consistently then it should in theory stay up to date and be an excellent source of information fo...

We've all worked as part of a team as a tester before, whether that be in an Agile team where you work directly with developers or in a QA team in a more waterfall environment, but have we ever looked at how we can improve our relationships within the team? I'm not necessarily talking about nights out, although that undoubtedly helps, I'm talking about team relationships and enhancing them as you see fit. It's been a long time since I worked in a Waterfall environment, however, I think the same principles apply to waterfall as they do for agile when it comes to team relationships. When working in a team, the following are key principles that I think you should follow: Team first - Put the team first before any personal gain, if you are up for a promotion for instance, then don't just think about yourself, don't put your personal objectives above that of the team, this will be noticeable. Communicate freely with the team - Often I've been in teams whe...

We've all been there, we've fixed a bug, it went live, but then a future release broke the code that fixed the bug, and the bug was reintroduced, also known as a bug that has regressed. What if there was a way we could guarantee that bug could never be re-introduced into live again, that would be great right? Well, there is! If you already have an automated testing pack, be it in QTP, Selenium, CodedUI etc. then all you have to do is create an automated test that tests the bug, this test could even be a unit test (depending on the bug) and ensure that it is run before every release (even more often in an ideal world, as early feedback is good feedback). This way, if the automated test fails, then you know you have to fix it, as the bug has been reintroduced :) If you don't have an automated testing pack, well, if you can, create one! :) But I appreciate this isn't always possible, so in this case, create a manual test case and add it to a regression pack, to ens...

A recent project I was on meant testing a lot of legacy code,  in fact I think it was all legacy code! So I thought I'd write some bits about what the challenges are or what you should look for. Firstly, let me start by defining what I mean by legacy code. I have seen definitions of legacy code which state any code without unit tests can be defined as legacy, whilst this is true, I also like to think of legacy code as something that isn't being refactoring, isn't being improved upon, it is what it is, to quote Ronseal "it does exactly what it says on the tin". The problem with the Ronseal analogy, is that what happens if you can't find the tin? Or you can't make sense of the tin? This brings me onto the first challenge... In that if it is legacy code, and there's no supporting documentation around how it works or what certain features are for, then it makes our lives as testers (and developers) difficult. We have to ask questions over what certain ...

We have recently created an automated test suite to replace some of the manual tests that we used to run for regression. I'm finding the below more of an occurrence now!

I have in the past questioned the value in getting certifications/going on courses for the sake of getting a certificate in testing. Whilst I do still question the worth of such an issue, I have recently read some articles which has shown me there is more value in these courses/certificates than I previously gave them credit for. The main positive that I can think of, upon completing a course like an ISEB Foundation, is that it ensures that testers are on the same page when it comes to communicating. A bug is a bug, or if I'm speaking to someone about Integration testing, they know exactly what I am talking about and won't get confused. I think in ensuring that everybody is on the same page when it comes to discussing testing issues/testing activities, it helps in gaining respect and confidence from other teams and other team members, as we are all singing from the same hymn sheet.  It isn't just about communication in the term of words however, it is impor...

I recently took part in a PI assessment, for those that don't know what a PI assessment is, it's a behavioural assessment, the PI stands for Predictive Index. It asked 2 questions, and asked you to tick words that describe how you feel in reference to the questions.  The questions were (something like) : - Describe how you view yourself - Describe how you behave in your work environment You then had to tick as many words that you felt applied to the question.  I'm going to take the results of the assessment and hopefully try and explain how this applies to testing and how it makes me a good tester, also how it highlights things that I feel that I need to work on. The first part is to analyse your natural behaviours: ·         You are a team orientated person, co-operative and agreeable you seek harmony where you can. - I think this helps especially in working in an agile environment, where we work in such a...

We recently released to a number of teams our automated regression pack that has been worked on over the past few months. This regression pack tests legacy code, but contains a large number of tests.  As a bit of background, a number of teams are working on new solutions whilst some are still working on legacy code. With this in mind we constructed an email with a list of guidelines when creating new tests that need to be added to this regression pack.  I figured that these can be quite broad so should apply for any organisation, so thought it would make an interesting blog post...  So here goes,  when creating automated tests, it's important to consider and adhere to the following: - Think about data . The tests need to retrieve or set the data they need without any manual intervention - This should help them be more robust and easier to run without manual intervention. - The tests need to be idempotent - By making it so that each test is standalone and does...

We've all been there, working on a project when suddenly....

I was recently updating my LinkedIn ( Add me here if you like ) and I was looking through the skills, something that I find as a bit of a pointless feature, well, the endorsing of skills is a bit pointless, as I have people who I've never worked with endorsing me for skills that they really don't know I have, it's nice that they feel they can endorse me but it happens so often, that it kind of makes endorsements pointless? Anyway, I digress... There was a skill in there for the Software Testing Lifecycle, and I thought about it, and what it meant. It's saying that you can have a skill in just the software testing lifecycle, but in my opinion, we should be moving away from this, we shouldn't be focusing on just the testing phases, we as QA should be involved from the offset, and hence, we shouldn't just be having a Software Testing Lifecycle as a skill, we should be aiming for having the Software Development Lifecycle, as we are all (Devs and QAs) involved in t...

I often try and think of ways that I can offer value to my company by going above and beyond that of a standard QA. Whilst this will vary from company to company, I've decided to list ways that I try and go above and beyond in my company and my role to help out and offer as much value as possible. These are in no particular order, but here goes: 1 - Share your domain knowledge, whilst this should be a given, all too often this isn't the case. If someone asks for help on a particular subject, help them, don't just say I'll do it and let you know when it's done. If you show them then they will hopefully learn and be able to help others, and become less reliant on you and your time. 2 - Offer your help whenever you can, if you do have an expertise in a particular system, or something you have worked on in the past, when issues arise, don't shy away from offering advice, or offering solutions to problems. This will get your name out there and people will tak...

We recently came across a problem with Selenium not quitting the webdriver and this would then lock a file that was needed on the build server to run the builds. We were using Driver.Quit() but this sometimes failed and would leave chromedriver.exe running. I looked around and found this was a common issue that many people were having. We (I say we, as we came to the solution through paired programming), came up with the following, that would encapsulate the driver.quit inside a task and if this task takes longer than 10 seconds, then it will clean up any processes started by the current process, in the case of the issue on the build server, it would kill any process started by Nunit. [AfterTestRun]         public static void AfterTestRun()         {             var nativeDriverQuit = Task.Factory.StartNew(() => Driver.Quit());             if (!nativeDriverQuit.Wait(TimeSpan.Fr...

I recently wrote a little function that takes a screenshot at the end of a test if it has errored. What sounded very simple at the start turned out to be quite a bit of work, and quite a few lines of code to handle certain scenarios! It's now over 50 lines of code! I'll start with what I had at the beginning, this was to simply take a screenshot in the working directory, we are using SpecFlow and Selenium to run the tests, so we are going to check if the ScenarioContext.Current.TestError isn't null, if it is, then using Selenium, take a screenshot (note the below code is a simplified version of what I had at the beginning). [AfterScenario]         public static void TakeScreenShotOnError()         {             if (ScenarioContext.Current.TestError == null) return;             var screenshotDriver = Driver as ITakesScreenshot;             if (screenshotD...