In my previous post – Automated testing, Agile planning and the Theory of Constraints – Part 1 I discussed why teams that don’t write enough automated tests can run into problems with planning their sprints and how this relates to the Theory of Constraints (ToC).  When developers don’t write enough automated tests as part of development to validate their stories they shift a significant amount of basic testing work downstream to Quality Assurance (QA).  This can cause a cascade effect – stories get bottlenecked in QA which causes teams to find it hard to complete stories within their sprints so their velocity, the number of stories completed per sprint, suffers.  In response, teams will start to include QA time in their sprint plans because they don’t know what their planning constraint is and what they should be planning around – development or QA?

How this relates to the ToC is that the ToC stipulates that a system (the SDLC in this case) can only have one constraint.  The practices of estimating stories, calculating velocity and determining a sprint plan are all based on this, that is they all need to focus on one step of the process which almost always should be development (the constraining step in the process).  However, when teams attempt to plan across more than one role or step, for example development and QA, confusion can result because the relationships between estimates, velocity and sprint plans are less clear.

In this post I’m going to follow up by exploring three questions related to my first post:

  1. Why should development, coding and testing, be the constraint and not other areas of SDLC?
  2. Why not just add more QA team members to deal with a testing bottleneck?
  3. Why is it important for developers to both code and test their stories?

Question 1: Why should development be the constraint?

Estimates, velocity, and sprint plans all need to focus on development (coding and testing) as the constraint in the process and not other roles, such as Business Analysis (BA) and QA, for the following reasons:

  • Development is where the most value is added. It’s where requirements are developed into the primary deliverable, working software – functionality that is tangible and real that reflects all of the detailed implementation decisions that have to be made to transform a concept (requirements) into something that can be demonstrated to others (working software).
  • As per the ToC, a system where the constraint is not running at full capacity is not generating as much value as it could be.  As development adds the most value, we need a plan (the sprint plan) to ensure that development capacity is fully utilized each sprint.

Question 2: Why not load up with QA to remove a testing bottleneck?

One could argue that an effective solution to stories getting bottlenecked in QA when developers don’t write enough tests would be to add potentially less expensive, more abundant QA staff to the team to fill the gap. In this case logic testing, which should be done by the developers when they write automated tests, gets passed downstream to QA.  QA now becomes involved with both creating quality and ensuring it, whereas they really should just be focused on the ensuring part.  This approach can lead to long QA and regression cycles and should be avoided for the following reasons:

  • When QA does logic testing and encounters something they don’t understand they will not be as familiar with the implementation of the story compared to the developers. In response, QA will end up spending time communicating with the BAs and developers to understand the requirements and how they were implemented, deciding on whether things are working properly, and reporting their findings for consumption by the development team.  QA identifying issues, managing and validating fixes is waste and needs to be reduced as much as possible as it does not contribute to the end deliverable.
  • Having QA do logic testing is not an efficient cycle because it potentially promotes a “if it’s important then QA will catch it” attitude by the developers in the coding and testing cycle.  Quality is a team responsibility, it should not sit solely on the shoulders of the testers.
  • The earlier an issue is discovered in the development process the easier and less expensive it is to fix. Developer testing promotes discovery of issues early which is more efficient.
  • Getting to “Development Complete” assumes robust functioning software complete with automated tests.  This allows QA to focus on testing where they can more effectively leverage their skills, specifically behavioural and boundary case testing, resulting in a higher quality deliverable.

Question 3: Why is it important for developers to both code and test their stories?

Related to questions 1 and 2 above is the idea that developers need to both code and test their stories, ideally by writing automated tests.  Test Driven Development of course takes this concept to the extreme, but that’s a separate topic.  Reasons for including both coding and testing as part of “development complete” include:

  • Only during and after coding and testing can real feedback be obtained on how well the story will actually function.  Developers are best suited to interpret and address this feedback because they best understand how the story was implemented.
  • When developers code and test their stories they create a very tight feedback loop within the development step.  Extending this feedback loop, that is making it less tight by involving QA, is less efficient.  Lines of communication outside coding and testing are more formal around defect reporting, etc. – this feedback takes time and introduces additional communication overhead which makes this approach less efficient compared to having the developers process this feedback themselves during the coding and testing step.  As noted above, this is waste.

To conclude, it’s important to remember our recommendation from my previous post: base estimates, velocity and sprint plans strictly on developer effort and time, and ensure the developers are writing sufficient tests so that QA can instead focus on testing ideas, that is behavior and boundary cases, and not logic.