2.5 Test 

Previous | Next

The test phase ensures that the planned tests are executed to ensure the quality of the application developed. It includes setting up the test environment and test data. The test setup should simulate the real environment of the business as close as possible. The scope of testing would be limited to the test planning and test cases prepared. The test environment should have all the dependant system and interfaces configured for proper testing. The testing phase is bound to be conducted in an iterative form where any defect observed during testing must be fixed and re-tested again.

The Domino application test setup includes several aspects:

• Setting up the test server configured in line with the production and pre-production servers for better simulation of test scenarios.
• Creating multiple test user IDs on server to test application for different set of users with varied access rights.
• Setting up of an appropriate database access control list (ACL) as per the design specifications to ensure each test user ID has an appropriate access rights. Avoid using the higher access in database ACL for any test user ID that does not match the user role defined in the design specification.
• Deployment considerations: If the Domino application is to be ported to several platforms, for example, multiple version and types of browser, mobile and smart devices, an appropriate test setup should consider all these factors and the test environments should be made available for testing.
• Internationalization considerations: If the Domino application is to be deployed at a global level, providing multiple servers with different time zone and regional settings is another key factor of setting up the test environment to simulate the real life environment. 

Application testing

 
This phase consists of unit, integration, and system tests. All the modules are tested individually and then integrated for the system testing in successive cycles. The defects found in a cycle of testing are fixed before commencing the next cycle of testing. The systems testing is also carried out as part of this phase. There should be no open issue which is critical for the user acceptance the application. The application is not handed over for user acceptance test (UAT). Unless all the issues reported during the application testing are not fixed, verified, and closed. 

The key aspects of the applications test are: 

• Conformance to business requirements:
  This aspect of application test is focused towards to ensure the application developed meets all the business requirements. The requirement in terms of GUI, business use cases, business rules, and all type of business related processing expected from final application. Verify the features and the functioning of them as per the requirements and design specifications.
• Process workflow and application security:
  The important aspect of most of the domino applications is its workflow and security implementation. This being a core of any domino application, a special attention is required in this area including the workflow routing of the document and mail routing associated with it and the security implementation in terms of authors, readers, controlled section, and data security at different levels of workflow. The workflow must be tested with test user IDs having appropriate access to simulate the business environment.
• Application performance test
  Domino applications are expected to be tested for the performance. It encompasses several aspects of performance testing of an application: the response time, screen loading, form submission, the processing efficiency of various features, and overall performance with peak load of concurrent user using the application.
• Multi-browser compatibility test
  Consider the browser standards of the target business organization for Domino applications. In genera, business offers the application compatibility to one or few of the popular browsers. The application has to be tested for compatibility and awareness of the types of browser that offered. Perform the proper test of each browser enabled feature on the target browsers to ensure the application compatibility for the same. 
• Multi-language or regional setting test
  Domino applications must be tested as per the various target user’s regional settings to ensure better adaptability. The scenario wherein the application hosted on a Domino server that has a different regional setting as that of the users using the application should be established. A specific consideration must be made to test the date, time, and number type data fields for the formats, calculation, and presentation. The test is also required to understand the different character set to be managed for any data input and output processes for the application.

The Domino application testing is one of the key phases in the Domino application development life-cycle. The following are some of the guidelines to test the Domino application.

GUI
The GUI of the Domino application should be tested for its consistency in screen layout, font formatting, and color scheme as per the design specifications or the GUI standards defined during the design phase. Test the GUI screen of a view as well as of forms with a possible data in the Lotus Notes document with inline HTML or mark-up text entered by the users in one of the field. The system should either render such inline mark-up text without disturbing the application GUI or validate such data entry with appropriate restrictions. 

Data caching
Test the Domino application for a consistent, recent data presentation on screen for dynamic contents. Post a Lotus document with data content from browser to Domino server and re-open this document in read mode in browser. Verify that the last modified data, not the cached data, is display on the screen for the document. Irrespective of the browser setting for cache, the Domino application screens that deals with the dynamic data should be tested for no cache data implementation. 

Data views
Test all the user interface views of the Domino application for the number and the sequence of columns required as per the design specification. You should also test the views for other aspects such as view navigation or pagination, column sorting, default view sorting, document listing, empty categories (in case of categorized views), view actions, and view filtration. Test the view data access, log in to the Domino Application using different user access rights or user IDs and test for restricted document level access. Test the response time of the navigation across pages for the views to make sure it meets the requirement. The view level actions should be tested based on the features enabled for the Domino application. Such as the in-view document edit option, processing of the selected documents, and any other specific view actions must be appropriately tested with reference to the design specifications. The new documents created in the database which qualify to be listed in a particular view should be tested for appropriate listing of the newly created document in the view to verify the view index is automatically refreshed. If the document contents are expected to have multi-lingual data which includes accented characters, test the view column sorting for accent sensitive sorting.

Data access, edit, and search
Test the data manipulation features of the Domino applications for data validation, data consistency, data constraints, and business rules expected as defined in the design phase. The data accessible through a form in different sections as well as the fields and actions expected to be visible or actionable to the users with different access levels must be tested as per business rules defined for the application. For thorough testing, prepare an access control matrix for each type or level of access rights and roles against each and every user interface action and data presentation layer. Prepare such matrix in line with the design specifications and the business rules defined during the design phase. This approach would ensure that data access, in terms of visibility and editing, is tested appropriately without missing any particular combination of access levels expected from the application.

The data search capabilities provided in the Domino applications must be tested on the following parameters: the data fetch response time, the data search accuracy, and the data security.
During the test environment preparation, generate the kind and the amount of test data as it is expected in the production environment. Work with the business users to obtain this data to simulate the proper data search test scenarios. Avoiding this test could result in a number of blocking issues during the user acceptance test (UAT). Generally, in the UAT phase, the business user would use the actual data from the business to validate the user acceptance of the application. Hence, at this stage of application testing, it is critical to not only test the application features but also use the business data to simulate the actual business environment. This approach would help identify applications acceptability in terms of handling different type and set of data content expected to be used during production run of the application, for example, the amount of data to be managed by the application considering the initial production run and the data size growth expected during the applications production life-cycle.

The UAT incudes testing the applications response time and efficiency in data search capabilities of the application. Verify the performance requirements defined by the business or the design team in design phase is met with the data search response time parameters in the performance benchmark. In addition to the response time, the data search accuracy test is equally important in UAT. If the full text search feature is implemented to gain performance efficiency on data search response time, it has its own set of inherent flexibility which might not be acceptable from data search accuracy point of view. For example, the search action triggered (using full text search) for searching text "Belgium" would fetch the document field contains "Belgium" as well as "Kingdom of Belgium". This might not be the result the business users expect. It is important to understand the expectation of the business for such scenario, wherein whether the business needs the exact match or word match.

Background agents
Domino applications implement Lotus script and Java agents that have to be tested to verify the expected functionality defined in design specification. Test the background agents for the appropriate access rights for the business requirements. Generally, a background agent is run using the access rights as that of the agent signer. However, in many Domino applications, it is required that the agents to be run as web user to allow the agents to execute with access rights of the current session user. For example, the WebQuerySave agent that triggers email or performs certain activities that require the current session user context are configured to run as web user. If this perspective is missed during the application testing, it leads to failure in certain business use cases during UAT. This is one of the important aspects to ensure the agent is tested appropriately either in context of agent signer or the current session user as per design specifications. Similarly, depend on the application requirement, the proper functioning of the restricted actions by the background agent must be tested, for example, the proper functioning of the background agents that handle file system operations.

Other business scenario for background agents is where an agent attempts to access database on another server in the same domain. The common Domino server administration policy is to disable the access of any background agent triggered from the Domino server to access resources on another Domino server where the two servers are not explicitly trusted even in the same domain. The solution that considers the background agent accessing resources across servers should be done at earliest during the application development lifecycle. The design phase is an appropriate stage to make such consideration. The Domino application test has to consider this aspect and to check any possible issues arising due to the infrastructure setup constraints or the solution implemented. The best approach is to check the possibility with the administration team if, within the organization policy, the trusting of server in same domain is possible to allow this solution to function properly. The alternate solution is to create a replica of the other database on the source server to ensure the dependant database is available on the same server.

The background agent performance must be tested within the context of the real business scenario. Certain Domino server configurations settings have an impact on the time allocated for any background agent process of Domino application to complete its run on the respective Domino server. The Domino application background agents must be tested for its performance efficiency to comply with the configuration settings of the target production server.
 
Following are some of the key server configuration settings for a background process of Domino application:

• Max LotusScript/Java execution time:
• This configuration parameter (see the figure below) in Agent Manager tab has two possible values in context of daytime and nighttime parameters. The agents run during each period are subject to the settings in the parameter fields for that period. 
• Agent Manager is a server task that is responsible to manage the schedule and background agents run on server.
• This parameter specifies the maximum minutes a Lotus Script or Java agent has to complete execution during that part of the day. If the agent exceeds this maximum execution time, the job won't be finished, and the Agent Log records the termination. 
• Defaults are 10 minutes for daytime and 15 minutes for nighttime. Domino administrator can increase the execution time limits to allow the complex agents sufficient time to complete. Setting the value of this field excessively high might impact system performance, because the Agent Manager runs for a longer time to accommodate the agent. 
• This time limit setting prevents erroneous agent processing that take unusually long execution time from occupying the resource.  
  
• Web agent and web services timeout:
• The web agent or web services in context of this parameter (see the figure below) is the agent and web service that is triggered by the browser clients. This include application agents invoked by the WebQueryOpen and WebQuerySave form events and for the agents invoked by the URL command OpenAgent. 
• This setting allows the administrator to manage the execution time limit for web application agents. The purpose of the time limit is to prevent web agents from running indefinitely and using server resources. This parameter specifies how the maximum number of seconds a web agent or web services has to complete its execution.
   

User acceptance testing

 
This phase consists of acceptance testing by the customer. Development team must fix defects found during this period by the users. In addition, the development team has to continue to test the product and improve quality.  The acceptance test has to be performed for all deliveries and releases. 

Parent topic: 2.0 Application development lifecycle