Backlog Item progression to QC

[sewri...@gmail.com]

I am interested to find out how people are using VersionOne through
the QC process.

Currently in our shop, a backlog item starts in development. When
that item is complete, it is given to the tester in order to verify
the quality/functionality of the item. As you know with Agile, QC is
1 iteration behind,,in other words, if a backlog item is developed in
Iteration 1, it is tested in Iteration 2. The problem we have run
into is that leaving a requirement open across iterations skews the
burndown charts and reports that are run on backlog items. The
backlog item looks as if it always must live across 2 iterations,
which doesn't allow for us to gauge development progress versus
testing progress.

The work around we have implemented is to split a requirement at the
end of a sprint and created a separate QC sub-project under the main
project where the split backlog item will now live until testing is
complete.

Does anyone know of a more elegant way to incorporate QC and/or is
this on V1's radar to address?

Thank you

[Darrell Piatt]

QC should ideally be done before the story is closed. That is the
proper definition of "done," which means that it has been checked out
and is accepted by the Product Owner. Defects found while the story is
open become tasks within the story. Defects found post closing are
created as defect backlog items that get prioritized and fixed alongside
other story work.

This will obviously take time for many teams to transition to,
especially if they have separate QA teams that aren't as well-integrated
with the development team. With Agile, quality is a shared
responsibility across the team, even if you have dedicated test
resources. It's not a "throw it over the wall to QA" proposition.

There is also a great thread going on about linking these post-closure
defects to the originating backlog items (so V1, keep in mind that we'll
need to find closed stories in the backlog and then initiate defects
from them).

[SheSpeeds]

I am coming from a waterfall environment to an entirely agile shop,
and am delighted with the agile structure and the ability to "cure"
the problems I encountered with a QA-last approach by integrating the
quality process into the current sprint. Like the other post, I agree
that in a truly agile environment, quality practices should reside
within the current sprint; the definition of "Done" includes tested
and deployable. We have added a status in the backlog workflow "ready
for QA" for programmers, and "Done" is reserved for the tester. There
will always be testing after coding is complete to replicate user
acceptance, but the big quality savings is by having a quality role in
the process as early as the sprint planning meeting, formally called
Requirements testing. You may also consider an automation tool to
increase speed towards the end of the sprint when the bulk of
functional testing comes to the testers, which in turn creates
repeatable tests to add to your build verification test/ regression
test. Your testers would be writing these scripts after they've
reviewed the requirements for ambiguity but before/during when they
have UI's to test (keeping in mind the general rules of thumb for
automatable software functions). Your testers might also be able to
provide value enhancing user documentation or release notes during
this time depending on your volume and resources.

I have also read several posts by others on this site who use two
sprints to deploy enhancements. If your sprint is 2 weeks for
development and 2 weeks for testing, what about the idea of creating 4-
week sprints, and to get the programmers started on something else
after 2 weeks, have each team (programmers and testers) associated
with two sprints that stagger by date.

On Feb 5, 2:00 pm, "sewrief...@gmail.com" <sewrief...@gmail.com>
wrote:

[Kevin S.]

You stated-

"As you know with Agile, QC is 1 iteration behind,,in other words, if
a backlog item is developed in Iteration 1, it is tested in Iteration
2. "

Just to be clear, this is not an agile prescribed process. It is an
adaptation made by many, and is a norm. It is a way to ease into
agile, but staying in this state is not agile.

Here are several of my blog posts about QC in agile including links to
other articles:
http://agile-commentary.blogspot.com/search/label/tests

Ultimate goal: Your testers/analysts should be writing acceptance
tests while or before the developers are coding so that they can be
used in conjunction with the unit tests to drive TDD.

On Feb 5, 2:00 pm, "sewrief...@gmail.com" <sewrief...@gmail.com>
wrote: