Article Menu

Wednesday, 01 October 2008 05:05

Reducing the Cost of Change through Software Testing

Written by  Jonathan Malkin
Rate this item
(0 votes)

In business environments that include software development, business analysts must be able to identify key areas for improvement and justify the cost of changing software development practices.  IT departments may not write automated unit tests and QC departments may manually click-through the application.  Automated testing may not be a part of the software development life cycle.  Automated testing directly impacts the cost of software by reducing the Cost of Change.

Definition: Cost of Change = Cost of Changing Code and Cost of Changing Process

A software project with a high cost of change typically exhibits some of the following bad smells.

  • Quality delivered to customer is unacceptable
  • Delivering new features to customer takes too long
  • Software is too expensive to build (product development and implementation services)
  • "Hardening" phase needed at end of release cycle
  • Integration is infrequent (Manual Testing Cycle)

Cost of Changing Code

CS2/T = (Complexity of Code base) * (Slack of "in-flexibility" of design) 2 / (Test Coverage)

The cost of changing code (making a programming change) is a factor of Code Complexity, Slack or "in-flexibility" of design and test coverage. 

Automated testing reduces this risk by:

  • Providing a way for programmers to know when they're done.
  • Enforcing a quality standard.

What if unit tests are only written some of the time and the QC department manually "clicks-through" the application for every acceptance test?  What is the value of purchasing new tools and retraining staff?  Automated testing reduces the cost of maintaining code.

Cost of Changing Process

=  (Reduction in Cost of Changing Code) * (Number of changes implemented each year) / (Investment in training and tools)

The cost of any new investment in testing tools and training will be realized as a return on reduction in the cost of changing code.

The Bottom Line

  • Initial investment in automated testing tools and training for developers and QC.
  • Negligible change in cost for on-going training; cost of on-going training in automated testing similar to cost of current training in manual testing.
  • Increased licensing expense for better tools
  • Decreased cost of implementing new features
  • Increased quality to market
  • Increased flexibility - able to adapt to market conditions more quickly
  • Reduced time to market

Let me know what you think!  If there is sufficient interest in this topic I will return to it in my next blog and delve into the details of a test plan that adheres to this standard.

Jonathan Malkin is a Business Analyst at Plateau Systems.  Jonathan provides configuration, integration, documentation, and deployment support services for a leader in Talent Management Systems.  Jonathan's areas of support include 21 CFR Part 11 Validation and customizations to COTS software for which he has won multiple awards.  His experience includes work in the federal government, telecommunications, mortgage and banking, and custom software development industries.  Plateau Systems is a leading global provider of adaptable, unified web-based talent management software, content and services to onboard, develop, manage and reward talent.

Jonathan may be reached by email at This email address is being protected from spambots. You need JavaScript enabled to view it. or by visiting his LinkedIn page at http://www.linkedin.com/in/jmalkin

Read 2220 times Last modified on Tuesday, 27 March 2012 13:46
Published in Jonathan Malkin
Tagged under

Related items

More in this category: « Test Plan The Cost of Validation »

Comments  

 
0 # Jennifer Butler 2008-10-02 06:29
I would like to see more about this. As the sole BA in a small telecom billing software company, I write the requirements which then fall into a black hole and with a little fairy dust, magically appear as one of the mass of "delivered" projects at the end of a month. The QA process is far removed from my side of the project, or so I thought, but this writeup leads me to believe they either are or should be far more interrelated than I thought.
Reply | Reply with quote | Quote
 
 
0 # Ritesh Kumar Sinha 2008-10-02 07:00
Do you think the manual testing approach through an iterative life cycle model is an better than the manual testing through the waterfall model in which case it might be an alternative to the automated testing. This is because the testing quality increases due to the focus of the QA resources on parts of the product rather than the whole product together at one time.
Reply | Reply with quote | Quote
 
 
0 # Jonathan Malkin 2008-10-06 03:51
Jennifer -- The developers and QA staff at my company always come back to me with questions. I would at least network with your QA and development people to find out more about what they do. You might be able to improve the development process simply by reaching out and letting them know it's ok to ask you questions. Rit stylo -- Iterative development is preferred to the old "waterfall" model. The biggest problem in software development is getting the right requirements. Iterative development shows customers the latest changes and allows them to change their requirements every week or two. This is a great advantage and helps the testing process as well.
Reply | Reply with quote | Quote
 
 
0 # Neville Scheevel 2008-12-02 04:49
Our company has learned the intangible benefit of automated testing is an improved quality of life. Releases are no longer preceded with finger-crossing ("hope it works!") and the expectation of damage control. We can now make rapid changes to the underlying code-base knowing full well that the battery of automated tests (instead of our end users) will identify any unexpected behavior.
Reply | Reply with quote | Quote
 
 
0 # Gabe Martineau 2009-07-26 05:13
Does anyone have a specific Automated Test tool they like best? I know Mercury has one my firm uses.....
Reply | Reply with quote | Quote
 
 
0 # nomad2003 2011-05-05 04:05
What is forgotten is a facet I have label "creeping functionality". This is done by those who initially definded the requirements and by developers. Things like, "you can add this without too much effort", or "what we really meant to say was ...." or developer on his own, will say, "while I am doing this I will 'make this other part better', or "I can also add this". Enough of these and your project is late and your budget is blown.
Reply | Reply with quote | Quote
 
 
0 # nomad2003 2011-05-05 04:13
The level/depth of testing should also be determined by the use of programming. Code to just print a standard report, test to make sure it does what it is suppose to do. But for code that is life dependent (embedded in a medical device, code for a manned space flight) needs every data path checked. The QA folks need to write tests which first check for the deliverables in RFP. These tests should go to the developers. The software should not be "thrown over the wall" until these tests pass. The QA group should also run these tests , but also tests to see about breakage. Can the code be made to fail.
Reply | Reply with quote | Quote
 

Add comment

back to top