Why Freesat Works
Post categories: Freesat,ÌýMHEG,ÌýTesting,ÌýUnder the bonnet
| 17:47 UK time, Monday, 22 September 2008
Let's say you've just made a change to some software you're developing that you expect an audience of thousands to use daily to check news headlines, sports results, the weather or the state of the markets. Let's say it runs on a digibox. How long would it take to press the keys the remote control 10,000 times and check that what you expected to happen, happens? When it comes to the shiny new Freesat platform, it takes us less than 20 minutes. Here's how.
Last August we were handed the brief to provide a digital text service for , the joint venture between and the 91Èȱ¬ to offer an alternative packaging of the free-to-air digital channels broadcast by satellite, due to launch in Spring 2008. The product manager, Andrew Bowden discusses the challenges on the 91Èȱ¬ Internet Blog.
We were repurposing the channels currently available to view via (or ). We already provide a complete 91Èȱ¬i red button service on the Sky platform. But that service is written using software licensed to Sky's platform (called ), which Freesat chose not to licence, so we couldn't just run that 91Èȱ¬i service on Freesat. Instead, Freesat uses an updated version of the software that runs the red button services on . It's free, it's called and it's an open standard.
We didn't have much time. But we knew that we had an opportunity to refresh the service. We took the Freeview service and asked how important each section is to our viewers? How could we improve the look and feel, the navigation? How many sections are there? How many pages in each? How is the information fed through to screen - how many feeds are there? How many back end systems will we need to update/port/repurpose? Once we had that we did some estimates to see how long it would take to build. Then we took the prospective launch date and worked out what the minimum we could deliver on launch day would be and what we could add in subsequent updates.
We concluded that News, Sport, Business and Entertainment would come first and deliver almost 800 pages of content. Then we could follow up with 300 pages of Weather shortly after launch. We scoped work on updating the content systems that supply the Sky, and Freeview platforms and had confidence we could generate the content. But there weren't any Freesat set-top boxes when we started. We couldn't build a digital text service blind. Well, we could but it would involve something akin to staring at .
Luckily for us, 91Èȱ¬ Research had been working out the grand plans for Freesat over several years. They developed extensions to the MHEG specification, worked with manufacturers to define hardware requirements and provided us a "concept receiver" that we could use to start building a service on. Essentially this was a PC with a decoder and a custom software stack built to emulate how Freesat was specified to work.
Then we had to build the software. For those that are interested, the systems that were built to drive the Freeview back end were largely based on the programming language. We now use . We used for several years: we have since switched to . There was no automated build so we couldn't track and enforce stability or run automated tests on any changes we made whereas new projects are plugged into . Projects are being planned to bring Freeview in line, but we didn't have time to wait for them to complete. So, based on newer services and much learning undertaken in recent years we went for Java, the , using SVN as our repository, using and CruiseControl to automate builds and used methods (, , ) to manage the development process.
How do we build a service? Essentially we receive XML feeds from our colleagues in the Journalism department that are content based and described generically, e.g.
<Story>
<Page>
<PageTitle>Zombie plague sweeps the internet</PageTitle>
<Body>The summer saw a surge in the number of hijacked home PCs or "zombies", say security experts.</Body>
</Page>
</Story>
Fed through a custom and out to our platform plugin, we add the look and feel for the platform and generate and build a data stream ("carousel") to be broadcast alongside the video and audio that make up digital television channels.
Our broadcast application is designed to be content driven, so the backend just updates the carousel (essentially a static file system) and the application picks up the changes and updates the pages you see on screen. We couldn't take the Freeview application and re-broadcast it exactly because Freesat has a different specification, which also includes lots of goodies that Freeview is missing.
Briefly, the new stuff includes an extended graphics model, a greater number of colours, true colour backgrounds, the ability to use without visibly changing your channel, use of an internet connection (including ), the ability to get data from broadcast, the internet or local storage or have your box remember settings even if you turn it off, support for downloadable and smooth fonts, support for and lots of digital video recorder extensions to allow MHEG applications to exploit content stored locally (such as programmes you've recorded or downloaded). From our point of view this allows us great scope for future services, especially internet enabled ones.
Lot's of fun toys, but not much time! Luckily we have undertaken a lot of work internally to build new tools to allow for easier coding of the MHEG language. We call the new toolset "MHEGPlus". Anyone who was at might have seen it, and hopefully, after some licence issues are sorted out you should see it available for anyone to use. Watch this blog for updates and an in depth explanation of what the kit can do. Quickly though, it offers an interactive debugger including a visulisation layer (essentially a virtual set-top box, run on a computer server), integration into the Eclipse software development environment (including syntax highlighting), extended and simplified language syntax (think over ) and compatibility.
And it's FitNesse that provides us the most interesting piece of this puzzle. For the uninitiated, FitNesse is a software development collaboration tool, built around acceptance testing via a . Essentially, it allows software acceptance tests to be written in pseudo English, in a kind of way. We set up our FitNesse wikis to model interaction with our user interface. So a tester can describe user journeys in the wiki and the FitNesse backend provides a translation (a "fixture") that takes the wiki syntax, wraps it up as code and (effectively) calls our MHEG set-top box emulator. In reality it's a bit more complex than that underneath - our MHEGPlus toolset includes "MHEGUnit", a full unit testing JUnit style wrapper which the FitNesse fixtures interface with - but the result is that we have an almost natural language interface to testing user journeys.
e.g. The following wiki "code" navigates from the 91Èȱ¬ page ("bridge_default") to a News menu (menu_max9) and then uses the Yellow key to navigate back the way we came.
|check|scene is|tv|
|press|red|
|check|scene is|bridge_default|
|confirm text box visible containing|News Headlines|
|press|select|
|check|scene is|menu_max9|
|confirm text box visible containing|World|
|confirm no text box visible containing|News Headlines|
|press|yellow|
|check|scene is|bridge_default|
|confirm text box visible containing|News Headlines|
|confirm no text box visible containing|World|
Given we have a known input device and known language semantics, we can automate the generation of our automated acceptance tests. One of our System Testers built a virtual remote control so he could generate the wiki test scripts using a mouse and keyboard and then just copy and paste into the FitNesse pages. We also added the ability for the MHEGPlayer debugging tool to read and execute the scripts against code. So, if we find a bug using the automated tests then we can run the same test exactly against the code and debug it. Up next is integrating the generation into the concept receivers or adding some IR layers so we can just capture remote control key presses and bugs found in manual or exploratory testing can be recreated exactly. Anyone who is involved in software development knows that the less "randomness" and more repeatability there can be in bug discovery and reporting the better.
The final step, and my favourite bit, is the fact that we can plug FitNesse into our build system. So, every time the code is changed and checked into SVN the build system picks up the change and builds a new release. It compiles the Java code and runs the unit tests, uses FindBugs, , pmd, and . If the build was successful, it generates installation RPMs ready for deployment to our continuous integration chain - a dedicated replication of the live chain that runs Freesat, including a dedicated internal TV channel that pretends to be 91Èȱ¬ One. The build system also compiles and tests the MHEG code. This is where FitNesse, er, "fits" in. When the MHEG is compiled to (the broadcast data format) we inject it (play it out) to a broadcast carousel that is not connected to the broadcast system (i.e. compiles but doesn't go to air). The FitNesse test suite then connects to this carousel, injects to it a sample service and runs almost 10,000 assertions on the code. That's correct! Thousands of virtual remote control presses and other checks of the resultant data, all written by the test team in advance and added to continuously. The time to build and perform these tests is around 15-30 minutes depending on how much the server is doing at the time. The confidence we have in our user experience is awesome. I know that I can change something such as how the back key remembers where to go and that there is a huge safety net of automated tests that will guarantee the key presses and channels tuned to are all correct.
Currently we have 3 builds running and the little light on my desktop is green, so I know it's all OK. If the light was red it means that the last thing a developer changed broke something in the behaviour of the application. Everyone gets notified by email as well. The tests can be run locally too, so we can develop and check before we commit changes that the tests work. As things come together at the end the cumulative testing can check scenarios that we possibly couldn't check in the development environment. The three builds are our currently live service, which is in the Support phase - more to come in this blog about how we handle support. There's also the new enabled version of our backend due to go live any day now. When interactive TV was first created, Service Orientated Architecture wasn't invented yet. As we evolve we are moving our systems forward, implementing enterprise standard architectures. The My Sport Now team who built the Sport Interactive service for Virgin, Freeview and Sky went to air successfully using JBoss as a tool to manage their application as a web service. We updated our system to follow suit in time to launch the Sport Interactive service for the awesome Beijing Olympics. The other build is Freesat Radio, due to launch in the coming weeks, to give our digital radio stations a pretty face.
I hope you enjoy using the Freesat service and that this post has given a hint to how we try to push forward and refine the development process to support what some might have called impossible. We launched a complete new platform, using new architecture, with new extensions to a complex language; without hardware yet with complete confidence, no critical bugs and a fresh look within eight months. We followed it with a complete weather service a month later, Sport Interactive followed 2 months after that and Radio is on it's way. After that... well, I'll leave it as "to be continued..."
Comments