Get certified - Transform your world of work today

Close

Software Testing in Scrum

Do testers find it hard to adopt Scrum?

9 November 2015

Chinthaka Pietersz
MillenniumIT


Software testing can be defined as a process for running a program or application to find software defects. According to Philip Crosby's definition of quality, testing is conformance to requirements (1979, 16). So software testing is an important activity, especially in mission-critical software. End users expect 100 percent error-free software.

Testing is done during the later phases of the traditional software life cycle. Testing is frequently considered the final activity before the delivery. At the same time, testers' knowledge of the requirements and client's expectations are sometimes low when we look at today's Scrum teams.

Is it difficult for testers to adapt to Scrum? I don't think so. But it can be a little uncomfortable for some testers to transition to Scrum. Traditional testers are used to sitting in a cubicle, with little human interaction, focusing only on their testing activities. They don't feel responsible, overall, for what they have tested. But it's necessary for testers in Scrum teams to become accustomed to more frequent and meaningful conversations with teammates, and sometimes even with product owners or clients. One of the biggest challenges is learning how to work iteratively. In the first few sprints, testers have to learn the real expectation of the client and how the test suite should be worked.

Increasing test automation becomes the hallmark of Scrum teams, especially during the regression pace in the final sprints. Likewise, knowledgeable automation testers always give an extra advantage to Scrum teams. So one can clearly see that testers who transition to Scrum are making a smart move. Testers in Agile teams have more influence in the development process, and they have overall responsibility for the end product.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.6 (5 ratings)

Comments

Sayi Sarat Chandra Parvatam, CSP,CSM,CSPO, 11/9/2015 7:17:06 PM
You article brought out important points - Thank you :)
Niroshan Madampitige, CSP,CSM, 11/10/2015 4:34:23 AM
Good points! These are some of the challenges we have. Together with automation, we must involve testers, test lead etc to all Scrum ceremonies including pre-planning, daily scrum to retrospectives. This allows testers to be fully updated and therefor, for them to test sprint output effectively. We faced the same issues and once we got QC involved closely, things started to work well :)
Robert Day, CSM, 11/11/2015 8:24:37 AM
Testing always has to be a process which involves the testers with the rest of the development process, from requirements capturing through to delivery; otherwise, how do testers ultimately know that the product is fit for purpose? And the testing should not end once the product is shipped; there should be some degree of support, if only in the initial release phase, so that testers can say "Yes, that's a known feature" or "That's not anything we ever encountered in testing - let's raise that as a warranty bug", or even "You're doing WHAT with it? We never designed it to do that..."

Integration of testing with an Agile environment can be quite rewarding. On the last project I worked on, the Sprint activities of the testers was essentially testing the Sprint output of the developers one Sprint later - so Sprint 1 output was tested during Sprint 2 and so on. The developers built bug rectification time into their estimates, and bugs were rated as to their impact. The highest priority bugs were dealt with as soon as they were identified; lesser priority bugs went onto the backlog to be picked up as seemed best. A few low-point bugs on the backlog turn out to be ideal to fill in a little bit of spare capacity in a sprint or for the developers to score a few quick wins.
Niroshan Madampitige, CSP,CSM, 11/11/2015 9:13:47 AM
Hi Robert,For me Chinthak's points make sense. It's not clear if you agree with Chnthaka's point of view or not! particularly, when a traditional team is trying to adopt scrum,there are practical problems that Chinthaka tries to bring up(at least a few of them).So in your team, don't you do testing within a given sprint for the same sprint? If so, how did you ensue what you demo or produce within a given sprint has met quality measures prior the sprint finishes? Also, can you elaborate what was your team's DOD? I agree on your approach in testing the previous sprint within the current sprint? But there is a gap in the quality aspect within your current sprint deliverable? The quality assurance has to happen within the same sprint and that should be part of your DOD. Thanks....
Chinthaka Pietersz, CSM, 11/12/2015 11:53:15 AM
Thank you Sayi Sarat Chandra Parvatam.
Thank you Robert Day, Niroshan Pushpa Kumara for your valuable ideas.
I think Niroshan has got my point correctly. My primary idea is to point out some the practical problems that traditional teams are facing when they are adopting to scrums.

Points and questions still to discuss. Thanks.
Manikandan Raman, CSP,CSM, 11/13/2015 1:08:58 AM
Very Nice Article.. Actually, Testers are empowered in Agile world as they are involved along with Developers in all ceremonies and discussions. Over a period of time, they can look for options to swap roles with Developers that make a complete cross functional scrum team.
Michael Kuesters, CSP,CSD,CSM,CSPO, 11/13/2015 3:51:16 PM
Testers are "only" one of the responsibilities in a Scrum team. We don't even call them testers any more. They are team members with a focus on quality assurance.

The real challenge is becoming Cross-Functional, i.e. breaking out of the "checking other people's work" habit. But it's rewarding.

One side comment, though: Nobody expects 100% error free software, because that's a utopia.
People expect software that does what it's supposed to do- it's not about finding even that last little elusive bug that nobody would have noticed. It's about making sure the customer gets their value!
This may also be hard for traditional testers to comprehend.
Anushankar Ramadoss, CSM, 11/17/2015 12:11:21 AM
I agree with you Mike. Throughout my IT career, Quality Assurance Team Members have seen the s/w application or product as a box of bugs and NOT a value adding toolkit. Probably they have to turn optimistic about the product and start "using" the same instead of testing it (atleast in the early rounds of testing).

Again there are so many good testers contradict my thoughts. Hats off to them!
Robert Day, CSM, 11/19/2015 10:42:52 AM
Niroshan and Chintaka,

I was really trying to take Chintaka's ideas further based on my own experience.

On the project I was referring to, the development was being done by a separate team, and the functional/acceptance testing was done by the test team, who are part of the product owner's organisation. So we didn't get the end-of-Sprint deliverables released to us until the end of the Sprint. We weren't really a part of the development team and our test work wasn't in their product backlog; but we had to keep up with the development process. The product wasn't deployed to the business until the end of the last Sprint.

On our current project, there is a development team in-house as well as an off-site development team. The test stories are part of the backlog but are very dependent on what is actually shipped in each Sprint. This sounds like a fairly unwieldy way of doing things and neither of these projects would meet everyone's definition of Agile! But we are where we are, as the saying goes.
Robert Day, CSM, 11/19/2015 10:46:58 AM
Anushankar,

Certainly in acceptance testing, the difference between 'using' and 'testing' the product can often be quite minor; and as Michael says, no product can ever be 100% bug-free. And real-world users will find novel and imaginative ways to break applications that testers have never thought of!
Robert Day, CSM, 11/19/2015 10:50:02 AM
Chintaka,

In short, the answer to your question, "Do testers find it hard to adopt Scrum?" is "Yes!". If the testers aren't part of the same development team, we have to fit in with whatever DoD the developers settle on.
Niroshan Madampitige, CSP,CSM, 11/26/2015 11:02:19 AM
Anyone in Colombo, please join our next scrum meetup. One agenda item is 'Testing in scrum teams'http://www.meetup.com/Scrum-Meetups-in-Colombo/events/226441849/
Sunil Nair, CSM, 12/17/2015 9:02:22 AM
Thanks for the post Chinthaka.

As a software test professional for the past 15years (and part time CSM) I've seen scrum (or elements of it) being adopted in many ways. Sometimes as a hybrid within a larger waterfall process, "pure scrum", "pure agile" and DevOps.
I think Michael has hit the nail on the head, its about the team.

Scrum teams that don't have someone with a tester's focus are likely to come into trouble sooner or later.
I find it astonishing that in today's world there are those that go ahead with building a Scrum team without a tester role being filled.

We, as a Scrum team, are all responsible for quality.
As a tester I have relished the ability to influence design, implementation and the end product. When quality is built in from the early phases of a project it does lead to a product that meets the customer's expectations.

There is much talk about the role of a traditional tester becoming obsolete as automation and TDD etc are adopted.
However, I like to see tester's as the conduit between customers and the design/development teams. Being fully immersed in Scrum as a tester enables us to impart our experience and knowledge of quality upon the whole Scrum team. Ultimately leading to a quality product - with a little luck ;)

We move forward together as a team and, slowly over time, the lines between dev/testers start to blur. Testers who are not so technically minded to start with begin to understand the finer sides to product development and the developers begin to appreciate the value of building quality in from the bottom up. Often leading to more collaboration and lower costs in building the product.

If a customer representative is also part of the Scrum team then this can be hugely beneficial for the outcome too. The customer helps to refine functionality to ensure its what they want and also gains important knowledge of the challenges faced by a Scrum team and how they can help to ensure the product is tested to meet their needs before UAT and downstream activities happen.

Sorry if I've gone off topic, I just feel a holistic approach is required to scrum and seeing testers and developers only in their traditional roles makes adoption far more challenging and benefits realisation harder to achieve than it should be.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe