A functional end

This time last year I was enjoying an extended Xmas break and was using the time to learn Selenium and Java. I'd installed Eclipse on my laptop and was enjoying doing some coding again. In fact I was enjoying it so much and hating the commute into work that thoughts of a job change started.

And this is how the year has finished - a new job opportunity and I've just installed the Haskell Platform and I'm reading up on functional programming.

The job may change but the learning doesn't stop - only now I'm not doing it on my own and doing it on sample projects. I'm now working with projects that use all the stuff that I was reading about.

Looking back on the year:

• I'm learning how to use Git and Vim.


• Read Agile Web Development with Rails and followed the examples so I had a RoR website up and running on my laptop.


• Tested my first mobile apps


• Learnt about several sectors of industry that I previously knew nothing about.


• Attended Tester Gatherings in London, Oxford and Winchester and met Lisa Crispin and Michael Bolton.


• Attended 2 Tester Gatherings in Grand Rapids, Michigan and met Pete Walen and Mel Bugai.


• Met Matt Heusser and went out for a buffalo burger ( sadly sold out ) and tester chat.


• Spent 8 weeks with my finger in a splint after getting Mallet Finger playing Extreme Frisbee with new work colleagues.


• Celebrated the landmark figure of 10,000 members of the Software Testing Club.


• Terminated numerous STC posts and accounts, some of whom got pissed at me.


• Increased my library with numerous books


• Doubled the size of my Amazon Wish List

Goals for next year:

• Finalise my move to the US - the visa process is slow


• Get a deeper understanding of Ruby by looking at real projects


• Attend CAST 2012


• Finish reading the books I have before starting on my Wish List


• Continue growing the STC both in terms of numbers and influence


• Be an active member of GR Testers

Whilst writing this post other testers have posted their reflections on the year. I was struck by how two entries also emphasised learning - Anne-Marie Charrett (The Maverick Tester ) and Pete Walen. And I'm fortunate to be working at a place that also emphasises a culture of learning

Another blog post also got my attention, from Timothy Western aka Veretax/Discovered Tester - Reflections on 2011, a year of trial, growth, and questions

My current role on project has me pondering though. I've heard it debated around twitter, about whether you can be both a programmer and a tester. I know I can do either, but at some point do you not need to decide which to specialize in? The reality is there are only so many hours in the day for study and growth, and the opportunity cost of each new learning investment, in effect is at a loss for learning something else. This is a reality that I've now come face to face with in the last two months. I still have the knowledge from what I learned as a tester, but it has been hard to try and keep up on my learning where testing is concerned, especially when my current responsibilities require me to act in a more code-centric role

I'm enjoying poking around in code and even enjoying the headache that looking at Haskell and functional programming is giving me. But I've also started reading Thinking Fast and Slow which is giving me a lot of thoughts about bias in testing.

Which to devote more time to ? How to find the right balance ?
Something I'll have to try and answer in 2012

The Recipe Test

I have to admit to getting hooked on a reality TV show - Masterchef Australia ( who knew there were so many ways to cook a kangaroo ? ).

The series is basically about a bunch of amateur cooks who are set a series of challenges and whittled down week after week until there is a winner.
A recent episode made for great blog material.
The challenge was for the four cooks left in the competition to come up with a recipe - and then write it down so that a home cook could follow it and make the dish.

All four finalists were great cooks, had delivered some amazing dishes and thrived under pressure. Putting this skill and talent onto paper proved to be a very difficult task.

The rule of the challenge was that the home cooks had to follow the recipe, they could not use their own initiative. Very simple mistakes caused large problems for the people trying to follow the recipes.

One mistake was that a recipe said to use 'juice' but juice did not appear on the list of ingredients. So what flavour of juice ? How much ? The recipe writer had removed it from the list of ingredients but forgot to remove it from the recipe making instructions.

Another recipe which was for a 3-layered cake came unstuck because although it said to divide the mixture into 3 it also only specified using 2 baking trays and so the home cook ended up with a 2 layer cake.

The contestants found the task difficult, the home cooks found it confusing and the judges found the results inedible...

Being an MP ? Anyone can do it

An old friend of mine from uni days has an interesting blog about HR and the workplace. His latest piece was on the grilling of James Murdoch - or rather the lack of it

He pulls out a telling phrase from the main article

The task of questioning was given to MPs with little or no forensic training. As a result, an important moment in political history, but more crucially public accountability, was gone

The article itself has many other good points such as:

But most damning was the lack of focus and incision of the cross-examination

Poor questioning skills.
Vital questions were never asked.
No probing and follow-up.

Sound familiar ?

Reducing the Cost of Testing - Interview with Matthew Heusser

Next up in my series of interviews with authors of Reducing the Cost of Software Testing is Matthew Heusser


From a Linked In discussion to a book - quite a jump. What triggered the idea that the discussion could be made into a book ?

I have no idea. It was all Govind.

That’s a sort of secret in our industry: You can get shockingly far not inventing stuff, but by listening, paying attention, connecting the dots, and taking action early. Govind came to me with the book idea; all I did was take him seriously and then help him execute.

The book is about Reducing the Cost of Testing - this implies there is a a lot of waste that could be cut ? If so, why is this, why is there so much waste ?

There is waste all over the place in the corporate world. It is ridiculous.

Consider, for example, the telephone game we all played in grammar school. First one person says a sentence to the person next to him, and around the circle we go. By the end, the message is nothing like what it started out as. In many companies, that is the software development process - with a translation process from a human to a spec, and another from spec to design, design to code, code to test, and so on. I just don’t have a better term than ridiculous.

Now take a walk around a modern corporation with a clip-board. For everyone you see doing something that really looks like work, make a check-mark. For the ones that don’t, make a check-mark in a different column. Do it every fifteen minutes for a few hours, and you’ll find more waste than you might expect. Now am I saying that people don’t need breaks now and again? Certainly not. But a lot of people are just plain not working very hard. Often, no one is working very hard -- and that is due to systematic issues that management can do something about.

Chapters from different testers in different parts of the world - how was organising this ? was it like herding cats ?

Oh it was tough. You have to realize that most of the contributors are not professional writers, and that it is incredibly easy to create a fifty-word outline, but, for a non-writer, creating five thousand solid words is, well, hard. When we had to track down the contributors and ask them “when are you going to be done?” or, worse, tell a few we had quality concerns ... wow. That was no fun.

There’s an old saw that, as a publisher, you can have friends, they just won’t be anyone you work with professionally. It’s a joke, but I certainly understand where it came from.

Do you have a favourite chapter ?

Being both immersed in the problem and arguably doing the most research, and more than a little bit human and selfish, I’m a little partial to my own chapter. Michael Larsen’s , Michael Kelly’s and Scott Barber's chapters, along with Catherine Powell’s appendix, also provide some of the most direct/concrete advice in the book.

What was the hardest part of putting the book together ?

Oh wow. Everything. Offhand: Dealing with authors who didn’t deliver, or delivered substandard work. Dealing with the authors who stepped in at the last minute, who wrote a chapter in a weekend -- you have to admire that, but gosh did we have some polishing to do.

Probably the most painful for me personally was the communications problems that came from people genuinely mis-understanding, often because I had failed to make things clear in the first place. Knowing that more than a bit of it was my fault makes it hurt more.

You also did the foreword for "Clean Coder" by Robert "Uncle Bob" Martin and you've had a chapter in "Beautiful Testing" Are books and writing important to you ?

For me, writing is a creative outlet that is just enough like testing to sharpen my mind, and just different enough to be a distraction. That I can do it anywhere on my own schedule, without travel, certainly helps.

When someone tells me that they took one of my ideas and applied them to success, that makes my day. When they are more critical, it makes me think and improve. Either way, I win.

You did this book, had a day job, family, blog and got other articles published - do you only sleep 2 hours a night ?

The rumor seems to be that I have super-powers, but the truth is simply that I have made a conscious choice to make software testing an important part of my life. I also have a wonderful life-partner in my wife, who does many things that allow me to sneak in a few more hours for testing here or there.

It’s not two hours, but yes, you’re right, I do not sleep enough, and that’s a problem.

What's next in the pipeline for you - another book ?

How did you guess? (Laughs) I am currently gathering resources for a book on classic essays in software testing. I am open to recommendations ...




Thanks for the replies Matt - and to show how busy he is, take a look at his profile

Joining the club

When new members request membership of the Software Testing Club, one of the questions is:

What would you like to get out of the Software Testing Club ?

Pretty straightforward question but I have been amused at some of the answers.

I would not like to get out of the software club but in case you want me to leave this club then simply a mail will do.
- seems The Terminators reputation has spread.

I LIKE SOFTWARE TOO MUCH
- too much to do what ? test it ? and please dont shout

My dream software..its a secret, will let you know later
- I'm still waiting

Its too early...
you only test at night ?

dsdsdd
asdf asdf 123

Nothing
so you wont mind if I dont approve your membership then ?

Reducing the Cost of Testing - Interview with Markus Gärtner

Next up in my series of interviews with authors of Reducing the Cost of Software Testing is Markus Gärtner


It should be a short book - do less of it and/or hire cheaper testers. Why is there a whole book about it ?

Software Testing is a broad field. A very broad one. It is florished from diverse fields as software testing, programming, software design, psychology, philosophy, epistemology, ..., and management. So, when we ask how to reduce the cost of software testing, one possible answer is to do less testing. But considering the broad field of testing, that answer doesn't help you at all, because that answer does not tell you how to do that, what the liabilities of your approach might be, and what other things you may want to try out.

In the book, Matt Heusser and Govind Kulkarni got together many of the thoughtleaders in the field of software testing to provide a broad collection of answers. In fact, you will find 20 different chapters providing different answers on what software testing actually costs us, what we should do in our projects, and how we should do it.

I'm a tester, I find bugs - why do I need to worry about reducing the cost of testing ?

Testing is our profession. That means that we as software testers are asked about our professional opinions and inputs to the whole software development cycle. Managers make decisions based on our opinions and input to them. That is why we should provide the information of the actual cost of our actions. As professional testers we have the responsibility to inform managers and stakeholders about what we are doing, why we are doing it, and what it will actually cost them, so that they can make the right decisions. If you don't care about the cost of your actions, maybe you are wasting your company's time and money. I call that unprofessional, if you're unaware about it.

Your chapter was about Exploiting the Testing Bottleneck - why did you decide to write about that?

Initially I was considering to use some of the insights I got from the Quality Software Management series by Jerry Weinberg, and write a chapter on how to manage software development projects so that we can actually reduce the cost of testing.

When I started to write my chapter, I found myself on a different track though. Inspired by Elisabeth Hendrickson's talk on Agile Testing practices and principles, I started to explain that benefits you get from working on an Agile team that applies good Agile Development practices like Continuous Integration, TDD, and Exploratory Testing. As I digged deeper, I found more and more pieces, I wanted to incorporate. In the end, I had the difficulty to find a proper name for what I had written down.

As testing is mostly perceived to be a bottleneck on the software projects I had been part of until that time, I found that name quite easily. In Goldratt's The Goal he explains that you should identify bottlenecks in your process, and exploit them, in order to improve your work. The chapter name "Exploiting the Testing Bottleneck" is a deliberate pick on that, because I truly believe that we would test better on any projects, if we seeked to exploit the (perceived) bottleneck in first place, rather than blaming the messengers.

How long did it take you to write ?

Roughly 32 years, but I think that I need to explain that answer. I consider the question "How long did it take you to write your chapter?" similar to the questions "why does testing take us so long?", "how long does it take you to test that?", or "when will be done eating?" I incorporated some portion of my past life into the chapter I wrote. There are nuggets like the insights I got from "The Goal", Lean thinking, systems thinking, and Agile software development in there.

If you consider learning about the stuff I wrote about to be part of the "writing process" of my chapter, I would say roughly 32 years. If you think of the time of writing my chapter as the amount of time I actually worked on the text of my chapter, I would say, roughly one week of work, starting in early May 2010 during my parental leave from work, polishing it up over the summer holidays in August, and finishing "my" first final draft in early October 2010.


Are you happy when you re-read it or would you like to change it ?

For most of my writings I apply a fire-and-forget principle. I write it down, I hit the publish button on my blog, and then I start to forget about it. By forgetting I mean not to revisit it later. This makes a review process very hurtful. So, while I re-read it, I incorporated some of the insights I got from review comments, already. So far, I haven't received a physical copy of the book, so I haven't had the opportunity to re-read it there, but I didn't dare to read the electronical copies we got before the book went to printing. I am probably too scared about that, and I know that it will hunt me down in a few months, maybe.

This does not hold for all of my writing. Sometimes I re-read some of my stuff, and find quite a few shortcomings. I know that I will be hurt to find so many tiny glitches and problems I left in there. So, I prefer to keep the illusion of a good enough chapter for the moment, and deliberately taking the time to re-read in a few weeks or so. Whenever I feel like hurting myself with it. :)

Now that you are a published author, do you have any plans for future books ?

Oh, I was a published author before the book. Few of readers might know that, but I published my diploma thesis back in 2008. It's in German, it's about hand gesture recognition in a human-machine interaction, and I explained the approach to my mother - who is a non-technician - at the time I worked on it. I think, I sold 5 copies of it so far, but publishing the book didn't change anything for me, I think.

That said, I work on a book on ATDD right now. I submitted a first draft to the publisher. I am also in contact with a German publisher through whom I might publish a book on Agile Testing in German in the future, and I also got lots of ideas for maybe a second book in English. Personally I consider my chapter in "How to reduce the cost of testing?" as one milestone on a longer publishing road.

Will your copy of the book be put in a special place ?

I will put it on my book shelf right beneath Beautiful Testing. Since we just moved into a house, I don't have that book shelf filled, yet. So, the special place might actually end up as the first book on my shelf - depends on what reaches me first: my copy of the book, or my energy to unpack my library. :)

Putting you on the spot - what is your favourite chapter in the book ( and why ) ?

Oh, I can't take a single pick there. So, let me give a bunch. I loved reviewing Michael Kelly's "Session-Based Test Management" as well as "Opportunity Cost of Testing" from Catherine Powell. Curtis Stuehrenberg hit a nail for me with "Clean Test: Suggestions for Reducing Costs by Increasing Test Craftsmanship" , but it might be just the mention of craftsmanship in the title.

Michael Kelly explained thoroughly what Session-based test management is about. From his chapter I got the insight that lead me to the idea of inspectional testing - a way to explore the functions of the product in order to inform good test planning. Every tester that claims to do Exploratory Testing has to read this.

Catherine Powell explained the concept of opportunity costs in a way that I could understand, and follow-up on it. It was a real eye-opener.

For Curtis' chapter, I loved the mention of craftsmanship. Having been involved since December 2008 with the Software Craftsmanship community, I actually envied him to use craftsmanship in his title. I was considering to rename my chapter when I saw that, but it would have been obvious who would have spoiled whom about it.

But, I have to admit that I haven't read all of the chapters. I missed to read the one from Michael Bolton and the one from Jon Bach so far, but I am quite sure that I will love these chapters as well, and will incorporate them in my list of favourite chapters.

Until this book came out, what was your favourite testing book ?

This is a hard question. I have read some of the most tedious software testing books, I think. Among the testing books that I loved are Lee Copeland's "A practitioner's approach to software testing design". I also loved reviewing Lisa Crispin's and Janet Gregory's "Agile Testing".
But my favoourite testing book before "How to reduce the cost of testing" is "Lessons Learned in Software Testing" by Cem Kaner, James Bach, and Bret Pettichord, as well as "Perfect Software... and other illusions about testing" from Jerry Weinberg.

( Me - what a great choice, Lessons Learned was one of my very first books and set me off on my testing career )

From acorns to skyscrapers

Just over 4 years ago I was member number 8 of the Software Testing Club - membership is now over 9500 and rapidly closing in on 10,000

I've posted 506 times to discussions, declined numerous request for memberships from lovely fun girls looking for love, been threatened with having a DOS attack on the site and been threatened with the involvement of lawyers after an argument with a member who thought the biggest thing in testing was going to be copyright laws.

Thanks to Rosie and Rob Lambert and Stephen Hill the site has gone from being just an online site to a site that has offered eBooks, posters and the fabulous newspaper, The Testing Planet.

It has also gone offline as well with STC meetups at London, Birmingham, Oxford, Bristol, Liverpool - and Winchester later this month.

and now it's going trans-Atlantic with the announcement that on November 10 there is a Chicago STC Meetup

From a twinkling in Rosie Sherry's eye to this - WOW.
I'm glad to have been part of it - and who knows what's next....

( well, Rosie and Rob and Stephen probably have lots of ideas for what's next !! )

Reducing the Cost of Testing - Interview with Catherine Powell

The book How to Reduce the Cost of Software Testing is now out - a great effort by a bunch of testers to put a book together and get it published.

Wanting to know more about how and why they did it, I interviewed some of the authors.
First to respond was Catherine Powell

It should be a short book - do less of it and/or hire cheaper testers. Why is there a whole book about it ?

You're right, it is easy. Except for all the ways in which it's really hard. Our original title for the book was "How to Reduce the Cost of Software Testing Without Mindlessly Shooting Yourself In the Foot". (It was too long.)

The point is that there are consequences of our decisions, and the book is about making informed choices that reduce the cost of testing without unacceptable side effects.

To take one of your simple examples: we could reduce the cost of testing by laying off all the testers. This would absolutely drive the costs of testing down. It would also result in buggy, unpredictable software that your customers don't like. Your development costs go up - fewer features per developer hour - because they're working on bugs. Your revenue goes down because people don't really want to buy buggy or hard to use software. Your cost of hosting goes up, because you don't know how the system scales, and you have to just increase everything. In the end, you're worse off than if you'd kept your testers around.

The book is about placing software test - and the costs of testing software - in context of the entire software development lifecycle. It's about taking a facetious answer ("just do less!") and providing manager, executives, and testers with the tools to make those decisions intelligently.

I'm a tester, I find bugs - why do I need to worry about reducing the cost of testing ?

You're a tester. You do a whole lot more than find bugs. You gather information, you understand systems, you figure out how things work and how they don't. And, if you're like most testers, you worry about your job. Heck, most professionals do. This book is about the value that test brings to an organization, and about realizing that value in a cost-effective way. Those are exactly the skills that you as a tester will need to thrive in the future of software development.

Your chapter was about Opportunity Costs - why did you decide to write about that?

So much of what we do in testing is about making tradeoffs. It's about recognizing that we could test forever but that we don't actually have forever; instead there's a release coming up fast. I wanted to write about that decision making process using a tool that is recognizable to the business: opportunity cost. Opportunity cost is what we give up by not doing something. Because we went to the store, we didn't have time to go to the gym; the opportunity cost of going to the store is the benefit we would have gotten from going to the gym (weight loss! better cardio!). Opportunity cost provides us with a way to expose the risks and costs of not doing something, and not doing something is a choice we frequently face in software testing.

How long did it take you to write ?

That's a tough question. The chapter on opportunity costs took a few days. The first draft came together in about a 6 hour period, but it was (like many first drafts) terrible! Fixing it took rather longer.

The appendix on 25 Tips to Reduce Testing Today was faster. Matt Heusser and I worked on that and Immediate Strategies to Reduce Test Cost together - you'll notice the strategies and the tips align - and it was really about the quick hits and small changes that together make a big difference. I don't know if it actually took less time, but it was certainly fun, and a lot of fun to think about what the most immediate thing could possibly be.

Are you happy when you re-read it or would you like to change it ?

I'm still happy with it. There are some tweaks I would make, but I'm still very excited about bringing together business concepts with testing needs and helping those two worlds work better together.

Now that you are a published author, do you have any plans for future books ?

I haven't really decided! At the moment I'm mostly writing for my blog and shorter articles, but there may be a book waiting to emerge.

Will your copy of the book be put in a special place ?

Does the bookshelf count as a special place?

Putting you on the spot - what is your favourite chapter in the book ( and why ) ?

That's a tough one. The chapters are all helpful in very different ways. This is a book to me that you don't read all the way through and put it away. You read different chapters as you go through various situations, whether it's doing budgeting (and reading Michael Larsen's Trading Money for Time), or building up a test team (and reading Anne-Marie Charrett's Cost of Starting Up a Test Team), or trying to move faster (and reading Petteri Lyttinen's You Can't Waste Money on a Defect That Isn't There).

Until this book came out, what was your favourite testing book ?

I'm into the classics, so my favorite is Hetzel's Complete Guide to Software Testing. I pick it up when I need to be reminded of the fundamentals. Parts of it are a bit dated, but most of it is still solid guidance.

Conferences and Gatherings

I read a great blog post - Don’t Be This Guy - which was about going to conferences and listening to the tech talks but not connecting with any of the other people at the conference.

You see, since he was the only SQL Server professional at his place of employment, he didn’t have a lot of opportunities to talk shop in person with others. He longed for what they had, but couldn’t find the initiative to start up meaningful conversations with others.

Replace 'SQL Server' with 'testing' and that was me a few years ago - and doubtless applies to many lone gun testers out there.

So reading this reminded me of my first SIGIST conference a few years ago - being surrounded by testers felt good and listening to people talk about testing was great.
Luckily at this conference I did have some courage - at that time Testing Reflections was a very active site and I'd had some encouraging words from Antony Marcano after posting on there. He was doing a talk at SIGIST so I went over to say Hello and he invited me along to the usual after-event drinks. Without that invite I could well have been 'that guy'.

Now, a few years on and there is another SIGIST due - but I'm not going. Partly because it wasn't that well publicised, partly because the line-up doesn't excite me that much - but also because there are more events on now than there used to be

I have a couple of events at Skillsmatter to go to - with the bonus that they are free and in the evening. SIGIST I have to pay for and take a day off work.

Tester Gatherings and STC meetups are happening - next London Tester Gathering is later this month and there are a horde of STC Meetups happening (Winchester, Birmingham and Liverpool in October ) - and those that go to them give them great write-ups

( and a quick shout out to the Grand Rapids Tester Meetups - it will be a few months before I can attend the next one. Sorry )

Twitter, blogging and the Software Testing Club can also help those lone-gun testers make connections. Michael Larsen - TESTHEAD - is a fantastic example of what can be done
Or see this blog post from Pete Walen.

Online or offline though - just dont be That Guy ( or Gal ).
Connect.
Participate.

Random Ruby

I recently wrote a post on Atomic Spin about how I've been getting back up to speed with Ruby after a (too) long absence from it.

One thing that the resources I've been reading emphasise is practise so I've been looking for ways to try out Ruby.

So thank you Alan Page and his Numberz Challenge. It's a simple windows app that he's using in his blog articles about test design.

This seemed a good exercise so with the help of Scripted GUI Testing with Ruby I had the app automated.

A few more lines of code and I was able to check the data and find that the numbers used were not random ( #3 came out more than it should ) and the calculation of the total was sometimes incorrect.
Alan has now written an update which shows the app was indeed written to favour 3 and to occasionally get the total wrong.

Looking at the source code would have been an easier way to test - though making your source code available to view can lead to problems if you have a poker app. But even if your source code is not available some people will reverse-engineer your app ( the winner of the Numberz challenge did exactly that ! )

So one blog post shows what lengths testers will go to, gives some testers practice in their new language, nicely illustrates the point about recognising when automation can help - and gets Chris McMahon blogging again ( twice ! )

The new adventure

I've been looking for a new job for sometime - the daily commute was a real grind, waterfall projects where I never met the developers, working with companies who treated testing as a production line with testers as resources that could be swapped in/out, managers obsessed by counts of tests, days where the entire day seemed to be one conference call after another...

Being part of the test community was a great help when I started looking and I had a number of interesting opportunities put my way but then I saw this job ad which Matt Heusser ( thanks Matt ! ) posted to the s/w testing mailing list. I was intrigued and excited by it so went and found out more about the company - Atomic Object - liked what I read about them so sent in an application.

To cut a long story very short ( the long story is likely to be my submission to the next issue of The Testing Planet ) I was made an offer which I've accepted - though I have to wait awhile before I can be a proper employee...

The one big complication is that Atomic are in Grand Rapids, Michigan, USA and I'm in Bracknell Berks, UK...but I have a US wife which helps the visa process somewhat so early next year ( no jinx ) I'll be heading off to the US.

Grand Rapids has a good tester community - Pete Walen and Matt Heusser are there so I already have friends but until then I'm a contractor working from the UK.

It will be a challenge - Elisabeth Hendrickson mentions her visit to Atomic Object in her Exploratory Testing in an Agile Context session that she did at Agile 2011 and how she found it difficult to break the apps. Much better to have this sort of challenge than to be able to quickly rack up 700 defects as I did in my last project.

Working remotely as a contractor is also a challenge but there is Skype, Yammer, IM, email - not ideal but it will do until the visa arrives.

I'm already appreciating the extra spare time I have with no 4 hour commute - halfway through Learn Ruby The Hard Way and back to participating more in the online testing community - which is a good thing as I can return the favours I got from being part of it.

Well Connected - or not

So the Windows Wireless Network Connection manager got a bit confused

It seemed to think I wasn't connected but also thought I was.
C'mon, it's one of 2 states, how hard is it to get that right and consistent ?

( or this can be an exercise to the readers and they can tell me how really it can be more than 2 states... )

Grandad, what's a VCR ?

Currently on vacation in the US, I found that a new series of Hells Kitchen had started - worth watching to see if you agree that Ramsey is a great consultant or just a foul mouthed bully...

Having missed the first episodes, we used On Demand to watch them - with the added bonus that we'd be able to skip the commercials that appear every 6 minutes

except...

EXCEPT...

we couldn't.
Hit Fast Forward and the message

" VCR Controls are disabled "

appeared on the screen.
Whaaaaaaaaaaaaaaaaaat ?
Several Ramsey style expletives later, my tester senses kicked in.

What does "VCR" stand for ? Video Cassette Recorder
I'm not using a Video Cassette Recorder, no tapes are involved in this operation, why is the message referring to an ancient technology ?

And only the fast forward control is disabled, I could still pause and rewind so the message itself is lying to me.

All of which reminded me of the FAILURE mnemonic from Ben Simo.

The message was not Appropriate - I was not using a VCR and I can imagine some users not even knowing what a VCR was.
( how long ago did people stop using VCRs ? )

Impact - the message told me the controls were disabled which was incorrect

UI - should the error message really be using terminology of another technology ?

Emotions - seeing this message certainly made me mad !

But at least I got a blog post out of it - not that it makes up for commercials every 6 minutes.
Blech

Uninstallers - so square

I had to uninstall TweetDeck and got the not-very-helpful dialog shown above.

I know it's hard to imagine that users would want to uninstall the amazing life-changing program that you've worked on but always worth checking that if they want to do so, they can

Goodbye 17" seat

Just one more week of squeezing into a narrow seat* on the train and trying not to get seat rage.

Maybe I shouldn't complain as at least I do get a seat, two stations further on and it's standing room only for the remaining 50 minutes of the journey.

No more parking in side streets close to the station to avoid the rip-off £8 a day parking charge.

No more seeing cash-signs in taxs drivers eyes when trains are cancelled, the promised bus replacements never turn up so the only option is a cab share.

No more reminders to please remember to take my personal belongings with me.

No more dark mutterings when I read that train fares are due to increase by over 10%

No longer will I waste two days a year simply standing looking at departure boards to see what platform the train leaves from before joining the stampeding herd to get on it.

Apologies to all the tourists who's pictures I've ruined by getting in them - but I want to get home and not wait around whilst you take your picture of St Pauls and the City skyline from Embankment bridge.

I wont get to hear how the divorce proceedings of the woman who sat behind me pan out.

No more adding items to my Amazon wish list knowing I'd have no time to read them.

No more telling Rosie and Rob that I dont have time to write an article for the next Testing Planet.

End of an era and start of a new adventure - more details soon
( it's gonna be Grand and it's gonna be rapid )


*BBC has 43cm as being 18in when in fact it is 16.9291339 so 17"

'View from the 17" seat' would have made a great title for a blog on the joys of commuting. Too late now for me to use - any rat race commuters reading this, please feel free to use

left hand meet right hand

Rob Lambert recently blogged about Checking what other system allow - an online form asked for his Twitter name but wasn't able to process it as it didn't allow the same range of characters that Twitter does.

Maybe it was this post that made me more alert for examples of this as after reading this I found a discrepancy within a system ( never mind between systems ).

An app allows a user to be created and gives some guidance on creating a name and suggests using your email name. Makes sense as user names are system wide so as soon as someone has created 'Bob' then the second Bob has to try Bob1 or BobC and after a few months the ninety ninth bob has to spend several minutes trying to find a Bob that isn't taken.

So far so good.

Then an enhancement is proposed for the app that generates some output files. The files have to be given unique names but ones that are associated with the user. So the spec suggests using the username as part of the file name and gives an example as 'data_Mark.txt'.
Seems almost reasonable until you remember the earlier suggestion of using your email as a username. 'data_mark.specwriter@notthoughtthrough.com.txt' doesn't seem such a good idea...

so thanks to Rob for making me aware of checking the consistency of a system - and shows how testing memes can spread

Rock n Roll Characters

Google News had problems with the umlauts in Motorhead and Wurzel

But they are in esteemed company, the #AskObama Live Twitter event had a similar problem - great explanation of this can be found here

SpongeBob TestyPants

Just read a good blog post about Sponge Learning by Alex Rosen who hangs around on Hacker News ( as do I ) and soaks up infomation from the posts and comments there.

Reminded me a lot about my first moves into testing where I lurked on SQA Forums and Testing Reflections ( when I was not reading books )
The soak possibilities have increased the last few years - the awesome Software Testing Club site, blogs galore, podcasts and I suppose it's possible to soak a few drops from Twitter.

Simon Morley recently ranted about being given a headache by some of the questions that get posted on the forums ( and he doesn't get to see a lot of the posts that get Terminated as soon as I notice them )

But, as Darren McMillan points out in his latest blog post An untapped sea of knowledge, once you move on from soaking to interacting and participating in the community there are some great rewards.

If you're reading this then chances are I'm preaching to the converted but I'll try and remember how much I get out of the community and restrain my Twitter rants next time I open up the STC and find a post
"Plz tell me the Best Practices and Tool for naming Sanity Test Cases in an Agile team"

Steve Freeman - Smells

Went to Skills Matter last night for another of their excellent series of free evening talks. This one was Steve Freeman talking about Fractal TDD: Using tests to drive system design

His premise was that the standard TDD cycle of Write Failing Test -> Make It Pass -> Refactor could be done at a higher level and the benefits of doing so.

He started off by showing a unit test from the wild - pages long, full of references to other classes and mocks, even including a mock God object. This was TDD getting out of hand and someone should have noticed and said "this doesn't feel or look right"
Which led onto the meat of his talk - Test Smells.

If code follows good design principles then it should be easy to test, if there are any test smells then it's likely there are design problems. He suggested adding an extra stage to the TDD loop - "is it hard to write a test" ?

He then went through some of the common Test Smells

• Test Duplicates Code - the code of the test seems identical to the code that it is testing
  
• Too Many Assertions
  
• Faking The Wrong Objects - for example dont mock a 3rd party API, test this with integration tests so your TDD tests can concentrate on the design
  
• Test Setup Requires Magic - usual example of this is a clock
  
• Not Testing Logging - if logging is important enough to be part of the production code then it's worth testing
  

Steve then said that to test a system we need to

• Know what the system is doing
  
• Know when it has stopped doing it
  
• Know when it has gone wrong
  
• Details of why it has gone wrong
  

he then made the connection that the things we need to test the system are also the things that make the system easier to support. So if you do TDD then not only do you get code that's easy to modify but you also get a system that's easy to support.

He made use of the Ports and Adapters concept from Alistair Cockburn which I hadn't come across before but am now busy reading up on. Steve showed how good design means tests dont have to be confined at the edges of these ports but can go in deeper and test the model.

All in all an interesting talk, some new concepts for me to think over and I really really must finish his book

One thing I did think of though ( and only after the event ) was his examples of code that was hard to test.
If TDD was being done right then wouldn't the tests be written first rather than writing the code then finding it was hard to write tests for it ?

The Dog Saw The Risk

Been awhile since I last posted ( full explanation soon ), one reason was a vacation to the US. To pass the time on the flight I find that a Malcolm Gladwell book usually works and also provides material for a blog post afterwards.

This time was no exception - the book I was reading was What The Dog Saw and from the chapter Blowup I learned about risk homeostasis.

The theory behind this is that under certian circumstances, changes that appear to make a system or an organisation safer, in fact don't. The reason for this is that humans have a tendency to compensate for lower risks in one area by taking greater risks in another.

Gladwell gives some examples of this:

• Part of a fleet of taxicabs in Munich were equipped with ABS. Did the group with ABS have fewer accidents ? No, they had more ! They drove faster, made sharper turns, braked harder.
  
  
• More pedestrians are killed at marked crosswalks than unmarked ones because they compensate for the safe environment of a marked crosswalk by being less vigilant about traffic.
  

Risk homeostasis also works the opposite way.
In Sweden they changed from driving on the left-hand side to the right-hand side. This did not increase the accident rate, traffic fatalaties dropped by 17% as people compensated for the unfamiliarity with the new driving pattern by driving more carefully.

All of which made me think about whether this could relate to testing and s/w development.

• Do devs take more risks if they know there's a testing stage at the end to catch their mistakes ?
  
  
• If TDD is introduced to an organisation does it cause an increase in defects as devs think they are safer in the same way as the cab drivers did with their ABS ?
  
  
• Does switching to a new programming language decrease defects because devs are being more careful with their code because it's new to them ?
  

I was going to look more into this and get the book Target Risk that Gladwell references in his article - but not with a price of £163.95 !!

Cost of a bracket

Having been slaving away over a hot keyboard ( and smoking bug database ) I was starting to think I'd earned a nice little break.

Off to Lastminute to see what was on offer, found a nice deal, wanted to see the pics of the hotel in more detail.
Nope, not gonna happen. Pesky javascript error, " Expected ')' ", and the large pic didn't show, only the thumbnails.

So off to a site where there aren't such errors - some possible commission lost for Lastminute all because of a missing bracket...

I Was There

I Was There !

Well, I almost wasn't as I had to work late to help a dev confirm a bug was fixed so didn't get to SkillsMatter until the event had started.
But I Was There !

Laptop powered up, connected to the wi-fi, Skype started and I was part of it.

Part of what ?

A Weeknight testing session with people attending by Skype video from Germany and San Fransisco joining the attendees in London - with various other people joining on the Skype chat

Mission was to test Firefox 4 using the FCC CUTS VIDS heuristic but that was not the main takeaway from the evening for me.

I've taken part in several weekend testing sessions and one weeknight testing session, always enjoyed them and got something out of them but this session seemed different

Over in San Fransisco Lisa Crispin was there with assorted other US testers - there wasn't the usual 'introduce yourself' start to the session so I didn't get to find out who else was there

In Germany the session was led by Markus Gärtner

In London the session was hosted by Mike Scott and Sharath Byregowda.
In the audience were testing names such as Gojko Adzic ( who I'm sure will want me to mention the Agile Testing UK user group at agiletesters.org.uk ), David Evans. John Stevenson, Tony 'Tester Gathering' Bruce and others

And two esteemed managers of the Software Testing Club - myself and Rob Lambert. Good to meet the Social Tester in person even if he couldn't be social afterwards and had to head off to get a train

The usual suspects joined in on the Skype chat but I'm not sure how well the session worked out for them if they couldn't see the video feeds and hear the audio.

Rob showed he was a Bug Magnet by crashing Firefox, spell checking didn't seem to work for me though this was one of the claimed features but to be honest I wasn't totally involved in the mission.

I was just enjoying the feeling of community - worldwide testers coming together to work on and improve their testing skills.

Thanks to SkillsMatter for the venue and thanks to Mike and Sharath for facilitating

Gaming Entaggle

Entaggle is a new peer recognition web site that seems to be taking off fast.

Some people such as Darren McMillan have already blogged about its usability

The site itself has usage guidelines which aim to stop spamming and positivity.

It wasn't too hard to find a way to game the system:

1) Create a positive tag, publicly available that people will want to associate themselves with.

2) Tag people with it - especially some well know names

3) Once you've built up a good number of people with the tag - Edit the tag so it reflects what you want to market

4) Voila, now you have a group of people associated with your scheme.

I created a tag 'Weekend Tester' as a public tag then found there was a private one called the same. Tag deletion is not yet an option so I decided to change the tag I'd created to something else ( no-one else had yet tagged themselves with it ).

This is when I realised that people who had tagged themselves with a tag could find themselves tagged as something completely different if the tag was changed...
maybe "fan of ISEB certification"

Thanks to 007 Unlicensed to Test for helping me illustrate the point. He tagged himself as a Weekend Tester and now finds himself as a fan of this site

Something for the weekend, sir ?

On a Death March project where weekend work was being done, a defect was raised during the testing.

Defect:
Change to customer account in account database not being reflected in application.

Defect Comment:
The data flows are turned off over the weekend and restart at 9am Monday morning. If you are testing over a weekend then please let us know and we will enable the flows.

Make sure you check out your test environment before wasting peoples time and spoiling their Sunday morning lie-in.

Guided by tests - 5 years 0 failures

Went to Skills Matter last week for a talk by Steve Freeman and Andrew Jackman - Five Years of Change, No Outages.

Very interesting experience report on the experience of implementing a system for an investment bank.

It was the banks 3rd or 4th attempt to try and get a working system - Steve and the team delivered it in 9 months ( Project Manager, 2-3 BA's, 4-5 devs, 1 DBA ) and it has been working ( with changes ) for the last 5 years with a third generation team working on it.

It was implemented by doing XP by the book. Within 2 weeks they had a Walking Skeleton and continued to deliver every 2 weeks.

The team did not sit around debating quality - they just Got On With It.

The PM gave the team great support - no doubt due to the 3 or 4 previous failures. The team used pair programming ( the interview process for the team had a pairing exercise ) and the PM could see the sense of this due to a past experience where a contractor had been moved on and they found his code was unusable and needed a rewrite which cost the project a few months delay.
The team were co-located - again, there seemed to be no arguments from the PM who backed their approach.

FIT tests were used - the devs had experience of using them and knew where the problems were. Initially the BA's were not used to going to the level of detail required for these tests but soon became converts. They even used the FIT tests to explore the system and would bring people down from other teams to show off their tests.

No code was written until they had FIT tests with examples. This took time as the requirements were not clear so it also had the benefit of shaking out the real requirements.

The FIT tests were also used to explain the system to third parties that were using it.

Steve and Andrew showed actual examples of these tests and showed tests from 2005 and 2010 and you could see how sophisticated the tests were.

Steve emphasised that the primary purpose of the tests was communication.

Retrospectives were still being done every 2 weeks, there was 'relentless progress' as there was no stopping to deal with crashes or having to firefight and the regular releases were done on a Friday before the team went off to lunch ( a sign of the confidence in the system )

The devs were on front-line support 24x7 which was a great incentive to them to make sure the system was rock solid

The only drawback seemed to be that once the system was up and running and working then people thought that it must have been an easy problem to fix and forgot the previous failed attempts.

Excellent experience report and afterwards Steve stayed around to answer questions and sign my copy of his Growing Object-Oriented Software Guided by Tests book. It was good to find I wasn't the only person there with the book as there was someone else behind also with a copy.

Steve did remark that my copy seemed new so maybe it's time I read it again and turned a few corners of pages down...

WTA #7 - Down to the river

Took part in the WTA #7 ( Weekend Testing American chapter ) hosted by Michael Larsen and Albert Gareev.

Michael has already done a good write-up on his TESTHEAD blog so I'll give some of what I took away from the session.

( if you want to try out the app then try here - or the puzzle can be found here

Basic mission was to see if the program would help find the smartest candidates.

Almost immediately it did seem to find a not-so-smart candidate...

"Clicking the picture only does copying the file to Excel nothing else and I have 20 odds in my downloaded folder"

There was a debate on 'smart' - IQ smart, street smart ?
I went off to Google and found the solution to the puzzle - does that count as smartness ? The Google factor cannnot be discounted - even if a candidate taking this test had no access to Google it's also possible that they would have googled 'interview questions for Company X' beforehand and known that they would be getting a puzzle. Again, does this make them street smart ?

One of the great things about the Weekend Tester Sessions is what when a bunch of testers get together then things can go off on all sorts of tangents that one person alone might not have thought of.

If illegal combinations were put on the raft then there would be a bubble showing it was wrong - example is shown at the top of this post.
Now the Japanese with their anime culture might see nothing wrong - but as Justin Byers pointed out

"A father punching his daughter... even though it is cartoon violence, is this the kind of program you want to associate with your business? "

The app itself wasn't really tested but we did find holes in the puzzle.
There did not seem to be a rule about the prisoner being alone - in fact to solve the puzzle he was left on his own so why wouldn't he run away ?

If we were being brought in to test to see if the app was a good test of smartness then shouldn't we first be tested to see if we were smart ?

We found a way to get in a dig about certifications.

"Also, the customer can simply see if there's a "Family Raft Crossing Certification" on the CV/Resume. No need to use the app!"

The basic premise behind the mission was challenged rather than finding bugs in the app. This was a good thing and summed up in this great phrase ( that I think I'll be re-using )

"Like finding that the logo on one side of the sinking Titanic is the wrong color."

The session itself did seem to indicate that giving this entire mission to a tester ( rather than just the app ) might make a good audition for someone hiring a tester.

"For me, if I were the hiring manager, I think I would be more impressed if they were to have asked some of these questions during their session."

Great session, cannot recommend these sessions highly enough.

Thanks Albert and Michael !!

TWIST and Shout

Decided to make more of my commuting time on the train and download some testing podcasts. The TESTHEAD blog always has a good source of them so off I went.

The podcasts are actually on the STP site, having downloaded a few of the recent ones I noticed there were others such as Cem Kaner or Mark Crowther.

However, clicking the 'download podcast' link gave me the page shown at the top of this post.

Your Membership Level: Basic
Membership Level Required: Basic

Seems to match - where's my download ??

The smallprint on TESTHEAD's blog made it clear.

Each TWiST podcast is free for 30 days, but you have to be a basic member to access it. After 30 days, you have to have a Pro Membership to access it.

so there's the problem, the error message doesn't tell me that the required membership level is Pro.

Well, that was one problem...

On the list of podcasts if you choose one of the older links - eg Twist #16 Catherine Powell or Twist #15 Michael Larsen then you go straight to an error page that does correctly say that the membership level required is Pro.
However, that correctness is spoiled by there being another error message.

You must be logged in. Please log in or register for an complimentary or annual subsciption package.

Top right of the page shows my name and profile details so it knows I'm logged in.
Whoops.

That's one of the risks of running a website for testers, they're going to be all over any mistake they spot...

WT53 - What am I bid for this tester ?

Saturday morning and I fired up my laptop whilst watching Soccer AM and noticed a tweet from @weekendtesting that WT53 was about to start with @jbtestpilot aka Jon Bach.

Couldn't turn down the chance for some testing with the QA director of Ebay so I joined the session and had a blast.

Jon had set the session up to be 4 mini-missions all of which involved using the Ebay site.

First mission I attempted was to find the search term that gave the greatest number of results. First thought was to try wildcards but no, the site insisted on a couple of characters before any wildcards. So what letters would start or be used in the most words. Maybe 'mo' to match 'mobiles', 'motors', 'mothers'...

I started to learn how the site worked, typing one letter and the dropdown would start to offer suggestions so I tried different letters and tried to work out if the categories offered might lead to lots of hits.

'ca*' gave me 18 million results which for a while was one of the top results, 'co*' gave 21 million. With more time maybe a quick automated script to loop round valid 2 char combinations...

Second mission was to find the most expensive item. Could have been very simple if the search by price option didn't insist on having a category. Other people in the session had heard of a yacht being sold by Roman Abramovich for 168 million. This was no longer on there so did not count.

How to find the most expensive item currently on there ? I thought of items that are usually expensive - diamonds, yachts, cars. Some of these led to items on sale for 21 million and also a surprise. I was thinking of physical items but there were domain names for sale for 21 million. That was a good testing lesson.

Then I thought about houses and real estate, sure enough there were some on there, firstly a villa in Spain for 28 million and then a 5 star hotel on Sicily for 38 million.

One mission I did not attempt was to find the most bizarre item for sale. I didn't attempt it for 2 reasons:

1) One mans perversion is another mans pleasure so what I might consider bizarre might seem mainstream to another

2) Once I started looking then I knew I'd get sucked in and be there all day

Fourth mission was to do a Ebay whack and find a search term that only returned 1 result. Initially I thought this was easy - find an item and type in it's entire description. Jon told me that it had to be 2 words only. It still wasn't too difficult, find a search term that didn't return many results and use the results from that.

For example when searching for hotels doing my 'most expensive' search there were results returned for hotel souvenirs. So using a search such as "69 sheraton" gave me 1 result back and an Ebay whack.

Afterwards it was the debrief. Jon explained that the theory behind this and it was Open Book Testing and he was using it to get new testers up to speed quickly. Shrini and I both thought it would also be a useful addition to tester interviews.

As you can tell by reading this blog, it really is a useful guide into the thinking process that is going on when someone is trying to run some tests.

More details of the Open Book Testing approach can be found in this paper by Jon here

It was a fun session, I now seem to be getting a small addiction to surfing Ebay to find what is on there and it was yet another success for Weekend Testing

The Glaze Heuristic

Wish I could take credit for this one but I found it when reading this blog post from Dan North ( which in itself is worth reading ).

As an aside, this raises some interesting questions. What if you are writing scenarios in a domain that no-one seems to care about? (You can tell by watching their eyes glaze when you talk about it.) A lot of what we traditionally call non-functional requirements can fall into this category. For instance, most non-technical people aren’t interested in networking terms like latency, throughput or packet loss, but they might perk up when you start talk about sluggish response times or requests going missing. You can use the glaze test as a heuristic to know if you are talking to the wrong person – or using the wrong language

Looking forward to using this one at the next meeting...

lpr build this

More reading through Beautiful Teams gave me another good story.

This one was from Mike Cohn when he was asked what practices a team could do to improve the quality of the code.
Mike says that the first thing he would want a team to do is a continuous integration approach.

There's now a plethora of tools out there - Bamboo, CruiseControl, Hudson ( pardon me - Jenkins ), Team City, TFS, yadda yadda yadda.

This hasn't always been the case and Mike relates the tale from 1992 and how they utilised a Novell print queue to do the builds for them.


We actually wrote a build server that monitored a Novell print queue. Novell print queues were wonderful. They could hold anything. We put compile jobs into the Novell print queue, and we had a build server that would just monitor it and kick off compiles whenever it noticed anything getting inserted in there.

It was a completely cheesy, crappy way to do this network communication, but just on that application it had tremendous benefits


You might argue with Mike about whether CI is the #1 item on the list but you couldn't argue with that teams commitment to quality !

Roman QC

Reading through Beautiful Teams ( review coming soon ), one of the contributors had a story about engineers building arches and how in ancient times the builder stood underneath the arch as the support was removed.

Trying to find more on this, I found a quote that seemed to be quite well known

"The ancient Romans had a tradition: whenever one of their engineers constructed an arch, as the capstone was hoisted into place, the engineer assumed accountability for his work in the most profound way possible: he stood under the arch.”
- Michael Armstrong of AT&T

I also found that I'm in esteemed company at using this quote in a blog as even Grady Booch has used it...

My searches for more background also turned up the Code of Hammurabi from 1700 BC

Law 229: If a builder has built a house for a man, and has not made his work sound, and the house he built has fallen, and caused the death of its owner, that builder shall be put to death.

Law 232: If he has caused the loss of goods, he shall render back whatever he has destroyed. Moreover, because he did not make sound the house he built, and it fell, at his own cost he shall rebuild the house that fell.

Law 235: If a boatman has built a boat for a man, and has not made his work sound, and in that same year that boat is sent on a voyage and suffers damage, the boatman shall rebuild that boat, and, at his own expense, shall make it strong, or shall give a strong boat to the owner.

I'm sure QA Hates You would still like these laws to apply...

Review - Selenium Simplified

A few months ago I thought it was time to learn more about Selenium and as I was a subscriber to the Evil Testers blog I noticed he had an ebook out – Selenium Simplified.

I paid and signed up, got my copy and had a quick read through but was too busy to look into it in any great detail. Then along comes Xmas and the best present from Santa – time to catch up on a lot of things that were on the back burner and first on the list was working through Selenium Simplified.

The book has 38 chapters and took me around 7 days ( full days ) to get through.
It’s written in a very informative, friendly style, full of tips and information.

Starts off easily with loading your machine up with the necessary bits – Java, Junit, Eclipse ( the book is very java centric ) and of course Selenium IDE and RC and guides you through starting off with Selenium – using the IDE and then running Selenium RC

Which is where I ran into my first problem

“Selenium is already running on port 4444. Or some other service is.”

A quick Google and I found an answer and learned how to use netstat

With that problem solved it was onwards and upwards and with the not evil at at all Evil Tester guiding me I was soon writing my own tests in Eclipse. Having written some basic tests the guide then took you through refactoring the code – not something I’d ever done in my programming days so that gave me a real sense of satisfaction.

This was something I really liked about the book – started off with simple tasks, guided you through them very well and then took you onto the next steps and gave you a sense of achievement and confidence.

The guide also gives you useful minor tips – in all my years of programming I never knew that you could give the Command window a title. A small tip but a very useful one when you have several windows open

The book also does not stick to Selenium but also gives a guide to the basics of Junit, refactoring ( as mentioned above ), Xpath and Css theory etc etc

Basic tests written and refactored, Xpath and Css and HTML forms and Javascript tried out the next step was to use Ant and Hudson. Having read about Ant but never used it in anger it was yet another useful exercise to see and understand how this works.

Just this would have been a good introduction to Selenium but the guide then goes on and takes you through setting up a Selenium Manager Class, using Page Objects, Data Driven tests, running the tests on multiple browsers, cookies and Ajax.

The book comes with source code which is useful when you’ve got carried away and think you know it all and find you have a null pointer exception ! This incidentally was another good learning exercise – a reminder of how easy it is to introduce defects

The penultimate chapter works through all the previous learnings and shows what a ‘production ready’ version would look like. Not only is this chapter useful in itself but it really brings home how much you’ve learnt by the time you reach this part.

Indeed, by this point I had a laptop with a lot of new tools to play with, confidence in having learned and achieved something and found that although it had been an intensive time it was enjoyable. So I looked at the recommended reading section of the book and ordered myself Agile Java…

In summary I found the book to be really useful, and nicely paced.
Recommended

High Quality Defect - Do Not Fix

Jon Bach recently blogged about his experiences with High School students and how he used the infamous bug in Notepad to get their attention

If you type "this app can break" save and close the file, then reopen it, it comes back as rectangles.

"Where's my data?" I demanded, role playing an irate user.


He could also have typed in "Bush hid the facts" or any number of phrases

The defect goes back a long way - Jon mentions it in a 2007 newsletter, Shrini Kulkarni was so impressed when he read an interview where Jon mentioned in that he had to write a blog post on it - and here I am doing the same.

Not just testers that know about it - even bodybuilders were talking about it.

If you haven't heard of this defect then here is one of the many sites that explains it

Now if we were to take the famous Weinberg quote - "Quality is value to some person" then this is a high quality defect ! It provides training material, opportunities for the MS bashers to vent and something for bodybuilders to talk about after they finished their iron pumping.

Has it become a feature and not a bug ?

Use the source, Luke

Raise your quality standards as high as you can live with, avoid wasting your time on routine problems, and always try to work as closely as possible at the boundary of your abilities. Do this, because it is the only way of discovering how that boundary should be moved forward.
- Edsger Dijkstra

Found the quote above in this article about Malcolm Gladwell and the 10,000 hour rule.

Also came across the 'lots of learning' required in the blog post Agile Programming: Lesson One (Part One) by Patrick Wilson Welsh

The Bad News: Lots of Learning
Agile Programming with object-oriented programming languages takes a good long while to learn to do “well enough.” You must master the technical practices, principles, and patterns involved, in the context of “breakable toy” codebases, and then in real enterprise codebases. Even if you are an experienced programmer, expect it to take thousands of hours to master Agile Programming well enough that you can be reliably productive on a mature, healthy agile team in the real world

I've covered this topic before but revisited it after a Xmas break learning some Cucumber ( see last post ). The Secret Ninja Cucumber Scrolls came complete with source code so it was easy to look and learn and see how things were done.

Is it easier to learn coding than testing ? Get yourself some computer theory books and then go off and put it into practice: write your TDD tests, write the code, run and rewrite the code until all tests pass, refactor and voila, done.
Then go off and find some source code and find how the experts ( with their 10,000 hours of practice ) do it. Easy
( gross oversimplification I know )

Want to see a web server written in Postscript ? Here's the source code

Cool javascript apps written in 1k - large selection here all with source code and comments.

Want your code reviewed ? Go here

etc etc etc

So what's available for a tester ?
Having read the theory books ( or maybe not, most testers haven't read a testing book ) then how to practice it ?

For example you can be pro-active in your learning, subscribe to some testing blogs, read the series of posts from IM Testy on Combinatorial Testing and think it's great - but if you want to go and off and practice it to see if you really understood it ?

Even Harry Potter knows that theory isn't enough

Dolores Umbridge:
It is the view of the Ministry that a theoretical knowledge will be sufficient to get you through your examinations, which after all, is what school is all about.

Harry Potter:
And how is theory supposed to prepare us for what's out there?

Matt Heusser posts the occasional testing challenge

The Weekend - and Weeknight - testing sessions are getting more popular and those that take part seem to get a lot from them

Markus Gartner is blazing the way - his latest blog post is on testing challenges and he's set up a Testing Dojos site and it will be interesting to see how this takes off.

( I've volunteered to help out and I'm sure Markus would appreciate more input )


A recent interview with Michael Bolton indicates that just studying 'testing' is not enough

Study testing, but note that the great ideas are likely to come from outside the field—at least the narrow vision of the field that the process enthusiasts and “certificationists” present. Testing is a marvelously interdisciplinary craft. One implication is that whatever you bring to the table from your life and your experience and your education can inform new ideas about testing

I've started a discussion on the STC site about what you would practice if you spent 2 hours a week for a year - how would you spend 100 hours a year on ? Feel free to comment there or on this blog