Testing in Agile: The Sprint Is Too Short!

Testing in Agile: The Sprint Is Too Short!

While many developers love Agile, testers... not so much. "It's not possible to finish all the testing in one sprint", "the sprint is too short, let's add a week", "we need two or three weeks to complete the regression"... Have you ever heard any of these? I hear them all the time.

Agile changed our approach to development but testing sometimes still comes as an afterthought. In some ways testing became even more challenging. Here's a short list, to mention just a few issues typically experienced by testers in Agile environment:

  • Testing in the midst of code changes makes it hard to establish a baseline.
  • Development drops late in the sprint cycle don't leave enough time for testing.
  • Infrequent builds/deployments create delays and downtime.
  • Not enough testers to plan, document and execute the test cases.
  • Not enough time to go through functional, integration, regression, usability, security and other testing.
  • No time to review, fix and retest defects found late in the cycle.
  • Lack of knowledge and communication across testers, developers, SMEs and other specialists.

But if we read this list carefully, we'll notice that none of these issues are really caused by the length of the sprint. Three or even four weeks instead of two wouldn't make a difference when it comes to the lack of communication or knowledge, amount of manual testing, delays caused by manual or infrequent builds, late drops, and defects found on the last day of the sprint.

The challenges of Agile testing are not caused by the sprint length.

So what do we do?

We split the testing into two parts: tests directly related to the user stories developed during the sprint, and everything else. Then we defer the "everything else" to the end of the release, which happens every several months.

Here's the truth: all we can do during the sprint is pretty much just the functional testing. We're not doing much of the integration, regression or performance testing until right before the release. We call this final system test a "regression sprint" or "hardening sprint". Sounds familiar? If you nod in agreement, don't worry, you're not alone. This is a very typical Agile implementation across the industry.

Unfortunately, it's a BAD idea.

We say we try to mitigate the issues and challenges of Agile testing, but we don't really solve the problem. By pushing the major testing effort to the very end of the release we increase the risk, compromise quality and don't use the main advantage of Agile - ability to deliver value to the customers often in small increments.

So, adding the hardening sprint doesn't really help with the problem of sprints being too short.

The sprint is too short only if you planned more than you could realistically deliver

The real goal should be to eliminate the hardening sprint and to complete all types of testing during the sprint, however short or long it is. This way every sprint would end with a set of fully tested features that could potentially be deployed to Production or shipped to the customer. There would be no need for the context switch at the end of the release, no last minute defects and costly delays.

Do you still have hardening sprints? Do you feel like your sprint is too short?

Then join me on this journey and make 2017 a year of high quality and true agility.

Let's start the new year with some important decisions and pledge to make our solutions truly agile. Let's improve our quality and deliver software updates to the customers when they need them. Let's stop complaining about sprints being short and start being realistic about our planning. Let's eliminate manual builds, deployments and tests where possible, automate regression tests and run them on daily basis during the sprint. Let's update our definition of "Done" to include all types of testing.

Let's get rid of the "hardening" cycle.

Let's complete all of our tests within the sprint!

Here's a practical guide to testing without feeling that the sprint is "too short":

Did you like my post? Please like or share with your network. Follow me to read my posts and send me your questions about practical Agile. 

Carl Weller

Principal Consultant and Ways of Working Practice Lead at Sentify

7 年

Main issue called out, and agree it's a real one, is a 'weak' definition of done that isn't being worked on over time. Obviously automation would help, but that is a solution that's only required if the team expands its DoD. What the author describes smells a bit like 2 week waterfall and it's not even fair to blame Scrum. Yes Kanban would give more visibility within the sprint and maybe reduce a peak of work hitting test at the end of the sprint, but if the team doesn't fix its DoD issue Kanban won't help either. Secondary issue might be story splitting and sequencing - INVEST anyone? Let's not trash methodologies due to poor implementation (although now that I've said it, it is a fairly common practice to do just that!).

回复

Nice article. Agree this will work if eack team is full stack feature delivery team, but not when have multiple agile teams/trains all delivering parts of a large Release. There will be "integration" and other tests that can only be done when an entire story/flow is ready which may not be possible to line up to the same sprint timeline.

回复
Dean Peters

Product Management Trainer, Consultant, & Mentor | Innovation Coach & AI Tamer | Hakawati (??????)

7 年

Great points. Being a product peep, I might offer one more: write stories INVEST enough that they don't contribute to late drops and/or hardening sprints.

Tristan Bagnall

Business AI Transformation Strategist | Helping Leaders Navigate Market Volatility & Drive Sustainable Growth | Creating 40% Faster Strategic Alignment & Building Resilient Teams in Uncertain Times | CEO @ Veritern

7 年

I have heard the same story so many times. You are right everything needs testing during the sprint, there can be no period at the "end" when you find issues you spent ages building on top of and then try to fix them. Best to release at the end of each sprint and get feedback - then you find yourself ensuring you test during the sprint.

回复
Salman Khan

Information Technology Partner, Building Products, Getting things done!

7 年

Testing does not start once the developer signs off. Testing starts during grooming. There was another article about testing, I can't find it now -- basically, testing specifically in Agile is not one person job, it is a team activity, a mind-set. We test everything, the team tests the story for completeness before committing it to sprint, story effort must include requirements, development and testing effort. There must be an collaboration between testers and developers -- so incremental testing can be done. The daily stand up -- commitments -- must include impediments and acted upon. If testing sign off or stakeholder sign-off cannot happen in sprint. Then as-things-stand there is an over commitment. Flags need to be raised, vested interests notified, be agile, pull something out.

要查看或添加评论,请登录

Katy Sherman的更多文章

社区洞察

其他会员也浏览了