jeylabs

It is not uncommon for the scope of a project to change. This is typically due to inadequate qualification of the project requirements. Stats are that 70% of business app projects don’t get delivered as planned.

These changes can blow out the timeline, or force a ramp-up of effort to meet the ever-looming deadline.

Given the nature of the beast, re-testing of the previously completed work becomes a priority to ensure quality delivery.

In situations where deadlines cannot be moved to reflect the scope, we need to find any means possible to maximize output. This creates a need to ensure the app works with the changes made to reflect the amended scope. One of the projects we worked recently for a client had a change that created a lot of rework. This project was to replace an existing paper-based solution that was costly, inefficient and boringly repetitive and manual. Initially, the data sources for storage were agreed to be hosted in SharePoint. K2 SmartObjects exposed these data sources, allowing for data to be retrieved, manipulated and stored, using smart forms.

A decision was later made to move to SQL Server databases for storage of the data used throughout the system.

Extensive work had already been completed towards the original scope, meaning the data structure was present in the SharePoint environment. This means the SQL data structure was then developed to the new specification.

K2 Workflow and SmartForm user interfaces were already in existence as part of the project’s development activities. So in this situation do you repoint the SmartObjects that the existing workflow and user interface leverage to the new SQL data source? Or, do you build new SmartObjects to expose the new SQL data source, and recreate or modify the workflow and User interface to utilize them?

The obvious choice is to simply repoint the existing SmartObjects to the new data source so that we don’t need to redevelop the workflow and SmartForms.

But how can you be sure the SmartObjects work as they did before? Are the same methods available, do they receive the same input, and are there discrepancies in the output now?
We could simply retest everything and hope that the manual testing raises any bugs created. But manually testing takes time which as discussed, simply doesn’t exist.

Why not automate some regression tests? Creating tests that comprehensively validate our SmartObjects current composition, will ensure that the SharePoint storage and its portal into the outside world (the SmartObjects) are working effectively.

Once the migration has occurred to SQL, and the smartobjects have been reassigned, we could simply execute the regression tests and compare results. This will allow us to either confirm that the coast is clear and there are no bugs, or in the worst possible case, present the bugs to us on a silver platter.

PowerToolz is an all in one Testing Automation and Administration tool for K2. We used it successfully in this project to help us manage this change.

PowerToolz provides deep insights into your K2 applications, their composition, behaviour and environment. PowerToolz can be used to automatically validate the behaviour, performance, and interaction of your data sources within K2.

Why spend time testing when you can automate this process effectively? Check out http://PowerToolz.com.au