Realistic Testing of an ERP

Chris Kadavil: that's a good question. Um part of it is the experience that RigServ brings. So we've got real world experience with the actual process and how this happens in real life and we are able to translate that into use cases and stories that we can build into test cases. So you know, typically this is how it gets done. How does this process, you know, change versus what you plan, how you plan to do it And if that's the way that you want to do it, then what are the touch points and we build out a really tight use case scenario for that so that we get into the nuts and bolts of, you know, all the nuances of what can happen in that situation. So what are those those variables? What's the things that we didn't think of and through that discussion and engagement with the customer we're able to figure out. Okay, so there is a touch point here that we haven't thought of or this situation causes variance enough that we have to plan for something else. And as tight as you can plan that it's easy to build. It's much, it's much more important in my mind to um bring out a real world scenario and talk somebody through how this happens, how it's planned to happen and then to build it building parts, I think easier it's just built to spec and if you've ever seen iron man, it's sort of where that scene at the end where they're both up in space and it gets super cold and and Ironman asked how do you solve the freezing problem? And the other suit never knew that there was a freezing problem. It's just our experience that we've we've been there before, we've done that before and we know to look for that problem, you know, it's it's rarely perfect the very first time because there are and that's the reason that there's multiple types of tests. So there's um you know the test of, does it actually meet the functionality, Does it work as planned? But then there's does it meet performance testing? Does it meet the user experience testing? So you know, once we as part of the performance testing we flooded a scenario where we did 1000 entries a second. And just just to really hammer test the system and see if it would work. And um some processes started falling behind, which led us to have to scale up some of the services um and the environment to meet that at potential demand. So um you know when one one process runs a little bit longer than you expected to, there has there's trickle down effects of that. So so to prevent that we, you know, hammer the system as hard as we can beyond what we naturally expect just in case to plan for growth and then we build and scale to that