Danube - Scrum and Quality Assurance - Comments

push the definition of "done" each Sprint

MichaelJames — Wed, 28 Nov 2007 16:14:47 -0600

You probably won't be able to do all those things every Sprint in the beginning. The ScrumMaster's job includes pushing the edges of the definition of "done" each Sprint, to eventually include all development needed for shippable product. Each Product Backlog Item should have a set of acceptance criteria.

So yes, I mean performance testing, scalability testing, deployment, compatibility testing.... In the meanwhile your product is also growing in size, and must be regression tested every Sprint. So the amount of testing must increase each Sprint.

Your only hope is automating this system testing, which I talk about here:

http://danube.com/blog/michaeljames/mock_objects_considered_insufficiently_harmful

http://danube.com/blog/michaeljames/junit_is_not_just_for_unit_testing_anymore

Some projects have contractual requirements for Independent Verification & Validation. Others find value in external User Acceptance Testing (UAT). These can also be worked into the definition of "done." Other times it's best to have your customers and end users in the Sprint Review Meetings.

Michael James
Software Process Mentor
http://www.danube.com

System level tests in scrum

Anonymous — Thu, 22 Nov 2007 22:22:54 -0600

Any thoughts on how system level tests like performance, scalability, deployment, compatibility, etc., can fit into scrum ?
As we understand, such tests can happen only after completion of integration components.

Also, an isolated/separate test team performing tests on a product adds more value as compared to the teams part of development team....this would help to share separate views/thoughts/indpendent evaluation of the product quality, etc.,almost like a customer. So, does anyone feel it's not a right idea to follow in scrum ?

Software quality initiative stalled?

MichaelJames — Sun, 21 Oct 2007 05:43:47 -0500

A New York Times article about Google culture describes a novel approach to promoting modern engineering practices.

In the Testing grouplet, our idea was to have developers start writing their own tests. But no matter how hard we tried, we weren’t reaching engineers fast enough in our growing organization. One day, toward the end of a long brainstorming meeting, we came up with the idea of putting up little one-page stories, called episodes, in bathroom stalls discussing new and interesting testing techniques. Somebody immediately called it “Testing on the Toilet,” and the idea stuck.

We formed a team of editors, encouraged authors to write lots of episodes and then bribed Nooglers with books and T-shirts to put up episodes every week. The first few episodes touched off a flurry of feedback from all corners of the campus. We received praise and flames, but mostly what we heard was that people were bored and wanted us to hurry and publish the next episode.

Eventually, the idea became part of the company culture and even a company joke, as in, “Excuse me, I need to go read about testing.” That’s when we realized that we had what we needed: a way to get our message out.

Anonymous

MichaelJames — Tue, 25 Sep 2007 20:43:13 -0500

You don't seem to have a very high opinion of your people!

Becoming more agile than you are now entails learning skills you don't have now. This could include your Scrum team members who used to call themselves "testers" learning how they can help on the first day of the Sprint, your "coders" learning to collaborate, and everyone learning there's a fruitful gray area between black box testing and white box testing.

Scrum's not for everyone, and some of them may leave. But most people I've met in this business are interested in learning new ways of working.

--mj

Are you assuming QAs are all

Anonymous — Tue, 25 Sep 2007 12:50:36 -0500

Are you assuming QAs are all white box QAs or pgoramming QA? Because black box QA won't be able to help much during development phase.

Scrum and Quality Assurance

MichaelJames — Mon, 24 Sep 2007 20:31:55 -0500

A recent email:

[x] and I are over quality and we put folks from our teams on to the scrum development teams to help ensure quality. Some of the key questions we have are regarding how we ensure quality. How do we know with the scrum process that the quality is adequate? What are key ways we can report and track the quality during a scrum development cycle?