What to do when your product has multiple interfaces…
Ok, so you find out that the target application has multiple interfaces. One interface may be a client application such as Eclipse, another interface may be a web application accessible via web browser, and still yet another interface may be a developer API. Does this mean you need to create 3 different test frameworks and 3 test scripts just to test the same functionality on all 3 interfaces? Not quite…
Business logic is business logic. If your target application is an email application, then its business logic remains the same. Customers are given the function to ‘send mail’, ‘receive mail’, ‘add contacts to address book’, and other functionality typical to an email application. Regardless of the interface (web app, client application, or developer API), the business logic remains the same. If this is the case, then you simply need to define a test case format that is tied to the business logic. After this is done, you create an engine to parse this test case and, depending on a variable set in a properties file or global environment variable, your engine should be able to handle mouse clicks to the GUI or commands sent to the developer API. This is much easier said than done; however, there exist some QA groups who have created such intelligent frameworks and have saved their teams the heartache of having to create multiple test scripts / cases to test the same functionality on different interfaces.
So, do I practice what I preach? (No, but I wish I did). Our current project is not so current. We’ve been testing a set of Eclipse plugins, for well over 1 year now. The type of testing though has changed. We have two interfaces to tap into the existing functionality – the GUI, what customers intend to use, as well as an API that is callable once an Eclipse workbench is invoked. Although the business functionality offered by the GUI and the API are the EXACT SAME, we have not yet defined a common test format which could then be run into an engine, factory, or adapter design pattern. This engine would then plug and chug away once determining whether or not to attack the GUI or the API (based on a global setting). Can this be done for our test project? Yes, but we’re still inching towards this goal.
Recent Comments