It is not uncommon for the scope of a project to change. This is due to inadequate qualification of the project requirements, unforeseen circumstances or even an unpredicted change in timeline, resources or budget.
These changes can blow out the timeline, or force a ramp up of effort to meet the ever looming deadline. 70% of business app projects fail for a resson.
Given the nature of the beast, this will make the re-development and re-testing of previously completed work a priority. This becomes a need to ensure the app works with the changes made to reflect the amended scope.
In situations where deadlines cannot be moved to reflect the scope, we need to find any means possible to maximise output. This ensures we don’t miss our family dinners, meeting these new requirements and delivering a win for our team.
Recently this occurred during a K2/SharePoint project we delivered for a local university in Melbourne. 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.
This project was to replace an existing paper based solution that was costly, inefficient and mundane.
A decision was made to move to SQL database 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 mean 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 re point 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 utilise 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