Let's say that you wanted to manually test your application every time that you deployed it. How would you go about doing that?
Well, to start with, you might make a list of all the things you want to test so you wouldn't forget to test something later on. Then you would probably write the steps for each test to make sure that you did them the same way each time. If you didn't make sure the testing process you used was consistent, your results wouldn't be consistent.
So, now that you have the list of tests you need to perform, you would open your browser, read the first test's steps, perform them, and make a note of the result. You would repeat this process for each test in your list.
The number of tests you perform would continue to grow as your application grows and as you find new bugs. You would, of course, be limited to performing these tests at human speed, making them rather slow.
The irony here is that in mechanically stepping through a list of operations, you are computing. You're just doing it way more slowly than, say, a computer would.
This, among many other good reasons, is why we write unit tests: they let the computer do the computing so you don't have to.
I can run a comprehensive unit test suite fast enough to use it frequently during development, not just once a week before deploying. This lets me detect errors more quickly, saving me time and money.
I can even write tests that predict the behavior of the system and then write that behavior (which I already know is correct because I just tested it), a process known as Test Driven Development.