First I'll tell you a bit about how (at least modern) software development works to clarify what I mean by a "test". I'll also narrow the scope to a very particular kind of test known as block box testing since its the simplest form of test and is often highly effective in practice. I try not to assume too much about the nature of programs or programming here but I don't think I entirely accomplish that. Please feel free to ask questions!
A program (for the purposes of this discussion) is something that can be given inputs such as numbers or text and produces outputs. This narrow definition of a program can be mathematically formalized as a function. Specific inputs produce specific outputs. Under this simplified definition if the same inputs are given on two separate occasions, the same output is produced. A program of this kind is just a mechanical realization of a mathematical function.
When creating programs, programmers make mistakes. Sometimes programmers get it right however. In order to build confidence that a program has been created to mimic the desired function, other programs are creates to "test" the program. These programs that "test" another program are called "tests" conveniently enough. A test will give various inputs, one at a time, to a program under test to see if the program outputs the desired values. If an input is found that causes a mistmatch between the output and the expected output, we have a bug. If no bugs are found by the tests, we say the tests are passed (but we don't say that the program is correct because we haven't checked all possible inputs).
It's hard to explain why this process should give confidence of correctness however. Certainly I should have more confidence in a program if I've run some tests on it than if I've run no tests since I at least know that the tested inputs are correct. I should also have a bit more confidence if I test a new input and it sill passes. The more inputs I test the more confidence I should have. But why?
In practice forms of black box testing that randomly check many thousands of inputs consistently find bugs in practice. Programs which pass these checks generate very high confidence in practice. Additionally when tests check all "small" inputs exhaustively this generates high confidence as well. There are cases where the programmer has some information which tells them that the such randomized testing is unlikely to catch the inputs of greatest concern and this can undermine these high levels of confidence but in general this sort of testing typically generates high levels of trust that the program is correct.
One incomplete explanation is parsimony. As more and more inputs are attempted, a program which is correct on all of those inputs and yet not on some other input becomes more and more complicated to write pending contrived cases like a correct program modified to output something incorrect on one highly specific input. Can we be more formal?
It's similar to "why does seeing another black raven increase my confidence that all ravens are black" but each observation can be distinguished in this case. Additionally, while I haven't elaborated on this, programs have specific structure. For instance we can talk about the "size" of a program or we can talk about the kinds of mistakes programmers are likely to make in practice. Does this difference in structure change the problem? Does it give us a way to talk more concretely about evidence in confidence based on tests?