Category Archives: Testing

Agile and Lean Bookshelf

Some books on lean and agile software development.  The list is still in development.  I’ve read all of these books and will not place books here that I have not read. Some books resonate more than others, but still don’t expect instant recall of all the detail – rather the key ideas and concepts and then drive into the detail if required.

You’ll find some books are relevant to more than one section, so they will be repeated in the sections in which they have relevance.

The Lean and Lean Startup Side

Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated  The archetype Lean book for the Western Reader from leaders in the field. Real life case studies of people over process.
This is Lean: Resolving the Efficiency Paradox
Running Lean: Iterate from Plan A to a Plan That Works (Lean Series)
Kanban: Successful Evolutionary Change for Your Technology Business  Start with this for Kanban, let it sink in, read others and then come back to this.
Leading Lean Software Development: Results Are not the Point
The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
The Goal: A Process of Ongoing Improvement
Kanban in Action  I nice start for those wanting to learn about Kanban, don’t ignore David Anderson’s book though!
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win  Systems Thinking for IT People.  Be nice to those Brent’s they only work in a system.
Lean from the Trenches: Managing Large-Scale Projects with Kanban
Kanban and Scrum – making the most of both (Enterprise Software Development)
Personal Kanban: Mapping Work | Navigating Life
Lean-Agile Software Development: Achieving Enterprise Agility
Lean Software Development: An Agile Toolkit
Lean Enterprise: Adopting Continuous Delivery, DevOps, and Lean Startup at Scale

The Agile and Lean Frameworks Side

Essential Scrum: A Practical Guide to the Most Popular Agile Process (Addison-Wesley Signature Series (Cohn))
Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Addison-Wesley Signature Series (Cohn))
Kanban: Successful Evolutionary Change for Your Technology Business
Scrumban – Essays on Kanban Systems for Lean Software Development (Modus Cooperandi Lean)
The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban (Agile Software Development Series)
Real-World Kanban: Do Less, Accomplish More with Lean Thinking
Agile Project Management: Creating Innovative Products (2nd Edition)
Agile Software Development with Scrum (Series in Agile Software Development)
Kanban in Action
Agile Project Management with Kanban (Developer Best Practices)
Agile Project Management with Scrum (Developer Best Practices)
Lean from the Trenches: Managing Large-Scale Projects with Kanban
Kanban and Scrum – making the most of both (Enterprise Software Development)
Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust
Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series)
Lean Software Development: An Agile Toolkit
Succeeding with Agile: Software Development Using Scrum
The Art of Agile Development
Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise (IBM Press)
Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series)
Scaling Software Agility: Best Practices for Large Enterprises
The Software Project Manager’s Bridge to Agility
Scrum and XP from the Trenches (Enterprise Software Development)
Actionable Agile Metrics for Predictability: An Introduction

The Technical Side

Domain-Driven Design: Tackling Complexity in the Heart of Software
Pair Programming Illuminated
ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (Addison-Wesley Signature Series (Beck))
Agile Testing: A Practical Guide for Testers and Agile Teams
The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)
Clean Code: A Handbook of Agile Software Craftsmanship
Code Complete: A Practical Handbook of Software Construction, Second Edition
The Pragmatic Programmer: From Journeyman to Master
Growing Object-Oriented Software, Guided by Tests
Agile Software Development, Principles, Patterns, and Practices
Patterns of Enterprise Application Architecture
Refactoring: Improving the Design of Existing Code
Refactoring to Patterns
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))
Continuous Integration: Improving Software Quality and Reducing Risk
Test Driven Development: By Example
Pattern-Oriented Software Architecture Volume 1: A System of Patterns
Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects
Design Patterns: Elements of Reusable Object-Oriented Software
Extreme Programming Applied: Playing to Win
Writing Solid Code (20th Anniversary 2nd Edition)
Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
Working Effectively with Legacy Code
Dependency Injection in .NET
Effective Unit Testing: A guide for Java developers
The Art of Unit Testing: with Examples in .NET
Pragmatic Unit Testing in C# with NUnit

The Product Ownership and Agile Requirements Side

User Story Mapping
Scrum Product Ownership: Balancing Value from the Inside Out
Working Effectively with Legacy Code
User Stories Applied: For Agile Software Development
Agile Estimating and Planning
Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series (Cohn))
Impact Mapping: Making a Big Impact with Software Products and Projects
Specification by Example: How Successful Teams Deliver the Right Software
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
The Principles of Product Development Flow: Second Generation Lean Product Development

The Agile Tester Side

Agile Testing: A Practical Guide for Testers and Agile Teams
More Agile Testing: Learning Journeys for the Whole Team
The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers)
Testing for Continuous Delivery with Visual Studio 2012 (Microsoft patterns & practices)
ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (Addison-Wesley Signature Series (Beck))
Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration (Net Objectives Lean-Agile Series)
Specification by Example: How Successful Teams Deliver the Right Software
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
xUnit Test Patterns: Refactoring Test Code
Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing
Effective Unit Testing: A guide for Java developers
The Art of Unit Testing: with Examples in .NET
Pragmatic Unit Testing in C# with NUnit

The People Side

The Five Dysfunctions of a Team: A Leadership Fable
The Introvert Advantage: How to Thrive in an Extrovert World
Emotional Intelligence: Why It Can Matter More Than IQ
Fearless Change: Patterns for Introducing New Ideas
Turn the Ship Around!: A True Story of Turning Followers into Leaders
Management 3.0: Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn))
Peopleware: Productive Projects and Teams (3rd Edition)
Drive: The Surprising Truth About What Motivates Us
Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency
Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))
Death March (2nd Edition)
Agile Retrospectives: Making Good Teams Great
Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision
The Core Protocols: A Guide to Greatness
Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers
Dynamics of Software Development
Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)
Project Retrospectives: A Handbook for Team Reviews
The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully
Who Moved My Cheese?: An Amazing Way to Deal with Change in Your Work and in Your Life
The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change
Liftoff: Launching Agile Teams & Projects
The Fifth Discipline: The Art & Practice of The Learning Organization
Switch: How to Change Things When Change Is Hard
Start with Why: How Great Leaders Inspire Everyone to Take Action
Team of Teams: New Rules of Engagement for a Complex World
Principles Of Software Engineering Management
Emotional Intelligence 2.0
How to Win Friends & Influence People
Smart Questions: The Essential Strategy for Successful Managers
Great Boss Dead Boss Recommended by David Anderson in KCP Training. A model of identity.
Lessons in Agile Management: On the Road to Kanban
Thinking, Fast and Slow Science on how parts of the brain work. Involuntary vs Logical parts
Nonviolent Communication: A Language of Life, 3rd Edition: Life-Changing Tools for Healthy Relationships (Nonviolent Communication Guides) Judging or helping? Which is more helpful?

 The Organisational Side

Reinventing Organizations
Team of Teams: New Rules of Engagement for a Complex World
Maverick: The Success Story Behind the World’s Most Unusual Workplace
The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer
Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results
Why Plans Fail: Why Business Decision Making is More than Just Business (MemeMachine) (Volume 1)

 The Coaching Side

the act of coaching is distinct from the People and Organisational Sides although strongly linked

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn)) It’s a start but it won’t be enough
Executive Coaching with Backbone and Heart: A Systems Approach to Engaging Leaders with Their Challenges For real meat on the act of coaching. Years of experience here
Co-Active Coaching: Changing Business, Transforming Lives More meat on the idea that people have the ability to solve/change/improve their lives. Partnership wit a coach
The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever A good start, go to other sources still for more detail
A More Beautiful Question: The Power of Inquiry to Spark Breakthrough Ideas Build that muscle of inquiry first before jumping to a solution
Flawless Consulting: A Guide to Getting Your Expertise Used A consultant’s book every coach should have!
Advertisements

Test Infected Developer

TwoBearsDeveloping

Lisa Crispin and Janet Gregory’s seminal book, Agile Testing, refers to fellow agile author and coach Jonathan Rasmussen as a Test Infected Developer.

The story as presented in the book describes the first encounter between Jonathan Rasmusson and Janet Gregory.  Jonathan’s first reaction was to think there was no role for a tester in an XP (extreme programming) team. Janet’s inital response is long forgotten, however the value she introduced was displayed in the next six months. Automation of the low level test cases allowed her to focus on more value add areas like Exploratory Testing.  Jonathan was thus converted and saw the valuable role of a tester on a team.

They also go on to say a happy result of Agile Development is that many programmers are ‘test infected’. An agile team is happily test infected.

This essentially means that everyone is pulling for the team. Testing becomes a task rather than a role. What’s good for goose is good for the gander.

The aim is to deliver more value for the customers. Testing and the Testers mindset from the beginning of the project is an important part of the process as it can effect everything from requirements gathering through to installation and all points in between.  In requirements gathering we are questioning to ensure we build the right thing and during the build we are building it right!

If you are a developer who unfortunately does not have access to a (agile) tester you will need to take these skills on if your haven’t already.  I’ve personally been in the place a few times in the past and adopting the testers mindset and directing yourself to the most value adding tests results in a much better result.  This is not necessarily to be confused with the very specific role of Software Developer In Test which some teams employ – although the swarming, t-shaped skills mindset still kicks in to ensure the value (value trumps output) is delivered for the customer.

Key Takeaway

We can all learn from each other and develop those T-Shaped skills that help deliver solutions faster.  When we have testers available we can accelerate even more, when we don’t we need to fill the role ourselves.  Either way we should and need to be Test Infected.

With this important part of our toolkit, we can delight our customers and get onto the next great thing. A win-win.


Agile and Efficient Requirements Workshop Tips

Agile requirements gathering is an ongoing task that occurs throughout the build of an application or project.  We never, ever, generate the full requirements up front as this assumes we have learnt everything.  This is hardly ever the case as we learn as we go as we get better at the domain we are working in and the feedback we receive from users.  It also means we don’t waste time on ideas that may not be needed. This great article gives more reasons as well. We must be careful to also focus on goals and avoid creating solutions (e.g. the system shall…) as we gather requirements.

One of the tools available to a team is the Requirements Gathering Workshop.  This is a focused and time-boxed activity to increase our learning and understanding of the domain.  Gojko Adžić has written about this quite extensively.  Other ideas like Deliberate Discovery and Feature Injection assist as well.  But for workshops Gojko provides solid reasoning.

I’ve summarized his thoughts on requirements workshops from his book Bridging the Communication Gap.  He builds on this in his subsequent book Specification by Example.  If you buy Specification by Example you can get Bridging the Communication Gap for free from Gojko.  This is a summary so don’t expect a full explanation here.  Hopefully you still find similarity in your own experiences and a reason to seek out Gojko’s pragmatic and useful books.

He also gives great training (from what I hear/read from Perth Western Australia – he’s in the UK).  I also include this in my course on Agile Testing for which this post is also a little plug for.

  • Diversity is an advantage.   Avoids GroupThink and embraces Wisdom of Crowds.  Diversity includes different roles, backgrounds and don’t forget the stakeholders.
  • Agreement should be reached within the timebox. Max 4 hours for a two week iteration.
  • Knowledge Transfer is key. It will allow suspect issues to be surfaced quicker.
  • Challenging of ideas is encouraged until agreement is reached.
  • Ok to come to a workshop with ideas – but they need to be critiqued.
  • Go to the source – avoid third parties and telephone game info.
  • Output are examples, not solutions. This will limit flow and is the wrong time to discuss solutions.
  • Examples are good, the most important output is Shared Understanding
  • Run Feedback exercises to measure understanding. Differences in feedback indicates misunderstanding exists
  • Common Language to avoid translation between business and technical jargon.  Use the language of the domain.
  • Not a Meeting and favour smaller workshops to remain focused
  • Not a Presentation – not how the system will work.
  • Open Discussion focussed on goals

Who can Facilitate – a role for a Business Analyst

Don’t have access a professional facilitator?  Got a Business Analyst?  Use them.  The role business analysis is transformed in an agile team.  No need to fear as a BA can provide constant and valued input at an increased level of effectiveness than in a traditional process.

The role is transformed from ferryman of information using the lowest bandwidth communication (documents) to a facilitator using highest bandwidth communication (human communication face to face).  Developers benefit from your valued input via the facilitation during the workshop, chasing down pesky issues, chasing greater business value. Because they don’t miss the vital points and aren’t subject to ambiguity and misunderstanding as before, you’ll have time to do this.

By automating the specification into an executable specification trace-ability is improved and tracking of progress is improved as well.  Costs come down and more value is delivered quicker.  Value can be created elsewhere (see the Pareto chart here).

Your confidence goes up and stress levels come down and rituals like CYAM are removed.

The role of the BA has a lot to offer in an Agile setting!  Here’s a great drawing from Lynne Cazaly summarizing the role of a BA in a talk given by Bernd Schiffer and Chris Chan.

Role of BA


A quote on Test Driven Development from 2003 – Sometimes you need to fail

Wow – I was searching my email for something else and in passing re-discovered this except from an email I wrote in 2003.  I still struggle with this in 2014. Here it is as is with small grammatical errors included:

“I did this last week with someone on my team at InfoHealth.  This person had not unit tested the code (properly) and there were loads of errors.  I fixed them by first writing the tests to catch the bugs and then methodically fixing them.  I finally got to a green light. Yay.

A couple of days later this person changed something and whammo the website we were working on was giving the wrong results.  This person was really having a rough time of it trying to find out what the problem was.  I offered to setup the test harness on his machine but it didn’t eventuate (he had tried himself and was unsuccessful getting it to compile).  The next two days he was away.  I logged on to his machine and got the test harnesses to run and show the first error.  I didn’t proceed to fix them though.

He then came back in.  None of the bugs had been fixed yet after a day of some fruitless bug fixing previously. I suggested him to fix the bugs through the test harness.  He ran the harness and discovered the first error and fixed it, and then the next and then the next.  After about 90 minutes and fixing 9 or 10 bugs he was done.  He comment afterwards was ‘Testing was never so much fun’

Hopefully I gained a convert to Test-Driven development.  Only after demonstrating a regression test suite it made all the difference.  This person was not on the project where we had previously done Test Driven development and I felt he was a somewhat cynical person as well who gently needed to be shown the light.

And so ends my anecdote.”

Testing is so important but we are still refining the practice.  Lately James Coplien and David Heinemeier Hansson (DHH) have been wanting to scale back unit testing (both from different angles), removing some of the pedantic nature (my words).  DHH wants to take it out a level to the integration.  They both have valid arguments.  See DHH’s article for more and this will have links to James Coplien’s ideas as well.  On May 9 2014 Kent Beck, Martin Fowler and DHH will be discussing TDD in a google hangout entitled Is TDD Dead.  It should be interesting and I’ll be tuning in.

Testing exists somewhere and we are trying to get to the sweet spot, balancing the risk mitigating advantages and the ROI on creating and maintaining them.

Edit: The second episode of the TDD occurred last Friday 16 May 2014.  DHH struggled a little with his argument the TDD creates bad design. Perhaps more like inexperienced programmers create poor designs. James Shore weighs in here.

The HeartBleed bug and GOTO Fail bug in Apple products could have been prevented by a unit testing culture and saved a lot of time and money as a result.  This article from Mike Bland explains.  I’m of the same mindset that we should not resign ourselves to an acceptance of complexity and that these things ‘just happen’.  Simple design and unit testing would have greatly mitigated these issues.

The non-unit testing culture means there are probably many other bugs waiting to be discovered.  The relatively small impost on time to do unit testing and do it well is paid back many times over.

The twitter hashtag #IsTDDDead is covering the debate, although now seems to be simmering down.

Uncle Bob Martin puts TDD in the context of Teams, paraphrasing – Good personal hygiene is good for the team.


Real Business Value of Testers

Another reminder type blog post that may or may not get further expanded upon 🙂

Liz Keogh says:

“If you don’t have actual testers, get someone to play that role. Someone who *isn’t* a dev. Us devs are very good at abstraction, and will start solving a problem before we see the whole problem. I don’t believe that an awesome dev can also be an awesome tester, or vice-versa.”

I wonder if we still need tools.  James Shore says the tools are a waste in 2010.  Was in kind of agreement there with him.  But there is value in the thinking process and dev’s can’t do all of this.   I need to revisit Jame’s article from then to make sure I’ve got all the nuance and not glossed over details.

Tools help but that’s not the be all and end all.  Remember the Agile Manifesto.

I tend to think the Agile Tester (more so than the traditional tester) can be a great productivity booster and very valuable to the organisation.  Their critical thinking at the beginning should be regarded as a blessing.  I’ve also worked with some great testers at end of the cycle, but you can also feel their frustration as well.  We can help each other 🙂

This is a reminder only – ideas are still forming – but the conversation is nonetheless open.