How to Have Smooth Handoff From Dev to QA?

Hi, all.  This is a topic I've been struggling with for a while. What's the best way for the development team to notify QA that a particular feature has been coded, smoke tested, and all bugs found during smoke testing have been fixed? I.e., that the feature is ready to test in the next automated build?

What we've come up with is, the programmer who's responsible for implementing the presentation layer for the feature is responsible for e-mailing the QA lead when the last bug has been fixed and the smoke tester is satisfied. The thought here is that the presentation layer person "owns" the feature since their layer is what the user "touches," as well as their layer is typically the last in line to be coded.

The problem we're facing is that the responsible programmer oftentimes forgets to send the e-mail.  In addition, sometimes the smoke tester fails to notify the programmer that he has moved on to other things.

This means that I, as product manager/project manager, need to keep tabs on everything and make sure the feature gets pushed through. This is not a big shock--it's part of the product manager/PM job description to coordinate the lines of communication--but I'm just wondering if there's a better way to make this part of the process more efficient.

Does anyone have any suggestions for a better technique?

- Dave

Dave
Tuesday, November 4, 2003

Our experience is that if you toss things over the fence like this to QA you're not going to get the best out of them.

Does QA do acceptance testing or do you? If QA does it, how do they do acceptance tests without being involved during development?

Why can't QA prepare/run tests while you're doing development? It means you have to work in smaller chunks and deliver more frequently, but it's worth it.

We're working towards having acceptance of a story completed on the same day as coding. We have some challenges ahead  of us but we think we can do it.

But all that doesn't really answer your question: how to signal the delivery of a feature to QA. In the past, we used to use a defect/enhancement tracking system. Enhancements are entered into the tracking system, development codes them, and marks them as complete. QA monitors the system and tests when delivered.

However, if your developers can't be depended upon to send an e-mail, they possibly can't be depended upon to use a defect tracking system properly. The only answer to that is to try to create a sense of discipline in the team.

It's a whole lot easier if QA is involved up front so they know when something is about to be delivered. QA should pull from development rather than have development push to QA.

Just my opinion...

anon
Tuesday, November 4, 2003

I agree with anon, your developers need more discipline.

But, in a perfect world, your source code control system and ticket tracking system are aware of each other and can alert the needed parties as to when the code is ready for testing.

As the psuedo, wanna-be Project Manager for my team, during a Project I have everyone send me daily (yes, daily) updates. Everyone should be working off of a daily list of tasks anyway, so make sure they update you everyday. That way you know when something is almost done and testing can be coordinated with your Quality Assurance team.

(i think some people really enjoy being told exactly what they are supposed to accomplish in a day, it works for my team anyway.)

Michael Sica
Tuesday, November 4, 2003

Thanks, guys.  I appreciate the feedback.  This gives me some food for thought.

We typically deliver features to QA every one to four days, so we are doing frequent cycles.  I think I just need to continue to coordinate things, since everything is reported to me on a daily basis.  I do have the team update Project Server with their tasks each day--but Project is less granular than the features I want to deliver to QA (for the simple reason that I don't want to manage 6,000 tasks....)

- Dave

Dave
Tuesday, November 4, 2003

The way it's worked for me is as follows :

1) Make sure the testers have got a copy of the spec and understand it before you cut the first line of code. Otherwise you'll be screwed from day one.

2) Get an automated build set up as soon as possible. Don't worry if all the code is just stubs that do nothing; as long as the process is set up to work over and over again, that's the important thing.

3) When doing the build, add a label to each project as it is retrieved from the source code system. This label is in a well defined format that includes the build number and date. It could also include the user who did the build.

4) Once the build is done, scan the labels in the source code system in order to produce a diff of changes between the current release and the last one. Mail this to test along with information on where to find the latest build when you're happy it passes the smoke test.

5) If you need to, extend this so you can produce a report containing changes between several different builds.

This also has the advantage of forcing people to add meaningful comments when they check in code, otherwise the testers harrangue them with "what does this mean" comments.

Better Than Being Unemployed...
Wednesday, November 5, 2003

At a more general level, it sometimes pays to disrupt peoples worldview.

Knock the idea that QA is a passive receptacle for finished features out of the heads of both QA and development. There is absolutely no reason why QA cannot be involved, or at least aware, of the progress of features right at initial brainstorming through to design and implementation. Ideally, you are working with QA to develop tests.

Ultimately, the distinction between development and QA is artificial. It is not necessary. There is no reason why you can't just have people who design, people who code, and people who test. There's no reason why you can't have people who do all three.

Commonly you'll hear people say that developer's don't have the "objectivity" to test their own code. Garbage. The idea is to remove objectivity from the equation altogether.

I'm not saying you have to get rid of QA or anything like that. I'm just saying that having two distinct groups that operate at arms length through a hard interface is not always the best solution. Problems like those described in the original post are symptoms of that hard interface. Try to make that interface as invisible and permeable as possible.

anon
Wednesday, November 5, 2003

  Recent Topics

  Fog Creek Home