-: Testing application code.
So we've talked about ways to develop the code
using our different models.
We've talked about the processes and the eight steps,
and now I want to talk a little bit
about how you can test this code.
Well, there's four different ways you can test code
after you've coded it.
You can scan it using an automated tool.
You can use automated vulnerability scanning tools,
things like Nessus and QualysGuard
that we've talked about before
after it's been a compiled piece of code.
We can do manual penetration testing
or we can do code reviews.
Now, OWASP is the one who says that code reviews
are the best and most thorough of these options.
And one of the ways they recommend doing it
is what's called a 360 review.
This is where you're gonna combine a code review
with a manual penetration test,
and then using the results of that manual penetration test,
you'll go back and review the code again.
This way you're getting a complete look at that code.
Now, how do you do a code review?
Well, in this lesson, I'm gonna mention a couple
of different ways to do a code review,
and we're gonna go through five different methods
that are used.
Code reviews are gonna share knowledge
of the code with others.
That's one of the great benefits of code review.
If I'm reviewing your code, I start understanding
how your code works.
Now we have two people in the organization
who understand your code, right?
More experience is learned across the team,
so as we do code reviews, if we do it with a group of four
or five junior analysts, they're gonna start learning more
from our senior analysts as we go
through those code reviews.
And this is gonna allow us to detect problems
and enforce good coding practices
because if I know my code's gonna be reviewed
by other people, I'm more likely to do documenting
of my code and I'm more likely to do good practices
and not hide little things in there like backdoors
and other things because you're gonna find it, right?
And so we wanna make sure our code reviews are done well.
Now, there's agile and formal methods for code review,
just like there was for software development.
There's five different ways we're gonna talk about
in this lesson.
There's pair programming, over-the-shoulder,
pass-around, tool-assisted, and the Fagan model.
Now pair programming is an agile development technique.
This is gonna have two developers using one workstation.
And so what ends up happening here
is one guy is coding away while the other guy
is watching him and looking at the code
and saying what he thinks the other guy is coding, right?
And then they was gonna switch,
and the other guy will start coding
while the other guy reviews his.
And so constantly, they're doing a give and take
where they're trading off on the keyboard
of who's coding and who's reviewing.
This provides real time code review,
but it is very costly
because you have to pay two programmers
all of the time to create the amount of work
that one programmer normally would.
Now, the next one we're gonna talk about
is what's called over-the-shoulder.
This is a little bit of a modification on pair programming.
It is an agile development technique,
but this case, you're gonna have
a developer code everything.
Then he's gonna call over a second developer,
and they're over the-shoulder gonna look at the code,
and he's gonna explain, the one who coded it
is gonna say hey, here's what I was doing here.
I'm doing this function to do this to do this to do this.
And the one who's over-the-shoulder watching
is gonna be able to look at it and review it.
This is less costly than pair programming
because it's done in intervals, right?
I can code for an hour and a half or two hours
and then call you over for a 10 minute review
instead of both of us being there for two full hours.
Now, the next thing we're gonna talk about here
is pass-around, and pass-around is a form of code review
where one or more reviewers can actually look at your code.
Whereas in over-the-shoulder and the pair programming,
we only had one other person looking at your code,
here I can have one, two, five, 10 people look at your code.
The code is then emailed around or shared for review
on a central server, and the code has to be well documented
because in pass-around, I'm not sitting there explaining
to you what I programmed.
Instead, you have to go based on the comments
and the lines that I put inside the code
and figure out what I did.
It's not nearly as effective, in my opinion,
as pair programming or over-the-shoulder,
but it is much less costly, and it allows people
to review the code at their own pace,
but they're not gonna get nearly the amount
of knowledge value as talking with that person
who coded it originally.
Now, the last one here as I'm talking about agile ones,
is tool-assisted.
This one can actually be agile or formal.
It's gonna be software tools
that conduct code reviews for you,
and it allows us to mark up those codes
and provide feedback very easily inside the code.
So a good example of this is Codacy.
Codacy is here on the screen you can see,
and there is a place where they have highlighted
hey, I found this bug, I found this issue.
Here's what my problem is with the way you wrote your code.
This isn't nearly as efficient as it could be.
All of those things are centralized
in this knowledge repository going back to the coder
and all of the reviewers.
This is just a tool that assists in one of those pass-around
or those type of code review.
And the last one I wanna talk about
is a very formalized one.
It's called Fagan.
Now, Fagan is a structured formal code review
that's done by a team of reviewers.
This is gonna specify entry and exit criteria
for each and every process,
and then each of them is reviewed and tested
as it goes through.
So if I'm expecting our check writing program
to be able to take in a dollar value
and a customer's name and output a check
that is printed on the printer
with that customer's name and dollar amount,
we know that's the input and that's the output.
Now, Fagan is very costly though,
and it's harder to implement because it is very formalized.
There is planning to it.
There's an overview.
There's preparation.
There's meetings.
And then there's actually looking at the code.
And then there's rework that happens,
and then we gotta go through the process again
because code has been changed.
It gets to be very, very expensive
but it is very good if you need high security
and a high level of review.
Fagan is a formalized method,
very similar like when we talked about Waterfall
and Spiral, how they had a very formalized method
to make sure we had good security.
That's the idea here with Fagan.