Sure, but testing usually purely relies whether your assumptions are right or not - whether you do it automatically or manually.

Like if you're manually testing a login form for example, and you assume that you've filled in the correct credentials, but you didn't and the form still lets you continue, you've failed the testing because your assumption is wrong.

Like even if the specs are wrong, and you make a test for it, lets say in a calculator Assert(Calculate(2+2).Should().Equal(5) - if this is your assumption based on the specs or something, you can start up the calculator, manually click through the UI of the calculator, code something that returns 5, and deliver it.

Then once someone corrects you, you have to start the whole thing over, open up the calculator, click through the UI, do the input, now it's 4, yay!

If you had just written a test - even relying on a spec that was wrong, it's still very easy to change the test and fix the assumption.

Also, lets say next sprint you'll have to build a deduct function in the calculator, which broke the + operation. Now you have to re-test all operations manually to check you didn't break anything else. If there were unittests with like 100 different operations, you just run them all, see they're all still good, and you're done