Coping with changing customer requirements is quite a challenge for both developers & software testers. We discuss here some of the best practices they can follow to deal with this problem.

What is it that bugs software de¬velopers and testers repeat¬edly? It is the changing requirements of customers till the prod¬uct 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 devel¬opers and testers embrace change through better processes and practices. We discuss here some of the best prac¬tices for the software developers and testers advocated by Agile methodologies to cope with the changing scenario of IT world.

1. Get into the habit of throwing bad quality code: Traditionally products were built assuming that testing team will une'arth the defects in design and code. While an effective testing team can find only 60-70% 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 de¬velopment method'. In this method, cod¬ing is done looking at the unit/acceptance test cases and the code is expected to pass the tests 100% all the time. Here testing team is the internal customer, and automated acceptance testi ng is run fre¬quently (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 pre¬vent defects but also helps in preventing high costs involved in maintaining bad quality code.

2. Get into the habit of throwing zero yield test cases: Testing team is al¬ways 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 consider¬able portion of market window. Data sug¬gests that almost 30-40% 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 sug¬gests 'Release small pieces but release of ten' and 'Test early and test often' as strong philosophies to solve this prob¬lem. While talking about cycle time, growing test cases in regression testing is a big enemy. Regression is defined as 'Se¬lective 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

Applies To: Software Developers & Testers
USP: Equip yourself with some of the best practices in developement and testing.
Google Keyword: Agile methods Primary Link: None
Thomas Jones once said 'Friends come and go; but enemies accumulate'. Craft¬ing 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.

3. Throw yourself at the problem:
There is a perception that testing is for test engineers and they need not be mas¬ters 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 de¬velopment. 'Crossing the boundary' in¬creases 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.