As many testers have, I struggled in my first year on a Scrum team. How do I write tests without a spec? How do I know when I am done with software testing when there is no test plan? I present this article to show the important contributions that software testers on Scrum teams can make in the phase of feature and user stories creation.
It’s fairly hard to know what solid testing is all about within Agile and Scrum teams. What traditional practices are fine to continue, which ones need modification and what totally new approaches are necessary. Moving from traditional to agile testing is often a high-wire balancing act to some degree with no clear direction.
Backlog refinement is an important part of the Scrum team activity as it allows to gain a shared understanding of the work flow. Behavior-Driven Development (BDD) is a technique that use a business language to define acceptance testing (test cases) of requirements. In this article, Zia Malik explains how teams can use BDD to support product backlog refinement.
In his article “Creating an ATDD Ready Sprint Backlog in Scrum“, Ralph Jocham discusses the requirements definition in Scrum and how examples allows the team to better understand them. As the backlog is now also expressed in terms of business requirements, each team member can easily focus on the bigger picture during the Scrum stand-up meeting and align with the ‘why’. If you translate the business-facing examples into automated tests, it enables the team to verify during the Sprint that the software increment always meets the evolving requirements towards the Definition of Done and the overall goal.
In this article, Davide Noaro discusses the software testing phase of Scrum projects with a final Waterfall interaction. As Scrum’s adoption is often incremental inside an organization, both approaches can coexist for a while. Compared to a full Scrum approach is that, in this situation you are obliged to rerun the tests for the whole functionality to qualify the product before going to production. In the article, he presents how software testing has been integrated into his organization’s process and then analyze the objections that are sometimes raised on the software testing choice made, mainly that running tests for every user story is inefficient because they have to rerun them for the whole functionality during the Waterfall at end phase.
This is an on-going series of blog posts that want to answer the classical question: How is software testing done during Scrum sprints? In the first installments, Clemens Reijnen discusses the importance of having testing knowledge in the team and implementing a collaborative culture. He then presents regression testing, test automation, end-to-end testing, avoiding overlapping tests, product backlog item implementation sequence, risk and business driven tests, writing acceptance tests. Microsoft Visual Studio is used as an example of tools supporting software testing practices in Scrum sprints.
How do you manage activities that don’t seem directly related to features in your Scrum sprints? This blog post discusses why it is a problem when Scrum teams start to wonder about having time to manage infrastructure, technical debt or test framework. For Johanna Rothman this is the sign that the culture is not Agile enough and that the product owner doesn’t want to take iteration time to schedule anything other than features in an iteration. She offers seven hints on how to improve this situation, saying that product owners that don’t want to fund technical debt will instead create more of it.