Essay: Understanding ICM and Billing System of Majesco & Suggesting Improvements in Testing Process

1. INTRODUCTION:
1.1. Background
1.1.1. Billing System in Insurance Companies:
Billing is a necessary function of the insurance transaction. A customer may go months or years without filing a claim, but every customer receives a bill on a regular basis. A customer may never read marketing material insurers send or the insurance policy itself, but they will examine the bill carefully. Therefore billing represents a chance to build a satisfactory and meaningful relationship with the customer. Billing creates an opportunity to create a positive experience and to build longstanding relationships.
Insurers too understand the link between customer satisfaction and effective billing system, a 2008 GuideWire Software survey of wide range of Property and Casualty insurers in North America showed that most insurers considered that billing is ‘important’ or ‘very important’ to customer satisfaction.
Following are the major finding of the survey:
‘ The majority of carriers surveyed believe that billing impacts customer satisfaction and 88% believe that billing impacts customer retention.
‘ Carriers report that the ability to offer flexible payment options to customers is critical, but 60% of respondents have difficulty creating new bill plans.
‘ 35% of carriers polled are still unable to provide a single invoice for multiple policies.
‘ 41% of insurers reported they are not confident their current billing systems will meet future needs.
‘ Carriers continue to shift from agency bill to direct bill. 53% of carriers support agency bill today. 19% of the 53% planning to increase agency billing in the next three years, while 34% plan to decrease agency billing in this same period.
‘ 34% of carriers surveyed still house billing in their policy administration system which is contributing to the difficulty creating new bill plans. 58% of this group plan to separate billing from policy in the future. The carriers that plan to keep billing in their policy administration system tend to be the smaller carriers.
1.2. Need of the study
Currently most of the companies are using billing system which are either a part of ‘Policy Admin System’ or are run on mainframe based billing system and are more than 20 years old. The reason of longevity of these systems is that the insurers have worked to maintain, enhance and modify them over the years to continue to meet the business needs. However the legacy systems have several shortcomings:
‘ They are typically hard-coded, often in archaic programming languages that are increasingly difficult to support.
‘ They may not be a consolidated system but, instead, a collection of different applications purchased over time to perform different billing sub-processes and cobbled together with inflexible, point-to-point integration.
‘ Business logic and workflow is embedded in years of coding, making it difficult to change and leading to manual workarounds to overcome system limitations.
‘ Many insurers feel that their current billing systems do not meet their billing needs ‘very well’. Using these legacy systems result in poor customer service and inflexibility in providing various billing options to the customer for e.g. EFT, Credit Card/ Debit card payments.
Functionality of Current Billing system
In todays market these limitations means losing customers. Customers expect to be provided with flexibility in regards to making payment. Insureds who hold different policies with the same insurance company expect to get a single consolidated bill for the specified billing cycle.
1.3. Organizational Profile
Majesco has over two decades of experience in providing technology solutions, products and services for the insurance industry across lines of business ‘ Property & Casualty (General Insurance), Life, Annuity, Health, Pensions, and Group & Worksite Benefits insurance. Majesco focuses on delivering business value and enhanced business capabilities to their clients through a combination of their world class enterprise grade products in modern technologies, implementation services and specialized application services. They have products for Insurance content management, Billing systems, PAS systems.
Majesco serves just one vertical ‘ insurance; and has developed Insurance Software, Support and Business Consulting expertise over two decades of serving the insurance vertical. With industry expertise, wide capabilities and strategic alliances, Majesco offers an integrated portfolio of IT software and services, including: IT Consulting, Application Development, Systems Integration, Application Management Outsourcing, Testing, Data Warehousing and Business Intelligence, CRM services and Legacy Modernization. It is the trusted partner of more than 120 insurance carriers globally spanning the entire core systems landscape.
The experience and expertise in executing complex transformation and mission critical programs for insurance companies worldwide is Majesco’s key strength. Majesco is committed to building strong and long-term relationships with its carrier partners. It has a successful track record of long-term client relationships with close to 90% of business coming from existing customers. With a strong global presence across North America, Europe, the Middle East and Asia Pacific, Majesco is a technology partner of choice for insurance carriers worldwide.
Majesco helps Insurers to migrate from legacy system to newer technologies which provide integrated solutions to wide area of problems. They also strive to seek continuous improvements in their product by implementing new functions such as directly taking content from the ISO site and loading it in their system, this has removed the need of manually performing the task.
1.4. Organizational structure:
MajescoMastek is now demerged and Majesco is a separate entity. Till date the exact organizational structure is not yet defined. However various key person of Majesco are as follows:
‘ KetanMehta,CEO, Co-Founder
‘ Edward Ossie, Chief Operating Officer
‘ Chad Hersh, Executive Vice President
‘ Bill Freitag, Executive Vice President
‘ FaridKazani, Group CFO & Finance Director
‘ Prateek Kumar, Executive Vice President ‘ Sales
‘ NimishSankalia, Senior Vice President – Insurance Services
‘ Rajeev Jain, Senior Vice President, Delivery
2. INSURANCE CONTENT MANAGER:
Insurance Content Manager (ICM) is Content Management system for an insurance vendor. An insurance content can be Master Data, Various Business rules, Rating Algorithms, Payment plans.
ICM deploys the concept of Repository. There are three internal repositories in ICM:
‘ Common: Holds Meta information like User, ACL, Content repository details, Tag details etc.
‘ Artifactory: Holds compiled rule packages for product and non-product
‘ ISO Content: Holds ISO-ERC content files
‘ Single instance of ICM is capable of handling multiple Content Repositories. Content repositories can be created by users through ICM application.
‘ There exist two types of workspaces for a given content repository.
‘ Main Workspace: For product and non-product modeller content. (This workspace is visible to normal users upon login.
‘ Ticket Workspace: Any content that may be added or modified is maintained in this workspace, which is then merged into main workspace upon ticket closure.
‘ ICM provides various editing and validation options:
‘ Editing the Header rows
‘ Default values for selected entities
‘ Providing dropdown feature
‘ Add/Hide Columns for an Entity
‘ Validations
2.2. LOGIN SCREEN:
This screen allows the user to log into ICM. Click http://172.16.209.113:18080/icm/icm.html link to display the Login screen of the ICM application. User needs to valid user ID and password to get access.
2.3. LAUNCH SCREEN:
This screen of ICM application displays various menu items, from which a user can choose various user actions. The screen also displays the Quick Access menu for Logout, Preferences and Help.
Preferences menu helps in changing the password of the logged in user and also helps in choosing default repository.
2.4. MANAGE USERS:
This screen allows user to perform tasks such as User Registration, Group Creation, Create Repository, Access Control and Enable/Disable Users.
Users can be of following type:
Permissions Viewer Writer Configurator Manager Administrator
Repository Access Yes Yes Yes Yes Yes
Repository Import No No No Yes Yes
Repository Export No No No Yes Yes
Repository Create No No No No Yes
Ticket Create No No No Yes Yes
Subject Area Access Yes Yes Yes Yes Yes
View (Ticket) Yes Yes Yes Yes Yes
Write (Ticket) No Yes Yes Yes Yes
Configure (Ticket) No Yes Yes Yes Yes
Publish (Ticket) No No Yes Yes Yes
Entity Read Yes Yes Yes Yes Yes
Entity Write No Yes Yes Yes Yes
User Create No No No No Yes
User Detail View Yes Yes Yes Yes Yes
User Edit Yes Yes Yes Yes Yes
Reset Password No No No No Yes
Through Manage Users menu we can use following functionalities:
‘ User Registration: This screen allows the user to create a new user in the application. For creating a new user we require User Name, User ID and Email ID. After user creation an email is automatically sent to the users ID with login credentials and application login link.
‘ Group Creation: This screen allows user to create a new group. A user is generally assigned to a group and a group is subsequently assigned to a role. Through this screen user can also update a group by performing tasks like adding and removing users from a particular group. All members cannot be removed from the group; a group should always have at least one member.
‘ Create Repository: This screen allows user to create a new repository and add or remove database details for a repository. Note that more than one database can be added to a repository during the time of its creation. User can also test database connectivity through this screen.
‘ Access Control: This screen allows controlling the access given to the users and groups on the repository. User can be assigned roles on different repositories and can be given access to selected subject areas. In same way Groups can also be assigned different roles and given access to subject areas.
‘ Enable/Disable Users: This allows the user to enable or disable users in the repository. User once disabled cannot log into repository.
‘ Reset Password: This screen allows a user with ADMIN rights to reset password of any given user. Mail is sent to the user with the new password.
‘ Update Templates: This screen allows the user (with appropriate rights) to choose a repository template while creating the initial repository. User can create new template or use an existing template to create a new repository.
‘ For creating a new template user needs to provide Meta Data (.xls), Entity Mapping (.xls), Fixture Node (.xml) and Constant (.xls) files.
‘ User can also download a template from the application.
2.5. REPOSITORY EXPLORER:
2.5.1. System Data Definitions:This section stores the physical data structures and database schemas, as well as definition of the entities in ICM and their mapping to physical data structure. System Data Definitions has following folders in it:
2.5.1.1. Data Mapping:These folders are automatically created based on the data in the Entity Mapping.xls that is used while creating a template. It consist of two sub folders:
2.5.1.1.1. System Table List- This displays information of all the database tables available for use in case of an entity creation.
2.5.1.1.2. System Table Reference Mapping (SRTM) – This displays information of reference columns available for use in case of an entity creation.
2.5.1.2. Constants:These folders are automatically created based on the data in the Constants.xls that is used while creating a template. Contains information about the types of reference entities that are available for use in ICM with defined constant names.
2.5.1.3. Rule Mappings:Contains the jar files that are required to process the circular files and validate the rules.
2.5.1.4. Lookups:This is automatically created as a part of the template and is initially blank. You can define global lookups here that are used in the rating process. Global lookup is used to extract data from the back end and display it in the front end.
2.5.1.5. Rating Template:This is automatically created as a part of the template and is blank initially. You can create rating templates here that are used to create a rating in the system. A rating template is similar to a rule but it is in a template format. The only difference between a rating template and a rule is that a rule contains a data grid for entering data for its decision table where as a rating template does not have a data grid for the decision table.
2.5.1.6. Schemas:These folders are automatically created based on the data in the metadatanew.xls file that is used while creating a template. It contains information about schemas, tables and columns available for creating entities in ICM.
2.5.2. User Data Definitions:This section stores user defined logical structures and their definitions. These logical structures can be referenced from anywhere within ICM to create more complex structure or store data against those logical data structures.
2.5.3. Product Templates:This section stores the user defined ISO and NON-ISO revision templates that are used to create a product.
2.5.4. Product Definitions:This sections stores the rates, rules and forms associated with the product which are used for policy product definitions.
2.5.5. Business Rules:This section stores the business rules that define the behaviour of the application for event like cancellation, reinstatement and cash allotment. You can have multiple rules, queries and functions.ICM uses following business rules:
2.5.5.1. Decision Table Rule:Decision Table Rule is used to describe and analyse complex business scenarios where a number of conditions determines the execution of relevant actions.
Decision table consists of three sections:
2.5.5.1.1. Conditions:Conditions represent the When portion of a business rule. It specifies under what conditions the actions of the rule will be executed.
2.5.5.1.2. Actions:The action part of a rule describes the outcome when the conditions of the rule are met. If there is more than one action to perform, the actions are carried out in the order that they appear in the action part of the rule.
2.5.5.1.3. Rules:Each Rule column represents a combination of condition(s) and action(s), meaning that when one or more conditions are met, action or multiple actions are performed accordingly.
2.5.5.2. When’Then Rule:You can define rules that are run conditionally by using the WHEN and THEN conditions. You use these rules to define which elements are run when the defined clause is true.
2.5.5.3. Scripted Rule:Scripted Rules are stored as text. A scripted rule consists of a condition and action. The condition begins with the keyword when, binds variables to objects and attribute values, and specifies tests on attribute values. The action begins with the keyword then, specifies the actions to be carried out if the rule is executed. It also includes an optional second part which begins with the keyword else, that applies only if the last evaluated statement in the condition part is false.
Select the subject area and the location where the when-then rule is to be created and click Actions > New Asset > New Business Ruleto display the Adding New Rule window. Add details such as conditions and actions in the window and click on save. For applying When-Then rule, click on newly created rule which lets you configure the When-Then rule. For applying scripting rule, click on newly created rule to view a blank template to enter the new details.
2.5.6. External Data Definitions:This section stores the definitions of the external data structures and their mapping to logical structures within ICM.
2.5.7. JBEAMS Configuration:This section stores the JBEAM related configuration to control and monitor the batch process.
2.5.8. Action Items:Each of these sections have action items associated with them, they are:
2.5.8.1. New Master Definition:allows setting up new entity under the selected node. The list of values and rules constituting the master setup for the new entity are defined for further use in the system. Master Definitions can only be created within reference entity or a folder.
To create a new list of values (LOV), in User Data Definition select a folder and click Actions’New Asset’New Master Definition to display the Entity Definition window. The window consists of the following three tabs:
‘ Reference Column:
‘ Definition
‘ Property Definition
2.5.8.2. New Reference Definition:Allows setting up a new reference entity within a subject area in the repository, wherein, a value for a specific column created in the master entity is retrieved from the parent reference entity.
2.5.8.3. New Lookup Criteria:This action item lets you define global lookups that are used in the rating process. Global lookup is used to extract data from the back end and display it in the front end. It is defined under System Data Definitions. It is reusable and can be used multiple times at various instances once defined. Existing lookups are visible in System Data Definitions -> Lookups. For creating new lookups, select the location where the lookup is to be created and click System Data Definition > Actions > New Asset > Lookup Criteria.
2.5.8.4. Import Lookup:Import Lookup functionality lets you import the existing lookups from the database to ICM in form of a XML file. The complete data configuration is imported on importing the XML file.
2.5.8.5. New Rating Template:This action item lets you create a rating template to be used for creating a rating. A rating template is similar to a rule but it -is in a template format.
2.5.8.6. New Rating Node:This action item lets you create a new rating node to define rating specific configurations. You can create a rating node using a rating template.
2.5.8.7. New Folder:allows creating a new folder within the subject area.
2.5.8.8. Copy Entity:copies the selected entity or folder frim the repository. An entity can be copied directly or its repository reference definition can be copied.
2.5.8.9. Rename Entity:allows renaming an entity.
2.5.8.10. Delete Entity:allows deleting the selected node or entity from the repository. You can delete the folder or entity from the ticket workspace.
2.5.8.11. Payment Plan:The objective of this step is to ease the process of creating a payment plan in the system. Payment plan is created by the Payment plan wizard. It is a three step process that consists of:
2.5.8.11.1. Setup the plan in the answer table:Navigate to the Payment Plans in User Data Definitions. Click Actions > Payment Plan to display the Payment Plan window. We can select the payment plan code from the dropdown. By selecting a particular rule, information of that rule is populated in description field. If no payment plan exists then ‘No payment plan setup is created’ message is displayed. Click on ‘OK’ on payment plan page.
2.5.8.11.2. Setup the instalment schedule:Enter the deposit % i.e. initial plan deposit percentage. Enter number of instalments. Click ‘Generate Instalments’ to generate the payment plan. Click ‘Next’ to display Payment Rules page.
2.5.8.11.3. Setup the plan-related business rules:Select a rule from the dropdown and click ‘Submit’ button to display the details, modify the records if required and click ‘Submit’ to create payment plan with payment rules. New Payment Plan Code will appear in the Repository Payment Plan list.
2.5.9. ICM Repository Toolbar:
2.5.9.1. Search:The Search icon is used to search any entity in any subject area from the repository.
2.5.9.2. Sync with Explorer:Sync with Explorer allows the user to switch to the selected entity from another table.
2.5.9.3. Edit Entity Definition:The Edit Entity icon is used to edit the entity definitions for a folder.
2.5.9.4. Save:This icon saves all the changes permanently to the repository.
2.5.9.5. Insert a row:The Insert row icon allows inserting a row for the user to define a property or column for the entity.
2.5.9.6. Delete selected row:The Delete selected row icon allows deleting a row.
2.5.9.7. Duplicate selected rows:The Duplicate selected row icon copies the selected entity and creates the replica of it at the same level.
2.5.9.8. Import/Upload:The Import/Upload icon allows appending or replacing the selected table under a subject area.
2.5.9.9. Export/Download:The Export/Download icon allows downloading the table details under a subject area in an excel format.
2.5.9.10. Filter builder:The Filter Builder icon allows the user to filter the results.
2.5.9.11. Version:The Version icon displays all the version history for the selected entity under the subject area. In this option we have an option of comparing two versions of the entities. The changed record is represented with a colour coding in the other version.
‘ Red – represents a deleted record.
‘ Yellow – represents an added record.
‘ Blue- represents a changed record. While creating the master entity, if the primary key is defined then only on modification of the same, the legend will turn blue on comparison.
‘ Grey – represents a changed source version.
2.5.9.12. Validate:The Validate icon is used to apply user created validations for the entities.
2.5.9.13. More Information:The More information icon allows the user to view additional details for the selected folder or entity.
2.5.9.14. Access Permission:Users with viewer permission do not have rights to change the entity details. The access permission icon is used to give access to users with viewer permission to modify the selected entity.
2.5.9.15. Show List:The Show List screen allows the user to view the previously accessed entity list. User can also remove the entity which he does not want to view.
2.5.9.16. View Records:View Records allow viewing individual records on the screen for easy understanding and modifications.
2.6. MANAGE REPOSITORY:
This menu items provides various options to manage the repository and has following sections:
2.6.1. Switch Repository:This screen shows list of various repositories assigned to the user. User has to select a particular repository on which he has to work. Only one repository is active at any given point of time. On selecting different repository, data of old repository is removed and that of new repository is loaded. If you select current repository, a message is displayed indicating that you are in the same repository.
2.6.2. Import Repository:This screen provides the facility to import data from a file into the ICM repository. Only XML file can be uploaded to the repository. A ticket ID for import operation is also generated and displayed on the screen. While uploading we have two options:
2.6.2.1. New Environment:To upload the complete XML data in the new environment, click ‘Yes’. A new ticket is automatically created, the existing environment data is deleted, and data from the imported XML file is updated in the environment.
2.6.2.2. Retain Environment:To retain existing environment data, click ‘No’. A new ticket is automatically created, the existing environment data is retained, and new data is succe0ssfully updated. If there are any conflicts the files are overwritten.
2.6.3. Export Repository:This screen provides the facility to export a copy of the current repository in a file format (XML). You can export the full repository or select the entities that can be exported. However export cannot be performed under a ticket and then you must be in Main Workspace to use the export repository function.
2.6.4. Properties:This screen allows the user to view the information of the current repository. Details about existing databases are displayed. Users can check the connectivity of the databases to the repository. Name of user who created the repository is also displayed along with creation date. These details are divided into two tabs; Database details and General details.
2.6.5. Running Tasks:Tasks such as import, export, ticket and repository run in the background if they are not completed within a specified time as defined in the system. Running Task menu is used to view details of these tasks. Details displayed on this screen are read only format.
2.6.6. Sync UDD Data:This functionality lets you sync master entities and rules from one repository to other repositories in the system. This reduces the effort in creating the same entities and rules in each repository individually. You can sync all the entities and rules or select the entities and rules to be synced. The system automatically creates a ticket in each repository where the entity or rules are being synced, creates a replica of the data in that repository, and closes the ticket.
2.7. MANAGE TICKETS:
Tickets are opened in ICM to process changes or errors/faults in the application. On identifying a necessity for change, a ticket is opened in ICM. A new ticket can be created in ICM by following steps Manage Ticket > Create a New Ticket. Enter ticket details such as Headline, Severity, Priority, and Description. We can add user who can work on the created ticket through user details and system will send emails automatically to all the relevant parties. A ticket in the ICM application can have following statuses.
2.7.1. Ticket Status:
2.7.1.1. Open:Initial status when the ticket is created in the system.
2.7.1.2. Assign To:This is the status of ticket when it is assigned to the user to work on. Ticket is assigned to a user at the time of creation (not mandatory, can be assigned later too). The Assign To is status is only to mark that the work on the ticket is in progress.
2.7.1.3. Complete:This is the status of the ticket when the changes have been incorporated. Ticket is then sent to reviewer for approval.
2.7.1.4. Approve:Status of the ticket when reviewer approves it, no changes can be made once the ticket is approved (changes can be made by putting the ticket again in Assign To status).
2.7.1.5. Close:Status of the ticket when all the changes are incorporated, once the ticket is closed all the changes done are merged into main workspace.
2.7.1.6. Discard:Ticket is discarded if no action is taken on the changes mentioned therein.
2.7.2. Manage Ticket Menu:
There are different sub menus under Manage Ticket menu, which are as follows:
2.7.2.1. Create a New Ticket:ICM application allows user to create new tickets in the application. A common ticket number is also created along with the ticket; this ticket number is common across all repositories.
2.7.2.2. View Tickets:ICM application allows user to check the details of the ticket with the View Ticket option. All the tickets are viewed under this option irrespective of the status. The following options are available:
2.7.2.2.1. Switch to ticket:This button lets you switch to the ticket view to work on the ticket and perform any necessary changes.
2.7.2.2.2. Add Note:This button lets you add brief notes for the ticket. Note that note can only be created for ticket which is in open status. Note cannot be created for a closed or discarded ticket.
2.7.2.2.3. Publish to Repository:The button lets you publish a ticket to incorporate the changes made in the ticket to the database. Note that only closed ticket can be published to repository.
2.7.2.2.4. Publish History:This button lets you view the publish history log files. Change log for the published ticket are displayed.
2.7.2.2.5. Ticket History:This button lets you view the complete history of the ticket in a read-only format. The various status of the ticket along with the user name of the user who modified the ticket is displayed. The date of modification is also displayed.
2.7.2.2.6. View Notes:This button lets you view the complete history of the ticket in a read-only format. The various status of the ticket along with the user name of the user who modified the ticket is displayed. The date of modification is also displayed.
2.7.2.3. Change Status:This menu is used to change the status of the ticket. Tickets can have statuses such as Assign To, Approve, Discard and Complete. Status of ticket can be change only in ticket workspace. Tickets with status of close cannot be changed.
2.7.2.4. Close Ticket:This menu item is used to close the ticket so that the changes made can be merged with the main workspace. User cannot close a ticket from main workspace; he needs to switch to ticket workspace to close a ticket. If an error is encountered during closing of the ticket then all the data published to the database are rolled back.
2.7.2.5. Export Current Ticket:This functionality allows saving a ticket in the ICM application as an XML file on your local machine. Only closed tickets can be exported from the ICM application.
2.7.2.6. Import Ticket:This functionality allows importing ticket in the ICM from the local machine. Only XML files can be imported to the ICM. After import new ticket would be created in ICM.
2.7.2.7. Main Workspace:Objective of this functionality is to allow user to directly go from ticket workspace to main workspace.
2.7.2.8. Concurrent Ticket:Concurrent ticket allows opening of more than one ticket simultaneously for users to work on their changes. Every change made against a ticket is saved in corresponding workspace, i.e. One Ticket => One Workspace. If same changes are made on different tickets on the same time then application prompts the user to either merge or override the changes when closing the ticket.
2.8. MANAGE TAGS:
In ICM, the process of transferring data from one environment to another involves transferring of entities. This is a lengthy process as the developer has to make a list of tickets containing the entities that needed to be transferred. Tagging simplifies this process by promoting the entities directly from the ticket. You can tag an entity and directly export the tag in the new environment to replicate the entity data in the new environment. There are two types of tagging:
2.8.1. Node Level Tagging:This level of tagging always refers to the latest version of the entity. When you export an entity having a node level tag it directly exports the latest version of the entity present in the database.
2.8.2. Version Level Tagging:This level of tagging always refers to the version tag of the entity while exporting data.
2.9. MANAGE PRODUCTS:
This menu lets you create a product using ISO and NON-ISO templates.
2.9.1. ISO Product:ISO (Insurance Services Office) releases information as monthly or quarterly circulars for different states. These circulars are processed by ICM to generate a template for Property & Casualty (P&C) insurance product to be sold in the market by the insurer. These circular files which are in .XML format are uploaded in ICM to facilitate bulk processing. You can create a product using ISO files by:
2.9.1.1. Upload ISO Circular:The primary step in creating a new ISO based product is to upload the circular files in the ICM system. To upload the files you need to go to Manage ISO Content ‘ Upload ISO Circular. Here you get options to upload countrywide content, rating content, state specific rating content, algorithm content, and data structure content.
2.9.1.2. Process ISO Circular:This section lets you process the uploaded circular files in order to generate a template required for product creation. For processing the ISO circular go to Manage ISO Content ‘ Process ISO Circular. We need to select Line of Business and search to display existing circular files. Select checkboxes besides the required circular files. Click ‘Process’ to process the selected circular files.
2.9.1.3. Add/Modify Content in ISO Template:To Add/Modify the content, create a new ticket and navigate to ticket view. Click Product Template’ISO Templatesand click the desired Countrywide or State specific folder to display the Working Copy Details window. Navigate to and click Working copy to populate the folder structure. Select the checkboxes corresponding to the entities to be modified and click ‘Checkout’. Add the required information for the entity and click ‘Save’ to save the changes. Close the ticket and changes are automatically checked in.
2.9.1.4. Create Snapshot-ISO:A snapshot is a minor revision that is created on the template when entity changes as per the current business requirements are completed. The first draft of the template is known as a major revision and is always Revision 1.0 and subsequent revisions are minor revisions. For example, if major revision is 1.0 then minor revision will be 1.1, 1.2 and so on. To create a snapshot:
‘ Open New ticket
‘ Click the required product folder.
‘ Select the checkbox corresponding to the required revision to display the Working Window copy.
‘ Click working copy under revision to display various folders and entities.
‘ Select entities to be modified and click checkout.
‘ Make necessary changes and click ‘Save’.
‘ In main workspace, click the required product folder to display the Revision details window.
‘ Click ‘Create snapshot’, click ‘Yes’.
The required snapshot is created.
2.9.1.5. Create Product-ISO:You can create a new product using the template created by processing uploaded ISO circular files. Following are the steps for creating a new product:
‘ Click Manage Products’Create Product. The create product window is displayed; this window lets you search for the state using products and line of business as search parameters.
‘ Enter the search parameters and click ‘Search’ to display results.
‘ Enter details besides the State name for which the product is being created.
‘ Click ‘Create Product’. The system automatically creates a new ticket, processes the uploaded content in new ticket, merges the content into the main workspace, creates product and automatically closes the ticket.
2.9.2. NON-ISO Product:
This functionality lets you create a product in the ICM system manually. The following steps are involved in creating a product using Non ISO templates:
2.9.2.1. Create New Countrywide Template:In the Main Workspace, click Manage Products’Create Non ISO Template to display the Create a New Template window. Fill in all the relevant details and click ‘Create Template’. During the template creation process, a new ticket is automatically opened; template is created, a revision is created for the template, and the ticket is automatically closed.
2.9.2.2. Create New State specific Template:Creating State specific template also has same procedure as creating countrywide template.
2.9.2.3. Add/Modify content in the Template:To add or modify content in the template, you have to navigate to the main workspace, create a ticket and check out the entities to be modified. You can check out all the entities in the template or select the entities to be modified. Once the desired changes are incorporated, the ticket is required to be closed. System then automatically checks in the entities that were checked out in the ticket into the corresponding revision’s working copy.
2.9.2.4. Create Snapshot:A snapshot (minor revision) is created on the template when entity changes as per the current business requirements are completed. You can create snapshot directly from the main workspace. In main workspace, click Product Templates’Non ISO Templates. Navigate to the required Countrywide or State specific folder to display the Working Copy Details window. Select the required Revision and click Create Snapshot. Click ‘Yes’ for confirmation.
2.9.2.5. Create Product:You can create a new product using the countrywide and state specific template. The product can be created based on the major revision (working copy) or the minor revision. Click Manage Product’Create ISO Product. The Create Product window is displayed. Select the Line of Business and the Product Name and click Search to display the results. Enter the details. Select the Revisions based on which the product will be created. Click Create Product to create the product successfully.
2.9.3. Manage Product Screen Functions:
2.9.3.1. Copy Template:This functionality lets you prepare a new country wide or state specific template by copying an existing ISO or Non ISO template. You can create the new template based on the revision of an existing template. All the configurations of an existing template are copied over to the new template. Click Manage Products > Create Non ISO Template to display the Create a New Template window. To create a template by copying an existing template, select the Copy Template check box.
2.9.3.2. Import Template:This functionality lets you import a template into the ICM system. The template file to be imported should be an XML file. Click Manage Products->Import Templateto display the Upload Revision Data window.
2.9.3.3. Export Template:This functionality lets you export a template (working copy or the minor revision). You can select the revision and the working copy and then export the file. The file is saved as a XML file. You have options to either export complete data or to export incremental data. You can also export selective data, wherein you can select entities that you want to export.
2.9.3.4. Import Product:This functionality lets you import a product into the ICM system. The product file to be imported should be an XML file. Click Manage Products’Import Productto display the Upload Revision Data window.
2.9.3.5. Publish Lookup:Publish Lookup functionality lets you republish the lookups to the new database location. You can republish all the lookups or select the required lookup to be republished. Click Manage Products’Publish Lookup to display the Publish Lookup window.
2.9.3.6. Delete Product:This button lets you delete a selected product revision. You can only delete a product from the main workspace. ClickProduct Definitionsand navigate to the required product. The Product Details window is displayed. Select the required Product Revision to be deleted and clickActions >Delete Product.The delete confirmation window is displayed. ClickYesto delete the product successfully for clickNoto cancel.
2.9.3.7. Generate Product Definition:This functionality lets you directly generate an XML of the product definition based on the product revisions. Previously, we had to first create a product from the snapshot, then create its revision, and then generate the product definitions. This reduces the effort in creating new products and revisions regularly and lets you create a product definition directly. Click Manage Products-> Generate Product Definitions. Select the check box corresponding to the revisions and click Generate to generate the definitions successfully.
3. MAJESCO BILLING SYSTEM:
Majesco Billing is a part of Majesco’s insurance suite of software for property, casualty & general insurance that includes policy, billing, claims, rating and distribution management. The software can be deployed on-premise, in a hosted model or in the cloud as a stand-alone solution or as a part of the suite. Following are the functionalities provided in Majesco Billing system:
3.2. ENTITIES TYPE:
There are three different types of entities:
3.2.1. Account:For a single user having different policies, those all policies are clubbed together in a single account for ease of transactions.
3.2.2. Insured:This is an entity which represents a single person who is insured.
3.2.3. Agency:In this entity we deal with an agent who represents many insureds and does tasks such as collecting premiums from the insured and remitting it in company account.
These different entities help in making transactions easier and more convenient.
3.3. BILLING TYPE:
There are two types of billing supported by the billing system:
3.3.1. Direct Billing:
In this type of billing invoices are generally sent to insured, system also allows sending bills to alternate billing party or mortgage. Invoices are for gross premium (receivables). There are two types in direct billing:
3.3.1.1. Single Policy Billing: In this type, the invoices are sent for every term of the policy. The invoice is usually sent to insured. Invoices can also be sent to alternate billing party or mortgage
3.3.1.2. Account Billing:In this type, an account is created for one or more insured. There are one or more policies associated with the account and invoice is sent per account. The account invoice lists all the receivables (receivables that are current and or past due) for the all the policies under the account.
3.3.2. Agency Billing:
In this type of billing, Agent collects the money from the insured and remits it to the company after retaining the commission. Agency billing is further divided in three categories:
3.3.2.1. Wholesale Billing:An invoice is generated and sent per policy term to the producer (insured). The invoices are inclusive of commission.
3.3.2.2. Statement Billing:A statement of account is sent once in a month to the producer for all the transactions booked in the prior month. Billing is inclusive of commission as well.
3.3.2.3. Account Current Booking:In this type of billing an Agent sends a statement depicting the transactions booked by him in previous month. The statement is called as a promise to pay.
3.4. POLICY TYPE:
Billing system allows categorizing policies in following two types:
3.4.1. Auditable Policies:These are the types of policies where the premium is not calculated at the start, but the actual premium is calculated when policy is cancelled or expired. The process of calculating the premium at the end is called as audit processing. The premium paid at the start of policy is called as estimated premium.
3.4.2. Non-Auditable Policies:These are the policies where premium is calculated at the beginning and the premium charged is actual premium. System does not allow processing an audit on these types of policies.
3.5. PRODUCT:
Billing system caters to all lines of business and products, List of products that is reflected in the system can be defined in List Of Values (LOV) table ‘PRODUCT_CODE’. System also allows for setting up of various business rules by defining them in the system. System does not allow issuance of the product which is not defined in the LOV table ‘PRODUCT_CODE’.
3.6. TRANSACTIONS:
There are various transactions defined which are applicable on a particular policy, all such transactions are defined in LOV table ‘TRANSACTION_TYPE’. List of valid receivable types associated with a transaction type is defined using LOV master table ‘TRANSACTION_RECEIVABLE_MAPPING’. Various transactions types applicable are given as below.
3.6.1. Binder (BIN)/ New Business (NEW)/ Renewal (REN):A Binder is a legal agreement issued by either an agent or an insurer to provide temporary evidence of insurance until a policy can be issued. Binders should contain definite time limits, should be in writing, and should clearly designate the insurer with which the risk is bound. ForNew Business, system validates if there is any overlapping term existing for the same policy. If there already exists an overlapping term which is in force (not backed out) then system rejects the transaction. If a New Business transaction is interfaced for a policy with different effective date, system creates a new term provided the prior new business transaction is backed out. System supports policies to be renewed with a different policy no. The system captures the policy no of previous term and links the two terms.In these types of transactions, system does following processing:
o Validations Check
o Entities Registration: Once validations are cleared, system first registers the entities such as insured, additional insureds associated with the policies in the entity address master.
o Generates Installment and Schedules Invoices: RBS establishes the instalment schedule based on payment plan, effective date, transaction date.
o Generates Installments Schedule (Parameter Based): System generates the output for instalment schedule upon processing ‘New Business / Renewal’. The generation of ‘Instalment Schedule’ is controlled by a parameter in business rule master called ‘Instalment Schedule Print Y/N’. The possible values are Yes/ No.
o Rounds Installments to 2 Decimals: The rounding off is based on the parameter ‘Rounding method’ which are:
‘ C = Ceil
‘ F = Floor
‘ N = No Action
o Calculates Invoice Send Date / Due Date:
o Automatically allocate cash in Suspense: While processing Binder/ New Business/ Renewal transaction, the billing system checks for any suspended/ unapplied check for the policy/ account being processed. If it finds then check is applied to the policy. The ‘cash application rules’ are followed while doing this.
o Generates Welcome Letter (Parameter Based): System also has an ability to send a ‘Welcome Letter’ on booking of New Business / Renewal transaction. This is controlled by a parameter in business rule master called ‘Welcome Letter Required’. The possible values are ‘Yes/ No”. The Welcome letter can be sent at Policy or Account depending on the value set in the parameter ‘Welcome Letter Level’. ‘The possible values are Account/Policy’.
o Non- Premium Receivables spreading: Non premium, receivables will be spread either, ‘Entirely on first invoice’ or ‘Spread across the invoices’ based on the spreading rule mentioned in the Receivable Master table against specified receivable type.
3.6.2. Back-out (NEWO/RENO/BINO/):Back-out is usually processed to correct errors. System internally processes binder back-out transaction when a new business/ renewal transaction having same policy number is interfaced, irrespective of account no, agency code, bill type and effective date, if ‘Auto back-out current term’ parameter is set to ‘Y’. Binders are backed out on the open accounting month set in the system. Back-out followed by New Business/ Renewal is used to cancel and rewrite/reissue policy. New Business/Renewal back-outs are booked on the accounting month received through premium interface.
3.6.3. Monetary Endorsements (EDR):Changes made to policy which result in changes in premium are termed as Monetary endorsements. There are 5 spreading options on monetary endorsements:
o I: Bill the full premium immediately (off cycle).
o F: Bill the full premium on the next instalment/ monthly billing cycle.
o S: Spread equally on all remaining unbilled premiums.
o C: Calculate the catch-up amount as per the payment plan and the endorsement effective date and bill the balance amount immediately.
o M: This option is same as C except the balance amount is billed on the next monthly cycle.
There are two types of monetary endorsement processing:
o AP Processing: In case of AP processing an off-cycle invoice is generated and sent next day. This type of processing is applicable on Single/ Account/ Wholesale billed policy. This does not support agency billed policy.
o RP Processing: In this type of endorsement the adjustments are not processed immediately, credit from the endorsement is applied to open receivable during invoice processing and is billed in the next instalment/ monthly billing cycle. This processing is not applicable on agency billing.
3.6.4. Non-Monetary Endorsements (NEDR):Changes in policy that does not result in monetary impact are termed as Non-Monetary endorsements. All data elements as in New Business / Renewal with required changes need to be passed, except there is no premium associated with it. The processing is same for single billed, account billed, agency billed and wholesale brokerage policies.
3.6.5. Payment Plan Endorsements (PEDR):This can be part of Monetary or Non-monetary. When monetary or non-monetary endorsement is interfaced system checks ‘PROCESS_PAY_PLAN_ENDORSEMENT’ flag, if it is ‘Y’ the payment plan on the policy is changed and if it is ‘N’ then system retains the payment plan sent during new business/ renewal transaction. If the endorsement transaction is done directly into the system and of the user changes payment plan, then system processes payment plan endorsement. As Payment plan endorsement is applied the system performs following operations:
o Void previous instalment schedule and transactions booked on the policy.
o Generates new instalment schedule based on the changed payment plan.
o Re-apply all the previous endorsements.
3.6.6. Agency Endorsements:Agency endorsements are for agency billed policies. They are of 2 types:
o Monetary Endorsements:
o Non-Monetary Endorsements:
This endorsements have impact on outputs, commission processing and inquiry screen.
3.6.7. Cancellation(CAN):If sufficient payment is not received before the cancellation effective date + Cancellation grace days then system sends a request of cancellation to PAS (policy admin system). A request for cancellation is generated if payment is not within tolerance; the tolerance amount is calculated based on business rule and notice amount. When request is sent the status of policy is changed to request of cancellation.
System accepts a cancellation transaction from PAS in premium feed. System allows configuring the billing after cancellation (B/D), to determine the billing option for amount due, (B ‘ Bill immediately and D ‘ Bill delay till next monthly cycle). For different policies there are different calculations involved for calculating mailing date, due date and cancel date.
3.6.7.1. Single Billed Policies:If Bill option after cancellation is set to ‘B’ then invoice is billed immediately and due date for this invoice will be invoice mail date + bill lead time OR due date of last billed invoice, whichever is greater. If Bill option after cancellation is ‘D’ then invoice is mailed on next monthly cycle and due date on this invoice will be invoice mail date + bill lead time OR the due date of last invoiced bill, whichever is greater.
3.6.7.2. Wholesale Billed Policies:In these types of policies invoice will be mailed immediately i.e. on the day cancellation is processed in the system. The due date for this invoice will be cancellation transaction date in PAS + No of days setup in parameter master OR transaction process date in system + Minimum invoice mail days whichever is later.
3.6.7.3. Account Billed Policies:For account billing even if one or more policies are cancelled, billing for remaining policies on the account continues. When all the policies of the account are cancelled then system sends earned premium invoice and starts earned premium processing.
When cancellation transaction is received system voids all the unbilled instalments and the difference between cancellation premium and total amount of unbilled instalments is billed based on the business rule ‘Billing option after cancellation’.
Cancellation Outputs: After cancellation, system sends out confirmation of cancellation. There are 2 types of cancellation confirmation.
o Confirmation of cancellation Debit (generated when the balance on the policy is a debit or zero).
o Confirmation of cancellation Credit (generated when the balance on the policy is a credit).
3.6.8. Rescission:Rescission processing is done for the policies which are under notice, due to ‘Non-payment of premium’. Policies are rescinded if one or more of the following transactions are processed:
‘ Payment applied.
‘ Write off reducing the past due receivable
‘ Adjustment reducing the past due receivable
‘ Credit from RP endorsement is applied against the past due balance
Rescission can be two types:
3.6.8.1. Automatic Rescission:In this type of rescission policy is rescinded automatically based on the business rules defined. System uses ‘Consider for rescission’ parameter stored against the receivable to determine if the receivable should be taken into account while rescinding the policy.
3.6.8.2. Manual Rescission: Policies can also be rescinded manually; this can be accomplished from cancellation preview screen.
3.6.9. Reinstatement (REIN):System allows reinstatement transaction only if the policy is cancelled. After reinstatement status of the policy is changed to ‘In Force’. System allows reinstatement with lapse in coverage based on the business rule ‘Reinstatement with Lapse’ (Y/N). If value is ‘N’ then reinstatement amount should be equal to cancellation amount and reinstatement effective date should be equal to cancellation effective date. If value is ‘Y’ then reinstatement amount should not exceed cancellation amount.
After reinstatement system generates invoice based in the rule ‘Bill after Reinstatement Option’ (B – Bill Immediately/D ‘ Bill delay till next monthly cycle).
3.7. Underwriting & Operating Companies:
Policies written within operating company can be written by any underwriting company. System does not enforce a relationship between operating company and underwriting companies. System can run in multi-operating company and multi-underwriting company mode.
3.7.1. Underwriting Company:System captures the underwriting company on the policies through premium feed. Valid underwriting companies are stored in LOV Master under table ‘UNDERWRITING_COMPANY’. System allows configuring various business rules by underwriting company. System allows associating only one underwriting company per policy.
3.7.2. Operating Company:System supports multi operating company structure. System captures the operating company on a policy through premium feed. List of valid operating companies is stored in LOV master under table ‘OPERATING COMPANY’. System allows only one operating company per policy. System allows following setups by operating companies:
‘ Security Setup: User roles can be configured by operating company.
‘ General Ledger Setup: Chart of accounts can be configured at operating company level.
‘ Output forms master (matrix) and text messages: Mapping of output forms and events at which they are triggered can be configured at operating company level.
‘ Logos: System allows configuring different logos by operating companies. These logos can be printed on output forms.
3.8. Payment Plan:
Payment plans are used to setup payment schedule. Billing system handles wide variety of payment plans. There are various attributes which are needed to setup the payment plan master. Effective date for New Business/ Renewal is the date from which payment plan will be effective. Using payment plan effective date, different versions of payment plan can be created. Correct version for policy is selected based on the policy effective date.
3.8.1. Plan Code:Each payment plan is allocated a unique plan code to identify it.
3.8.2. Instalment Code:Any number of instalments can be defined in a given payment plan. Each instalment is numbered serially starting from 01. The instalment number for down payment is ’00’ and renewal down payment instalment number is ’99’.
3.8.3. Instalment Description:Instalments can be flagged as ‘down payment’ or ‘regular instalments’.
3.8.4. Instalment Percent:Instalment amount can be percentage of the premium receivable type.
3.8.5. Bill Due month/day:Instalment due dates are defined by two fields ‘ Month & Day. Month is number of months after the policy effective date this instalment is due. If the due date is required to always be on specific day of the month then Day field is filled in; otherwise instalment is due on the anniversary day of the policy. If Bill due month is not specified and only Day is specified then it is treated as number of days after policy effective date that the instalment is due.
3.8.6. Send before Days:If an invoice is to be sent, mailing date of the invoice can be filled in as a number of days prior to the due date.
3.8.7. Cancel after days:This parameter is used to determine when the notice of cancellation should be sent, if notice of cancellation is to be sent immediately then this parameter can be set to ‘0’.
3.8.8. Bill lead time:IN case of late billed policies, using Bill lead time parameter user can specify the number of days after send date which all bills will be due. This parameter is useful when bills are to be sent immediately.
3.8.9. Service Charge:It is the fixed amount charged as service fee on instalments.
3.9. Billing Cycles:
Billing system identifies following three types of billing cycle for the purpose of calculation of due date and also for establishing the instalment schedules.
3.9.1. Instalment Billing Cycle:This is normal payment plan associated with the payment plan on the policy.
3.9.2. Monthly Billing Cycle:This is the cycle for months outside of the instalment billing. Monthly cycle has the same due day as that of the instalment cycle but the due month is not as per payment plan.
3.9.3. Off Cycle Billing:An invoice is generated outside the instalment and monthly billing cycle.
3.10. Receivables:
Billing system allows defining various receivable types and accepting the same in premium feed. Receivables are further classified in receivable categories such as premium, dividend, fee, recovery, security and surcharge. The various attributes of each receivable will be defined in the receivable master.
Receivable master is used to create, modify and delete the receivable types. Billing system does not allow deleting receivable types that are already in use. Each receivable will have a unique code and description. Billing system supports following categories of receivables:
o Premium: Premiums for various coverages.
o Surcharge: Surcharges and taxes.
o Fee: Billing and other processing fees
o Recovery: Expense recovery.
o Security: Securities and escrow.
o Dividend: Dividend payable on a policy.
3.11. Policy Term:
Billing system can handle policies of various terms. It captures policy effective dates and expiry dates. System allows extension of the term through an endorsement, but reduction of policy term is not allowed. System does not associate payment plans with policy term i.e. it does not validate which payment plan is valid for which term.
4. SOFTWARE TESTING:
4.2. SDLC Process:
Software Development Lifecycle (SDLC) is process followed while developing software. SDLC provides a sequence of activities and processes to software developers and designers to follow. Basic flow of SDLC is given below:
Software Development Lifecycle
The different phases of SDLC are as given below:
4.2.1. Requirements:This stage is where the team interacts with clients and understands the requirements. They also do a feasibility study and analyse which requirements are feasible and which are not. Through this process the client and vendor arrive on a common ground as to the requirements and what will be the end product. At the end of this phase team gets signoff on the requirements and requirements are freezed.
4.2.2. Design:Based on user requirements and the detailed analysis. In this phase we move from ‘what’ to ‘how’. The logical design produced during the requirements phase is converted into a physical design. We get a detailed description of how we are going to solve the problem and inputs, outputs, databases, forms etc. are defined and designed.
4.2.3. Development:The ‘how’ part defined in design phase is actually implemented in development phase as a workable system. This is also called as Programming phase in which programmers convert system specifications in to computer instructions, which are called as programs. Programming tools like compilers, interpreters and computer languages are used.
4.2.4. Testing:In this phase the system which is developed is put to test to check whether it is functioning in desired manner. Any system which is designed will always have bugs, it is the job of testers to find out the bugs and reporting them; so that they can be rectified before system goes live i.e. it is implemented. Objective of this stage should not be to prove absence of bugs but rather to find as many bugs as possible.
4.2.5. Maintenance/ Deployment:After the system is tested sufficiently and it is accepted that the system works according to the requirements specified in the requirements stage, the system goes live or is deployed. The client starts using the system. The task of vendor is still not finished, they have to give support to the users, i.e. whenever user encounters any problem in using the system it is the task of support team to solve those problems.
Here we can see that software testing is an important function in overall software development as software bugs can potentially cause monetary and human loss, history is full of such losses. Below we can see various examples of disasters which occurred because the system was not properly and thoroughly tested:
‘ China Airline’s Airbus A300 crashing due to a software bug on April 26, 1994 killing 264 innocent lives.
‘ In 1985, Canada’s Therac-25 radiation therapy machine malfunctioned due to software bug and delivered lethal radiation doses to patients, leaving 3 people dead and critically injuring 3 others.
‘ In April of 1999, a software bug caused the failure of a $1.2 billion military satellite launch, the costliest accident in history.
‘ In May of 1996, a software bug caused the bank accounts of 823 customers of a major U.S. bank to be credited with 920 million US dollars.
‘ As you can see that testing is important because software bugs could be expensive and dangerous too.
4.3. OBJECTIVE OF SOFTWARE TESTING:
Software testing can have various objectives and purposes but major objectives are given below:
‘ Finding defects which may get created by the programmer while developing the software.
‘ Gaining confidence in and providing information about the level of quality.
‘ To prevent defects.
‘ To make sure that the end result meets the business and user requirements.
‘ To ensure that it satisfies the BRS that is Business Requirement Specification and SRS that is System Requirement Specifications.
‘ To gain the confidence of the customers by providing them a quality product.
Software helps in finalizing the system developed against the business and user requirements. The test cases developed should be such that they cover maximum possibilities of finding errors or bugs. Testers should test the system in s way end users use the system. The purpose of testers should be that the system once delivered to the end users, they should be able to operate it without any complaints. Various things which testers check are various areas like functionality of the application, compatibility of the application with the OS, hardware and different types of browsers, performance testing to test the performance of the application and load testing to make sure that the system is reliable and should not crash or there should not be any blocking issues.
4.4. TESTING TECHNIQUES:
There are 2 techniques to software testing:
4.4.1. Static Testing Technique:Static testing is the testing of software and related work manually or through tools, but the software is not executed/ run. This type of testing starts early in software development lifecycle. Most static testing techniques are used to test any type of document including source code, design documents and models, functional and requirements specifications.
4.4.2. Dynamic Testing Technique:Dynamic testing includes actually executing/ running the developed software. Example of dynamic testing is unit testing, integration testing, system testing.
Software Testing Techniques
4.5. ISSUES WITH STANDARD SOFTWARE TESTING PRACTICE:
From the above SDLC model we can see that testing team gets involved in the process of software development at the end of the process when most of the development is already done. By taking this kind of approach we are increasing cost of fixing a defect, because cost of fixing a defect increases across the development lifecycle. The earlier in lifecycle a defect is detected, the cheaper it is to fix. Assessment of several projects has shown that defects introduced during requirements and design phase make up close to half of total number of defects.
Snowballing effect of software bugs
From above illustration we can see that the bugs which are introduced in early phases of software development and go undetected tend to cost more in fixing them.
4.6. IMPROVEMENT IN TESTING PROCESS:
This issue of escalating bugs can be handled by taking test team on board from the very start of the project. This technique of involving test team from the start is known as V-model of software development or Testing Driven Development method.
In V-model of development, corresponding testing phase of the testing phase is planned in parallel. So there is verification phase on one side of V and validation phase on other side. Coding phase joins two sides.
We will see each phase in detail:
4.6.1. Verification Phase:
Verification phase consists of following parts:
4.6.1.1. Business Requirement Analysis:In this phase product requirements are analyzed from client’s perspective.
4.6.1.2. System Design:System design phase contains understanding and detailing complete hardware and communication setup for the product under development.
4.6.1.3. Architectural Design:Architectural specifications are understood and designed in this phase. An approach is proposed to develop the product and based on technical and financial feasibility final decision is taken. The data transfer and communication between the internal modules and outside world is clearly understood.
4.6.1.4. Module Design:In this phase detailed internal design for all the system modules is specified.
4.6.2. Coding Phase:The actual coding of system modules designed in designing phase is taken up in coding phase.
4.6.3. Validation Phase:
Following are the validation phases in V-model:
4.6.3.1. Unit Testing:Unit testing is the testing at code level and helps eliminate bugs at an early stage.
4.6.3.2. Integration Testing:Integration testing is associated with the architectural design phase. Integration tests are done to test the coexistence and communication of internal modules within the system.
4.6.3.3. System Testing:System tests check the entire system functionality and communication of the system under development with external systems.
4.6.3.4. Acceptance Testing:Acceptance testing involves testing the product in user environment. This testing uncovers compatibility issues with other systems available in the user environment.
V-Model of Software Development
4.7. TESTING PROCESS FOLLOWED BY THE TEAM:
The testing process followed by the team is as follows:
‘ Business/Client faces some problem while operating/using the product.
‘ Development team/ BA team from Majesco analyses the problem/defect.
‘ If there are any operating lapses from business side then BA team explains them the correct way/procedure and cancels the defect.
‘ If it is a genuine issue then the BA team analyses the requirement document and decides whether the issue is a defect or enhancement or a change request.
‘ Based on the classification of the defect BA team prepares an IRD, which is given to business for sign-off.
‘ After sign-off document is shared with both development team and testing team.
‘ Development team works on the issue and in the meantime testing team analyses the requirements and prepares the test scenarios and test cases.
‘ Once the development team is ready with the solution, testing team runs the test cases and if cleared gives sign off.
4.8. IMPROVEMENTS TO CURRENT PROCESS:
Following things can be implemented for improving the testing process:
‘ In the current process we can see that testing team is getting involved in the process at the end of development cycle. The team is mostly following waterfall model, but as a part of Agile initiative we should be moving to a more involved testing team.
‘ We should have a test lead from the testing team involved in the process from the time IRD is received and should work simultaneously with development team and follow the test driven development model.
‘ Before the team starts working on development process the testers should come up with test cases and test scenarios. Testing team should share these scenarios and cases with development team and BA team and get a signoff from them. This will help developers in understanding what their code is meant to do. It will also remove any ambiguity in requirements.
‘ A representative from clients’ side should also be involved in all these processes. He can be involved through daily status calls and status reports. This keeps customer in the loop and more satisfied because he can view daily progress. Also if there is some change then it can be pointed out during the process and there would not be any duplication of efforts.
‘ Having testing manager would improve working of the testing team. He is someone who controls macro aspects of the project.