How Much Testing

This presentation was very interesting.  It looked at the age-old question of “how much should we test and what do we test?”  It started out going over several real-life stories of companies who had failed to properly answer the question.  One in particular had a test suite that took over 15-20 minutes to build, over 5 minutes to start the server once built, and then used “webunit” tests that took forever to run.  Also the tests only covered 21% of the system — four years later the coverage was 24%!  (As a side note: Selenium testing is hard, to do right.)

For testing it’s critical to get feed back as immediate as possible.  So if your test suite it taking hours to run then you have issues.  You also should ask yourself if your tests are actually failing from time to time, are they really catching bugs and providing value?

Tests should influence your design.  If you are not finding that tests are influencing your design, they you’re probably not doing something right.  The speaker didn’t seem to specifically push TDD or BDD, but I could understand what he meant by this.  In order to test code easily you have to have testable code to begin with.  Code that is not easily tested is probably overly complicated and not designed/abstracted well.

“How easy is it for you to write a new feature?”  This begs the answer as to why testing is a good thing.  Well designed code is easier to maintain and change, and with tests you gain confidence that your application is working as you expected despite the changes.  Martin Fowler often explains that modifiability is the more important attribute to your code (even above performance), and you gain this through understandability (code is easy to follow/read) and testability.  Writing tests helps you write well designed, understandable, and testable code.

There are a lot of reasons why folks are not writing tests.  The speaker addressed the concerns of both management and developers.  Surprisingly he explained that managers are no longer the road-block, and that most managers now want testing – but the developers are resisting.  To write tests first requires a shift in thinking, and for many developers who’ve been coding a certain way for their entire careers, find this shift sometimes uncomfortable.

Ultimately the answer to the question “How much testing,” can be answered by asking, “What’s the right level of assurance?”  If you’re a company like Twitter (for example) if you lose tweets, or a search doesn’t come back exactly right is it really a big deal?  If you’re a patient in a hospital and your heart-lung machine software fails, is it a big deal?  Obviously you wouldn’t necessarily worry if Twitter admitted to less than 70% code-coverage, but you might be concerned if your heart-lung machine was anything less than 100% code-coverage.

Be Awesome

This was a very fast-paced talked that just touched on values or principals you should adopt to “be awesome,” taken from the speaker’s personal experience:

• Pair program (remote paring is hard, but possible)
• Respond to change
• Use micro-frameworks and tools
• Creativity and craftsmanship
• Monolithic processes are unfun
• Are your apps a joy to maintain?

Cucumber

I got the pleasure of seeing Joseph Wilk in person!  He gave his usual presentation on Cucumber, although there were some new features thrown in there.  Tagging was one of them.  The slideshow was pretty involved and if you would like to see an example of his presentation go check out this video:

Herding Tigers

This was the last big talk of the conference.  It was presented by Danny Blitz, who’s a very dynamic and interesting character.  He basically talked about agile teams, which he refers to as “tiger teams.”  He didn’t really talk about Scrum or XP or the more formal Agile methodologies, but instead discussed his own take on the corporate environment.

Book suggestions:  The Passion of Command, Corpus Business

What is a Tiger Team?

Small development team where velocity and quality are the primary drivers.  The team self-improves, has no meetings (or very few and short), test-automation is taken very seriously with actual QA members on the team.

“A lot of companies fake agile, wtf is a 3 hour scrum?!”

Workplace Archetypes as Animals

• Tiger:  calculating, cautions individuals who avoid fights they can’t win
• Cow: herd mentality, afraid of risk, have no original thoughts
• Bear: big, mellow, live and let live attitude, also avoid fights they can’t win
• Leopard: unmatched in ferocity, not a good team player though (avoid these)
• Elephant: C level execs, invincible in battle (even a tiger will not take on an elephant)
• Hyena: scavenger, dangerous weasels, steals ideas, back-stabbing

Leadership Characteristics

• Faith and Love
• Hope
• Success belongs to the team
• Failure belongs to the leader
• The buck stops here
• Fearlessness (moral courage)
• Listener and learner
• Protector

Also good leaders should manage by intent (servant leadership), not micromanage.  They should reward failure, people will make mistakes – let them feel comfortable in making them, as long as people learn.  Demand to be questioned, if your team is afraid of you they will not question your decisions and warn you when something is wrong.  Glorify the lower levels.

Good “grunts” show politeness and professionalism.  (They got it easy.)

Agile is a buffet not a dogma.  Methodologies are wrapped around Agile, *it* isn’t a methodology itself.