Testing as part of Development activity

Testing should be a part of the development activity and not be relegated as a separate function, to be performed post development. Here are a few “things to do” to enable this.

Involve testers from the start

It makes a lot of business sense to involve testers from the requirements phase itself. Testers can better understand the product to be developed, test the requirements and help clarify requirements better. As is common knowledge, it is least expensive to fix a defect at this early phase rather than at a later stage, such as a post implementation phase of testing or even later, when the cost of fixing defects escalates drastically. Testers can begin working on developing test plans while also checking to ensure testability of requirements.

Require Developer Testing

The minimum requirement from development should be to perform Unit testing. Testing groups should ideally receive report of tests run and results, along with information on any open issues or workarounds, before accepting a build for more formal testing. Unit testing helps catch issues much sooner with lesser turn-around time involved in addressing issues. Also, a “stable” build to the testing team enables testers to be more effective and reduces time spent on test / fix / test cycles. Other useful practices that may be adopted include – test driven development which is part of an agile development methodology. Also, having developers perform a set of integration tests, with their module integrated into the larger application, can be pretty useful in identifying more common and basic issues. These integration tests need not be extensive or complex and can involve a basic set of tests. Often developers tend to stop with unit testing their module or area of work. However, on integration with the larger application, newer issues tend to show up. Having a set of integration tests also being run, in addition to the module level tests can be very useful. The idea is to avoid delivering a “broken” or “poor quality” build to the testing group. Having testers blocked on basic features / items wastes a lot of time and effort as well as involving a lot of back-and-forth interactions to communicate, analyze, fix, check-in, re-build and re-test.
Leverage test automation

Test automation is not just for testers. In fact, developers can and do leverage test automation to test their work. Testers and developers working together on a common automated framework to develop and run tests is a good idea. Tools must be chosen that can support such a scenario and does  not involve a steep learning curve to learn a new language required by the tool. Tests may be added incrementally – developers as they develop new code, can add in new tests while testers can use the framework to build more complex tests. A common framework eases communication and helps to benefit from synergies of working together. Other good practices to follow include, building automated test suites (generally regression) and having these run against regular builds (often on a nightly basis).
If you are not already using it, you might want to consider using a continuous build / integration system and tying in your automated regression suite to it. When a build is generated, you can have a set of automated tests run on it and mark the build accordingly based on the results of the tests, observe the stability of builds, analyze test failures and be notified of any failures. We use Hudson at my present organization.
All of the above relates to the point I mentioned in an earlier post – Software Quality is the responsibility of everyone involved in producing the software. It is not confined to just the Quality / Testing team. Quality must be built into the product and the Development team (as also the Testing team) has an important role to play in building a quality product.