Some amazing blog articles ...

Was it only yesterday I said I was aiming to be quiet?

I did a review of the articles I've read in the last couple of weeks - most are favourited on Twitter (so easy to look back).

Interestingly, reading isn't a silent activity.  And by that I don't mean I mumble when I read.  If you come across good ideas they challenge you, and you also want to champion.  And so here are the articles which most have made me think this last month ...

The Role of Testing

Let's start with Scott Barbers article about 10 things about testing which should die.  If there is just one recommendation of mine you should read, it's this one.  I don't agree with a few of them, but they are really some great points there for you to review as a tester.

The big challenge there is really, stop behaving like a spoiled child.  The idea that some testers relish their ability to disrupt delivery as a kind of power trip.  This was echoed in another article by Eliza F, Oi you tester, where she points out "being a mean tester doesn't make you a clever tester".

It's perhaps right, something about testing we need to challenge, the trait inside us to look at a train wreck and go "if only they'd listened to us".  Rob Lambert also touched on this on the review of a conference, where there was a talk about "them and us" referring to "developers and testers".

I heartily agree, developers and testers need to have a working relationship.  Although my friend Russell went too far when he ended up marrying his tester, Maxine.  Like I've said many times, developers are like strikers in soccer, and testers are goalkeepers.  We do different things, but we're part of the same team, and we need to understand the ways we support each other.

In that vein then, I found the following presentation by David Evans about What testers and developers can learn from each other fascinating.

Talking about developers

If I have a second "must-read" recommendation it's the following article about developer habits.  We all know the stereotype of developers working until late.  Why programmers work at night is just a piece of absolute brilliance.

It explores why when dealing with something complex like programming, your mind needs to focus for long periods of time.  It's not something which can be stop-started by interruptions of meetings etc.  As an ex-developer I agree, when code has clicked in your head, you just can't get it written fast enough, and you need to be left to get it out of your head.  It's a fragile thing and interruptions disrupt it.

What I'd pick up from this is in an ideal world you'd try and have any meetings with developers within the first two hours of the day, and try and leave them to get on with it the rest of the day.  Fits in with the Agile idea of stand up meetings at the start of day.  Pester them and they're less productive.

I will give this to my project managers to have a read on Monday.

Bringing fun right back

Oliver Erlewin's article on Fun, IT and quality was interesting to read.  Are we losing sight of the fact testing should be fun, we should feel engaged rather than down-trod and under pressure?  I know I'm getting guilty of that.

Likewise I loved Brent M Jensen's discussion about how he socialised what testing was doing in his workplace in Speed date your way to better software.  These seem like quirky and silly exercises, but bringing fun into the workplace is about getting testers more engaged on what they're doing rather than doing the "test zombie" workforce who might as well be test automation machines, never varying what they test, never exploring.

Building on from that Olaf Lewitz discussed What makes a good tester, championing problem finders and problem solvers.  We're perhaps more famous as testers for the former over the latter.

And finally

Rosie Sherrie wrote a brief article on The tester and the marketeer.  I am working on more and more projects which are led by marketing, and I do hopes she revisits and expands this.


And finally - just for kicks.  We all know our favourite websites.  Everyone moans every time Facebook or Twitter changes or evolves.  This article reminds us what they looked like when they first launched.

Shhh - the sound of learning ...

I'm going to attempt to be very quiet this month, but I'm going to tell you why ...

Writing this blog is a great experience, and it really helps me in my work.  However as part of an experiment, I'm aiming this month to divert my energies from writing to reading.

Why?  Well just as a way of exposing myself to other testers ideas.

I'd been thinking about this anyway - but then was inspired by Lisa Crispin's article on Professional Growth in the December edition of Teatime With Testers (well there's also an article there by yours truly).

In it she talks of the importance to find time each week for some professional growth.  This is kind of true.  Most of what I've learned is self-taught through home study.

These days though I don't have the time to work through text books like I used to.  I might tackle an area or a chapter.

I find Twitter really useful, and keep a professional Twitter account.  I have a 25 minute commute to work via train, and use it to follow several testers around the world.  I find better than test books is reading blog articles.  They expose you to a small area, with a couple of ideas, and a little bit of opinion. But it's easily digestible.  And they often provoke ideas or reactions.

I'm also a big believer that the best way to learn about testing is to not just learn about testing.  Most of this blog is about looking at things like sport or films or Star Wars (not that Star Wars isn't a film) and looking for the parallels and the parables which we can bring back to our professional life and be better at our job.  Learn but in a fun way that it doesn't feel like learning.

Okay - so here are some great places to start.  There are a few online testers magazines out there, which contain an absolute rogue's gallery (but in a good way) of articles,

Testing Planet (which I sometimes edit articles for, but ironically never been published in) ...
http://www.thetestingplanet.com/

Tea Time With Testers
http://www.teatimewithtesters.com/

Testing Circus (which I've had the Agile Haka published in)
http://testingcircus.com/default.aspx




I'll try and return at some point and list some of the better articles I've experienced ...

A year of blogging and for what?

I'm coming up to a year of blogging  on testing, and it's interesting to reflect back.

I first came up with the idea of this blog really as a place to collect some useful materials.  I've always worked in my companies as a mentor, and imagined this place as a mentoring hub for anywhere I'd work in future, rather than my hard work being locked into the company intranet of somewhere I'd long left.

But as 2011 turned, I moved out of just testing and into test management in my new role.  My new company offered a lot of challenges.  Sometimes I'm frustrated that “we're not there yet”, but we're making progress, all-be-it slower than I'd hoped.

Work has presented me with a few frustrating moments and dead ends.  I've found it useful from tough weeks to sit in front of my machine, and talk about what's gone wrong – but try and stay positive, and talk about how to make things right.

I think an article I personally go back to a lot, is the Kobayashi Maru of Office Relationships.  It was a very tense time at work, and somehow talking about it and breaking it down helped.  I've worked really hard since to build bridges with Pauline, and I'm hoping we have a much better relationship.  Ironically through the bridge building process I've found out just how much pressure she was in, and she's admitted to not always handling it that well.  What could have become a bitter office feud is turning slowly into two mates trying to watch each other's backs – relationships take some building.

Another stand out article I've written has been The Agile Haka, about getting teams to work better, which got published in The Testing Circus, and my General Manager read this month and gave it his seal of approval.  And finally Those Darn Test Estimates, which is more identifying when testing overruns – I refer to those root causes regularly with my Project Managers now.

Those were my favourites, though ironically not the most popular of my posts.  You can never second-guess your readers.

I thought I was going to write this blog to teach.  In fact I found every time I sat down to write, I actually learned.  Just sitting down and thinking of an aspect of work I was unhappy with helped me look at the problem, break it apart, and look for answers.

What else did you expect?  I am a tester after all ...

Why is it so important to be able to socialise after work?

We had a great night last week after work. A departmental meal and karaoke night had been organised for the Friday.  Everyone talked with each other, and often with someone new during the meal. We enjoyed a few drinks, and we got really into the spirit of things becoming quite competitive on the microphone.

It's important to like the people you work with (although I'm usually better friends with people outside of work). But it's important to do these events once in a while because there's an important though subliminal message within these things as long as it's all fun and games.

The office is a place of tension. Project managers want one thing, business owners another, testers and developers something even more different. I discussed a little about office tensions in the Kobayashi Maru ofOffice Relationships – I've worked many different projects in 15 years in the IT business, and it's a similar story everywhere.

But in a social environment, when you get on and even have fun with others, there's an important thing you come away with. No matter what the strains of the 9-til-5, you can get on with each other. Yes it's going to be tense at times and sometimes emotional. But it's nothing personal.  And that's something important to come away with.

The Rugby World Cup – learning to celebrate

The end of an amazing road for New Zealand – hosting the 2011 Rugby World Cup and of course also winning it.

Behind the Rugby World Cup has been an army of volunteers who've given up their time for something they had passion for.  I was among them.

A year ago in September 2010 they asked for volunteers, and I put my name into the ring.  Expecting something glamourous like marshalling at the odd free game, or meeting a celebrity.

In actual fact my volunteering meant I had an office job, working with IT creating photo passes.  As it would turn out, a portion of this has been my actual day job.  So not really glamourous.

But is that a surprise?  When work needs to be done, it needs to be done.  Sometimes it's unglamourous, sometimes dull, sometimes tiring.  But it needs to be done.

The best part after the win by the All Blacks was the victory parade in Wellington.  As volunteers, we got to wear our uniform and walk behind our team through the streets.  It was an amazing experience.

Oddly enough we've been reflecting at work about projects, and how we end the.  Invariably projects complete a little later than liked, and we scurry from one to the next.  We lose our ability to celebrate success in any form.

All told my volunteer work for the World Cup added up to about 7 days.  And yet we walked through the streets with a bit of fanfare, we got a mention of thanks from the Prime Minister himself.

And yet I put many more hours and effort into my work and projects.  But do we find the time to have our own celebration?  Perhaps it's time we did.

[Look very carefully and you'll see yours truly in the volunteer army behind]

Dennis Ritchie dies

Last week Steve Jobs died, and consumers and world leaders stopped to pay tribute.

This week Dennis Ritchie died … and many outside the world of computing will go “who?”.

He was a computer scientist, who not only created the C programming language, but also helped to create the UNIX operating system in the 60s and 70s.

If like me you have ever done programming, you've no doubt done it in C – it's a hugely popular language, and incredibly powerful and flexible one. It's spawned and influenced many of our current languages like C++, C#, Perl and Java. If you've programmed in C, then you've owned C The Programming Language by Kernighan and Ritchie.

The same can be said for the impact of UNIX, itself written in C.

The technologies have made pretty much every type of device and gadget you can imagine today possible, it's used to program mobile phones to XBoxes. You cannot imagine the world of software today without them.

Quite rightly it's been said that the world of computing has lost a titan.

Those darn test estimates …

How long is a piece of string?  I'm tempted to be a wise-ass and say that to project managers when they ask me “how long will it take to test my project?”.

That's actually unfair, experience gives us as testers an idea, based on similar projects, of how long it'll take to test.  But one of the problems is, testing is an activity which has a complex relationship with other factors in a project – we can keep testing and testing, but if development don't start fixing some bugs, we're going to be here forever!

So yes, we can look through the designed features and estimate how long it will take to script, and how long to execute those scripts.

But how long until the product is finished testing?

How long is a piece of string?

Having worked in a test consultancy, there is no doubt about the importance of estimates.  They need, when a project manager looks at them, to be attractive but also realistic, with some contingency.

What we introduced was a list of estimates for testing tasks for “best case”, “probable case” and “worst case”.


                BEST   PROB   WORST
Test Plan         1 2 4
Test Conditions   2      3      5
Test Scripting    4      7     10
Pre-Testing       2      4      6
UAT Execution     4      5      8
Retesting         2      5     10

This gives the test manager some leeway, usually if things go okay it should follow the Probable estimates.  If they book the Best case estimates, be very worried.

What I'm finding is my project managers are taking my estimates, adding the Probable case figures together and times it by an hourly rate to get a budget. I don't know why I'm so surprised ... makes sense, but I'm used to working against time and not $$$.

Unfortunately at the end of the last two projects we've been considerably over that budget.  There seems to be several factors at play which determine which of those estimate paths our testing is going to follow, and it's important to understand and recognise them.

Software Delivered Late

You book in a test contractor to help you test for 6 weeks.  They arrive on week 24 to start analysis and scripting, with some test execution happening in week 26 for 4 weeks.

Then your chief developer tells you there's going to be a 2 week delay getting the build together, it won't be available until week 30 now.

You've made a commitment to your test contractor, and are so obliged to pay him, and possibly find them other work.  If you can't get them to assist elsewhere, then by week 30, you're 4 weeks in and not testing yet.  You've blown over half your budget, and Lord help you if there's any more delays!

We all know developers can often deliver late.  Late software is going to burn up budget.  You need to work with your Project Manager to make them aware of their duty to get software to you as scheduled in order for your budget to be met.

Software Delivered Is Of Poor Quality

Kind of the flip side of late delivered software.  Your vendor has promised that the software delivered has been unit and system tested, and no bugs were found.

You wrote your test plan for acceptance testing, expecting the software to have been extensively tested beforehand, with a certain level of quality.  Your project manager and you are expecting what's delivered to be a candidate for release.  You turn it on, and immediately notice a dozen problems, not able to finish basic use cases.

The developers under duress delivered what they had available to schedule instead of flagging any delays.  Little if any testing has happened, and basic bugs are being discovered only now.  Testing 101 says "more bugs = more fixes = more builds = more retesting".

One thing I try and do with vendors is ask for a release note and end report for testing, detailing what defects were found and what were fixed.  This is a bit of a game of bluff.  If I receive an end report which says “everything was tested, and no defects were raised” I get suspicious.  Very suspicious.

I've also had vendors on conference calls inform me “we're running a build up now, you'll have the install delivered in an hour”.  I pull my project manager to one side when this happens and warn them that maybe that will mean no testing whatsoever has been done …

The Delivery Chain

If you have developers on-site who you can give defects to, they fix, build, test it's possible to get a build almost every day.

If they're off site, only receive defects daily, have to courier builds, you'll be hard pressed to get a build weekly.

If you have two weeks to test, and have a daily build, you'll have 10 opportunities to get it right.

If you have weekly builds it's not likely to happen.  Your second build will have to be perfect – and it usually takes about 3-4 even with an initially high quality piece of software (there are always tweaks needed).

Time erosion

It's so easy to happen.  You have,

• a daily half hour team meeting
• a one hour weekly project progress meeting
• a one hour weekly project technical meeting
• a daily 15 minute end-of-day defect wrap up meeting
• each day you spend half an hour writing a progress report for the concerned business owner

Oh you're giggling there, but we've all been there.  Did you add it all up?  Yes, you're losing about a day a week.  Look at your estimates, did you plan on there being so much leakage?

I'm finding we're increasingly working on projects where there are a large amount of meetings to keep track of progress.  This needn't be a bad thing, and small meetings daily can help set the direction and key priorities of the day/week.  But it's easy for reporting to actually delay any progress being made, and become a sizable and unknown overhead in itself.

And some projects need test management – how do you budget for that?  It's not a solid “task” again more an ongoing overhead.

Requirements?

Requirements?  We didn't have time to write down everything we asked for!

Due to constraints a project has been only broadly defined, but you're required to perform specific testing against it, to a limited timeframe.  Oh and business analysts are too busy to answer your questions, so just get on with it and you know, test!

This is a nightmare position to be in.  You press a button, a message is displayed.  But you have no idea if it's the right message or not.  There are some things you can do – you can check the application didn't die when you pressed the button, and the message made sense in the context of the button.

But if you have vague requirements, you can only vaguely test.  Such projects really feel like they're setting up the test project to fail.  And take the blame.

Another variant of this is you raise about 10 defects against requirements, there's a review, and a business analyst says “oh yes these aren't defects, I asked for these changes by phone from our vendor”.  If things aren't documented, how can anyone keep track of these changes?

Take it easy.  Take it nice and slow.  That's no way to go.  Does your PM know?

Thankfully there's usually a place for these factors in a test plan under risks and assumptions.  But I can't emphasise enough to you the importance to talking them over time and again with your project managers before you embark on any test estimates, so they can understand and more effectively evaluate the risks and the impact to budget.