 Okay, in this second video, we are looking at inspection techniques as a part of the quality assurance process An inspection as a reminder is all about looking at the static system at not executing anything looking at documentation looking at code not running it and There are essentially two two kinds of techniques. You can do this manually so you really read through that and You do it in an automated or in a dynamic Yeah, spelling is difficult in a dynamic way and Manual techniques are for example as we already discussed in the requirements module reviews where you read through the requirement specification and try to find issues inconsistencies you try to figure out if any needs are missing and Essentially just by reading by thinking you try to detect issues and There are for reviews. There are of course formal procedures So you have certain checklists or a kind of for example perspective based readings different people look at it from different ways And there is of course at Hawk where you just basically without any process you read through we try to find issues reviews are Extremely effective So they are quite useful and they are as a matter of fact standard practice at Definitely the bigger companies the established software companies, but also at smaller ones So this is again to remind you inspection is nothing that you can replace with testing It's actually a very useful standalone technique and maybe as a reasoning why this is so good is that on the one hand you can check properties That you otherwise could not For example imagine code reliability or the how well commented there is a code That's nothing you can do with an automated test. So even if you can execute the system, even if you have everything Checking the whether you follow certain guidelines is just often easier in a in a If in a manual way if you reviewed it the code So that's one of the reasons the other reason that is good is essentially That you build up a shared understanding So if we talk about code It's not so common anymore if you have code reviews that only one person knows how a certain piece of code works But by reading it other people start getting that knowledge as well And then this way you actually effectively share the knowledge within the company Which is really a struggle otherwise. So that's another reason why we would like to do code reviews and These two things together really make that This is such a standard process in many companies Then we should also mention that we actually have dynamic ways of doing inspection or automated ways. So for example There are tools that are called linters that can automatically check code for For example style violations, you might have a certain Coding style that people have to follow and the tool automatically detects that The tools nowadays are so good that they can also detect for example, what is called a bad smell. So code fragments that are Written in a in a suboptimal way and that are known to cause problems later on So these kind of can highlight them and say well, you cannot commit this until you have fixed it or well Please fix it if you can so that's a very effective thing then in general There is the whole area of natural language processing. So basically techniques that try to read text and Reason based on that and that's for example used In requirements engineering to automatically try to analyze requirements or try to Check the requirements, whether they fulfill certain legal standards So these are things that are also getting more and more common and then finally Something that has been an extremely Active research area for a while, but now is getting more and more Common in practice is the area of program analysis and repair. So you have tools that automatically check your software code Find issues with it and actually repair them. So last year. This was quite a new thing That's why I had it sort of a news article in the lecture But Facebook has now launched this as a standard process So if there is a bug if tests fail automated tests then there is an automated program that Analyzes the code and tries to fix it until the test passes So this is actually not an engineer that has to go in but as some kind of automated process That does this without anyone intervening and then the engineers basically just have to sign off and say yes This is a good solution. So overall, this is an extremely powerful tool and Just as a reminder You don't really need the running system. You can do this with parts of your code You can do it with an architecture documentation. So The this can be done very very early even if there's nothing running. This can be done in a waterfall process Years before the final product is ready. So it's an Not to underestimate technique that you can run on basically anything Okay, so From now on we'll leave the the area of inspection. This was just a quick dive into that But now we go into the dynamic part of actually executing the system