Ranked 79 in Phase 1 with 36 unique views, 7 counted upvotes and 9 counted downvotes

About the author

I test (mainly) & write (less so) software, studied physics. I like the ocean, mountain hiking & art. Languages (in alphabetical order): English, German, Ruby

As for the event: I hope to meet old and new friends, see a bit of Athens and bring hone lots of great ideas — and some greek (cretan, actually) thyme honey. :-)

The Days After Tomorrow — Are Cucumber, RSpec, Mini::Test And Friends Enough?

The anniversaries we're celebrating at Euruko 2013 are a good reason to think about what you need to do, to create long lasting software. Let's think about the future of the software we're building.

Sure: If our software fails to provide enough value today (or at least in the near future), we'll probably be better off looking for the next job. However, software development is a game played in rounds — and most teams nearly always prefer to stay in the game for many rounds.

It's interesting — and a it worrying — that most of the testing techniques and approaches applied today are focussed on the current version of our software and its ability to solve to right problem and doing this correctly: We concentrate on a relatively short period of time.

However, we should also make sure our systems can cope with tomorrows requirements, customers and users. Therefore, let's look at some ways we can do this.

Previous Next


  • The proposal author responded 8 months ago

    Thanks for the comment. You're right it is supposed to be a teaser as well as an abstract. I'll tell you a bit more about what I have in mind, yet, won't tell the whole story. Because, you know, what's the point of telling everything in an abstract (and/or teaser)? If you do, who's going to listen to you at the conf? ;-)

    What I see a lot in many projects I've worked in, is that the better ones are using well described business scenarios for testing (whether these are automated or not, often written in Cucumber, if automated) and/or pretty detailed unit tests (automated almost always using RSpec, Mini::Test or what-have-you). And that's fine: If done right, these help team implementing the right systems and feature and it also helps to avoid bugs.

    However, I learned that team should also have the future of the project in mind and be open to probable/likely new features and/or unanticipated uses of the system. I think we should find ways to explicitly work on topics as maintainability, expandability, etc. (It's called software for a reason.)

  • 9287985f53b36866bb3c639a6aedc867?d=retro John Pagonis suggested 8 months ago

    Hi, could you care to elaborate? Your abstract sounds more like an interesting tease :-)