I have been involved in a lot of conversion project. More specific it has been converting legacy VB6 applications to .NET applications. I’m not sure why or how but I have found myself in many project like this.
Common scenarios in conversion project
Very often these project has an ideal picture that “it’s just a conversion”. “This is 1 to 1 project” is a very common phrase in many of the projects I have been involved in. That can be understood as: “just convert it in the new language – with the exact same features”. I have even been asked to do bug conversion – that is to also convert any bugs I find into the new language.
Moreover, these project very often lack interest, time and effort from the stakeholders/customers/business people. To non-technical persons conversion is purely technical thing. “Just recompile it – let me know when you’re done”.
And also as most VB6 applications still living today are old application the violation of the DRY principle in code and documentation has been painfully clear. What I mean by that is that the documentation (if present at all) very seldom reflect the actual behavior of the application.
So – as a developer you are asked to do conversion with no requirements except the old application. And the expectations is high. “How can you fail? It’s just a conversion…”
The tester also have a hard time. Since there of course cannot be a one-to-one-conversion (features change in languages, a rewrite change the behavior of the code etc) and there is not requirement, you have to test case by case with only the old application as verification.
ATDD to the rescue?
As readers of this blog know, I have lately snowed in on agile testing (or agile acceptance testing, or specification by example, or BDD). Using this kind of specification by example will give you the most when collaborating on them with your customer, I know. But in many cases, in conversion projects like above that is simple not possible.
Can specification by example still be of use? Jonas Bandi ask (and answers) a similar question here. I think that it can be most useful. Using this approach you will get:
- a shared understanding of the task at hand in the team (developers and tester)
- an executable specification for the developers to code against. That gives them the possibility to work outside in
- the tester get a skeleton for a suite of automated regression tests
- the test can live during the sprint – that is developers and testers can introduce new specifications to verify behaviors as they are found.
- and finally; given that your using a tool with a readable language (Gherkin in SpecFlow for example) – you can take it back to your customer for verification. That will hopefully get them to engage more in the process.
How it’s it done?
If I ever got the opportunity to decide on matters like this (and I DO, sometime) I would set it up like follows.
If we use the example that we’re converting a VB6 application, our most probable choice would be WPF. One nice feature of WPF is that there are loads of great frameworks building on well known patterns, such as MVP, MVC and MVVM. I blogged about some of these frameworks here.
So I would probably go with Prism from Microsoft. That will give us a clean separation between the view (XAML code that only do data binding and an abstraction of the view that holds the properties the view binds to; the ViewModel.
Given this setup you can write your the steps that the specifications are executing against the view model, leaving the View to be tested separately. This is not ideal but automatic GUI testing cannot take you all the way in any case. There will always be a human take on where stuff are best placed and how the interaction should be. This can never be automatically verified. I think. And hope – that would almost be scary.
My specifications would then look something like this
Given I’ve entered customer number 12345567
When I choose Open Customer
Then I should see the following information on the screen:
| ID | Name | Street |… | … |
| 12345567 | Marcus Hammarberg | My street | … | … |
I would have the test run against the “real system” with a real database and all the real dependencies (no mocking).
I get back to you when this is tried out, and I have ran into all the problems I didn’t foresee.
5 comments:
Hi Marcus,
interesting post.
I replied on my blog :-)
http://blog.jonasbandi.net/2010/05/bdd-antipattern-business-readable-but.html
Please do not get my reply wrong, it is formulated in a provoking way in the hope to trigger a discussion and not meant as a critic.
Critism from you Jonas, are always welcome. I have the highest respect for your knowledge in this field, and i wrote this to get feedback like this.
I have replied in the comments section of your blog :)
At the very least you could use your BDD-style spec to garner discussion and get some agreement on what is going to be converted.
Very interesting blog posts, yours and Jonas's. Very timely for me - will look forward to the rest of the discussion.
I'm drudging up an old post here, but it's very timely for me. I'm wondering if you ever got to implement this in one of your conversion projects?
We're about to embark in a project for converting an Oracle forms UI into a more modern UI (likely a web UI in .NET or something). I'm the business analyst on the project, and I'm trying to figure out how to approach user stories without being totally overwhelmed. The app is huge and there are a lot of business rules. Just trying to figure out the best way to approach it.
Hi Jason,
I think you should stay away from the automating thoughts until later. Start with thinking about how to slice and dice the app in user stories first. Check out user story mapping for a great way to structure your backlog
In this particular project (way back) we had quite a few user stories that fell out just simply because they wasn't used anymore. Cheapest possible implementation, huh? :)
When you have a rough idea about the user stories use the Specification by example workshops to flesh out the details for the first user stories to implement. In this part use the old application as a reference and you can "simply" write scenarios down.
Finally think hard about automating through the UI (read more here). I would suggest that you try to write most of your scenarios against the "controller"-level of your application. Much faster and more reliable. Maybe leave 5-10% of your scenarios running against the UI as a smoke test.
I hope this gives you some ideas on how to pursue the project.
To sum up - BDD/ATDD is VERY useful, but the technical part of it is not the thing. Read more here
Post a Comment