Skip navigation.

Development methodology

Thoughts on Agile & Agile Testing

agile | development methodology | general software testing | perspectives

This past weekend, I finally made time to start reading Agile Testing: A Practical Guide For Testers And Agile Teams, Lisa Crispin & Janet Gregory, Addison-Wesley (2009).  I made it through the first two chapters before life called me away.  After I put the book down and starting going about accomplishing a mundane series of errands, I realized that I was feeling disappointed and that the disappointment had started growing just a few pages into the book.  Not because of what the book had to say, what it said was pretty good – not exactly how I would have expressed a few things, but thus is the plight of a writer reading what someone else has written on a topic they also care and write about.  What was disappointing me was the fact that the stuff in those chapters needed to be said at all.

Sharks, Debts, Critical Mass and other reasons to Sustain Quality

agile | development methodology | extreme programming (XP) | project management

A while back I tweeted about critical mass of software:

Critical Mass of Code - past which the changeability of the code is infeasible, requiring that it be completely rewritten.

An elaboration of this might be:

Critical Mass of Software: the state of a software system when the cost of changing it (enhancement or correcting defects) is less economical than re-writing it.

This graph illustrates a hypothetical project where the cost of change increases over time (the shape of which reminds me of a thresher shark):

Agile Performance Testing Again

development methodology | non-functional testing | performance testing
Two Views of Agile Unit Testing reminded me (indirectly) the QAForums Agile Performance Testing - Oxymoron? discussion about agile development and performance testing some time ago

Well, if we talk about agile development I don't see any problem with performance testing at all: you have a working build each iteration – you test it. What is a problem? It should be synonym, not oxymoron.

The short and the long of IT: two videotaped presentations

context-driven testing | design & development | development methodology | functional testing | test automation

Since the middle of the year, I’ve presented and facilitated about 12 hours of sessions at 2 traditional and 3 open space conferences, plus a Googleplex visit. Two presentations are now on video, both filmed on the other side of the world from my usual location of Melbourne, Australia.

A lightning talk (at the functional tools workshop held before Agile 08 in Toronto, Canada) called Shades of Green discusses how the “green” passing tests of functional automation may not be as green as they seem. Note the static pose to stay within camera range, compensated for by the wildly waving arm. And yes, the audience was not limited to a leg and a foot.

An order of magnitude longer at around 50 minutes, a Google Tech Talk (filmed at the San Francisco Googleplex) called 80:20 Rules! Building Software Smarter looks at formal and informal ways to get significant improvements in creating software, including various puzzles and questions for viewers. I had looked at some tech talks by other people I know, and they had been watched around 1000 times over a year or so. It looks like I may hit that mark only a few days after the video was posted which is great. I hope my talk inspires people to build their software smarter. Can I turn “shades of green” into a similar talk? Probably not!

Testing Lessons From Civil Engineering

context-driven testing | development methodology | events | functional testing | general software testing | heuristics | patterns | perspectives | test analysis

Below is the paper I submitted as a prologue to an experience report, discussion, and (hopefully) additional research that I'm presenting for the first time during:

Attend CAST

Performance Requirements

architecture | design & development | development methodology | non-functional testing | performance testing | performance testing patterns
My performance requirements paper was published in the January issue of Software Test & Performance (pp.18-24).

It was simple: I just sent a draft – and now I am reading it printed. With a new name - or even two: it is referred as You Can Gauge Performance Without Requirements in one place and Gauging Performance in The Absence of Measures in another. Not to mention other minor improvement.

From the Mailbox: Software Development: Art or Science?

design & development | development methodology | metaphors | perspectives | project management
Here’s a question that I didn’t realize I had much to say about until I read my own response.
 
The Question:
Software Development: Is it an art or a science? An age old question I know, but what do you think and why?
 
My Response:
 
I refer to new software development as a scientific art. I've seen some maintenance work, platform porting, etc. that has been almost entirely mechanical -- I'm not sure what that counts as, but I certainly didn't witness anything "artistic".

What Skills Performance Testers Need and How to Get Them?

architecture | design & development | development methodology | non-functional testing | performance testing | performance testing patterns | performance testing tools | service oriented architecture | stress testing
From time to time I see questions on different forums asking what skills are necessary for performance testers. There were pretty interesting discussions. Looks like most experts agree that performance testing requires more skills than just knowledge about how to create a script for a particular load testing tool. While it is still possible to imagine a performance tester in a large corporation with deep specialization who only creates scripts and mechanically runs them while other performance experts monitor the system and analyze results, I don't see many perspectives neither for this person, nor for the approach. Systems become so complicated now that the sum of specialized expert views doesn't give the whole performance picture.