Migration of Scripts from IBM Rational Functional Tester to Selenium

[PU]

Dear all,

We are using RFT as Test Automation. Thousands of scripts are
developed in it. Now we are planning to Migrate it to Open Source Test
Automation tool Selenium.

Just wanted to know the possibilty of migration.

Please help, if anybody has tried it.

Thanks,
Purvi

[PU]

Dear all,

I tried on myself. There was following issues that i have discovered:

1). RFT records the location on the page with the help of pixel while
selenium records the xpath of the element and the pixel(optional). If
we want to migrate our script from RFT to Selenium, than also we will
require xpath.
2). RFT with pixel is also have function attach to each line in case
of selenium as such there is no case.

Please let me know any idea/pointers to rectify it.

Thanks,
Purvi

[Andy Tinkham]

I'm not sure what you're describing in point 2, but based on point 1 alone, I don't think you're going to find any way to automatically migrate your scripts. Figuring out the xpath for a given pixel might be doable, but it's not a trivial task and it seems likely that you might find doing that well across all your tests takes longer than it would take to recreate the scripts from scratch in Selenium. It's also my suspicion that any sort of wholesale automatic migration like this might cause you to have to do a lot of ongoing maintenance on the converted tests because there's only so much that a program can do to optimize things like xpath selectors or program flow.

My recommendation would be that you approach the transition to Selenium as an ongoing process rather than trying to convert all of your existing scripts at once. Start by building any new tests in Selenium and keep both the RFT scripts and the Selenium tests running at first. Then, over time, analyze your RFT scripts. It may not be worthwhile to move some of them into the Selenium suite - it's not uncommon to have tests that really aren't ever going to find bugs anymore since they've grown stale as the system has changed or which have had their functionality duplicated by other tests created later. As you find those, you can remove them from your RFT run and not worry about rewriting them in Selenium. There may also be scripts that are always failing due to issues in how the script was written initially (and not due to bugs in the application). You may have a small number of test scripts which require the majority of your time to keep working. Figure out how you could redesign those scripts in Selenium to be more robust and useful and re-implement them using the new designs, then remove the old scripts from RFT. Over time, you may also find that existing scripts need significant rework to keep them working against your application as it changes. When you find these tests, rather than making significant changes in RFT, write the test in Selenium and remove the old RFT ones.

Eventually, you'll probably be left with a smaller set of RFT tests that are worthwhile to run but fairly stable. You can work on rewriting these in Selenium as time allows or keep them in RFT until they get stale or broken at which point you remove them or replace them with new tests in Selenium. You may find that at some point this pool of remaining RFT tests is small enough that it's worth the effort just to finish rewriting the tests in Selenium and finish the transition.

Changing an automation tool is not a quick task, particularly when you have as much invested in the original tool as it sounds like you have. While you might find a faster way than what I've recommended, you need to be careful that you don't just trade time transitioning for time performing ongoing maintenance of the test suites. If you take a little longer transitioning tests and spend the time to review and analyze your tests, you should end up with a higher quality test suite at the end.

In some ways, what you're trying to achieve is conceptually similar to trying to take an existing system and add unit tests across the system when they weren't present before. Michael Feathers talks a lot about this in his book "Working Effectively with Legacy Code" and you may find some ideas in there to help you plan out a sane transition strategy as well.

Andy

Dear all,

Thanks,
Purvi

--
You received this message because you are subscribed to the Google Groups "Selenium Users" group.
To post to this group, send email to seleniu...@googlegroups.com.
To unsubscribe from this group, send email to selenium-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/selenium-users?hl=en.

[Tarun K]

very well said Andy

~T

[PU]

Thanks Andy for the suggestion. Looking into the scripts and
complexity involved. Even I was thinking in the similar direction.

Purvi

> For more options, visit this group athttp://groups.google.com/group/selenium-users?hl=en.- Hide quoted text -
>
> - Show quoted text -