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