The Scrum methodology can pose a challenge for software testers who are used to more traditional waterfall-inspired development processes. Jonathan Kohl relates his experiences working on Scrum teams who found some clear advantages in changing their methods.
Conventional Software Testing on a Scrum Team
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’m glad to see more emphasis being placed these days on iterative processes in programming. It marks the evolution of programming towards becoming a mature engineering field. I’m somewhat puzzled that in all the talk of good processes, there is no talk of good tools, but I figure that the importance of good tools will become evident to programmers when they sort out the problems related to methedology.
There ain’t anything new under the sun — just different packaging. 🙂
Also, a good tool can help, but in many cases a tool is not an adequate good substitute for a clueful developer (no matter what project management weenies might tell you <vbg>).
That it may be too stressing for some developers to work this way.
Why? Because they actually have to work at a regular pace, instead of trying to get everything done in the last week?
I’m not a big fan of “XP this” and “Agile that”, with authors promoting fluffy and expensive books, usually from Addison Wesley.
It’s not that the individual techniques are bad. The ideas of short iterative development cycles, writing comprehensive unit tests early in the game, and holding design and code reviews are time-tested; they go back decades, though they aren’t universally adhered to. But the authors and trainers of these methodologies, probably realizing that packaging best practices isn’t enough to justify the funny names, come up with dogmatic approaches – the team must meet for 15 minutes every day (even though some developers are early risers, others late risers, and others do lots of work at home), all unit tests must be written before any code, programming must be done in pairs, etc.
An intelligent person reading one of these books (hopefully borrowed from someone else, because they aren’t worth the $34.95 cover price) would consider it as another bag of tools which can be mixed and matched on a per-project basis. I don’t think any of these prepackaged methods would be a good approach for developing an operating system kernel, for instance, even if all the developers were on the same campus.
Paul G
I’ve never been able to do this well. It feels more natural to develop the first iteration of my unit of code, then create the unit test. The unit test will invariably drive the remaining development iterations of the module that I’m building. The unit test will evolve with each iteration as well.
Am I missing something? Maybe I just stuck in my ways.
I can’t generally do this either, and I’m not a particular big fan of the practice. Designing the interface before at least prototyping the code always seems to lead me to baroque, inelegant interfaces. I prefer to start with a basic kernel that does the essential job of what a particular component needs to do, then use the knowledge gained from that exercise to design an interface that fits both the client of the component, as well as the implementation of that component.
I like this idea and have used it in the past with some success, but our time frames were a little different. A meeting every few days worked well for us, and our sprints were usually between 4-8 weeks (never exceeding 8). The result of each iteration was a internal release for QA with fully implemented functionality.
Good. I thought it was just me.
The software beast is not easily managed.
I’ve never heard of any software developer delaying code writing “until the end”. Nor would that make good software.
Props to PaulG’s comment, and to the ‘anon’ who talked about writing the first crack at the code before the first tests — I do this also.
When I worked at Hughes Aircraft on the Military Automated Air Traffic System (MAATS), bugs had a lifetime of months, possibly years — the exact opposite of my approach which is to interact with other programmers as needed and fix bugs ASAP.
The infamous waterfall technique is an IBMism, pound for pound the worst software writing company in the world.
Microsoft comes out with tons of builds and “eats their own dog food” — I am quite sure this leads to programmers ‘talking to’ programmers a fair bit.
Bottom line: I think most of good programming is common sense, and that most managers get completely in the way. Proven by the fact that the best programs were one man bands, like Borland’s early stuff, Hertzfeld’s contributions and of course The Woz. Even Gates did his best work early, and on his own — once famously coding some core software functionality on the way to delivery to the client.