Scrum and Quality Assurance

About Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

  7 comments for “Scrum and Quality Assurance

  1. Anonymous
    March 27, 2009 at 12:52 pm

    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.

  2. Michael James
    March 27, 2009 at 12:53 pm

    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

  3. Michael James
    March 27, 2009 at 12:53 pm

    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.

  4. Anonymous
    March 27, 2009 at 12:54 pm

    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 ?

  5. Michael James
    March 27, 2009 at 12:54 pm

    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

  6. Michael James
    March 27, 2009 at 12:54 pm
  7. Anonymous-2
    January 6, 2010 at 9:21 am

    I am a developer on a team using Scrum to develop a brand new software project. We have 5 developers, 1 automation tester and 1 QA (manual) tester on the team. We typically run 3-week sprints. We are struggling with the fact that our developers typically don’t finish designing, implementing and unit testing the new system components until near the last day of the sprint. We are fairly early in the project and much of what we design depends on each other for correctness. Thus, we don’t have anything to give to either tester until near the last day of the sprint. This is not enough time for manual testing and not nearly enough time to write automation scripts. So, our non-unit testing lags behind one sprint. How can we pull all testing into the original sprint?

Leave a Reply

Your email address will not be published. Required fields are marked *

*

CAPTCHA Image

*