The full program is available on the Eclipse Testing Day Wiki Page, and we’re pleased to be able to offer a selection of talks about different areas of testing, including:

• Acceptance and GUI testing
• Embedded testing in OSGi
• Scope and coverage of tests
• Unit testing
• Test generation

As mentioned in the previous post, registration is now open on the Eventbrite Site. Member tickets (Eclipse and OSGi members) are priced at 40€ net, non-members at 50€ net. The ticket cost covers the event organization and includes catering during the day and the evening reception.

We’re looking forward to a successful day – start inviting colleagues, contact us if you’d like the logo and we’ll see you on the 8th September in Darmstadt!

We’ve created an Eventbrite site to ease the registration process. Details of prices and payment are both on the Eclipse wiki and directly on the Eventbrite site, but just get in touch if you have questions.

We’ve also extended the call for papers for another week – you have until the 10th July to submit your abstract (again, details on the Eclipse wiki). Any Eclipse and/or testing enthusiasts are invited to tell us about how they test, and of course, to register for the day. Tickets are limited to 80 participants, so we recommend registering early!

The first half of the evening saw Brox’s demonstration of SMILA followed by a demonstration of testing Eclipse applications with GUIdancer by Bredex. After a short break the camp continued with the two final demos: Erhard Weinell of Yatta Solutions showing their UML Lab and Sven Efftinge demonstrating XText. If there is a prize for how many Eclipse Award winners are present at a Demo Camp, then this one is a good contender: Both XText and GUIdancer were winners of awards this year.

After the demos there was enough time for chatting, discussions and introductions – Ralph Müller from Eclipse and Michaela Kraft from Microsoft were both on hand to provide excellent networking opportunities.

With even more new faces at this demo camp than the previous one in November, our hope of creating a strong Eclipse community in the Hannover/Braunschweig region seems to be becoming reality. Stay tuned for more Eclipse events!

The slides from the demo camp are available on the Eclipse Wiki.

Previously we’d found ourselves wasting time because a story wasn’t thought through well enough, either from the development/implementation perspective (we went the wrong way technology-wise) or in terms of the features (incomplete or inconsistent concepts, for example). We were also ending up at the end of a sprint with nothing deliverable because our chunks were often too big.

After a good session with Lisa Crispin last October, we put some ideas into motion about making our stories better described, with a focus on deliverable, testable requirements.

1. We take the time as a team (sometimes all of us, sometimes just a few, depending on the meeting and story) to really talk our way through stories for an iteration. This often means spending more time discussing things than we previously did – we even invented a new word for the process “excrucialating”. A combination of excruciating and crucial. Especially in terms of epics, this has really paid off for us though. Now even stories that are connected and continue over many sprints end up being deliverable and we find ourselves on the wrong path much less often.
2. We make a huge effort to make story points as “thin” as possible. We focus on value – what *must* be achieved to make this story useful for the customer? Nice-to-haves and other features either get put into the product backlog, or we write cards in case we have time at the end to smooth things out.
3. Acceptance test criteria are a part of the story and we write them on the card. Sometimes a story has to be written in a more technical way, but wherever possible, we describe (and often automate) the test that will prove that the story is done.
4. We introduced a story board in the room where we have our stand up meetings. We have four columns: planned, under construction, to test and done. The “to test” column came later to make us really aware that “done” is also tested. Ideally, cards shouldn’t be in the “to test” column for very long though. An automated test should tell us the next day if the feature is done, and a manual test should be done as quickly as possible once the feature is committed.

These few steps have really helped us over the past few sprints. We’re coming along well with our stories and are getting much better at identifying (and sticking to) what we *need* to implement to release a new feature.

So far, so advantageous for the team. But we’ve run into the question a few times now of “where is the time to refactor”? The focus on thin stories that implement the minimum amount of code possible to gain new features doesn’t leave much room for making the internal code better, clearer or more maintainable on the way. After all, no-one can release a new version of the software that proclaims to do everything it did before, just with nicer internal code and updated libraries.

There’s a few ways we could try to deal with this:

1. Adjust the amount of stories we try to fit into a sprint to leave us the time to look at such areas.
2. Work on a case-by-case basis. If we have to extend the time a story will take to gain much better code, then we can make this decision for certain stories.
3. Introduce regular sprints (perhaps shorter than our usual 4-weekers) to work on internal knots we’ve identified recently.
4. Add a certain amount to each story for “possible refactoring”.

We haven’t decided which of these options we’re going to try (first) yet, but I can imagine that it’s not a question that just affects our team. We’re pleased that we’re focusing on features, but we are noticing that the time-pressure has increased somewhat by doing this. We’d be interested to hear suggestions of what other people have done to combat this, and I’ll keep you up to date on our process and results.

Eclipse Demo Camp
On the 21st June, we’ll be organizing an Eclipse Demo Camp in Hannover with Brox IT Solutions GmbH. We already have three confirmed demos and are waiting on another two, so we’re looking forward to another successful camp. The Eventbrite page is up and running for you to register, and details about the Demo Camp are on the Eclipse Wiki.

Eclipse Testing Day
On September 8th, we’ll be in Darmstadt with MicroDoc GmbH for the Eclipse Testing Day. The call for papers is now open, and we look forward to hearing your suggestions for talks about testing Eclipse as a platform, testing OSGi applications and testing tools based on Eclipse. We’re also still looking for sponsors – more details are on the wiki page.

These two events should be a great chance to meet people from the Braunschweig and Hannover region, as well as test enthusiasts within the Eclipse Community – so get registering, submit a talk and come and meet us at one (or both) of the events!

Now we have a continuous integration process; the latest version of the software is built and tested every night. This has brought us many benefits: we have quicker feedback on developments and the team can work with the current version each day. However, despite having functional software every morning, we don’t have a version any more that we can call a beta. Daily builds are feature-incomplete and there are occasionally areas that shouldn’t be touched or worked with because they are still somewhat under construction. If we’ve been working on epics, then we often have new developments that are leading up to a new big feature, but not the actual feature itself. It’s hard to make a cut and say “this is the beta”.

We’re still unsure about whether this bothers us, though. Do agile projects need specific beta versions, or should customers be able to work with the daily build, having been informed if any areas are unfinished? If betas are desired, how can they be planned for and constructed in the agile paradigm?

Maybe it’s an obvious point, but I’d like to suggest that agility isn’t just beneficial for the customer; it’s also beneficial for the team.

The fresh news just in this morning from EclipseCon is that GUIdancer has been chosen as the best commercial developer tool in the Eclipse Community Awards for 2010. So the GUIdancer team had the chance to toast their success at our meeting this morning before getting down to business about the upcoming 4.0 release.

To round off the month’s activities, I’m off to the Agile Acceptance Testing Days in Belgium tomorrow to give a talk on agile testing and am looking forward to some good discussions with the community there.

The next few months are likely to be just as busy – we’ve got more conferences coming up and we’re organising the Eclipse Testing Day with MicroDoc and the Eclipse Foundation on the 8th September in Darmstadt. More details about call-for-papers and sponsorship will be coming soon, but feel free to get in touch if you’re interested in participating.

That’s about all from my end for now – except to wish everyone a happy Easter and a good break for those of you having one!

Braunschweig Eclipse Stammtisch
First of all, we’ll be having the first Eclipse “Stammtisch” of the year on the 24th February here at BREDEX.  Ralph Müller will be there and we’ll be hearing from Markus Tiede about a “normal day working with Eclipse” before we go round the corner to “Mephisto” for some food and drink. If you’re interested in coming, or if you want to speak at an upcoming Stammtisch, take a look at the BREDEX website for more details.

CeBIT
The second piece of news is that BREDEX is going to CeBIT! We’re teaming up with other members of the Eclipse Foundation to showcase Eclipse technologies and solutions.  Drop by the Eclipse Island, in the Open Source Park, Hall 2, booth numbers 151-154, to meet representatives from EclipseSource, Actuate, SOPERA, BREDEX and the Eclipse Foundation.  Visit the demo theater and see Eclipse products and projects, including GUIdancer, Yoxos, RAP, BIRT and Swordfish.

Looking forward to seeing you there!

The location in the Stadthalle was perfect: enough space for the 48 participants with room at the back for drinks and snacks in the break.

Networking in the break

We were treated to five demos over the course of the evening, starting with Ralph’s contribution – complete with mandatory audience participation! He was followed by Sebastian Voigt from brox, giving a demo of SMILA and Eccenca. Just before the break, we presented our role play of an agile development team working with GUIdancer.

Benjamin Muskalla, who had joined us all the way from Karlsruhe in an elaborate demo-swap between EclipseSource and Bredex (Markus Tiede will be heading to the Karlsruhe demo camp on December 3rd), welcomed us back from the break with his demo of the Eclipse  Memory Analyzer and RAP. We even saw some spontaneous community spirit when Frank Fauth from IT-Region 38 lent Benny a power cable for his slowly dying computer. The final demo of the evening was from Prof. Dr. Kreyssig from Ostfalia, who showed us how he uses Eclipse to program embedded systems. The demo culminated with the words “Eclipse Demo Camp” being shown on an LED display.

Eclipse Demo Camp

After the camp we were grateful for Ralph’s invitation to have a drink in a local restaurant and for the chance to get to know some of the participants a little better.

I think that the success of this demo camp shows us that we have the makings of a strong Eclipse community here in the Niedersachsen area. I hope that you all enjoyed it as much as we at Bredex did, and I look forward to seeing you at the next Stammtisch or Demo Camp!

Slides for all the demos are available on the Bredex website.