Software Testing approach [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question开发者_C百科 so that it can be reopened, visit the help center. Closed 11 years ago.

I would like to know what in your opinion should be included in approach and recommendation on testing for existing issues and planned activities ( as a part of the software strategy ). Thank You

---

To me, you need three levels of code testing. Here they are, from lowest to highest level:

• Unit-tests, for method testing. One test class per implemented class. These tests are tied to the specific implementation (to some extent) and try to achieve 100% coverage (I'm talking functional coverage here, not lines coverage, which is usally meaningless). You can use a mocking framework to make them test behaviour rather than state of your objects.

• System / integration tests They test all the interactions between components of your application. Not limited to testing a unique class, they rather test a specific external access to make sure it works as expected. A good example is CRUD test (Create, Read, Update, Delete) for a database access: although the unit-test would use a mocked database layer, the related system test uses the real one (on a development environment of course). Http calls to external servers are also part of this layer of testing.

• Acceptance tests (ideally using a testing framework like FITnesse or JBehave for Java, but can be done using plain JUnit tests) - these tests are high-level criteria for acceptance. Ideally written with (or in collaboration with) end users or business analysts, they serve as documentation to your system, and boundaries for each story / task the developers are working on. They should not change during refactoring of the related functionality, and still pass when you modify the implementation. In fact, they are your harness, your proof for successful refactoring. Ideally, they are readable by a non-coder human being (using wiki pages for FITnesse for example), to act as dynamic documentation of your project features.

All the tests above should be part of a continuous integration build, that's triggered everytime anyone adds or modifies the codebase. If any test fails, then the whole build fails and noone should check anything else in until it's fixed.

In addition to that, you should also plan:

• Regression testing This is normally achieved by a continuous integration server. Every build will re-run all the tests, ensuring you haven't broken a previously working feature.

• Reconciliation testing To test everything that cannot be captured by normal runtime testing. For example, if an application does some processing on a database population, then you might want to run a reconciliation program on two successive versions of the fully populated database, to make sure you haven't broken anything on the real production data. These tests usually take a lot of time to complete (reprocessing the whole database) hence they usually cannot be added to the automatic build. Typically done just before getting the green light for a release.