We're into a tricky area here, since "acceptance tests" and "unit tests" are not *tests* as such. (I recognize that this is controversial, but please hear me out I DO acknowledge the value of them, too, but let's get clear on what I'm talking about here.)
First, "acceptance tests". Most of the time, when they've become artifacts, they represent *examples* of what the product should do. The process of *actually examining* the product to assert that it behaves in a way consistent with the example is a test. And yet...
...it's a pretty weak test; less like an experiment or an exploration; more like a demonstration to show that the product CAN work. Interestingly, though, the process of *developing* an acceptance test has more testing content in it, since thought experiments are going on.
Nonetheless, those thought experiments *don't* result in an improved product unless someone changes their minds or sharpens their ideas. In other words, the testing does not make the product better, even though it's part of a process that does make a product better.
One reason I want to emphasize this is to give credit where credit is due: to the people who actually put the quality into the product; those who actively build it; those who manage the product. I don't do that. I'm delighted to say, modestly, that I help them do it.
Now, "unit tests" and "unit testing". There are things that people call unit tests; we in Rapid Software Testing, we call them unit checks *when they can be performed algorithmically*; *when.they are encoded*. They are not tests as such, to us; they are *parts* of a test.
Unit testing (again, to us) is an activity of exploration and experimentation focused on units and unit-level risk. It may (maybe should) involve unit checks, but you can do unit testing without unit checks (example: stepping through the unit via the debugger to learn stuff).
Nonetheless: whether you're unit testing by applying checks or by more direct interaction with the product, it doesn't improve the product *unless you change the product code* or *change your mind* about some aspect of developing the product. Testing *on its own* doesn't do that.
Also, you can set out to improve without acceptance tests and without unit tests — although you'd almost certainly need testing in some form to discover whether it had *actually* improved or (perhaps more significantly) got worse.
So, to sum up: I think we'd agree that a testing mindset (whether taken by some person called "tester" or not) *informs* making a product better. A testing mindset and testing activity *on their own* don't make a product better; developers and development do that. Testing helps.
