Advertisment

Building Competencies in the Changing IT World

author-image
PCQ Bureau
New Update

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.

Advertisment

1. 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% 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% 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.

2. 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% 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.

Direct Hit!



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

3. 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

Advertisment