It is increasingly common for a software system to experience evolutionary changes during its lifetime. These changes need not only be the result of software maintenance-changes may occur in the operating environment, the purpose of the software, or the manner of implementation. It is often desirable to know how much testing is needed to establish that software is relatively unlikely to fail. Such information can often be provided by methods that use reliability growth models, but these methods have some difficulties when the modification of a program is not the result of debugging. The paper examines the amount of testing needed to establish that an evolving program has a low probability of failure. The number of tests is bounded using evolution constraints, which restrict the forms the software may take as it evolves. The techniques presented here can yield pessimistic results during program repair because they make few assumptions about the repair process. They are most appropriate when applied to software whose initial development is already completed.