Test Driven Development    
Autor: Paulo Dansa | Publicado: 2013-09-01T06:48:00-07:00

&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;
Quality assurance is of the main challenges when we get
to software development context.


It defines not just the border of customer satisfaction
but, as consequence how feasible and profitable this type of business can be.


Quality is the reason behind most of complaints for suppliers
and the reason why major losses are coming and making this, for most of players
of consultancy market, not profitable.


Well the cost of non-conformity: customer bad perception,
team demotivation, lots of effort and money trying to recover what should be
done properly, at first.


Even worst, as much software complexity and code base
increases more difficult becomes the task, of “clean development” work. 


Velocity X Cleanness: 


If you wake up in the morning and, trying to leave to
home earlier, doesn´t shave, you are not really becoming faster. You are
cutting scope and becoming dirty.


Customers are always requesting an earlier delivery: this
can lead our teams to a mess.


How to become fast and stay clean?


1 – Keep the code basis consistency – for every piece of
already developed functionality, keep a good test suite.


As soon as you “open” a module of an application for a
new development, as soon as you download from the repository the code base, do
the same for the base test suite.


Run all test cases for existing functionality, becoming
sure about code integrity.


This is the first basis, the first step.


2 – Start to work in the code, including each single
functional change in both, source code and test suite, like a credit and debit
operation, always keeping the balance.


Consistent test suites and customer business rules knowledge:
those will be the main assets of what is called software factory (terminology
that I, personally, dislike, but this is another history…).


Challenge How
to build a complete test suite for an existing code base when this was not done
in the past at all. What is the size of effort that we are talking about? How
to appropriate this cost? Where are you going to recover this investment?


Well, all activities, in a company, have two aspects to
be considered:


The first the activity itself, the technical need and
benefit. The other, of course, financial investment, benefits, pays back etc. &nbsp;Let´s discuss it further. 


&nbsp;ROI calculation:


How to calculate the gain and the losses of TTD, to see if it worth the effort?






The main point of analysis is to verify how slower development goes after TDD implementation and how much this additional period costs.


We have, at first, to assume that TDD development goes slower than conventional development.








In principle, delivery 0 (D0) is happening later, but this time is to be recovered later in QA (Quality assurance phase). This would be a consequence of the fact that QA phase with last defects can be finalized earlier. Defects use to be blockers for future test cases execution. So while certain defects are no solved, QA phase, or part of these phase is put as “on hold”.


This will happen as an ongoing process, after TDD has been adopted.


However, major challenge, is how to cover initial investment on TDD.


Consider that, for the set of applications that your team is developing there is no test suite prepared, at all. It will be, most likely, not possible to recover such investment in a project life time.&nbsp;&nbsp;However, since most of development organizations doesn´t have any other funding source than projects themselves, test suites are to be built in parts, in a per project basis.


What about investment return?


ROI = Project Life Cycle Reduction – investment


&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;________________________________________________________


&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;investment


&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;


Time is money. If we do consider Life Cycle reduction, of course, without additional resources, there will be cost savings.


The investment will be the additional effort allocated in a given project for Test Cases preparation, for the coverage of Use Cases implemented in such project.


But how to measure benefit of existing test suite?&nbsp;&nbsp;How to evaluate benefits of composition, project by project, of a consistent test suite that is to be completely run, as soon as project starts. This is an important asset that will be incorporated to development organization.


Investment returns calculation in project organizations is not an easy model because return doesn´t necessarily goes to project itself but to the organization as a whole. So benefits are to reflect In future projects,





Benefits of quality:





Cost savings, during project (life cycle reduction)


+


Cost savings for product sustain.


+


Image damage savings.


______________________________________________________________








References





[1] W. Humphrey.&nbsp;A discipline for software engineering.


Addison-Wesley, 1997.


[2] M. MÄuller and O. Hagner. Experiment about test-¯rst


programming.&nbsp;IEE Proceedings Software, 149(5):131{


136, Oct. 2002.


[3] M. MÄuller and F. Padberg. Extreme programming from


an engineering economics point of view. In&nbsp;International


Workshop on Economics-Driven Software Engineering


Research (EDSER), Orlando, Florida, May 2002.


[5] The Land that Scrum forgot – Robert Martin.