When you ask a successful person what life experiences shaped them into becoming successful, without hesitation they will answer what stretched and grew them the most wasn’t their wins, but instead their failures.
Curious, isn’t it?
Our failures have a way of molding us into the higher performing and higher achieving individuals we always wanted to become, much more so than with our successes.
Which is why when we asked our incredible IV&V team (who has received an Exceptional rating by our VA client for their work – which is the highest rating that can be provided) what makes their team so successful, it wasn’t completely shocking to hear that their success has been birthed through constant improvements on what didn’t work very well in the past, instead of what did.
From these improvements, our IV&V team has put together 4 lessons learned for how to have a successful IV&V release.
When it comes to testing, regardless of if you have a great team, certain aspects of IV&V could not be performed effectively if the below objectives were overlooked.
For more information on IV&V Testing click here.
The Sprint Planning Session phase of IV&V testing is instrumental for the sprint’s success. For every new testing release, our IV&V team receives the development team’s scope (which list’s the number of items), however we always do our own Sprint Planning Session internally where we identify our own testing scope.
Based on the given acceptance criteria, the test cases are created to ensure that it meets the requirement.
Taking the time to do this is crucial to our success because by identifying our scope, we enable our team’s subject matter experts (SME’s) to help us if we have any questions to the acceptance criteria and with the functionality.
Which leads us to lessons learned #2...
Identifying your bandwidth is the most crucial aspect to a successful release!
The reason for this is because even if you have a great team, testing may not go effectively if you’ve added scope that is outside your bandwidth.
For example, the development team may have a set amount of items that need to be tested, but the IV&V team may not have the bandwidth to cover all the items for that particular release. When this happens, it is crucial we have our own IV&V Sprint Planning Session (Lesson Learned #1) where we analyze all the items and identify our own testing scope to prioritize what items we should take based on our bandwidth.
We do this because from past experience we’ve seen what it does to our team when we take on a larger load than we have the capacity to carry. Our team becomes exhausted, their attention span limited, and they began to lose their ability to focus. Yet, despite these feelings of exhaustion, we still have to deliver IV&V testing because that is what is expected from our team.
It's from past experience that our team has learned to be very, very careful when it comes to defining our scope.
This is why the Sprint Planning Session is very important. You need to properly define your scope based on your team’s velocity & capacity to ensure that what we are assigned can be accomplished.
Before the testing phase begins, it's important to conduct a test readiness review meeting with the IV&V team, product owners, development team, and key stakeholders.
During this review the IV&V team will confirm that the environment is ready to test, the code has been deployed, and any outstanding action items have been completed before beginning testing.
If our team begins testing before the testing environment is ready, the accuracy of our testing results could be thwarted rendering our testing efforts unusable.
Lastly, for a successful IV&V release, we always want to test beyond the testing requirements.
Most development teams do some testing in-house, but usually they do basic-level testing leaving aspects of the software untested. IV&V provides that additional layer of testing where we identify issues and find solutions that were not previously caught by the development team.
This is where our team’s IV&V testing truly succeeds. We go beyond the requirements creating our own test cases and scenarios. For example, if the acceptance criteria says the software should throw an error if XYZ happens, instead of covering only that exact test scenario, we want to confirm if the software will still work as expected if something similar, yet is slightly different, happens in respect to that test scenario.
By creating our own test cases based on the acceptance criteria we receive, we test more than what was initially required to make sure we are not only covering the scope but going BEYOND the scope to ensure a only a quality product goes into production.
By: Anisha Shah (SQA Test Lead at InnoVet Health)
About Us:
InnoVet Health is an IT consultant company specializing in AI and business intelligence, digital services, and health interoperability founded by MIT-alumni & informatics experts. Learn more about us on our website or reach out on LinkedIn.
Driving modernization and improving healthcare for our nation's Veterans.