The most important take-away idea from CITCON Europe this year for me was probably building ‘save game’ functionality as an integral feature in software systems.
Antony Marcano talked about this, not as part of the official programme but over beers which is another example of how informal chatting at conferences is often more valuable than the schedule. He mentioned how it is common for games to automatically save the complete state at checkpoints. This allows us to easily go back to the last saved position and continue playing if our character gets killed for whatever reason. So if something really bad happens after 10 hours of playing, you don’t have to do it all over again.
Functionality similar to that could help immensely with exploratory testing in software. When we find an issue, we could easily go back to the last checkpoint and reproduce it and also use that same saved game later to check if the problem was fixed. This could also be used if a customer encounters a problem in production to make bug reports a lot more complete and reliable.
Implementing this feature is by no means a trivial task and might be nearly impossible to retrofit into existing systems. The reason why gaming companies can do it is that they consider saving as an integral feature of their systems from start. I have yet to try this but my gut feel is that if a system is built with this in mind, the actual overhead of doing it is minimal. Modern games have states as complicated as lots of enterprise systems, with tons of actors, their states and event information at any time. Yet they manage to load it up in a few seconds and continue from the saved state. By designing for that up front, ensuring that all actors can be persisted and loaded and that all state is easily extractable, we should be able to do the same in enterprise software as well.
|
|
I guess enterprise applications are more like peer to peer multiplayer games. It gets fairly more complex to save a state in such games.
This is already possible with some virtualization products. VMware Lab Manager made checkpointing efficient in 2007 if I remember correctly.
I wrote a post about a CI system that used Lab Mgr system about a year ago here.
Hi Gojko,
This is a very interesting and creative idea! I think software testers could benefit a lot when such a feature would be present in the software under test.
One of the most neglected quality attributes in ISO 9126-1 (in my opinion) is testability. This idea would certainly give this quality attribute a boost. Efficiencyy could rise a lot. Have you heard of an example where this has actualy been put into practice? I am very interested in experiences on such an idea.
Not just testing, but in builds too!
Consider a multi platform product. One that spans multiple OS’s. In that context, the ability to restart a build due to failed infrastructure (eg, the AIX, Linix and Windows builds were fine, but the Solaris one was not available) is critical. Do you fail the overall build? No, you simply restart it at the failed step on the platform in question.
The approach is currently in use.
Doesn’t this already exist in the form of source code tagging and database exports? The trick is knowing when or how often to save the game so you can go back to that state when you need to.