Right after the recent release of Windows 7 Microsoft also released a platform update for Windows Vista and Windows Server 2008. The update brings in some of the new technologies from Windows 7 to those operating systems. Besides 'Windows Graphics, Imaging, and XPS Library' (which actually gives you new DirectX), 'Windows Portable Devices Platform' and 'Windows Ribbon and Animation Manager Library' (I hate the ribbon interface), the update also includes something called 'Windows Automation API', which "enables accessibility tools and test automations to access the Windows user interface in a consistent way across operating system versions"
Since Active Accessibility Microsoft has been providing programmatic interfaces for UI automation in Windows. So if you are starting a Windows automation project, think about using this approach. You can script with the Automation API in any of Microsoft's programming languages (Visual Basic, C# and even C++) even with the free Express Editions of Visual Studio. This will not only be a really cost efficient approach, compared with the prices of automation tools like QTP or RFT, but probably will produce results which are more stable too. After all this is the technology Microsoft uses to create UI tests for their own applications.
Hi,
I am a QA engineer working for a software company. The company just used the ribbon interface which I had to find a way to automate the test plans.
Currently, we are using the key combinations to test the ribbon interface. However, as more functionalities are added, the combinations changes. I have to go to each test case to change the combination.
Do you have a better way to automate the ribbon UI test? I appreciate your help.
First let me say one more time that I hate the ribbon interface. It is one of the reasons I started using Open Office instead of MS Office.
Unfortunately I have not done any automation for Windows applications with ribbon UI, so I can not be very helpful here, but in my experience when most things fail, keyboard shortcuts are usually a good bet. I think that your problem probably lies somewhere else. You said that when the keyboard shortcut changes, you have to go through each test case and change them too.
Change in software is something normal and we should try to create our tests in a way which accommodates change. In your example – it is probably possible (depending on the tool you use) to create your tests in such a way, that if the keyboard shortcut changes, you have to modify only a single place in your test framework.
For example – if you currently use Ctrl+S to save a document, do not type the keys directly each time you want to save. Create a method or function or ‘reusable action’ or whatever it is called in your test tool, name it for example SaveDocument and call it each time you want to save.
Then if the keyboard combination changes you will only have to change your SaveDocument function, not every test script that uses it.