LISA – No Code Testing Tool

Hello Friend! If you are reading this blog that means you are already aware of the testing tool iTKO LISA. You may have heard many times that it is considered to be a no-code testing tool. I would like to share case-study which will prove that really LISA is a no-code tool.

Overview
The project was developed for a major US insurance company. It is in the process of re-architecting its complex insurance policy system to meet broader insurance market needs, by replacing many legacy data transfer and business process technologies with an ESB and SOA-based architecture, the firm is implementing systems that can flexibly scale and deliver new functionality faster to meet the needs of a larger insurance marketplace.

The Challenge
Policy Administration is the heart and soul of any insurance company. Due to the vast complexity of the system and the agile development cycles it was very difficult for the QC team to perform testing. Whenever any changes are implemented the test team had to perform smoke test before starting with the functional and regression cycles. Smoke test used to take couple of day to complete as different downstream were involved and the QC team has to validate the processed policies. Few policies were identified for the smoke test and were processed. All the processed policies were zip in a folder which used to have CCYYDDMMHHMMSS.policy.zip naming convention. The QC had to indentify the zip folder which was processed in a particular run and validate all the policies are available. Once the policies are processed a copy of the policy.zip folder used to be maintained at the archive location. The QC had to copy the folder from archive location to the local landing zone which was part of the identified frame work and extract the policy files and confirm all the policies are processed successfully. Match each policy file is available in the processed .zip folder from the archive location with the policies they have processed, execute SQL queries to perform audit database validation which involved more than 50 validations such as status log, verify the column values as per business rules, processed dates. The status log can have Error or duplicate as the status of the file if it was reprocessed or some error occurred while processing the policy files. If the status is error the detailed description of the error had to be captured which can be shared to the development team. If the status is duplicate, the previous date of the policy when it was processed had to be captured. If the policies are processed successfully the details of the downstream for the policy had to be captured. This had to be done for each and every policy which was processed and for every release. It took QC team more than 2 days to complete the smoke test and later start with the actual testing, so there was a requirement to automate this process so as to reduce the duration of smoke test so that the QC team can utilize the time to concentrate on function and regression test.

The Solution
iTKO LISA product suite offered the broad ability to test, validate most complex elements and as the tool was identified for functional and regression testing, a script was created for smoke testing. Different DOS commands were used to capture the .zip folder name, copy the folder to local system, extract the file and compare the files with the files from archive location. Different available filters and assertions were used to perform this. JDBC steps were been used to perform Audit database validation. A user customized report was generated in .CSV which used to provide the required details for each processed policy.

The Result
With the help of the scripts QC team was able to perform smoke test in less than one hour for each and every policy with customized report which would provide the required details which can help the development team to identify the issues and work on them and reduce the release cycles. QC team was able to perform the smoke test and was able to concentrate on functional and regression tests. The script was used for each release to perform smoke test. The scripts were created using all the default features available in the tool and not a single line of java scripting was used.