 Okay, so we have now looked at a couple of different views of how testing looks like, what you can do But by far the most common categorization I would say is to follow the V-model Which we have covered in the process lecture. So you have the specification on top So you specify your requirements, your goals of the system Then you design, you build an architecture And then you implement So those are your system activities, what are you going to produce and then on the right side of the V you have the corresponding Testing quality assurance activities, and I usually down here you have something that is called unit testing In the middle you have integration testing and on top you have the system testing and They all have their own goals. They cannot really replace each other So they're actually quite important and we'll just quickly go into all of them And then later on we'll dive especially into unit testing since it's the most common way of testing in industry today And it's also really where it starts on a developer level So this needs to be good in order to really enable a working system I would say so first of all unit testing is Looking directly at the implementation activities of a developer So it's testing a single unit of a system a small part of the system For example, if you are in an object oriented language, it could be a class for instance and since Units these small parts usually do not fulfill any requirements The main focus of unit testing is defect testing So you try to cover as many cases as possible in order to expose errors anomalies and so on Another thing that is very common is that unit testing is automated So you have scripts tools that run automatically on the press of a button or on a git push or so on And everything runs and it directly shows you what the results are so you don't need anyone manually to do anything and Finally something that's also not uncommon up here, but particularly common in unit testing is what is called regression testing so you have a number of tests that are designed to be quick and Whenever something changes in the system you run all of them so that Everything is fine, but as soon as you accidentally change something you directly get sort of a warning saying now Something happened now. We have an error. It wasn't here before So maybe you should look at that and a very common technique is actually to say whenever you find a bug in your system You write a unit test that reproduces it And then you fix it and then the regression test the test passes But then if the bug ever comes again, it would directly fail again And the the motivation behind that is often that bugs happen because you have changed things That you have forgotten about or that we're working well before and you just don't realize and if you don't have regression tests That can sometimes take a very long time for you to realize that so this is an extremely important part of testing overall but also in particular of unit testing kind of reproducing old bugs and always running these tests again Integration testing is well it's concerned with the design So we basically put different pieces different units of the system together And we assume that unit testing is done in a good way. So we don't have to look at the unit level We have to look at the integration and what we usually have there is we test the interfaces. We test the communication between different components and the reason Why this is important is that for example interfaces are misused someone doesn't understand them in the right way So they just call it in a way that is not correct. That would lead to errors Or they have actually not been decided really so people just do whatever they feel like or what they think is correct and then there are problems so interfaces are a big thing to test and the other thing are quality properties like timing or performance in general and Probably also things like memory access so You might for example in your unit you are accessing the memory in a correct way But then if you have multiple components, they might access a shared memory and then suddenly this leads to an error This is nothing you would realize at the unit level because as long as you only have one unit everything is fine But as soon as there are more components accessing the same place in a strange way you could get errors similarly timing you can of course check your your algorithm for example is a performance But often because of the way the interfaces work the communication between components You really start seeing these timing and performing issue at performance issues at integration level Also, if you have delays for example messages arrive in the wrong order these are the things you typically see up here and integration testing is Also usually or let's not talk about integration testing but integration in general This is a place where usually a lot of problems happen So everything is fine here as soon as you put things together It starts really breaking and the problem here is in contrast to the unit level It's quite often hard to debug to understand why there is a certain behavior For example think of of issues like memory access and timing order of messages Those are usually things that are really hard to figure out why they happen for instance a timing error or a memory Access error might only happen once every thousand executions maybe because it depends a bit on the operating system on on the runtime of the machine, so These things are not at all easy to debug and that's happening at integration testing usually System testing then well, it's obviously the whole system. That's where the name comes from Including all the dependencies So if you for example depend on a database you depend on some kind of external cloud service you extend depend on some library all those things are somehow included in there and It has to do it's on the level of the specifications So very often you do for instance validation testing that you test whether the requirements are fulfilled You have a certain use case you try to execute that use case Defect testing is of course also possible here. You just try to put weird Input in and see what happens for example System integration testing can also be automated, but it's usually much much harder And something we haven't talked much about yet is also that bugs very often errors very often mask each other So some kind of error happens your test fails But that's actually not the only error. It's just that as soon as the first error happens the system stops but if it would continue running there would probably be four five six more bugs coming and That's an issue on all levels But in particular on system testing if there are a lot of things wrong You will only see the first one because then the execution stops and that's often called a masking behavior Which is also a reason why why inspection is sometimes preferred because there you can still see all follow-up errors If you read it correctly So these are essentially the different testing levels that you very often hear later on we will look at the bit at the user side There's also above that something that is called acceptance testing. That's basically whether the user likes it accepts it or not But this is another aspect of testing We won't cover system and integration testing so much here, but we'll now dive a bit into unit tests And look at how do we actually design that what kind of tests should we write and issues like that