Skip to main content

Twas the night before Christmas and testers were testing....

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 probably not really practical, like a pony for instance! It’s then down to the team to drill down and find out about the missing requirements, or for the pony, well it’s probably best to set expectations for the child…. Children and Product Owners can be very similar, they will want the world, but it’s up to you as a team to manage their expectations! They will also both want it to be delivered early, whether that’s giving them their presents early or delivering the software as early as possible! Obviously this isn't practical, especially for the presents! Although, release dates can be brought forward, in that case items may be descoped due to time constraints.


Once you've gathered the requirements, the next step is planning on how you’ll test it, or in the case of Christmas, plan on a) how you’re going to afford it all and b) when you’re going to buy it! With regards to the tester with the software, it’ll be a case of analyzing the requirements and coming up with appropriate test cases based on the testing strategy that they are following for the project. If the team feel they can not commit to delivering the software by a certain date, they might speak to the Product Owner and explain why, and then some features might get descoped for a future release, similarly, if the parents feel they can’t afford to purchase everything on the list, then some items will get “descoped” for a future celebration, like a birthday etc.


As the Release/Christmas day gets closer, the planning and execution is in full swing, testers are testing the software and raising bugs, parents are wrapping presents, buying presents, decorating the house and ensuring that no presents are missing that they wanted to get! Teams are getting anxious to release their software and see it in live, parents are getting anxious to see their kids faces when they open their presents.


Regression testing and Christmas Eve are very similar, they’re often very stressful (ensuring no late bugs are found and the release plan is prepared, or ensuring that all presents are wrapped and Father Christmas has been to put the presents under the tree), but hopefully it all goes without a hitch, and the software is ready to go into live and the presents are ready to be unwrapped under the tree!




So, the end is sight, often where I've worked we've done overnight releases due to the high volume of traffic and infrastructure restraints, so I’ve often struggled to go to sleep before a release, and as a Parent, I will no doubt struggle to sleep this Christmas eve, in preparation of an awesome Christmas morning for my family. So in that way, they are similar.


Obviously, they are different, for instance I’m yet to meet anyone who has had to rollback Christmas, I’m sure there have been threats to naughty kids on Christmas morning! But I doubt anyone has actually had to follow through, but we all know rollback of releases are something that can happen unfortunately, no matter how well you plan for something like a software release things can cause issues in live. Also, as I mentioned earlier, Christmas does not change it’s date for anyone, except maybe Jesus, but release dates can and will change. Christmas is probably more waterfall than agile, but it’s an interesting concept.


I love Christmas, and I also love testing, for what I initially would have thought for different reasons, but after writing this article, there are similarities that I otherwise wouldn't have thought of. For instance, I love seeing the face on my son, and will love to see the face on my daughter when she’s older, just like I love seeing something I have worked on make it’s way to live and be used by people in the “real world”. I am good at managing people's expectations, if we promise the world at Christmas or for a piece of software, when it comes to implementation, then people will be disappointed.  I love planning on how best to test things, just like I love buying gifts for my family and children.

So, here's an early Happy Christmas, may your Christmas be as successful as your well tested and well planned releases!!!

Comments

  1. Torrentsformac
    A free download hub to activate, crack your softwares for windows and you mac. you can download keygen, generator and activators to crack your desired Final Cut Pro X Crack With Activation Key

    ReplyDelete
  2. I absolutely love your blog and find many of your post's to be just what I'm looking for. Does one offer guest writers to write content for yourself? I wouldn't mind writing a post or elaborating on a number of the subjects you write regarding here. Again, awesome web log!designer door handles

    ReplyDelete
  3. Does your website have a contact page? I'm having problems locating it but, I'd like to send you an e-mail. I've got some ideas for your blog you might be interested in hearing. Either way, great website and I look forward to seeing it expand over time.Decision Support And Business Intelligence Turban test bank & solutions manual

    ReplyDelete
  4. A great post , i will definitely share it across my other network best budget hotel in georgetown

    ReplyDelete

Post a Comment

Popular posts from this blog

Coding something simple.... or not! Taking a screenshot on error using Selenium WebDriver

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

How to manage resources within new teams?

Working where I work we are constantly spinning up new teams to take on new workloads as business come up with new demands and new features they want developed and tested. The problem with this is how do we ensure the work of the newly spun up team is of sufficient quality. One method is by taking people from other established teams and placing them on the new team. This works great for the new team, but unfortunately it will oftenl eave the established team lacking in a resource whilst they try and fill the gap left by the person who has left. We are seeing this often with our offshore teams, it can be damaging to the team structure and the teams velocity, but try as I might, I can't think of another way around it. It's far easier to take 1 person from a team that is established than it is to build a whole new team from scratch. At least by leaving the core of a team in place, you should be guaranteeing that the new team are aware of any coding standards or any QA standard...

Considerations when creating automated tests

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