Team building on two wheels...

As luck would have it, all of the KJRA consultants who actually live in Canberra own, and ride cruiser style motorcycles! Michael rides a Suziki Boulevard, Neil rides a vintage Yamaha Virago and I ride a Harley Fatboy which as Johnny and Behzad said 'sounds evil'. So in the spirit of team building and hitting the open road those of us (Michael & I) who were on leave headed out for a day's ride.

The rendezvous point was Bungendore which is about 30 mins drive from Canberra on the way to the coast. We had previously decided that rather than battle with the hoards of Canberrians heading to the coast for New Years that we'd head in land and so Tarago was the next stop. The ride is along well sealed roads country roads and accordingly there is minimal traffic. We pasted the newest (and largest) of the districts wind farms and it is just amazing the size of the turbines they are huge. I counted 15 towers, but apparently there is actually 25 in total. Once we reached Tarago 'The Loaded Dog Hotel' was our pub of choice, its steeped in history having opened in 1848 and really there is not much else in Tarago! We had a yarn with the publican, who was most interested in the 'hoops' one had to go through to get a bike license these days. There was a couple of friendly locals and a hand full of other bikers, but the road was calling!

From Tarago we headed for Goulburn and then on to Crookwell, passing by another wind farm which was much smaller than the one we passed earlier. Crookwell was the designated fuel stop for both man and machine, and I thought getting a Pie n sauce might have been an easy option for lunch. However it seems it would have been far easier to go for a pub lunch. The first bakery we stopped at looked open but was not, and then the second bakery we found was open but didn't sell pies or sausage rolls - which was most curious. To my way of thinking this makes it more of a cafe than a bakery. The lady in the no pies bakery said if its pies your after then try 'Barkers Bakery' down the street and so with this vital piece of local knowledge we pushed on in the quest for the great Aussie lunch. Finally we arrived at Barkers and surveyed the offerings of pies on the menu boards, and I asked for a steak and mushroom pie only to be disappointed once again. Since it was getting close to 1:30pm the pie stocks had dwindled and alas no Steak and mushroom pies were left - Doh! So Michael and I changed tack, and asked "well what do you have?" luckily there was two pepper steak pies left so Michael and I didn't have to go toe to toe over who ate and who didn't.

Now that the men were full, it was time to feed the machines and head for home. The road between Crookwell and Gunning is fabulous those of us that enjoy two wheels and loads of twist and turns, with some gentle rises and downhill runs for some great riding. As seemed to be the pattern thus far we passed yet another wind farm and we quite rightly questioned if we'd joined the southern NSW wind farm tour! At the end of this short run is Gunning where three more bikes just out for a run tagged along as we headed too Gundaroo, our final stop. To keep our stops consistent, we pulled into 'Matt's Wine Bar' for a quite ale.

My final comments relate to bugs (well we are a testing company!). Along the some of the 250 odd kilometers we covered we discovered more than a few bugs! There was the bugs that went SPLAT as they hit my sunnies, the ones that went THUD as the collided with my helmet and the rather interesting ones that caused me to go OH Sh!t that hurt as they smacked me in the cheek. Though none of these compared to the legend of the Christmas Beetle that the publican at the Loaded Dog spoke about. He said he'd seen results of an encounter with one of hovering bricks that had crunched into a fellow open face helmet, Harley riding compardray and it wasn't a pretty site! A welt as big as your elbow, squarely in the middle of his head. And he said if you looked close enough you could see the outline of the jolly fatmans' face in the mooshing of blood and skin were skull met beetle! I'll just have to trust him on that one, but needless to say I was on high alert watching for the hovering beasties and even ducked under a couple to avoid a collision. We were within 50kms of home and blasting down the Gundaroo Rd when out of no where BANG! a bug of some sort smashed into the lower rim of my sunnies, and as if that wasn't scary enough then I felt the wriggling and squirming of the bug behind my glasses on my eye lid - seems this bug was not done yet! It would have been so much simple had he just sucked it up and died when he got split in two by my glasses, but no he wanted to fight some more. Luckily for me he was under the right hand side of my glasses and easily squished with my left hand (the now on the accelerator!).

All in all it was a great day for bike riding and a fitting start to a new KJRA Canberra tradition of two wheeled team building. Until new time stay rubber side down and shinny side up!

It's all about testing!

As I look back on the year that has been and ponder the year ahead I have a smug little smile on my face, and not just from the Christmas cheer that I've over dosed on!

The project that I am currently working on is like any other, multiple systems, tight deadlines, thorw in the mad rush to get all the loose ends tied up before the Christmas break and its pretty much situation normal.

So for several months now I've been telling anyone that will listen, that "the sooner they realise this project is all about testing and that my needs are the most important the better off they will be!" Self centred I know, however I see a large part of my role is keeping testing at the front of every ones minds. Some days I feel like a little kid saying "don't forget about me" but if that's what it takes to ensure that testing is not left out of the information/communication loop then I'm ok with that.

Well in the lead up to Christmas I received a couple of most welcome, and unexpected Christmas presents partly due to my nagging. Both the project manager, and the software engineering manager commented separately to me "This project is all about testing" and without too much of a "I told you so" look on my face I replied with "indeed it is". It's amazing how the acknowledgement of the importance of testing to the projects success lifted the spirits in the run to up Christmas break.

I've been able to establish several reasons for the realisation of the importance of testing to the project. Firstly, the sign off of several key testing areas (performance & SOE) are absolutely critical and not negotiable if we want to release our software into the production network. Secondly, acceptance of the software by the stakeholders is largley based on the results of the final acceptance testing; and sign off of the Acceptance Test Report is therefore a key milestone. Finally, because I said so, and will continue too remind them.

What do you do if there are no requirements?

Towards the end of last year (2009) I was delivering a one day training course on Agile Test Management and as we were wrapping up one of the students asked "what do you do if there are no documented requirements?" Its a question that has been asked many a time, and I came across the answer I gave, well before I understood what Agile was.

I was working on a project that I now understand was using one of the Agile methodologies Feature Driven Development. I remember clearly enjoying a coffee with the test manager mid afternoon and discussing our approach to the documentation of the test cases and our analysis of the requirements specifications; and one of the comments which has stuck with me ever since was "well you know that documenting test cases is really just further derivation of the requirements. Because by documenting positive and negative tests you are refining the requirement to say that not only does the system act in accordance with the requirement, but also does or doesn't behave inline with the test conditions you've specified." Now, several years on I have found many a time when this is exactly the case.

Whilst testing on a subsequent Agile project, following a scrum methodology, I found that it was my test cases that modeled many of the system behavior. In this instance where the story said something like "must be able to save an Agreement with the minimum data set date, amount, client..." it was the testing that I did with fields missing, maximum text entered, alphabetic characters in numeric fields and alike that formed the basis of the error checking implemented. So the derivation of the requirement now meant that the requirement was "must be able to save an Agreement with the minimum data set including valid dates, an positive, integer value for the agreement dollar amount, a valid Australian format date in the future for the beginning and end dates of the agreement. All of these test cases where derived from the fields present on the screen and a little discussion with the business and developers.

My answer to the student also included another school of thought that I subscribe to "requirements are everywhere and are not always contained in a BRS document". One of the lessons I learnt early on was that in the absence of specific system documentation there are so many other sources of system requirements. The system itself contains almost all of the requirements in implemented form, and by exercising it in a structured manner you will be able to discover them. A simple example I use is to just click the Save or Submit button on a screen and there is a pretty good chance you'll find out what the minimum data requirement to save is!

Another potential untapped requirements repository is the system Help and Training documentation which will often tell you what to do, as well as what not to do. My response on the day also included speaking to the 'power users' of the system and asked them about how they use the system on a day to day basis, and then reverse engineer the requirements from there.

While researching another presentation I re-read the marvelous book "Lessons Learnt in Software Testing" by Karner, Bach and Pettichord 2002 and came across lesson 179 from "Take advantage of other sources of information. You aren't helpless if no one gives you a specification. Plenty of other sources of information can help you steer your thinking..." The lesson goes on to list many sources of information to assist with testing and further demonstrates my point about requirements being abundant you just have to know where to look.

The final part of my response was to leverage the knowledge capital in your organisation, by having some of the more experienced people in the team/project review and agree to your test cases, and therefore test your derived requirements.

"I Just break it" a simple catch phase

I've often been quoted as saying "I just break it" around my workplace, and to some extent there is some truth to the catch phase.

On my current project, like most projects as the test manager I'm not in control of any 'development/technical resources' and therefore the most visible aspect of what my team does is gained via the incidents logged when something is considered 'broken'. Of course there is far more to testing software than purely seeking to break the system, it is equally as important to prove it works! Though more often than not (I've only worked at one site were the number of completed tests was more important than the residual defects) the decision makers focus there attention on whats not working rather than whats working. For example recently I prepared a presentation on the progress of testing, one slide for test procedure results, four slides for outstanding defects and when the presentation was given there was an exponential difference in the time spent discussion the procedures vs the outstanding defects. Some (including me) could/would argue that the discussion of the outstanding defects given the link to failed/not completed test procedures, should be attributed to the procedures slide discussion, rather than the defects. However at the end of the day we tend to focus on the broken bits more so than whats working because of the broken bits implies it requires fixing and that has a visible/measurable resource cost associated with it.

So you may ask why do you tout the "I just break it" ideology when there is sooooo much more to testing than just breaking software. Well I see the role testing to give an assessment of a software solution (component, system etc) at a point in time, against a set of criteria. The criteria could be a requirements document or a capability brief or a verbal direction. The end state of this process is that the testing outcomes (test case results and incidents) are delivered to the requester for consideration. The requester will (should/might) take the outcomes into consideration when making their decisions. I use the just break it analogy to draw a conceptual boundary around the outcomes I (and my team) will provide, so there should be no misconception that at the end of testing the software will be (close to) bug free - instead collectively we should be better informed about the software's' operations and limitations. We should also understand the effort required to 'close the gap' between working and not working and were the effort needs to come from.

And while we/were are talking about catch phases - you may or may not have heard of Catch Phase the TV game show on in Australia (Channel 9 I think?). I recall the host saying to the contestants "See it and say it" and that's now what I say to my team in regards to system abnormalities they observe during testing. Its been an essential part of my testing philosophy for many years now that just because an incident is recorded doesn't mean its going to be fixed. And to those who scream out about the statistical implications I say - there are three (3) types of lies; lies; damn lies and statistics!