All of the secure coding tools in the world are no good unless we have good tracking of code quality and testing. So once your code is developed, the first thing you're going to want to do is you're going to want to test that code. Luckily for us, there's lots of really great tools to help us test. But we break it down into really two different types of tests. First are what we're going to call static code analyzers. static code analyzers, look at your actual code.
They don't run the code. They just look through the code. And they look for standard types of errors that coders often do. So if you take a look on the screen, I've got an example of a static tester. And if you take a look, it's a little bit hard to read. It's at the bottom, but you'll notice that it doesn't like the way I'm doing a particular input validation.
And I'll use this as a way to go back and check that to see if maybe I could do it a little bit better. So there's lots and lots of static code analyzers out there. You just pick the one that works best for your type of development platform. The important thing to understand is that it's not running the code, it's just reading it. And based on lots of people's experience and a little bit of logic, it makes suggestions that you then go back in and change. If you really want to test something, though, you're going to have to use a dynamic analysis.
In other words, run the code. A dynamic analysis actually runs the code to look for logic errors to look for security holes, you can do things for example, try to put really bizarre inputs in now I'm not talking about input validation, per se. What I'm talking about is like typing in SQL commands into the last name field, crazy things like this that are known generically as fuzzing. And there are actually tools out there fuzzers that you can use to actually throw in a lot of well known hacking type code to see if we can break your system and that's what it's all about. So the dynamic analysis actually runs the code. dynamic analysis handles things that you could never deal with with a static code analyzer.
For example, do you have a memory leak? Do you have a problem with the way you're querying the databases? These things really require a dynamic analysis. Alright, so you keep running these tests, these tests aren't run once they're running continuously through the development process. But there is a point where you're really starting to think you've got your code. And that's where we move into staging.
Staging basically means you want to start creating more and more realistic real world environments to see how your code does. So the first test that we normally do is a stress test. With a stress test, what we're doing is we're actually putting the entire system under load. Can the databases keep up? Do I get refreshed problems with screens? Do I have good denial of service attack defenses built in or at least up to a certain point?
To do a stress test, we usually use what's known as a sandbox with a sandbox. What we're is where we actually use real servers, usually virtualized servers. And we get everything up and running. If you have a database server separate from your application server, everybody's up and running in cooking. But it's a completely isolated environment, you're not actually out in the real world, you might even be public facing a little bit in some sandbox environments. After a good stress test within a sandbox, you're getting close to saying, I think we're getting ready to put this up into the last stage, which is going to be deployment or production.
But before we do that, the last step we're doing is called model verification. Model verification is the process where we go back and we go Look, when we first decided to make this application, whatever it is, we had a vision of what it was supposed to be and what it was supposed to do. That is our model. The model verification is that step that goes is this doing what we visualized from the model. Now if it's a game, it could be things like well, when we shoot the evil robot overlord Does he explode into 25 pieces that are blue, or 37 pieces that are red. If we're setting up a database system, or the input screens coming up at the time, we expect them to come up and closing properly.
So we go through this model verification, not to necessarily say that it's not working, but to make sure that it's matching the vision, the model that we originally chose. Once we've gone through these steps, then the last step is the most interesting. And that is production. At this point. We're taking things off the sandbox, we're putting it up on public facing servers, and we flip the switch and hopefully we make I don't know lots of money.