Projects:NewCombos/QA-Test Plan

Test Plan

This project affects all the windows across the application, in this areas:

• FormInitilizationComponent (FIC)
  • New record
  • Edit existent record
  • Modify a field that triggers callouts/validations
  • While in edition navigation to another tab and coming back to the previous one
• Before the project, all available values for all drop down lists were calculated and sent to the browser, now only one value (default or current one) is initially calculated. Now, opening the drop down list (by clicking down arrow or by typing a filter criteria) triggers a request to retrieve data

As this is something that changes the implementation but keeps the functionality as it was, existent automated tests cover most of the cases.

In addition, some specific tests to be executed manually focusing on these changes have been written in TestLink, they can be found in 3.0 Test Suite > Platform > combos refactor.

Performance

The whole project goal is to improve performance for the FIC cases described above.

After the project, FIC scales much better because its response size is kept stable regardless DB size. In some cases before the project creating or editing a record might simply not work or be really slow (several seconds) and after it, it performs nicely.

Two batteries of performance tests have been executed, results of them can be seen in this sheet, note all of these measures are taken in server side, user experience improvement is expected to be better because it also improves network bandwidth by reducing response size as well as browser computation as it requires to parse much less information:

• jMeter test that simulates a FIC request equivalent to the one triggered from UI to create a new record. This test case has been included in the automated tests that are nightly executed. It is executed on a clean database with sample data (no volumes). The improvement in this case is noticeable from the response size (reduced an average of 72%) and in terms of time spent to generate it is slightly better (~2%)
• Manual execution on an instance with real data where some problems were previously detected (even the DB size was just moderately big). Here is where the biggest benefit can be seen, for example a request that before generated 5.1MB of data, now it has been reduced to 1.3KB being computed now in 54ms what before took 2.7s.