Some thoughts on iteration vs incrementation

Alister Scott’s post on Incrementation vs Iteration was doing the rounds at work with some comments, and I felt the need to comment.  I had a couple of attempts at responding to this.  It’s a big topic, but to some degree I think iterative vs incremental is a bit of a distraction as a general philosophical discussion (and I *love* philosophical discussion, so I am not meaning to be dismissive).

I think it’s more important to ask -

- What is our plan for validating the product definition?
- What is our plan for validating the architecture?
- How does the organisation want to ‘manage the work’.
- As a team, how will we know when our work is ‘good enough’?
- As a team, how do we plan to manage incomplete work (ie. future enhancements and defects).

The first two are probably the biggest factors of uncertainty that will drive the degree of iteration vs incrementation.

The third is a question relating to the organisations belief systems around predictability of software projects and how much power management wants in designing work methods to support their agendas.

The fourth question will shape how actively the team works against ‘doneness’ by finding bugs, soliciting feedback and exploring the solution space throughout the iteration.

The last question is about how the team wants to manage defects and backlog.  If you don’t want to carry bugs and want to minimise backlog management, my experience is that the sprint needs to plan for internal iteration (or you need to get rid of sprints/iterations and go with a pull/dock assembly approach).

The most important thing is understanding why we iterate.  Alister highlights a couple of examples when he talks about time to market vs user experience prioritisation, but it’s only sensible to talk about iteration in specific contexts of uncertainty and risk management.  Similarly, we discuss incrementation in the context of the cost/benefit of a particular release approach and/or schedule.

I feel the biggest lesson in the Android/iOS history is as an example of how expensive it is to fix architecture if you get it wrong.  Excuse me before I start on my old-guy ‘RUP got it right’ rant.

More Ruby goodness for testing

Did I mention how much I love Ruby?

items = (“A”..”Z”).to_a.in_groups(5,false)

5.times do | i |
puts items[i].flatten.to_s
puts “—-”
end

Source code is at http://apidock.com/rails/Array/in_groups

Yet another reason why testers should use Ruby

Instant sequence of New South Wales licence plates:

start_lpn=”AA00AA”

end_lpn=”ZZ99ZZ”

return start_lpn.upto(end_lpn).collect { | lpn | lpn }

Cem Kaner interview on uTest blog

Cem Kaner’s interview on the uTest blog talks mostly about his new book, but was especially interesting when it got to the part about emerging trends.

<Scientific> communities are sometimes characterized as moving between two dysfunctional extremes, with stagnation at one end and fragmentation at the other. In the stagnant extreme, everyone pretends to believe in the same things (or the dissenters are unable to gain attention) and the field makes slow, incremental progress. Dissenters break out of this by forming schools that gain influence and add a lot of creative tension.

Testing seems particularly stuck in a period of stagnation at the moment.  Hopefully time will see some interesting new schools form.  I put myself in the ‘dissenter’ category right now with respect to what I would once have considered my testing ‘community’, the context-driven school.  I know I’m not the only one that feels this way, but I’m not in a place in my life right now to voice my feelings on the subject.

Kaner and Bach’s public split is certainly evidence of fragmentation.  It will be interesting to see what happens next.

Jonathan Kohl back down under with testing and user experience training

Jonathan Kohl is going to be back in Australia and New Zealand in February with his mobile testing course, as well as with a new course on mobile application user experience.  Courses are being run through SoftEd in Auckland, Wellington, Melbourne and Sydney, so check it out!

I’m hiring

I currently have a vacancy in my team for an assistant test lead to carry some of the low-level planning, bug and environment management load.  They would also be hands-on.

See Transurban’s career site for details or contact me if you have questions.

A reminder on what not do when you’re automating testing

Five years ago I wrote, somewhat flippantly, on automation failure, but apparently some people never noticed.  It still seems relevant, so please go and read (or re-read) ‘Automate your way to ineffective testing with my twelve step program…

Problems with CA Workload Automation

On the off chance it helps someone else, when firing up CA Workload Automation for the first time, it failed to start with the message ‘JVM terminated, error code=-1′.

There was no obvious cause for this, the install was a fresh one on a newly set up machine.   I reinstalled the JDK, and still the same error.  A bit of reading suggested there may be issues with an ini file related to eclipse.  I found the CAWADesktopClient.ini file and had a look.  The file looked a bit messed up, with lines being broken in odd places.

After making it look like this…

…everything is working as it should be.

Hope this helps someone.

Yodle are looking for a tester

This came out of the blue, and I don’t know much about them, but someone from Yodle.com asked me if I would spread the word about their open tester position (New York-based). On paper, it looks pretty interesting, and my readership is mostly US-based, so hopefully this might help someone out: http://www.yodle.com/yodle-careers/jobs/new-york/qa-engineer/

Test Strategy Mnemonics

Based on some current work, I’m going to need to extend my test strategy mnemonic to include ‘Accountabilities’.   That gives me a ton of options, such as ‘Gated Script Rats’, ‘Script a test drag’, ‘Attracts Red Pigs’ or ‘Egad! Script tarts’.

I’ll update once I’ve decided, but feel free to offer your favourites from the Anagram server, here and here.

Page 1 of 1512345»10...Last »

About me

I'm Jared Quinert, a testing consultant located in Melbourne, Australia. With over fifteen years of experience, I specialise in agile testing, context-driven testing and intelligent toolsmithing with a focus on business outcomes over process. As one of the most experienced agile testers in Australia, I've been diving in hands-on since 2003 to discover how to build successful whole-team approaches to software development.

Contact Me