Life, Teams, and Software Engineering

Month: April 2012

Book Recommendations: Testing

I got an email from one of my teammates yesterday asking me for some book recommendations on testing.  I’m glad that he didn’t just ask for books on unit testing, hopefully that means I’ve done a good job at emphasizing that it’s not all about unit testing.  Anyway, here’s my list of required reading on testing:

The Art of Unit Testing, Roy Osherove - At the time this was the only book to talk about the structure of unit tests and what made good tests versus bad tests.  To my knowledge this is still true and it’s #1 on my required reading list for developers.  The author sought to fill the gap between starting from scratch and the various works on Test-Driven development that were already out there.  This book doesn’t focus on TDD, it focuses on unit testing.  What makes a unit test, what makes one good or bad, and how to build suites of good ones.

Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin - I’m a strong believer in breaking down the silos between the “development team” and the “testing team”, to the point where I hate hearing those designations.  For any team to be successful the entire team must be involved with everything from the beginning and this includes testing.  Nothing is done until it is tested.  This book shows that no matter what your designation is on the team that you have value to add to testing, and that testing early and often is necessary for long term success.

Growing Object-Oriented Software, Guided by Tests, Steve Freeman and Nat Pryce – This is the best book on Test-Driven Development I have read to date.  The examples and explanations of the whys and hows of test-first development, as well as the authors’ wisdom to focus on test-first at all levels (i.e. Acceptance Test-Driven Development combined with Unit Test-Driven Development) make a fantastic book to learn how to apply the test-first approach.  The authors focus on showing you that incrementally building your test suite while you add the functionality doesn’t have to be difficult or overwhelming.  It’s about repeating simple cycles of developing an acceptance test at the outer loop, watching it fail, then moving to the inner loop and developing a set of unit tests while implementing the actual functionality while working towards passing that acceptance test (and all the unit tests of course).

xUnit Test Patterns: Refactoring Test Code, Gerard Meszaros – I’ve gone through a great deal of this book, and while it has a wealth of information I honestly had a hard time finding places where some of the patterns could be applied to my test code.  That doesn’t make it a bad book by any stretch, however, and if you’re the kind of person that patterns speak to, this will help you find structure in what can sometimes feel like a daunting learning curve.  I find this as more of a helpful reference than required reading, but it’s still nice to have around.

Advanced Software Testing – Vol. 1: Guide to the ISTQB Advanced Certification as an Advanced Test Analyst, Rex Black – Despite the fact that this is a certification book, there is a lot of useful information in here about test analysis techniques.  Understanding these techniques and both where and how to apply them is necessary to be able to develop test suites that are “lean” in that they cover the necessary parts of your system without wasting effort through duplication or ineffective test cases.  The layout is a little chaotic, but if you can cut through the noise you’ll find the techniques indispensable.

Practice – Seriously.  This is the best way to learn the ins and outs, limitations and strengths of various tools in various language, as well as how to generally unit test various situations.  CUnit or Unity?  CppUnit or gtest?  NUnit or MBUnit?  CMock or mock-by-hand?  GMock or mock-by-hand?  RhinoMocks or Moq?  You can’t know to what situation each of these tools is best suited unless you’ve tried them (ideally on a real project).  But don’t try to master the tools, try to master the practice.  It will make you more valuable if you understand the foundations since you’ll be able to move between environments quickly with little ramp-up time.

There are no shortcuts to mastery, and as much as one would like to believe they’re special in the beginning (I’m sure I’ve been guilty of this), the 10000 hours can’t be faked.  Practice and you’ll get better at it, you’ll find the patterns, and you’ll be able to pick up most any tool like this and use it effectively.  But you need to develop the foundation to understand why you’re unit testing before it can evolve from just another mundane task to perform before something is “done” to being engrained in the very way you do your work.

Overtime as Failure

First, let me make myself clear.  This post isn’t focusing on voluntary overtime (though you should still consider the impact to your team, but that’s another post), it’s focusing on forced overtime in order to meet some deadline.  I consider this to be one of the worst kinds of failure.

Teams forced into this situation are typically faced with the worst of all possible choices.  Do we take shortcuts to get out on time and risk the quality issues that can come from that, or work long days and weekends, not have a life, and still likely introduce problems due to burnout?

It’s failure if you have to even ask this question, but let’s look at the choices anyway.

Keep Working 8 Hours

Hopefully this is the direction your management is leaning, but it comes with a cost.  In order to continue working at the same pace you must sacrifice scope or let the schedule slip.  Yes, personnel can change too, but I’m assuming that by the point you realize you need to make this decision that adding new people won’t get you to the finish line any faster.  Everyone must either accept the delay with the understanding that this is what is necessary to achieve the expected level of scope and quality, or strip out a few unfinished/untested features and move them to the next release (yes they should move to the top of your backlog).  This will let you release a working product of known quality without cutting corners.

Burn the Midnight Oil

Some people might not think this is so bad.  I think it’s one of the worst things you can do to your team.  What message are you sending when you’re forced into this situation?  To management?  To your team?  By deciding to work long hours, weekends, or even burning the midnight oil to put out the occasional fire (many of which were a direct result of those long hours and weekends) you’re sending the message to everyone involved that this is the new normal.
This sets a precedent and creates the expectation that all future situations like this will be addressed the same way.  Then the first time it doesn’t go this way (because you tried to do it the right way) you’ll catch flak about why your team is no longer dedicated to their job.  Do you really want to knowingly commit to 7-10s every few months?  Think of the children.

Evaluate Why

After you’ve made it across the finish line, you absolutely must evaluate how you got there.  How did you get into that situation to begin with?  Did the team commit to too much?  Did certain features take longer to implement or test than the team estimated?   Did the team not consider testing costs?  Were there a lot of unknown unknowns that crept in?  Maybe some other part of the process caused the schedule to drag?  You need to answer these questions in order to avoid this type of situation in the future.  

Don’t Go There

This is one of those cases where the best answer is to avoid asking the question in the first place.  Pull things that would normally be done at the end of a project earlier into the schedule.  Build your installer or deployment pipeline after the first couple weeks, produce system-level tests for each new feature you add (and make sure they pass before moving on!), do code reviews on a per-feature basis rather than monumental reviews at the end, etc.  The more frequently we do these things the better we get at them and it also has the welcome side effect of enabling us to be releasing almost all the time.
Remember, no matter what anyone tries to force you to do Quality Is Not An Option.  Be a professional and stand your ground.  This is a tough spot to be in, but burning your team out or torching the codebase with sketchy implementations will do more harm than good in the long run.
Comments are open.  I’m sure everyone has their own stories or advice to lend to this situation.  Let’s hear it!

Copyright © 2017 Life, Teams, and Software Engineering

Theme by Anders NorenUp ↑