Sharing my experience working with a team building a software product in the IoT domain.
The product is being used in the Mechanical Industry domain that interacts with industrial machines. These machines can be programmed and their data can be accessed through this said product.
There was particular feedback from the users on the ground —> "To provide role-based access information based on who is logging into that system so that only one person should be able to perform write/update operations at a given time."
The stakeholders were frustrated as this requirement took 3.5x more time to complete than the estimation.
Below is the sequence of how this requirement was implemented:
STEP 1:
A USER STORY was created by the product owner with the expected BUSINESS OUTCOME as
“If a user is updating a particular machine through the product then any other user accessing the same machine should have a few specific restrictions in accessing the machine data”
⬇️
STEP 2:
The assigned developer and tester start working on the story
⬇️
STEP 3:
While analyzing and implementing the story, the developer realized 5 more different ways in which a said machine can be accessed depending upon the given state of the machine, business function and the data it hosted
⬇️
STEP 4:
The developer goes back to the product owner to get confirmation of the findings. The product owner apart from being surprised by the missing items then completes another iteration of the requirement generation
⬇️
STEP 5:
The updated requirement is now coded by the developer. The tester tests the same and all now seems GOOD
⬇️
STEP 6:
The requirement is now tested by UAT people who find out a few more gaps while testing out the same.
Now, again the process of requirement updates —> Dev coding —> Tester testing —> UAT testing had to be repeated till the requirement was eventually delivered.
ANALYSIS & ACTION POINTS:
During our analysis as to what went wrong, we identified a bunch of issues that can be corrected and could be done in a better way.
We identified critical issues that needed to be addressed FIRST in our effort to improve. This helped the team to get the QA process moving in the right direction. eg:
The QA tester had no clue about the missing gaps identified in step 3 and 4
A communication gap between Product Owners and UAT team
As the next steps, we identified the Critical Movers as a Plan of Action. eg:
A custom SOP for product owners for creating a requirement because the software product is used in a lot of different ways in a production shop than other B2B or B2C software applications
A custom SOP for test engineers on how to create test cases by breaking up the requirements, speaking with the UAT team etc
Since the UAT team's role is critical for software products in such domains hence introduced the UAT application feedback mechanism process as part of the QA framework
Delivering consistently good quality software product releases can be achieved through implementing a sound process that evolves and continuously improve through every iteration. The experience share
d in this article is just a few steps in this process...
I hope this adds value to you. Do share your feedback with me at prashant@PristineProtech.com; visit my website www.PristineProtech.com to engage further...