Test-First for Quality

May 7, 2017 — Posted by Al Shalloway

Quality is a pretty open ended term.  Test-first is often thought of as implementation and verification – is the code being written of high quality?.  But there is also quality to the customer – is the right thing being built?   There is also the quality of the culture of the organization developing the software – is collaboration present?  And finally, the quality of the process being used – is it efficient? Test-first can actually help with all of these.

So what is “test-first”?  It obviously isn’t just about testing since there’s nothing to test at first.  Test first involves several aspects.  Its most familiar one is deciding on the desired behavior in a collaborative way.  It is often elaborated in the Given-When-Then format.  It can also be combined with mock objects and design patterns thinking.   I’ll discuss the impact of these three aspects first, then I’ll extend test-first to the front of the value stream and see how it can be even more useful.

Deciding on the behavior you want in an interactive manner

This aspect of test-first requires the customer (or their proxy), the developer and the tester (these last two roles may be fulfilled by the same person) to work together in defining what is needed.  This improves the following:

  • Collaboration since the three different roles now work together instead of working in phases
  • Clarity on needs. Creation is facilitated by discussion.  Demanding that people with different backgrounds and ways of thinking work together results in moving from abstract ideas to a more concrete statement of what is needed.
  • Better Internal Design.  It is a well established phenomenon that thinking about the tests before writing the code to implement it improves the design of the code (see Define Tests Up-Front, a chapter from Essential Skills for the Agile Developer: A Guide to Better Programming and Design).  This also happens to be the first mantra of design patterns – design to the desired behavior, not the implementation of the code itself.

Use Given-When-Then

One of the challenges we see developers new to Agile have is breaking large stories into smaller stories.  This is especially difficult when the code being written is seriously technical in nature.  By making the situation (the Given) tighter as well as narrowing the case to handle (the When) the work to handle (the Then) becomes smaller.  This helps with:

  • Decomposing large stories into smaller stories because each story deals with a smaller amount of functionality
  •  Facilitating the automation of tests because Given-When-Then is the basis for most popular test frameworks.

Add mocking and design improves:

  • Intra design – that is, how different objects (possibly being built by different teams) because the behavior of the objects working together is known early
  • Emergent design.  That is, design that evolves over time.  This enables the design to change over time as new requirements are discovered.  See Refactor to the Open-Closed, another chapter from Essential Skills for the Agile Developer: A Guide to Better Programming and Design).
  • Sustainability.  One challenge with writing tests-up front and automating them is that changes in requirements often require changes to several tests.  With proper design of the tests (we call this Sustainable Test-Driven Development) tests can be written where a change in a single requirement results in only one test needing to be changed.

Drive From Business Value

People often think that the point of origination for defining the business value to be built and the testing of its implementation are at opposite ends of the spectrum.  In fact, however, Acceptance Test-Driven Development can provide an over-arching view of the entire value network.  In particular, we can:

  • Refine our Minimum Business Increments (our preferred term for Minimum Viable Products) by clarifying the behavior of these chunks of value.
  • Clarify responsibilities by having clear roles in defining what is responsible, how it is built, and how it is validated. 
  • Manage Work-in-Process (WIP) more easily when smaller chunks of value are worked on and what each chunk represents is clearly defined.
  • Improve alignment across the organization because teams understand that their focus is on building value, not stories.  So they coordinate across the teams in order to get an MBI’s value delivered quickly

In Conclusion

Test-First is both a way of thinking and a way of working.  It represents a way of collaborating to better understand what to work on, how to decompose this work into small pieces, how to design the code that implements it and how people can align to be able to realize the value quickly when multiple teams are required.  There is so much value here that we, at Net Objectives believe, it should be one of the primary starting points for most any transformation to Agile.

For more, see Built in Quality With Test-First (either live May 9th or a recording afterwards).  If you are interested in learning more about test-first and/or how you can take leading edge training in it, please contact me at alshall@netobjectives.com

Al Shalloway

CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban