Can scrum work for testing projects?

Question

Hi, can anyone comment on whether scrum works for testing projects? Meaning if my company gets a testing project can I implement scrum in it?

Answer 1

Testing project means you get an existing system or application, and your task is to find faults and bugs in it? I don't see that scrum couldn't be used. You might need a good scrum master. In the end, choose what best suits your team.

Answer 2

I've never done it, but it seems like Scrum would work well. Each iteration, you should identify the things that need to be tested and add them to your backlog. The customer can prioritize the important parts, and you test as many of them as you can each iteration.

Answer 3

You'd have to adapt Scrum to make it work. That is, the activities that you do: planning, daily stand-ups, reviews, retrospectives, could all be made to work for pretty much any type of project, but you'd find that a lot of the descriptions of what Scrum is don't really apply. You're not, for instance, categorizing new features per se for inclusion in the iteration. You pretty much have the set of features to test given to you. What you may be doing, though, is determining how to test those features and prioritizing what types of tests to write/develop and when to apply them.

My feeling, and this applies to all agile environments not just testing, is that you eventually want to get to the point where you have the set of practices that apply to your situation and team. Starting from Scrum (or XP or DSDM or FDD) and adapting it to your organization is a worthwhile exercise, especially if you're new to agile methods, but don't get locked into a rigid framework -- agile or otherwise. Make the framework, work.

Scrum (and other agile methods) recognize this and formalize it in the concept of reflection. Too often, though, this is the one part that doesn't get adopted and you end up with a lighter weight, but decidedly non-agile process. That is, you can develop software agilely, but you can't adapt your process agilely. To me, the latter is where the real win is otherwise it devolves into a different (albeit better) assembly line for developing software than the plan-driven methods that came before it.

Answer 4

My company (a global internet company) uses it to great effect. We create stories for blocks of functionality that need testing, then create subtasks to further subdivide the effort and make estimation easier. We use greenhopper (a jira add-on) to manage it. So far it has worked well.

Answer 5

I think it could work well, if you don't look at the software as the thing you're delivering.

Your customers are now the development team producing the code, or whoever reacts to the bugs you find. In the same way that customers in Scrum often change their mind, the developers are going to change the code, or the way in which they interact with you.

Your delivery is made up of bug and quality reports, so your "showcase" should be designed to get feedback from them on the quality of your delivery. You could ask them if your reports are clear enough, if you are producing too much or too little information, or if there's a different way they'd like to interact with you. Maybe they'd like to be able to Skype your team, or have you visit them? Perhaps they'd like to prioritise which areas of the code they want testing? Are their requirements clear enough - do you understand what it is that their code should achieve, or are you just looking for bugs without looking at usability?

Within the scope of your team, you can address the work however you want to - so hold the retrospectives, work out where the pain is, and maybe introduce new tools to help overcome that pain. Automated regression tests seem as if they might be a useful tool to a testing team. There are no doubt others.

Ideally, in Scrum, a team is made up of everyone who needs to be involved to deliver the software, and they're co-located. You wouldn't get such a thing as a "testing project". That kind of hand-off can be expensive. If you could use Scrum to get better communication with the team that gave you the code to test in the first place, I think it could be a big differentiator.

Good luck!