[00:00:01] Speaker A: System testing and making the go/no-go decision.
Hello. Thank you for joining us. This is What Counts. A podcast created by Trailblazer Consulting. Here we highlight proven solutions developed through our experience working with companies across various industries. And we talk about how you can apply these solutions to your company. We share our experience solving information management challenges like creating and implementing a records retention schedule, creating an asset data hierarchy for helping with email management. This is Lee, and in this episode, Maura and I will talk about a couple different levels of testing and making that ultimate go/no-go decision.
Maura, what are these different levels of testing?
[00:00:44] Speaker B: I'm so glad you asked, Lee. Or as my younger sister would say, thank you for asking.
Hi everyone. So, testing.
You want to believe that when you setting up a new system, everything's just going to work, but reality sets in and you know that something's going to go wrong. And in the case of contract management solutions, we've talked about a number of different things. Data migration, document migration, changing your processes from your current state to a more streamlined future state that takes advantage of technology.
So there are a lot of pieces we haven't talked about. Whether your contract management system is going to just stand alone, or if you're going to try and integrate it with, say, your financial system for payments, or with some customer relationship management system to manage your counterparties. We haven't talked about those things in depth, but each one of those pieces introduces a need for testing. So let's start with the system piece.
First thing is you're going to configure this system, and then you're going to test each piece of it and make sure that it works as you expected, as you designed it. And then when you do the configuration, does that configuration really match your idea in the design, or do you need to change something? One level of testing, does that mean.
[00:02:05] Speaker A: In your environment too, or am I getting ahead of myself?
[00:02:09] Speaker B: It does mean in your environment too. I guess that's the first level, actually. Good point. Does it even work? Like, are you a Linux shop and you went and bought an AWS system? People probably have made that decision before they picked the system, but it's still a good idea because you might have firewall issues or you might have some server compatibility problems or bandwidth issues or something. So test number one is, can you even get the thing to turn on? Yeah, I see you laughing, but it's true.
Test number two is maybe also related to that environment. Question, how are you going to back this up? And what kind of backups are you doing? Are they in the cloud, are they on prem? Are they automatic? Are they just.
You may have bought a subscription service, software as a subscription, do you even have to worry about it? But these are all questions that you're going to answer before you start configuring. And you'll test each one of those pieces, security, fit and performance.
Okay, we've done that. Now we're going to design and configure and test each piece of the solution that we're configuring to make sure that your field names are the way you want them to work and what things are going to be required and what things might be conditional. So if you answer yes to this question, then you get three more choices that you have to pick one. Whereas if you answer no, that next level of choice doesn't come in. You've all seen that in any kind of form you fill out online these days. You can set those things up inside your solution too. So if, for instance, you are setting up a contract with someone that you are going to be paying through the course of this contract, then you kind of answer that question and then the next thing you do is say, okay, are we going to pay them through a check or through some sort of an electronic transfer? And if the answer is electronic transfer, then you can set your system up so that the user has to fill in a bank routing number and an account number so that you can do that transfer. So does your configuration match your design? Test each piece, then test it as a whole. Purely from a system perspective, do the buttons work? Do the fields work the way you want them to? If you are doing some integrations to other systems, like to your accounting system or to a customer relationship management system, then test those integrations.
Finally test all of that together again. At this point, it's only it involved and they're just making sure that all the connectors work the way that they're supposed to work.
At that point, you're ready to start talking to users about testing. You don't want to involve the user too soon. You don't want them to be part of the very early test, because when things break, they're going to throw their hands up in the air and say, I hate this system. So that's not what you want. Instead, wait until you've tested it.
[00:05:01] Speaker B: You, the it team, you've tested it, you're feeling good, like, okay, we made with fits in our environment, we've got the security worked out, the integrations are working, the configuration works as designed. Now bring the users in. You might want to start with a small group depends on how big a change you're looking at. But the users are going to be thinking about data and process, so you have to have. You've done your process changes. We talked about those in an earlier episode. We talked a little bit about the data and document migration that you might have to go through to get data into the system. So the users will recognize what's happening and they'll be able to say, oh, this didn't work like we expected it to. The calculations wrong, or these two pieces of data are not connected correctly. So you have to have enough data in your test system so that the users can make sense of it. You don't have to have all the data in the test system, but you have to have enough. So you want these tests to be scripted, where you've got the user's involvement in what are we going to test, what are the scenarios, what are the processes, what's the expected outcome, how do we expect the data to look or to change or a calculation to happen or report to come out so that then they can check off. Yes, I did these things and I got what I was expecting, or I did these things and it missed on these two points, and then you can go back and correct those things.
At the end of all of this testing and corrections, you have a final go/no-go question.
And I like to picture it as the Houston control Center in Apollo 13, where it's like, flight, go secure, go, doctor, go, or whatever. They go one by one and ask them all the questions. And I have sat in on many of those conversations when we were doing big system go decision making. And you go through the piece, does the data, is the data right? Are the documents there? Are the screens right? Do the integrations work? Does everything work as expected? Are the users ready from a process standpoint, from a training perspective, is the whole team ready, not just the three people who were involved in your testing? When you get to the end of.
[00:07:18] Speaker B: That and everyone says, go, then you're ready to go live and take it forward.
[00:07:26] Speaker A: That's the moment of truth, plain and simple.
[00:07:32] Speaker B: Yeah, it's a whole new world on day one.
[00:07:35] Speaker A: Satisfaction, and then you can move on to the next project.
[00:07:41] Speaker B: There you go.
That was a quick overview of testing. Obviously, there's a lot of detail in each one of those, but I think it's important to talk about the pieces because it's not enough to just do a system test. It's not enough to just have the users take a quick look and say, yeah, it's okay.
[00:08:00] Speaker A: You got to do more in depth and then the user test scripts has to be script out like you said and go through the check and then make all the updates. I mean, it's a big, long, lengthy.
[00:08:12] Speaker B: Process and it's worth the investment of your time and your resources because this contract management solution is going to hold the key to your revenue. These contracts are governing your revenue. They provide the terms and conditions under which you make money. So you want it to be right.
[00:08:31] Speaker A: Okay, let's go. If you have any questions, please send us an email at
[email protected] or look us up on the web at www.trailblazer.us.com. Thank you for listening and please tune in to our next episode. Also, if you like this episode, please be a champion. Share it with people in your social media network. As always, we appreciate you the listeners. Special thanks goes to Jason Blake who created our music.
[00:08:59] Speaker B: Thanks everyone.
