Best practices for s/w developers and testers

BANGALORE, INDIA: What is it that bugs software developers and testers repeatedly? It is the changing requirements of customers till the product finally gets delivered. The software testers and developers have to modify their product as per client requirements and that too in a stipulated time.

This tedious task could be simplified if developers and testers embrace change through better processes and practices. We discuss here some of the best practices for the software developers and testers advocated by Agile methodologies to cope with the changing scenario of IT world.

Get into the habit of throwing bad quality code:

Traditionally products were built assuming that testing team will unearth the defects in design and code. While an effective testing team can find only 60-70 percent of defects and the rests are found at customer's place. However, testing and finding defects is a non-value-add activity which only proves the presence of defects and not its absence.

It's time for us to embrace 'test driven development method'. In this method, coding is done looking at the unit/acceptance test cases and the code is expected to pass the tests 100 percent all the time. Here testing team is the internal customer, and automated acceptance testing is run frequently (daily) to make a decision that the piece of code written is meeting the specifications as defined in acceptance tests.

At the end of acceptance testing, the decision 'Integrate or Toss' is taken, which means the code is thrown out if it doesn't meet the standards set by acceptance tests. Integrating the bad quality code and putting extra efforts to make it work, is counter productive and may take longer, and will cost more than writing a new piece of code. Hence this practice not only helps in getting the test team prevent defects but also helps in preventing high costs involved in maintaining bad quality code.

Get into the habit of throwing zero yield test cases:

Testing team is always a hurdle and a necessary evil for a product to go through. Big companies have the problem of schedule over-run and they take little time in releasing the products, losing considerable portion of market window. Data suggests that almost 30-40 percent of effort is spent in testing, irrespective of the types of release. However, this effort can be made in parallel with development/defect fixes, thus reducing cycle time of testing.

Agile methodologies suggests 'Release small pieces but release often' and 'Test early and test often' as strong philosophies to solve this problem. While talking about cycle time, growing test cases in regression testing is a big enemy. Regression is defined as 'Selective retesting' but many test engineers keep adding test cases to regression suite not because they need to be executed but because of historic reasons and fear of failures (many times not justified) at a customer's site.

Test engineers end up running all test cases and the selection part of definition is often left in the air. Test cases in regression keep growing as Thomas Jones once said 'Friends come and go; but enemies accumulate'. Crafting regression suite based on code changes to increase the usefulness of regression (friends) and eliminating unwanted test cases (enemies) from the suite can reduce cycle-time considerably.

Throw yourself at the problem:

There is a perception that testing is for test engineers and they need not be masters in development and vice-versa. This prevents developers from contributing to testing and testers in bug fixing. Agile methodologies suggests that 'Everybody test/develop all the time; by crossing boundaries' unlike the traditional way of product development where developers wait for testing and testers waiting for development.

'Crossing the boundary' increases ownership and team work, as all members of the team are expected to jump-in and resolve issues of product without caring about roles. This reduces the skill/knowledge gap between test engineers and developers. Also this method prepares test engineers for automation, otherwise automation is often considered as the job of developers.

Srinivasan D, Systems Software Technologist, HP, India