Testing at InApp are tailored to meet client specific needs, manage critical testing processes and ensure consistent high quality through repeatable processes. The software testing methods employed here are as follows:
- Unified Selenium API Automation Framework
- Robot Framework
- QTP Modular Framework
- In house automation Frameworks
Unified Selenium API Automation Framework
In Unified Selenium API Automation Framework all objects that will be used to perform actions will be identified and grouped under different nodes, in an xml file. Updating the locator in xml file will reflect changes in all the areas the locator is referred. The advantage of this framework is ease of maintenance.
- API is modeled after human language – If it looks like a button, we call it a button, regardless of implementation
- Test code does not use locators verbatim – Locators are aliased through .xml file
- usAPI exposes locators by UI element type – E.g., button, link, tab, tree node, etc.
- usAPI transparently handles timing issues, logging, setup/tear Down
All tests will be derived from org.usapi.BaseSeleniumTest. This will expose (among others) as an object named ‘app’, which is of type BaseApplication. All interactions with the GUI utilize this ‘app’ object, at no time should there be any need to invoke selenium methods directly.
BaseSeleniumTest configures, starts, and stops the selenium client transparently to the test developer. BaseSeleniumTest provides generic methods for use in tests, such as assertTrue, assertFalse, isElementPresent, etc. Note that these methods are application-agnostic. Methods required for a particular application (e.g. to execute SQL queries) do not belong in this class.
Robot Framework is a generic test automation framework for acceptance testing and acceptance test-driven development (ATDD). Robot Framework has a modular architecture that can be extended with bundled and self-made test libraries.
Test data is defined in files, a file containing test cases creates a test suite and placing these files into directories creates a nested structure of test suites.
When test execution is started, the framework first parses the test data. It then utilizes keywords provided by the test libraries to interact with the system under test. Libraries can communicate with the system either directly or using other test tools as drivers.
Test execution is started from the command line or continuous integration tools like Jenkins, Hudson and the like. As a result, you get the report and log in HTML format as-well-as an XML output. These provide an extensive look into what your system does.
QTP Modular Framework
QTP Modular Framework (also known as Functional Decomposition Framework) is the approach where you first identify the reusable code from your test cases. Then you write this re-usable code inside different functions and call these functions wherever required. The advantage of this approach is that the reusable code would always stay at one place and thus it would be easy to maintain the code because you would have to make the changes at a single place only. To reuse this piece of code, all you have to do is call the function wherever required. The only challenging part here is to identify the reusable portions in your test case flow. Once that is done, you have to just create functions and use it wherever required.
In addition to these popular frameworks we customize and use frameworks based on client needs such as combining Unified Selenium API Automation Framework with hash maps to use as a temporary buffer space and auto email program.