automated testing - convincing people to do it

[vorad]

I am looking for a case for automated tests in order to convince one of my colleagues about their power. He doesn't believe in them, doesn't use them and it's the adopter of print, run and debug technique which clearly holds a big chunk of his productivity. I've tried all kinds of arguments:

- always running the whole system isn't going to make you more productive

- you don't know when you add regressions to the code base

- technical debt increases exponentially as you keep going without *any* kind of tests besides the old school main() entry point in which you do your basic tests

- you're dragging your team behind because of this

but these didn't work and I am looking for more arguments for this. it's really frustrating that the code base is a big chunk of untested monolithic code.

Any ideas will be greatly appreciated.

[Pierre Neis]

Hi,

Thanks for this interesting question. By nature, I think that human brain is the best tool: better than a testing one.

Anyway, Scrum Board and Kanban board helps to understand the need of the tool "awareness occurs when you are on the precipice".

Having the testing column at required level --> visualize the bottlle neck --> discuss with the team about solutions --> "sell" the tool & the test of the tool during 2 Sprints --> inspect & adapt each day if it helps to facilitate the flow --> check out during Retrospective if it helps or not --> if yes, then search for team acceptance --> if not, ask for solution

This is the luxemburgian vote ;b))

 

Pierre E.  NEIS, cspo psm csp
Head of Lean Competence Centre @ coPROcess S.A. │ Scrum & Lean Coach  

There is no impossibility to him who stands prepared to conquer every hazard. The fearful are the failing.~ Sarah J. Hale

Mobile:	+352 / 661 727 867		Calendar:	http://meetwith.me/pierreneis
Skype:	pierre.neis		Twitter:	Elpedromajor

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

[David Karr]

I just looked at this group, and I see this was posted a few months ago, but it's a topic I feel strongly about, so I figured I would add something.

I would say there are three distinct points to cover. I'd paraphrase them as "speed", "design", and "documentation"

Speed:

In a non-agile development process, the lack of automated unit tests is a handicap.  In an agile development process, the impact of the lack of automated tests is larger.  If you have to finish deployable changes in a two-week sprint, you need more help from your technology to maintain quality. Manual changes to code to add debugging information and actually watching the results takes time.  Having your unit tests find problems for you is much more effective.

Note that developing and maintaining unit tests takes time. To get the most benefit from them, they have to be taken seriously and developed with care. You will get long-term speed benefits, even if you'll need more time in the short term.

Design:

In order for unit tests to be possible, the code they are testing has to be testable.  It turns out that when code is more testable, it demonstrates "separation of concerns" and functional decomposition.  As a result, code that is more testable is often better designed than less testable code, and thus of higher quality, even without running the unit tests.

Documentation:

A well-written set of unit tests spells out in detail what is expected of the code under test. If you've hired a new developer, and there is little documentation on what your system is supposed to do, a great place for them to start is by reading the unit tests.