New challenges and experiences

The Eclipse Testing Day has been very successful over its past three years, and we intend to make the fourth year just as interesting for speakers, sponsors and attendees. We've chosen the exciting topic of mobile testing to reflect the new challenges is brings and the solutions it requires - be they technical, process-based or people-based.

The list of possible topics includes:

1. Eclipse projects with mobile aspects - and their testing
2. Cross-platform development and testing for mobile applications
3. Eclipse tooling for developing and testing mobile applications
4. UX design in mobile projects
5. Case studies of mobile testing projects
6. Mobile testing as a part of the application lifecycle
7. Comparisons between testing in desktop and in mobile projects
8. Manual, automated and crowd testing for mobile projects
9. ... your own take on the topic of mobile testing

Submitting a paper is easy

Just send an email to testingday@bredex.de with your 150-word abstract (in English), a short biography and a picture by 21st June 2013.

Got a solution to share? Sponsor a great event

As in previous years, the Eclipse Testing Day is non-profit. Our sponsors and supporters are the backbone of the day. If your company is involved in mobile development or testing, then you should consider supporting a fantastic event while meeting interested participants. We've got various sponsor and mutual benefit packages available - and if you have a different idea for sponsorship, then we'd love to hear from you too!

An overview of the sponsor and support packages is on the Eclipse Wiki Sponsor page.

Here's to a successful testing event!

• mobile
• events
• Eclipse Testing Day
• Eclipse
• test

One of the things that I love about the Eclipse community is when a talk includes the sentence "we saw this at a Demo Camp and decided to try it out". That's just what happened to Sebastian and his team - after seeing Kai Tödter's prototype for Swing renderers for e4, they realised that was just what they needed. After all, even though Swing is officially on its way out, their first consideration is to migrate their underlying platform. That way, they can gain the benefits of a more modern standard (that would be e4 ) without losing all of the work they've done on their GUI components - including custom controls and behaviour.

Sebastian gave a report of their progress up to now - after a three-week proof-of-concept phase, the decision was made that the move was feasible, and they're expecting the release to happen this summer. At a later point, they may move to JavaFX, but that's a different story.

Eclipse and Swing may seem like an unlikely pairing for some, but Sebastian's team have been using an Eclipse-based framework for years, and the work of people such as Kai Tödter and the Eclipse Scout team show that it's still of interest to the community. The most pleasing aspect for me though, was to hear that the prototype for Eclipse 4 + Swing was testable with Jubula / GUIdancer out-of-the-box, just like we found out for Scout applications .

• events
• Eclipse Stammtisch
• Eclipse

Eclipse e4 support

From a development perspective, the Eclipse 4 support was very much an area that we are familiar with and posed almost no problems.  The only challenge was pulling our internals apart and putting them back together to deal with differences between the 3.x and 4.x strands, but still profiting from the code reuse that was feasible for around 95% of our support.

The result is that, from a user perspective, almost nothing has changed. We put a lot of thought into the packaging of our support plugins (the RCP accessor), and decided that we wanted Jubula or GUIdancer to be able to decide which plugins need to be started. So, in this version, as in the previous versions, there is still one zip file whose contents have to be added to the plugins folder of your AUT, and the rest is done for you. It was certainly exciting to see the first tests running on pure e4 applications (we’re writing one for a customer, so we had a chance to eat our own dogfood fairly early on), and the support for e4 with compat layer means we can also finally consider moving to Juno or Kepler – we could test ourselves now.

iOS applications

On a wholly different (but equally exciting) topic, we’ve also made our first step into the test automation for the mobile world. The iOS support is only in GUIdancer, but we encourage everyone to get a demo license and try it out for 30 days to see what you think.

Again, we put a great deal of work into making sure that as many concepts remain the same for testing iOS applications as they are for desktop toolkits. Most of the actions already available for the desktop components can be used for iOS as well. So you can use the unbound modules to click (tap), to execute actions on lists, tabbed components, combo components etc.

Nevertheless, there are some technically motivated differences that are worth mentioning briefly (more information is in the documentation, and we’re planning some more blogs with examples):

1. Adapting the AUT : it’s a technical necessity to make an iOS AUT accessible for testing. The work to do isn’t much – just adding some header files to a test version of your app, and maybe adding some component naming if you want to show your love for your testers (which we assume you do :) )
2. Starting the AUT : for iOS applications, the AUT already has to be started, either on the device or on the simulator, in order to test it. The „Start AUT“ function from the ITE or from the testexec just connects to the AUT. The basic gist of these two points is that the development team should ensure that the AUT is testable and deployed for the tester.
3. Object mapping: You can generally collect and address a great deal more components in an iOS app than in a desktop app (for example, a button with a label can be broken into its composite components of button and label). The same applies to complex controls such as Table Views, which can be addressed as lists, or as any of the components they contain. There is more of a decision-making process involved in choosing the correct component to test, and this is reflected in the object mapping. We’ve implemented three gestures for object mapping:
   1. A single tap collects the component you tap.
   2. A double tap collects the component you tap and its parent. This is particularly useful for collecting the button "behind" its label, for example.
   3. A long tap of more than two seconds collects all currently visible components.

So some parts have changed, but the general concepts and principles have remained the same. As with e4 support, we’ve also been testing this on a customer application, and we’re excited about getting feedback from our users.

Other stuff

There are some other goodies in both tools too. Dedicated 32- and 64-bit installers, screenshots for errors in HTML reports, Windows 8 support, and a much more compact properties view. We’ve also made navigation easier – double-clicking items in browsers will now open the parent Test Case for that item. Double-clicking in editors now opens the item you double-clicked. These are suggestions that have come in from you, our users, and we’re happy with the effects – it’s much easier to work with the tool.

In just a couple of days, we’ll be heading to EclipseCon in Boston. Come and chat to us to ask us about the new version, participating on the project, and your own testing projects.

• mobile
• Jubula
• GUIdancer
• Eclipse Con
• Eclipse
• automated tests
• Release
• testing
• test

Keynote - Practices and Principles

The format of the keynote was great - using cartoon potatoes to represent members of the agile team. Andrea made some good points about what following a practice without understanding the principle behind it can do. If stand up meetings feel like control meetings, planning meetings feel like being shot at with stories, and retrospectives feel like you have to defend yourself, then something is very wrong. I liked his point about agile being about capacity management - you can't make (some old type of) printer print more than 6 pages a minute, and any attempt to do so will result in a paper jam. He talked about the team pulling from the backlog instead of having things pushed on them, and I liked that too. I'd argue that teams starting out with agile will usually (have to) begin with the practices. They should review them frequently ensure they are really in line with the principles (kind of like introducing agile iteratively) - but his warning signs are valid for all teams, regardless how long they've been together.

Agile Test Automation at Xing

This talk was an overview of how teams work at Xing, with a focus on the test automation for the mobile applications. It is fascinating to me that there are separate teams to work on separate applications - it clashes with the "write once, run anywhere" principle that we know from the desktop - and that I know BREDEX has as its aim for mobile development and test automation as well. Unfortunately I didn't get to chat to Sergej for very long because of the next talk, but he did make the point about different user circles and their expectations from an app. I'll be interested to hear from other mobile talks how other teams deal with cross-platform development and testing.

Exploratory testing for developer, testers and you

I was undecided about whether to attend this talk, because I've heard various talks on exploratory testing. I enjoy them, but I was unsure about whether I'd learn something new. I was so glad I went! I liked the very logical explanation of automating what we know to make sure we always know it, and using exploratory testing to find out what we don't know we don't know (second order ignorance). The real benefit from this session for me was session-based test management (SBTM). I'd heard about it before, but had never really been able to understand how to put it into practice. As luck would have it, our team had made the decision to have a "Test Day" just last week, and suddenly SBTM fell into place for me. Meike, Markus and Sven from Atlassian gave me some excellent tips after the talk, and we're going to try it out next Monday for our Test Day.

Dialogue Sheets for retrospection

This was a workshop using Allan Kelly's dialogue sheets to guide teams through a retrospection. I enjoyed the sheets - and the most useful part for me was chatting to the others in the team about our problems. I shared some of our current problems and got some good tips, and was able to share some solutions we've tried. A good session.

Aiming Higher - using test automation to drive better quality

This was the talk I held. As a non-developer, I was a little nervous about speaking to a room of developers - especially on a topic that can be translated as "how to take little steps to get benefits and use them as leverage to get the team to do more for CI and continuous testing". As it turned out though, I had a good mix of roles, and even the developers listened with open ears

Seriously though, the talk was about taking a very agile approach to test automation. Every little step already brings benefits - even if the whole aim isn't achieved. Sometimes the person or people driving the test automation need leverage to get the tools (in an abstract sense) they need, and I hope the talk provided some nuggets of information to take home.

Home was the operative word after the talk - I had to leave before the last keynote. But, the day was well worth it, and I'm looking forward to putting the things I learned into practice.

• testing
• events
• agile dev practices

e4 Support

Admittedly, we’re not as quick off the mark on this one as we’d have liked to have been, but nevertheless we’re proud to be able to release the support in the Jubula standalone as a preview for Kepler. We’ve already tested a customer project with the latest version, and can’t wait to offer it to the community.

iOS Support

GUIdancer customers will get the extra benefit of our new support for iOS applications. The concepts for test automation that you know and love from Swing, SWT/RCP/GEF, HTML and .NET have been transferred to the mobile world, and we’re looking forward to making it available. We’ve also been using this new toolkit in our projects – it’s a relief to finally be able to reap the benefits of automated testing in mobile applications as well.

EclipseCon

Three team members from Jubula / GUIdancer will be at EclipseCon, and we’ll be very happy to meet anyone interested in the work we’ve been doing, as well as any testers working with the tools or wanting to find out more. See you in Boston!

[1] EclipseCon Talks

• Continuous testing - where the rubber meets the road
• Testing a Scout Application with JUnit and Jubula (Presented by BSI)
• Designing software with users and testers in mind

• GUIdancer
• events
• Eclipse Con
• Eclipse
• Jubula

Due to a large contribution from one of our new committers, we’ve been able to remove a great deal of redundancies from our “RC” (remote control) code - the part that’s responsible for test execution - in the Swing and SWT / RCP toolkits. This makes it easier for developers on the project and anyone extending the tool to add new components and new toolkits. On the other hand, it has meant that a lot has changed on the RC side, with three side-effects:

1. Any existing extensions will have to be modified to work with the new versions. Class names, method names and constant names have changed, and there are new adapters to make your access to our implementation classes easier. We are documenting the steps to make your migration as painless as possible, and we’ll be providing the details with the release and here on the blog.
2. Writing new extensions has therefore changed as well. Again, we’ll be updating our examples to help you along.
3. All actions in the unbound_modules libraries that are preceded with DEPRECATED have been removed. This means that you should make sure that your tests don’t use these modules any more before migrating to the new version.

If you’ve got any questions about migrating to the new version, then the community forums and the blog will be a good place to look for general help. The GUIdancer/Jubula team will be at EclipseCon in Boston if you’d like to chat to us then, and don’t forget – if you’d like our guys to do your migration for you or to answer specific questions on your extensions within 4 business hours, then these are options too - contact us at sales@bredex.de to get more information.

We’ll be in touch soon to update you on what’s coming in the new version, until then - happy testing!

• Jubula
• GUIdancer
• Eclipse
• test

There's no need to worry - just because we're not exhibiting in the Open Source Park with the Eclipse Foundation doesn't mean any change to our involvement in either of those communities. This year we just fancied a change - and a chance to showcase some of the opportunities we offer in terms of mobile development and, of course, testing.

So come and join us in Hall 6, Stand C8 110 from 5th-9th March in Hanover. We'll be on hand to talk about work we've done with customers on their mobile projects, our research and experience in cross-platform mobile development, and the steps we're taking to ensure quality in mobile projects. As a teaser : the upcoming version of GUIdancer is something you should definitely ask us about

See you at the CeBIT!

• Test automation
• mobile
• Jubula
• GUIdancer
• events
• development
• CeBIT
• test

The topic seemed to really attract attention - we had good questions and discussions throughout the whole talk, and people chatting about e4 afterwards in the restaurant as well. I got the feeling that quite a few people have already looked into the new platform and are thinking of using it if they get the chance.

And hopefully, Ulli's talk will help them on their way. His experiences so far have made him a great fan of dependency injection and the new application model, but has had some problems with event handling in the context of lazy loading, and has already (re)written some renderers to make the application behave more how his customer expects it to. CSS was another topic that seems to be slightly problematic, although Ulli did admit that he hasn't worked on this area so much yet.

Since the experience report proved very popular, it would be great to hear about other projects either migrating or starting fresh for the next Stammtisch. If you're interested, drop us a quick line at .

• events
• Eclipse

The story dojo

This was a session of 90 minutes where we practised writing stories and examples, then practised splitting up stories in groups. The great insight for me from this session was that the difficulty sometimes present in writing great stories and delivering thin slices of value is something that every team will have. The questions I had about the exercises were exactly the questions that other people had too. Sometimes it’s just great to learn that you are working in the same way as other people, and that some subjects are just tricky.

“Technical awareness”

It may be a small point, but Lisa and Janet’s keynote put words to an opinion I’d had floating in my head for a long time. I’m a firm believer that testers shouldn’t have to be able to code, but I’d never found a good way of saying “but they should have an idea of how stuff works to question it, explore it and help to design it”. Janet said “technical awareness” and a light went on in my head. Thanks! :)

The World of Warcraft talk

Ok, so it’s kind of obvious to enjoy your own talk, but I was just generally pleased with the good feedback it got. Talking about fun topics is always going to be particularly nice, but I’m glad that the messages to take away came across well. I’m looking forward to hearing people’s approaches to simplifying and improving teamwork based on interpretations and experience from other areas.

New analogies

Talking to Paul Gerrard one lunch break, we got onto the subject of code coverage. He said that code coverage is like having a passport filled with stamps from countries. You may think that means that the person has travelled the globe and seen a great deal, but it could just mean that the person has stayed overnight in the nearest hotel to the airport (I’m probably paraphrasing a little). An excellent example.

The other great analogy I heard was from Gitte on exploratory testing: Scripted testing is like commuting. You go the same way each day. Exploratory testing is like being a tourist with a weak bladder – you make frequent stops and change your route depending on what attractions you learn are nearby.

Lean Coffee

At the awards dinner, I was sat on a table with Matt Heusser, who mentioned the Lean Coffee meetup early the next morning. I was a little sceptical about getting up so early, but I’m so very glad that I did. Choosing topics with the group, ordering them based on votes, and speaking about them in 8-minute chunks with the option to extend was a great way to spend an hour. I also got some excellent input by listening to ideas, offering ideas and getting a feel for what other people think.

The Testlab

I had a very productive and interesting 45-minute session playing the coin game with James, Baart and a co-player whose name I didn’t catch. Aside from being very pleased that we solved it, just the activity of sitting down and doing it was very worthwhile. The Testlab is a friendly place, so you don’t have to worry about your hypotheses being laughed at – you can just go and test and learn. Much fun.

The people

This year, I got to catch up with people I already know and meet a whole bunch of new people. The conversations around a cuppa, food, or at the dinners are yet another way to learn more and share more. Sharing experiences with other attendees helps to confirm practices, shed light on blind spots and give food for thought on new areas.

So in summary, a great conference again. I can’t wait to catch up with people after another year to see what we’ve all learned in the meantime.

• testing
• events
• test

Alex’s round-up

For me, Eclipse Con is about learning about what’s going on in the community by chatting to people and by listening to a wide variety of talks. In terms of talks, I think I had four favourites this year (listed in order of appearance).

1. “Desktop applications on tablet devices”, by Christian and Miriam from compeople. I’m completely interested in usability and ergonomics, and they had some good examples of what to think about when designing software for different platforms.
2. Wayne’s talk on the new project management infrastructure – I’m really excited about the things happening in this area.
3. Sarah’s talk on continuous integration – this was really well presented, and it is always brilliant to hear other people talking from their own experience about things we are also say are so important.
4. The keynote on “welcome to the new web” by Chris Heilmann. This was just a great keynote, with the right pace and amount of information, as well as enough to make me laugh at the right points (that picture of the hamster stuck in its tube? Hilarious).

Another highlight for me this year was talking to people at the booth and at the Jubula BOF – we’re hearing more and more about people using it, and are starting to hear more about people wanting to contribute. Getting direct feedback is really useful, and we’re excited about some of the contributions coming in that we heard about during the week.

To balance out all of the great conversations about technology, testing and our work, the Eclipse Con team once again did a fantastic job of making sure that we could all let off some steam. This was the first year I’d been in the main hall for the band (I found out later that they’d cleverly decided to put the beer stand *inside* the hall this year), and the music and atmosphere were brilliant. There may even have been dancing and singing…

Zeb's impressions

The overarching themes for me at ECE this year were:

• e4
• EMF / GEF / GMF
• Dynamic OSGi

This was my first real sip of the e4 Kool-Aid, and I must say: It tastes pretty darn good. The e4 tutorial by Jonas Helming, Marcel Bruch, and Lars Vogel was an excellent introduction, and I was also very happy with the other two e4 talks that I was able to attend: Lars Vogel’s “Extending the Eclipse 4 application model” and Sopot Cela’s “Harvesting the power of Eclipse 4 Context Functions”. I’m excited to see how I can apply these concepts in practice.

I was glad to see that GEF continues to be a hot topic. Alexander Nyssen’s talk about GEF4 (“GEF4 – Share and Enjoy…”) provided a good overview of the future of GEF. It looks like there’s a *lot* of work to be done, so I’m curious to see how that progresses.

My favorite OSGi talk was easily Simon Maple’s “Embedding the Enterprise”, which contained a number of interesting demos including OSGi web servers running on a Raspberry Pi and an Android phone. If I had any doubts about the feasibility of OGSi in memory- and CPU-constrained devices, they’re gone now.

I also decided at the last minute to attend Holger Staudacher’s “Effective Mockito in a modular world”, and was not disappointed. It seems like every time Holger presents something, I pick up a new tidbit in addition to the topic material. This time around, it was Debug Step Filtering in Eclipse JDT. This nifty little feature lets you skip statements that match a set of defined filters. This lets you easily skip over framework code when debugging. Slick! Oh yeah, and Mockito looks pretty cool, too.

And, most important of all, I got the chance to talk with several folks who are using or evaluating Jubula. It’s such a rewarding experience to meet these people face-to-face, get feedback and suggestions. I even got to show off Jubula’s integration with JDT and PDE Launch Configurations at the Jubula Users BOF. Hopefully, those who saw it will now spread the word; I think plenty of people would find this feature useful, but simply do not know that it exists.

Oh, and the band and circus were a blast, too.

• Jubula
• events
• Eclipse Con Europe
• Eclipse

Test driven toolkit development

Over the past few months, we’ve been working on new implementations that make the modules we offer for other toolkits work on .NET applications as well. One of the particularly lovely aspects of the work on .NET is that we’ve been able to test-drive a great deal of it. Our remote control (RC) components are subject to rigorous testing every night. We perform all our supported actions cross-platform on small example applications to make sure everything still works. Because of our hierarchical structure, the basis tests for actions valid on all toolkits can be reused quickly and easily to test new applications. And so one of the first things we started doing for .NET was to write a test application. Since then, we’ve been implementing to make the tests green.

Supported systems

We’re excited about letting our work out into the wild and getting your feedback on what’s still missing. We’ve been testing our support on WinForms, and have also run some tests on WPF. Letting us know which flavor of .NET you use would certainly help us to concentrate our efforts from here on in!

Downloading and trying out

The support for .NET is available in GUIdancer – trial licenses are available from the GUIdancer shop on the BREDEX website. The documentation contains useful information for getting started and writing tests – so have a read and get started!

• Jubula
• GUIdancer
• Eclipse
• test

New Services Section

In the navigation bar at the top, you'll now see that we have three main points under our "Services" menu: Development, Consulting and Quality Assurance. Under these three headings, we've provided an overview of the areas we work in as well as what unique benefits we can provide to our customers in terms of quality and process.

Project examples

One of the most fun parts to work on in the new section was the project examples. It's great to give projects the opportunity to present themselves, and to showcase some of the exciting work we're doing with our customers. The overview table is designed to let you see the big picture of our work, and most of the projects listed already have a description with specific highlights to read. Instead of a dry list of technologies and processes we work with, have a read through some of our real examples to see what we could do for you.

On behalf of the whole team that's worked on the new section, we hope that you enjoy reading. If you have any questions about our services, then get in touch with us at

• services
• quality assurance
• projects
• development
• consulting

Testing of Eclipse RCP based Products

Our first speaker was Manuel Bork from Yatta Solutions. His talk on testing Eclipse RCP products highlighted the challenges involved with multiple versions (old versions and bleeding edge), and various configurations (OS and plugin combinations for example) and presented the solutions that Yatta have implemented to make their quality better and reduce their manual testing effort. His comparison of Eclipse with a candy store with so much to choose from is well fitting, and their strategies to perform configuration testing, migration testing and functional testing were well explained. Also, from the Jubula perspective, it’s great that they are using Jubula and extending it

Cutting the right corners

Second on the list was my talk about cutting the right corners. Since the talk was about being pragmatic when faced with challenges in projects, I was really pleased to find that many of the other talks and discussions throughout the day also had a good dose of pragmatism to them. I also stick to what I said during the talk – if I ruled the world, continuous integration would be in place at the start of every new project!

Design by contract

After the break, we moved onto a more developer perspective on testing by looking at contracts in the C4J framework as an Eclipse plugin. As a non-developer, I was happy that the demo was easy to follow, and found the approach interesting. The idea of specifying generic pre- and post-conditions for methods and classes is something that harmonized well with my experience in UI testing, where checking that pre- and post-conditions are fulfilled (GUI state, database state …) is also hugely important.

Iterative model-based generation of Test Cases

Just before lunch, we had our first talk on modeling. It was refreshing to find a modeling talk that didn’t assume that everyone always wants to model – much focus was put on the ability to work with Test Cases or with the model. Using models to gain an overview of complex tests was another interesting point that Raimar and Johannes introduced.

Delta-Model based testing

After lunch, we continued in the modeling vein with the second and final modeling talk. This talk involved a lot more theory and dealt with the difficulty of testing multiple variants or product lines. In order to remove redundancy and make testing possible, only the differences between variants are tested – and the necessary test cases to execute can be generated based on models of the whole product line. Even faced with so many different test objects, we have to remain pragmatic – and find the minimum amount of test cases that will give us the information we need.

Testing for Tool Qualification

The theme for the third Testing Day was “Testing and Beyond”, so our final talks were planned to be not just about testing, but about testing as a part of the bigger picture. Oscar Slotosch was our first speaker, and talked about the work the Eclipse Foundation is doing with Validas to work on Tool Qualification so that companies working in safety critical areas can use the Eclipse tool chain. This was a totally new area for me, and I found the talk interesting and relevant – especially the statement that although Tool Qualification is important, we should find way to reduce or avoid it!

Mind meld with Mylyn

The final talk was an excellent way to zoom right out of our testing corner and look at testing as a part of the whole application lifecycle process. Benny demonstrated how Mylyn can be used to link the tools used by testers, developers and managers so that everyone can talk about the “fluffy clouds of relevance” associated with a project, and make developing, testing, deployment and production more successful.

Panel discussion

The newest part of the testing day program this year was the panel discussion. The topic chosen proved to be sufficiently tricky to get people thinking, and varied enough that the discussion seemed to fly by. There were some excellent points made about the value of community and user feedback to teams, how this can be used, how it can be encouraged, and how it is becoming more relevant as a part of a test strategy now that there are so many different versions of web browsers and mobile hardware and software on the market.

Beer!

After the panel discussion, we had some time to carry on our conversations over a beer and to chat to attendees, speakers and sponsors. Many of the thank-yous were said on the day, but it is definitely worth thanking our sponsors for their support, our speakers for their input, and the attendees for their presence! Over the next few days, we’ll be putting slides (and possibly videos thanks to Linus and Josha!) online, so keep an eye on the Eclipse Wiki page.

• testing
• events
• Eclipse Testing Day
• Eclipse
• test

Panel discussion

The aim of the panel discussion is to give the audience the chance to learn from the experts by asking questions about quality assurance, testing and deployment. Our three panel members are:

• Michaela Greiler from the TU Delft (the author of the Eclipse Testing Study)
• Dr. Frank Simon from SQS AG
• Jana Knopp from Xing

To get the discussion going, the program committee have decided on a few questions to ask at the beginning. The idea is, though, that we move to audience questions as quickly as possible so that everyone can learn as much as they can.

Our list of questions is posted on the Eclipse Wiki - use it to give you ideas about what you want to ask. There's a chance to enter a question during registration for the day, and, of course, you can ask during the discussion itself.

Signing up

The day is aimed at anyone who is a tester for Eclipse applications, a developer of Eclipse technology, or a project leader in a company using Eclipse.

You can register to attend the Eclipse Testing Day 2012 via Eventbrite. There, you'll also find the complete agenda and links to the biographies of all our speakers.

We look forward to seeing you on the 5th September!

• testing
• Eclipse Testing Day
• events
• Eclipse
• test

When and where

On 5th September 2012, we will be hosting the third day event dedicated to testing and Eclipse in Darmstadt. Doors will open at 8am for registration, and the day starts with a welcome talk at 8.45.

Talks

We've got 5 full-length talks on topics in testing and Eclipse:

• Testing of Eclipse RCP based products
• Finding the balance between effort and payoff for GUI test automation
• Java development contracts in Eclipse
• Iterative model based generation of Test Cases for Graphical User Interfaces
• Delta-oriented model-based software product line testing

We also have lightning talks planned - the first talk is on the topic of "Testing for Tool Qualification in Eclipse", and a second one is in the pipeline

Panel discussion and evening reception

Finally, to round off the day, we're going to have a panel discussion where participants can ask questions and have discussions with experts in testing, delivery and Eclipse. We have three great panel members confirmed - Micheala Greiler (who performed the Eclipse Testing study), Dr. Frank Simon from SQS AG and Jana Hoffmann from Xing. You'll have the chance to ask them questions on the day, and you can also send your questions in during the registration process.

Following the panel, we have an evening reception so that the discussions can continue over a beer.

The full agenda, including the details and topics for the panel discussion, can be seen on the Eclipse Testing Day wiki page.

Registration

As in previous years, the Eclipse Testing Day is a not-for-profit event. Ticket prices are to cover catering costs and room rental. Due to the excellent support of our sponsors, we've been able to reduce the ticket prices somewhat this year:

Eclipse member companies pay 30€ per ticket Non-member companies pay 45€ per ticket We also have limited student tickets, at 25€ each.

The registration is now open via Eventbrite. Credit card payments are accepted, and there is also the option to send a purchase order if you'd prefer to pay via invoice.

Sponsors

As a not-for-profit event, we rely on our sponsors to make the day possible. We are pleased to be working with excellent companies and magazines as our sponsors: The Eclipse Foundation, GFB IT Consulting and Services GmbH, Díaz & Hilterscheid, verit Informationssysteme GmbH, froglogic, EclipseSource, Professional Tester magazine and Testing Experience magazine.

All other details about the Eclipse Testing Day can be found on the Eclipse Testing Day wiki page and on the Eventbrite page. Sign up now to secure your ticket!

• testing
• events
• Eclipse Testing Day
• Eclipse
• test

New problems replace old ones

Sometimes it can seem frustrating if each retrospective brings new problems and issues to the table - but it's important to distinguish between a disordered process and actual improvement. We had a great example of the latter in one of our our latest retrospectives.

Test early

Over the years, we've been making gradual improvements to our process to ensure that our testing is as early as it can be. In some of our scenarios, this means we require small external applications that are used as a part of the automated test to check whether everything (still) works. In the past, we had the problem that these applications only started getting written when a great deal was already implemented - so we were losing out on valuable and timely feedback.

In this recent retrospective, one of the cards we wrote was "automated tests were blocked by missing feature". We identified that we'd forgotten to plan something that is a prerequisite for running the automated tests with these small test applications. While it's a shame we forgot to plan it, it was nice to make the realisation that this problem could only happen because the test applications were available from the outset. We have, in fact, achieved our goal of testing earlier in this context - even with the block in the last sprint, we are much earlier than we have been previously.

Gradual and iterative improvement

So not every new problem means that things are generally going wrong. Some problems are acutally a sign of progress. And that's why frequent retrospectives are great - you can chip away at the problems you're experiencing and improve the process bit by bit.

• testing
• Test automation
• agile process
• team

The agenda started this year with our Jubula demo on application hopping. After doing the demo camp circuit last year with introductions and basics to Jubula, it was nice to do a more complex demo to show off some of the capabilities for cross-application, cross-toolkit testing. Straight up after our demo, Marcel Bruch showed us what’s in and what is or could be coming for Code Recommenders. No matter how often I see the demo of recommenders, I never fail to be amazed – and I think the same was true for many of the participants, seeing it for the first time. Before we had a break, Kai Tödter gave his demonstration of work he has been doing on e4 and renderers. Switching styles on button press Is definitely cool – though I think my favourite style was the napkin to give prototypes that “not-yet-production-ready” look.

After the break, we continued with the e4 theme with a talk from Heiko Barth on Riena. His talk was excellent to get a view of one of the “other sides” of Eclipse – writing business applications. His points and talk dovetailed well into Kai’s demo before the break, so maybe there is the chance of some collaboration to get the work both teams are doing into Kepler.

To finish off the demo camp, we had two demos on modeling. First up was Ed Merks with a demo of the new tooling for Ecore, based on XText. A lot of people seemed to be nodding appreciatively, so I think that the new tooling is pressing the right buttons. Finally, we had two speakers from the TU Clausthal, Martin Vogel and Marc Janssen, demonstrating their work on TeamMode for merging models.

Six interesting and well-timed demos later, we were ready to head off to Braunschweig centre to watch the football. Our timeliness with the demos did nothing to help Germany win the game, but we nevertheless managed to spend a nice evening in Braunschweig with some participants and speakers.

All in all, a very successful demo camp – so a big thank you to all speakers and attendees who made it an evening to remember!

• events
• Eclipse Demo Camp
• Eclipse

Pretty much straight after the first release of Jubula for Indigo, the team started looking at the integration for Juno. It’s not always been an easy ride – much has changed in the new platform – but the clever guys on the Jubula team and the lovely people on the platform project have moved mountains to get everything in place. I won’t say that there aren’t a couple of compatibility problems still lurking around, but all in all we’re generally happy.

Of course, we haven’t just been working on integration, there are features a-plenty as well in the new release. If you’ve been working with the Jubula or GUIdancer standalone versions since March, then you’ll know them already, but for the sake of any newbies, here’s a really quick overview:

• We now support functions as test data. Use ours or add your own (as outlined in this blog entry, for example).
• The test result view got cooler. Now you can see which data each test case used, and how long it took without having to click through the whole tree.
• We got about as close to copy-paste as we’re ever likely to: you can save your lovely reusable modules from one Test Case into a new one using the new “Save As new Test Case” feature.
•  No more forgetting data! The editors now show you if you’ve forgotten to enter data in the properties view.
• You can now go nuts with categories. They are now available in the Test Suite Browser and Central Test Data Editor, as well as in the Test Case Browser and Object Mapping Editor.

The full list (including pretty pictures) is on the new and noteworthy page.

While the Juno release has been keeping us nice and occupied, we’ve also been spending time on the standalone versions for Jubula and GUIdancer. They will be released in versions 6.0.1 and 1.2.1 at the beginning of next week. Now normally, this summer release would just be some bug fixes. Well, they are in there as well, but we’ve also got an exciting new integration with the Chronon recorder. You can configure your test to record debug information while it is running, and then open the recorded file in the Chronon Time Travelling Debugger to see what was going on at any time during the test. Pretty cool. We’ve also put support into Jubula and GUIdancer themselves for the recorder, just in case you find a bug and want to help us reproduce it.

Three months since the last release, three new software versions. It should be time for a break, but we’re already well underway with new features for a release in October….

• Release Train
• Juno
• Jubula
• GUIdancer
• Eclipse
• test

To some degree, this makes a lot of sense. As Scott Barber predicted in his keynote, testing time and resources are only likely to shrink as release cycles get shorter. We need to make sure we are keeping up with new technologies and we need to get smarter as the tools and technologies we are using develop further. But Scott’s keynote was also about asking the question of “is it cool, or does it bring value?” Everything automated all the time (including the test analysis) definitely rates high on the coolness scale. But I wonder whether it would really bring us the value we need. I wonder whether our projects and software would suffer for removing as much human interaction as possible. I’m a great fan of automation, but I still think that eyes and emotions are sometimes better than a robot.

And I think that those eyes and emotions should come from a specific mind-set. Working on an agile team, I know the benefits of the whole team approach, and of having testing activities going on constantly. But I’m not sure whether I’d want to completely mix the developer and tester roles. Sure, there are people who can do both very well. But it’s also important to have people who do one or the other and can bring that important mind-set to the team. I agree that testers need to have technical understanding (in the same way that developers need to be test-aware), but we do have to be careful that we don’t lose their very unique individual perspectives.

In this kind of context, it was really great to be able to give a Jubula demonstration, because we place a lot of focus on enabling people with the test perspective to automate tests, so we keep the transparency for testers and customers but don’t lose out on the benefits of good design that we know from software development.

And as for Skynet, well, I did ask how they got the team to agree to building in monitoring capabilities for the whole software – my experience often sadly shows that development activities to help testing aren’t gladly done. The answer was “government funding” so I guess we’re safe from the killer tester robots for now…

• Test Automation Day
• Test automation
• Software testing
• automated tests

Disclaimer: This blog is written for people who already know Jubula and GUIdancer quite well and are interested in extending it. It’s a bit more complex than writing tests, so you will need some prerequisite knowledge of extension points in Eclipse :)

One of the things missing in Jubula 1.2 and GUIdancer 6.0 is a possibility to work with equivalence partitioning to avoid redundant data. Yes, there is the feature of Central Data Sets, but then you have to use them all in one loop, which isn’t always desirable. You cannot just use single entries or cells. But since the release of Jubula 1.2 and GUIdancer 6.0, it is now possible to use functions as test data. Even better, you can add your own functions as you need them. As it turns out functions are just what we need to solve this problem :)

So here is my example of how to solve this particular problem using a newly added function.

Example

First of all we need a nice example. Let’s say we have an online book store, and we have three simple uses cases we want to test.

User Stories

User Story 1 (US_1): A customer wants to register

A customer can register if he hasn´t registered yet. He has to give a lot of information about himself. For registration we need a name, surname, street, number, city country, email address and phone number.

User Story 2 (US_2): A customer wants to order a book

The customer has to fill in his login data and the book information and then he can order the book. For the order process we need the email address, book title, author and price. The customer should also confirm that his delivery data are still correct. If the combination of customer and book data is forbidden, the order process is interrupted with an error message. These are the rules for customer / book combination for this user story:

• Unregistered customers may not order a book
• Limited editions can just be ordered by premium members
• Premium members may not order cheap versions of a book (this is an excellent business model, and I’m planning on patenting it!)

Any other combination is possible. Because the workflow of the user story can be different we put the part with the error message in another user story:

User Story 3 (US_3): A customer fails to order a book

Equivalence Partitioning and Data Objects

Here we want to set the equivalence partitioning for our data. This should help us to get all relevant parameter combinations for our test cases.

Let’s start with the customer:

For the book:

Using the principle of data cohesion we could extract 3 data objects from this information:

• Customer

• Address

• Book

We will use these data objects later in our example. To identify each equivalence class we use a unique human-readable key that explains the necessity of this class (entered in the first column of each table).

Test Cases

When connecting user stories and equivalence partitioning we get the following test relevant test runs for our use cases:

• User Story 1 (US_1): A customer wants to register

• User Story 2 (US_2): A customer wants to order a book

• User Story 3 (US_3): A customer fails to order a book

Using Jubula or GUIdancer without any extensions to the functions, then we would need to write test cases using the following signature:

Ouch! This is quite long. When we add the necessary concrete data for US_2, it is also quite long:

That’s a lot of information to sort through, isn´t it? This method has some disadvantages:

1. Highly redundant data: You have to use the same data over and over again. If you extend the signature you need to copy the same information where possible. If the data should change, you need to do it everywhere you use it. Changes in big projects can be very expensive if you work this way.
2. Tests that are hard to read: It’s not easy to decide which kind of data will be used in a test. Is this premium member or just a simple customer? Is this book the cheap, expensive or premium version? Which data belongs together and which doesn’t? As requirements changes over the time it´s impossible to decide if you have tested all relevant equivalence classes.
3. Signature instability: Requirements change during the development of an application. In our signature we use primitive, atomic data. Every parameter should be used in a single test step. This way every change ends in changing all signatures of the test tree.

The simple idea is to use data cohesion. What belongs together should be encapsulated into one data object. Using our data objects from above, the signature and test cases look like this:

The parameters are now just a reference to your data. This way you do not need to copy the data itself. It’s better to read, to understand and to maintain. Problem is: The current Jubula and GUIdancer versions have no mechanism to support this. But now we can write a function to add this capability ourselves.

Functions

Using the function

In our use case the relevant data are stored in a central test data set.

We have three tables CUSTOMER, ADDRESS and BOOK. Every table has a unique and human readable (!) key to identify the row (for Jubula/GUIdancer) and understand what kind of equivalence class hides behind the data (for you and everyone else who should understand what happens in the tests).

When we want to use specific data (for example the name of a customer), we need the possibility to get the value from a specific table (CUSTOMER), from a specific column (NAME) for a specific row with the given key (this is the CUSTOMER_KEY in the parameters). The signature for the function is

?getDatasetValue (DATASETNAME, ENTRYKEY, COLUMNNAME)

When you are working with concrete values the function call looks like this:

In the given example we want to get the value of the column ‘Name’ of data set ‘Customer’ with entry key ‘Premium’. The value is ‘Diegobirth’.

I think normally you will use the ENTRYKEY as a parameter, so the call should look like this:

Ok, now we know how to use this function, but how should we write one?

Writing functions

The easiest way to extend Jubula/GUIdancer is using your Jubula version as a target platform in Eclipse. Afterwards you can add your own plugin project with a dependency to org.eclipse.jubula.client.core and write an extension for the extension point org.eclipse.jubula.client.core.functions.

The name of your function corresponds to its name in Jubula without the question mark. The necessary parameters have to be defined in the plugin.xml as well. You have to implement the interface IFunctionEvaluator. The method evaluate (String [] args) will return the result of your function. That’s it! Well, nearly. You do have to write the function itself, but that’s not very difficult, as you can see in the example here (Source and executable plugin). Feel free to download this patch, take a look at the code and add the project to your Jubula plugins folder, restart and begin. I think the Jubula/GUIdancer team will add this function to the trunk in the next release. Have fun!

http://www.bredex.de/web/index.php/guidancer_jubula_en.html

http://www.eclipse.org/jubula/

http://en.wikipedia.org/wiki/Equivalence_partitioning

http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

• Test automation
• Software testing
• Jubula
• GUIdancer
• Equivalence Partitioning
• Eclipse
• Data Cohesion
• automated tests
• test

Why name at all?

As in so many cases, the reasons for naming are simultaneously good for your users and good for your testing. If a dialog doesn't have a name, then how can you refer to it in the documentation? How can your users tell you if they like it or not, or if there is a problem with it? Also, if dialogs don't have names, then it makes it much harder to dynamically synchronize tests.

Dynamic synchronization

In GUIdancer and Jubula, there are actions such as "Wait for Window" and "Wait for Window to Close". These let you define the title of the dialog or window you want to wait for, as well as a timeout. The timeout means the maximum amount of time the tool should wait for. If the window is there (or no longer there) quicker than the timeout, the test continues immediately. Fairly clever.

But if the window doesn't have a title, then you will find yourself having to use one of a few workarounds:

• Waiting for a component within the window (which is sometimes not a problem, but in many default dialogs, the components they contain are very similar (an image and a label with two buttons at the bottom). Without names, one dialog can look pretty much like another in terms of our object mapping heuristic ( - which is specifically designed to recognize things that are similar but not the same...). This could mean you start confirming the wrong windows, or clicking away errors.
• Adding a static wait. Sure, it might not kill you in this one place, but small static waits in frequently used modules really do add up. We recently did a clean up in one project, and by removing small waits from our central modules, we were able to remove about 30 minutes of unnecessary static waits in a 4 hour test. It all adds up!
• When it comes to waiting for the window to close, you may find yourself in the situation that you're having to build modules that check whether a component is no longer there, and if it is, then waiting and retrying. Now, the retry possibility is one of my favourite things, but this is a bit of a stretch in terms of its original aim!

Naming well

Some workflows involve a lot of dialogs (some of which may be optional). For example, you want to export something to a place where a file may already exist. In this case you'll have the file chooser dialog then the overwrite dialog and then a confirmation dialog like this:

• Select export from menu
• Wait for file chooser (Export)
• Fill in export details
• Deal with optional overwrite dialog (Export)
• Wait for confirmation dialog (Export) and close it

Now, if all the dialogs have the same name ("Export" for example), then you may find your synchronization difficult, especially when dealing with the optional appearance of the overwrite dialog. To do this, you'll need one of the nice retry modules:

• Check that Export dialog doesn't exist
  • And if it does, click OK
  • Then retry the check, expecting that Export no longer exists

The problem should be obvious - after closing the Export dialog, you get another dialog with exactly the same name, which means that the test will fail.

Not only does having each dialog being named the same confuse the user (we had a case once where just the similarity of the "Open" and "Delete" dialogs lead to a project being deleted instead of opened - and they had different names and were opened using different menus!), but it's also more difficult to test in a dynamic way.

So show your love for your users and your testers, and give those dialogs meaningful titles

• Test design
• Test automation
• Jubula
• GUIdancer
• Eclipse
• test

I won't say who I most recently heard this quote from, but let's just say that we've decided to give you an extra week to enter your talks for the Eclipse Testing Day. We've already received some excellent submissions, but due to popular demand, we're extending the deadline until Friday 8th June.

That means that you still have some time to put the finishing touches to your abstract (or even to start it and get it finished!). Further details for submissions are on the Testing Day wiki.

Speaking of the wiki, we've just updated the details for the panel discussion that we will be having. We have three excellent perspectives on testing who are going to answer questions from a moderator and the audience on "asymmetric testing". Don't know what that is? Check out the wiki for more information ;)

The testing day has proven itself to be an excellent event over the past two years - put it in your diary, submit a talk, and register to participate when registration opens in a few weeks!

• events
• Eclipse Testing Day
• Eclipse

Two days of Eclipse

Day one, Demo Camp

At 5pm on the 28th June, BREDEX is organizing a demo camp in Braunschweig. Confirmed presenters include Kai Tödter, Ed Merks and Marcel Bruch - and we're working on a couple more  BREDEX will also be doing a demonstration of Jubula. Registration is now open via the Eventbrite site - so sign up for a great evening!

Day two, Eclipse 4.2 Training

The following day (29th June), Kai Tödter is holding a one-day training course on Rich Client Development with Eclipse 4.2. This is an excellent opportunity to get up to speed on the latest developments in Eclipse without having to travel to far-off conferences or workshops. A full description of the training day is on the BREDEX website, including a link to the registration. Places are limited, so register early.

• training
• events
• Eclipse Demo Camp
• Eclipse

Eclipse Demo Camp Braunschweig

On 28th June, there will be a Demo Camp in Braunschweig starting at 5pm. The Eclipse Wiki page gives more information on the event, including a link to the registration page and the opportunity to sign up as a presenter. There are still some spaces left, so come and show us what you're doing with Eclipse!

Eclipse Testing Day

The third Eclipse Testing Day will be held on the 5th September 2012 in Darmstadt. The call for papers has started; please send your submissions by the 31st May 2012.

We're also pleased to announce our current sponsors: GFB Softwareentwicklungsgesellschaft mbH, Diaz & Hilterscheid GmbH, and Verit Informationssysteme GmbH. We are also collaborating with Professional Tester Magazine and Testing Experience Magazine. There are still sponsoring positions available, and of course we're looking forward to hearing about the Eclipse community's experiences and adventures in testing as well as meeting testers, developers and project managers on the day.

• events
• Eclipse Testing Day
• Eclipse Demo Camp
• Eclipse

What we're looking for

The topic for this year's testing day is "Testing and Beyond". The program committee are putting together a format that will consist of traditional talks on the topics below, as well as a set of lightning talks from areas "beyond" testing and a panel discussion with experts from the Eclipse and testing communities. 

The topics for talks could be:

1. Testing Eclipse applications
2. Testing within the Eclipse Ecosystem
3. Testing on Eclipse Projects
4. Design for testability in Eclipse
5. Case studies of testing projects
6. Eclipse tooling and technology for the test process
7. Continuous integration and testing for Eclipse applications

As in the past years, demonstrations and case studies are very much welcome but product demonstrations will not be accepted. Submit your abstract (in English, 100-200 words) and your biography to testingday at bredex dot de by 31st May 2012. More information on talk submissions and length is on the wiki.

Be a sponsor!

The Eclipse Testing Day is a not-for-profit event. Costs are primarily covered by the organisors and our sponsors. We have a range of sponsoring opportunities available - sign up to support this great event and meet Eclipse users and testers on the day.

Come to the event

The registration will open shortly after announcing the program. If you would like to be notified when registraion opens, then send an email to testingday at bredex dot de.

We look forward to an exciting event!

• events
• Eclipse Testing Day
• Eclipse