and welcome to Module Five or we're moving along and we're upon to delivery. So we're gonna take a look at the components that we're gonna be doing
testing in and all the other ideas we need. Teoh, understand?
It is his lesson. 5.1. We're just module overview just to kind of understand exactly what we're gonna be learning.
So in this module with a defined first test and release, we understand what those the terminology means. They'll start looking at the dass tools or capabilities and also want to take a step to the side. Also, look at business logic, so we can't. It's
and understand the complexity of trying to test these because the automated tools can't understand your business and how it works with the application.
And then we look at automation for testing and defect tracking. Ah, go back to Jenkins and add on our dash tool will be moving on expanding our pipeline and we'll take a look at the eyes tools. Interactive tools actually get embedded in the application
and then ah, finally add on the wasp maturity model specific for delivery,
the objectives getting examines of the testing tools, activities, discuss release tools, activities.
Compare some of the open source desk tools and in different shape doing I s sass and asked. Since we're coming up with all these acronyms, we need to understand them
and then take a look at this secure code box integration.
So we're talking about delivery. It's to transition from the bill to the deployment where testing the readiness of the release to say, Can we
deploy? This is it. Is it ready for operations?
We're gonna in this phase, you do be packaging the APP, and we have a couple more of these NIST S S D F requirements here ps two and PS one where we have ah mechanism for for validating or verifying the software integrity
and then archive to protect each one of the software releases.
So during this phase, a delivery were other testing, but we're gonna be obviously doing our security testing and this is really the go no go decision for the application. At this point, assuming your dear different maturity level you would be performing are adding that released tagging to all the components before they're putting a repository.
Until we talk about testing, it's a continuous testing across all the phases. This was supposed to be a We mentioned it before that.
You do poor performing the testing now, but it should be done. It should have been done. Are planned all the back of the beginning. And there should be different levels of tests. Kind of. See, we've been doing sass and SDA and all these different tests,
and there's there's other ones that organization may be doing. Unit tests, functional regression acceptance.
These may not be into the purview of security, but these are all part of the testing that's done during this phase.
And then the testing begins an appropriation. Like said, the procedure scenarios. What data will be selected?
So one of another ways questions what tests are performed in your organization before release. If you know,
do you only do functional? Are you already doing security? Are you doing Web application testing? Is it done after its release? Is it only done when you're trying to make an accreditation decision to just kind of think of these how these all these concepts that were learning, how did they fit or how can they align with your organization?
The word release here is the
The idea is to have your artifacts digitally signed. The verification verified that it passed all the tests that the security past,
and then when they deliver him into the report, just repository would be all the artifacts. So the images I said, J. P it's not the J baggage if the images are specific to your containers, or maybe your VM where images you want include the test results. If you're doing infrastructure is a code, which we'll talk about a little bit later.
Any deployment scripts, they should all go
into the repository and be tagged with the release.
So back onto our little infinity so you can see how we're moving along the path. Where does our final test before it goes
live into the operations? This is not our last chance to do some security scans, but this is the last
go no go decision, specifically securities discussion in on the topic.
So we talked about the concepts that we're gonna be discussed in the module, and next we'll talk about best scanning the dynamic of the actual application we've mentioned a couple times. So we just want to expand a little bit on the idea