Shortly after becoming a Father for the second time, I thought I was about to become a slave to ‘routine’. ‘Sure the first one had his bottle at this time, so we’ll do this with the newborn, ‘sure when the first one cried during the night, we did this, let’s do this with the newborn’, ‘sure the first one slept during these hours, so will the newborn’ and so on.
Now as anyone who has had more than one child will testify, it’s not as simple as this. Things that worked the first time around can be pretty much obsolete this time, they were outdated, irrelevant and just didn’t work. Essentially, routine went not only out the window, so much as straight through the glass.
So what do you do? Do you persevere with the tried and tested even though it may be outdated and doesn’t fit anymore or do you invent different ways?
After all necessity is the Mother of innovation
The answer is of course the latter. You adapt your approach to the situation at hand, try things, they may work, they may not, toss them out (the idea, not the baby), tinker the approach, reinvent it. You end up finding a rhythm that suits and an approach that works. You end up with the same result (all being well) a healthy growing baby, but raised a different way than his older sibling.
Now what if we were testing software and not raising children?
Consider the following. Test Manager Seamie is given the responsibility for testing the initial release which is a new product going to market, after weeks of coming up with an approach, reviewing, refactoring and essentially agonizing, the test approach that best suits the product (and the company’s testing ethos) is in place. Given the company’s commitment to agile development, Seamie has put in place a mostly automated approach based on end user scenarios. He has agreed that the Test team will work approximately ¼ of a sprint behind development and this gives the automation time to catch up and test the stories and functionality in an automated fashion.
Now, there is nothing whatsoever wrong in Seamie’s approach. It is what I like to term ‘agile lite’ in that it takes whatever facets of agile that best suit the company’s make-up and utilizes them. Not fully blown agile (not any company claiming to be agile that I have ever come in contact with actually is) but that’s ok. It’s ok to adopt an agile approach to being agile
As it turns out, Seamie’s approach is very successful. The product is delivered on or around time, the testing effort found a number of issues (mainly early), the test pack is 95% automated and quick to run, customer beta testing was a success and straightforward and the testing effort suited the Test team and the Development team who were both equally comfortable with the style. – GOLDEN CHILD
Due to its success, another Product Owner in the same company but responsible for a different area has come to Seamie asking him to lead the testing for a similar type product. However, this product offers different functionality and isn’t so open to automation. In addition, the development team here are ‘pure agilists’, they want their Test team to work with them in getting a story ‘done done’ once development is complete. Seamie tries to adopt the same approach to project 2 as he did in project 1. This leads to confusion over where the overall effort is and what is required, friction between the Test and Development teams and to the eventual breakdown of communication resulting in long delays to project 2 and damaged reputations – PROBLEM CHILD
A short story, straight to video and a little general maybe. But this is a common problem today in the Testing world. I have seen this on a number of occasions throughout the years. In people terms it is what we would deem as ‘set in our ways’, it’s the way it’s’ always been so it is the way it is. What could and should Jamie have done for project 2?
Well, for starters the best way to approach any project, irrelevant of how ‘similar’ it may seem to a previous one is to treat it as standalone initially. Ask the question, ‘if I had a blank sheet in front of me with ANYTHING or ANY OPTION open to me, how would I test this?’ Re-invent testing each time! You may come out at the same destination each time (hopefully not or you should maybe re-consider your career as you are most likely getting stale in Testing) but each time new ideas should come out, mistakes from last time can be called out and made priorities this time, tools, ‘what ifs’, etc. should all come out.
After that, ask this question ‘what makes this project different (no matter how small) from previous projects?’ each project, even subsequent releases, have something new or different than before. Make sure you know, inside out, what those are and their usage. How will they be used, how could they be used, and what will a customer think of doing here? All these will help you build a picture as to what ‘extra’ you have to bring to your testing effort.
Finally and only finally, what facets of a previous project can I re-use? This has to be the question asked last. Why? Because, it keeps your mind fresh, sharp and doesn’t allow you to become lazy. If you ask this question up top, you probably won’t get to questions 1 and 2.
Don’t be a slave to routine because ‘it’s the way I did it before’. Things that worked previously may work this time but may not, new things may work but may not. But ask the above questions first – don’t assume and worse still, don’t shoe horn them in as Testing, as is raising babies, is not a ‘one size fits all’ business.
What you will find though is that after a few projects, you will start to notice patterns and this will eventually equate to different ways of doing similar things. Different approaches, tools, mindsets that all lead us to releasable software and a tested (as best we can) product. As mentioned earlier, we end up with the common result but their journeys may take different paths.
A healthy growing baby but raised a different way than his older sibling!
No comments:
Post a Comment