Okay, Now let's talk a little bit about the artifacts that are created as part of the testing process. So when we use this term artifacts, we're talking about the elements that are produced by the people involved in the testing process. So we have the strategy that plan the test case, the script, the sweet
harness. So just a little bit about each of these when we talk about a test strategy, So this is gonna be, ah, high level overview of the general approach that we're gonna undertake.
So ultimately, it's the strategy that we're gonna use to communicate to communicate with their stakeholders with their software development team and other members of the project. And it's gonna tell us what we're trying to accomplish. What are the goals? What type of methodology will we use? What sort of time requirements are we trying to operate within?
What's the environment gonna be like?
All of that information should be included in the test strategy, as well as how we're gonna monitor the results and how we're going to know if we're meeting those goals. You know, very early on, when we talked about If you remember when we discussed smart goals and objectives specific, measurable,
realistic and timely. We said that when we talk about ah strategies, they should be bound by time. So what's the time frame in which I have to operate all rights of test strategies Very high level in nature. They outlined the general approach. They tell us what we're trying to accomplish,
what sort of methodology to use
any sort of boundaries, like time or funding restrictions and also with the environment which we work is. So we start with test strategy. Now, the test strategy gets decomposed into what we call a test plan. So we have this high level strategy,
and now we're gonna take it, break it down into
more of a systematic approach. So we know what we're trying to accomplish and generally how from the strategy. But the plan itself is much more specific. This is going to show a tester the workflow that they would follow.
So this is really where we get into those procedures. And here's step one here, Step two in here. Step three.
From the test plan, we have what's called a test case.
So all the requirements from the plan in the strategy. And this is where we document the conditions that will validate that we're meeting our requirements. We already talked about how we're going to test those in the strategy. Now, this is where we're actually doing the testing,
and we're gonna measure and make sure that we're validating that we are meeting those requirements.
So the way we're gonna do that's we're gonna have a unique identify WR for each issue. What the requirement is that's being validated, any additional supporting information and then any sort of inputs as well as Theo expected results. So this is where we're really, um, figuring out what conditions must be met.
This is where we're actually, um,
tracking that information now. We'll also we will also have what's called a test test script,
and this is a detailed step by step how the test is to be performed. This is what the tester will go through. And for every test taste, there should be a test strip.
So for each scenario that we want to test that we want to validate, there should be a script that tells us exactly how to do so
now. The collection off all these artifacts as well as any other tools, documentation, input. All of this is referred to as the test harness. So all of those elements necessary to complete a test starting at the very basic, Um,
where we talk about the strategy all the way down to the scripts,
all of that information, plus any sort of input, um, like tools or techniques or environmental influence, All that would come together into the test harness.