[MUSIC] So, how do I go about reducing this overhead? Well, there's a lots of different ways that I can go about trying to [COUGH] attack this problem to make it, so I get to do the thing that I have fun with. One of the ways that we're going to talk about is about automating tests. We can go through and we can manually test things. We can do it in an unstructured way, like I was talking about where we know what's supposed to be done. So, we go and we manually click through all the buttons. We can do it in a more structured way where we write up documentation and we say, these are the sequence of steps that someone that wants to come along and check that this is correct should follow and we can have separate groups of people who do the testing. But one of the challenges with that is if we're going through and doing things in a manual process as a programmer when I make changes, when things are fresh in my mind, it's usually easier for me to fix mistakes if I actually make them. So if I go through and I make a change and then I manually test something or I make a change and then I hand it off to somebody else to manually test, it's usually going to take a long time if there is a bug for that to filter through and make it all the way back to me, so that I can go and see what I did wrong. Or in the process of making this change, if I'm fresh with it, I may be able to see better ways of improving the code. If I have more time to focus on my change and I'm not waiting for things to come through, I may be able to iterate quicker and make changes quicker in order to build better code. So this idea of manual testing not only does it add all of this overhead to every change that I make, but it also slows down the feedback loop to me. The longer it takes me to make a change and then hand it off to somebody who goes and runs the test, then it comes back to me. Or for me to go and run the test, there's overhead that it's creating for me as a programmer that makes me not want to change things which makes me not like running tests. There's time that gets created if I'm handing it off to someone, so that I don't have to do it. They're still having to do it and they may have to schedule with other people, it takes a lot of time to get back to me. So whatever we're doing, we're slowing down the rate that we can produce a software and iterate on it and incrementally change things. And often as programmers, we don't then get things right. We don't predict what are all the ramification of our changes. So being able to incrementally iterate and improve things is important, and be able to do that quickly is important. So manual is overhead, it's slow turn around. It's limiting and how quickly we can increment, and change things. It separates us more from when we make the change to when we see the result. So, there's lots of challenges there. So, how do we go about solving this? Well, we want to do automated testing and this is one solution. Now this isn't the only reason that we automate testing, but this is certainly an important reason for all these things that we're talking about here. So we want to automate testing, so that we would really like is that rather than going and running all this things manually, what if one time we write some code that automatically does all the things that the user would do? Let's programmaticaly run the test. Let's programmaticaly fill in the right values on each screen. Programmatically click all the buttons. And then when we get the resulting screen up, let's programmatically check that it's in the right state. Now as a developer, this provides a lot of benefits for me. So lets say, I can go and eliminate manual testing overhead. So, I don't have to do this at all. What does that look like? Well, if I could automate this piece and make it, so that it's not a manual process. So if this is automated. Then what that does is allows me to go and make a change, and then I can just push a button, and I can execute my automated test. And immediately, I get feedback on the result of my change and the beautiful thing is this all I have to do is a push a button or something close to that simple. And then I can say, well, I know wait, that's not exactly what I wanted and I can go for an example with my list example where I had all of these icons and margins that were wrong. I can go and try and tweak something a little bit more. I can press a button, the automated task process runs and I get the result. And this makes it to it where I get to focus as a developer on the thing that I really have fun with which is actually doing the software development and the programming, and I get to focus on making tweaks. Now, what is the downside of this? And I say, downside and it's not necessarily a downside at all and it just depends on your perspective. Well, the slight downside is, is that when I first create this change, if I just manually went and tested it, it might faster to do it manually than it would be to write the automation to perform the test for me. And this is where as developers, we have to have a little bit of discipline. And what we have to realize is, is that yes, although I could go and manually test this faster, maybe the first time I did it. And in some cases, we can't even manually test it faster. Some of these things are so hard to test we need to do tests that changes programmatically. But the first time I do this often, it's cheaper to do it manually. So if I just went and we know push the right buttons and enter the right values and went through their screens, I could do it easier manually. But if I'm not right or if I tweak this thing or if in the future I'm tweaking things that happened to impact the things that I care about, going in and re-running that manual test over and over. Overtime will be more expensive, then had I just sat down and written the automated test from the beginning. Now this is really important when we're trying to build maintainable software, because the truth is, is that we have some amount of effort. Let's assume we're graphing these and these are not going to be to scale. Let's assume this is the effort to create the initial application. So when we build our initial, let's say, mobile app in Android, we have some amount of effort to create that first version and then we have the effort to go and maintain and evolve that app over time if it's successful. And the truth is, is that we're going to spend a lot more time maintaining that out. And what that means is, is that we're going to build an app and we're going to continually make changes to it. And when we're making changes to the app, every time we make a change, we can't predict what we're impacting. So, that means we're going to be changing things that may impact all kinds of things throughout the application. And if we had to manually go and rerun every test for everything that we could have potentially affected in the application, it would be extremely time consuming to make a change. Think about it, as assume that you have that one screen and you're making a change. Well, you have one sequence of things that we have to go and test. Manually plugin all the right values, click all the right buttons and see the output. But if we suddenly have ten screens and each of them have five different options, then we end up with a huge number of manual test cases that we have to go and run. And if we go through and manually click through every one of those and if every time we make a change somewhere, if you do the right thing and test everything, because we probably can't guarantee that we've made a change and doesn't impact anything else. If we manually we rerun all of those manual tests, it's hugely expensive. And if we're going to spend most of our time not building from scratch, but changing existing stuff and adding to it, we're going to spend most of our time in a world where there's lots of things that really need to be tested every time we make a change.
