KJRA Summer School 2010, come fly with me...

Great food, great company and thought provoking discussions what more could you ask for?This was my first KJRA Summer School and for me it brought back many memories of my formative years attending a boarding school in western NSW. The location of summer school was the 'The Women's Collage' at the university of Queensland, which is steeped in history. The halls of residence where we stayed opened in the late 1950's and reminded me of the accommodation I lived in whilst completing year 12. At the time, the year 12 accommodation was the pinnacle, single rooms with a balcony. Oh I waited patiently "doing my time" for 5 years to ascend into "Hindmarsh". The memories of hot summers night with only a fan for cooling, sleeping without any covering flooded on back. However the most confronting thing about attending summer school at a women's collage was that in the bathrooms there was full length mirrors, and round mirrors over the sinks which didn't just reflect, but magnified ones face so that all the blemished became blindingly obvious! Back in the day, the bathrooms where I went to school had only a single mirror over one of the sinks for those of us that needed to shave! So being confronted with ones unshaven, just woken up reflection was a memory I'd rather not have gained!

I do love the boarding house/summer school/residential school setup where the focus is on community and communal activities. At school, as at summer school you never ate alone there was always someone too share a conversation at meal time. Talking about the events of the day, sports or conquering great plans for the nights activities! and that's one of the other great things group activities that inspire laughter and cooperation. Back in the day we played pool in the common room, or went 'out bush' into the forest in our younger years building cubby houses for all manner of adventure, and during summer swimming in the mighty Murrumbidgee river was a great way to pass the time and keep cool. At summer school some of the old favourites were played the egg and spoon race, sack races and the three legged race began the evening. Then we fast forwarded to what seems to be the in thing at the moment with Guitar Hero - World tour. After several rounds, each increasing in difficulty Todd was crowned the guitar hero hero! That was Thursday night, Friday night was 80's night and it was fabulous to see some of the attendees dress up! Oh the fashion crimes that occurred in the 80's :-)

I finished summer school on Saturday, checking out of my room which incidentally bore a plarke on the door frame "The John Graham Miller room, endowed by Mrs Rina Miller" which I pondered for some time. It wasn't the only room to be named after a bloke oh if only those walls could talk!!!

I sat in on the Test Project Management course for the morning which was the source of much inspiration on the trip home! On Friday whilst delivering the Agile Testing Course I quoted a Prince2 trainer (somewhat strange I know given some peoples views on Prince2 and Agile) that I'd heard say "The Project Management should be like a modern day pilot (with all due respect) in that he/she should plan the flight, get the plane ready, take off and then switch on the auto pilot - monitoring the progress at key points making corrections as necessary. Then plan the landing, land and disembark the passengers". In the context of Prince2 it made a lot of sense and on the flight back from Brisbane I juxtaposed some of my experiences as a test manager to that of a pilot, so come fly with me.

Thinking of myself as a pilot is an interesting thought and gives a much better visual than when I tried to explain the role of testers (many years ago) to a group of developers as 'life guards' to which they replied "in speedo's? LOL". But anyway, my comparison starts with the pilot receiving instructions of the flight that he/she is to take charge of today. I imagine there are several key details that the instruction contains: the aircraft, destination, departure time, flight crew, number of passengers and expected weather conditions on route. In my experience as a test manager I've received similar briefs about the project I'm going to be managing; intended release date, commencement date, testing resources allocated, scope of testing and warnings about the political landscape!

After receiving the flight instructions even the most experienced of pilots will research the route, weather and all manner of other details (assuming the flight assignment details are allocated several days in advance of the flight) steadily building the plan of the flight. On the day of the flight, the flight plan will be finalised with details of the flight path, check points, , altitude, number of passengers, expected take off weight, boarding gate allocation, expected boarding time, flight deck and cabin crew assignments.

In a test management context, this period equates to the period after you've received the initial project brief through until your troops begin arriving on the ground (covering the development and documentation of a master test plan). You will have discovered all manner of details about the project, including who the key stakeholders are, key stage gates (i.e. change control windows), allocated manual, automated and performance testing resources, environment availability, development and requirements status. All of these (and many more) elements are all considered in the development of a test plan, and each influences how the plan is implemented.

Now with the plan matured it's time to implement. In the case of the pilot, a pre-flight briefing might be the vehicle to bring all the aircraft crew up to speed. Then it's off to the boarding gate to commence the pre-flight checks. The process of getting the plane off the ground involves numerous activities, in my comparison I've focused on the following; the boarding of the passengers (Test Cases), load the catering (Test Data), Storing the luggage below and most importantly load enough fuel (defects) to complete the flight! To me, the process and activities surrounding taking flight are somewhat similar pre-requisites for commencing testing. Ideally at the commencement of a testing program the parameters would be as well defined! Can you image knowing at the commencement of testing outer limits of scope and duration? With a plane its absolutely defined, as a plane can only fit X passengers, has a maximum take off weight and maximum distance it can travel, therefore limiting overall capacity.

The nature of testing often prevents such well defined boundaries, but that's not to say we shouldn't have a detailed understanding of the testing we are about to undertake. In my comparison I've compared the passengers to test cases, and the reason being is the success of a flight can be measured in terms of did it arrive on time which is a quantitative measure, and perhaps more importantly were the passengers satisfied with the quality of the flight in terms of service, comfort and timeliness. Test cases also have quantitative measures such as 'were they all run' which by its itself doesn't provide enough depth to make a definitive statement about success. One needs to look deeper into the results, how many passed, how many failed and what was the magnitude of the failure? More on that later.

Once all the passengers, luggage and catering is loaded its time to depart! Even as a test manager I still get excited when a new build arrives in the test environment, its like the anticipation of taking off once you've boarded a flight you know you ever so close to taking off and you just want to be in the sky! Once clearance to taxi is granted we push back from the gate and taxi to the runway. At this point in the testing process I like to have the test strategy signed off, test cases reviewed and accepted - essentially all my 'Entry Criteria' met so testing can commence. The take off, by far one of the most exciting or scary parts of the trip, as the plane accelerates down the runaway and the G-force pushes you back in your chair and then the point where the plane lifts off the ground - I'll never get tried of that feeling! Often there is a little bit turbulence or bumps as the plane assents into the sky, in the same way as the first delivery of the 'build' often experiences some difficulty being deployed into the test environment. And once your in the sky and the seat belt sign goes off you know you're on the way... This is the equivalent of getting the green light to start testing and so it begins!

Now we're in the sky climbing to the cruising altitude and constantly monitoring all manner of things - weather, wind, cabin pressure and fuel consumption. Fuel consumption I found has some interesting similarities to defects - what tha I here you say. But think about it this way, as the requirements and code are developed defects creep in and steadily build up, then once testing commences (at any level) these defects are discovered and removed. Compare this to the fuel for a plane. The fuel required to make the flight is loaded pre-take off, then as the flight progresses the amount of fuel consumed increases to the point where by the time the plane lands the fuel load is minimal. This is exactly the trend that we want to observe with our testing, that at the beginning of the testing cycle the defect detection rate is high and then as testing progresses the rate decreases, corresponding the number of residual defects decreasing. After all defects are the fuel of testing! While there are defects there will be testing :-) it's not a perfect model, but I like it.

Whilst in the air the passengers consume the catering and the plane steadily makes its way to the destination. The pilot (or co-pilot) monitors the progress along the planned flight path making adjustments as required and all if fine. Then out of no where, that clear trouble maker of the skies strikes, turbulence and has the capacity to effect all on board. The pilot has several options depending on the severity encountered, turn on the seat belt sign, adjust the altitude and/or the flight path (as happened on my flight). In terms of testing, turbulence could be equated to a change in scope mid way through testing, or test environment issues or requirements or code instability. Any of these (and many more) issues often result in the test manager having to make adjustments to the plan! and its just a natural part of the process.

Newtons Law states "What goes up, must come down" and as the destination draws closer its' time to prepare the cabin for landing. All passengers need to return to there seats and place luggage appropriately. Throughout the flight the pilot is in constant communication with Air Traffic control, reporting location and status, and as the pilot prepares to descend, permission to land needs to be sort. The air traffic controller can be compared to either the stakeholders or the project manager whom need to be kept update to constantly about the status of testing -also making decisions in regards to ending testing. In terms of testing this is the point in the cycle where the test manager starts to make sure all is in order, all test cases have been attempted, the defect status is published and understood, requirements coverage is assessed and the test report is in draft. As with the take off there are many factors that influence the 'smoothness' of the landing and the pilot must continually monitor and adjust whilst approaching the runway. In this period even minor issues can have disastrous effects, but more often that now the plane touches down with little or no noticeable issues to the passengers. Once safely on the ground its time to taxi to the terminal and disembark the passengers.

Disembarking the passengers is a key 'milestone' of the flight and its at this point where the quality of the flight can begin to be assessed. Flights like testing cycles have both qualitative and quantitative measures of success. quantitative measures like all statistics are open for interpretation and qualitative measures are subjective so its important to gather both for consideration of 'success'. Its also important to have a definition of what 'success' is at the commencement of the project. Many would argue that simply reached your destination is only part of a satisfactory outcome!

With the plane on the ground, passengers and their luggage disembarked the pilot must complete some paperwork and then its off onto the next assignment. As the test manager wrapping up the testing cycle, the test report is usually the way to close out the testing for this project...

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!