BillRG
Bill Rinko-Gay
Member
Posts: 24
Registered: 09 Nov 06
Location: Boiling Springs, PA
Member Is Offline
Mood: Optimistic
|
![[*]](./images/grass/default_icon.gif) posted on 13 Nov 06 at 05:39 PM |
|
|
Agile Quality Assurance
I have been looking for information on Quality Assurance on Agile Projects and most of what I have read involves testing.
QA is the set of activites which increase the likelihood that things will be done right in the first place, reducing the number of defects found in
testing.
In traditional projects, QA will focus on the artifacts as they are being developed, ensuring they are as good as they can be before the next part of
the waterfall starts flowing. A good QA department will even ensure something similar to TDD is being performed - that is the tests will be designed
from the requirements and shared with the developers.
But Agile projects aren't managed the same way. So I'm wondering if there is a role for QA. I think there is, but not necessarily on every Agile
project. Especially in larger organizations I think QA can help. I'd like thoughts on the following tasks and whether an Agile team would benefit
from a QA group handling them.
* Attending meetings and verifying all stakeholders are present. Facilitating where appropriate
* Archiving the meeting key decisions and action items on a tool that allows everyone to refer to them as needed
* Supporting the acceptance test process at the end of each iteration
* Facilitating Retrospectives
* Verifying existing processes are followed
* Reviewing existing processes to ensure they are necessary and sufficient
* Other?
I know that the Agile approach to process is that no more should be implemented than is absolutely necessary. Would an Agile organization still need
QA to support those that are absolutely necessary?
Thanks in advance for your thoughts.
Bill Rinko-Gay
Delivery Director
Spherion
|
|
|
Joe
Joe Gee
Member
Posts: 16
Registered: 05 Sep 06
Location: Denver, CO
Member Is Offline
Mood: Moodless
|
 posted on 13 Nov 06 at 07:33 PM |
|
|
Some random thoughts.
In a waterfall process, each phase ends with the creation of artifacts, but an agile process really only creates one artifact of consequence, the
running software. That probably coincides with your observations on qa discussions for agile processes revolving around testing, as that is checking
the one artifact produced.
On most agile teams that I have seen, the focus on qa as you describe it has been very internal to the team in keeping best practices in place, like
TDD and customer testing, and keeping team motivations aligns with those practices, with things like big visible charts to keep the team alert to
current concerns.
Having an external authority gatekeeping would make most agilists very nervous, fearing that satisfying that authority would undermine their ability
to change what they are doing at any time to suit a given situation. A recent discussion on the xp yahoo group gave an example of a team that threw
most of their best practices out the window to be able to get something that could be demo'd at a trade show. That created some quality debt that
subsequently had to be paid off, but the revenue opportunties made it well worth it.
I speculate, however, that a qa organization could perhaps fill a role very like testing. If a test team's job is to provide insight into the state
of the product, a qa organization could perhaps provide insight into the state of the process. That could perhaps be in the form of watching
correlations between things such as execution of best practices (what does our unit test coverage look like?) vs defects introduced or features
added.
The caution with that would be to make sure that the measurements didn't become goals in themselves. For example, a team might be measured on pair
programming and find that they do it 80% of the time. If an artifical standard of 95% was expected because that was considered to assure quality,
that could easily take precidence over realizing that the defect rates didn't improve with a higher number, and maybe the velocity went down a
bit.
I don't know if such a feedback role could be called "assurance." What it would do is provide the team with better information to aid in steering
their process by, and raising flags where appropriate.
Hope that is helpful.
Joe
|
|
|
IljaPreuss
Ilja Preuß
Member
Posts: 96
Registered: 05 Sep 06
Location: Karlsruhe, Germany
Member Is Offline
|
| posted on 14 Nov 06 at 09:13 AM |
|
|
I actually think that the *activity* of "QA" is so important to an Agile team, that all team members are supposed to constantly work on it. It's
much too important to have some singled out persons be responsible for it, let alone an outside team.
That's not to say that different members of a team can't feel responsible for different aspects of QA. For example, in our team I'm currently
responsible for facilitating the iterations retrospectives.
|
|
|
BillRG
Bill Rinko-Gay
Member
Posts: 24
Registered: 09 Nov 06
Location: Boiling Springs, PA
Member Is Offline
Mood: Optimistic
|
| posted on 14 Nov 06 at 02:33 PM |
|
|
Joe,
Thanks for the feedback. Your comments raised some in my mind.
| Quote: | Originally posted by Joe
In a waterfall process, each phase ends with the creation of artifacts, but an agile process really only creates one artifact of consequence, the
running software. That probably coincides with your observations on qa discussions for agile processes revolving around testing, as that is checking
the one artifact produced. |
If the software is to be maintained there are some other artifacts. In addition, if the organization is large enough, there are interim pieces of
information - let's not call them artifacts because they aren't that formal - that represent agreements between teams that have responsibilities for
different parts of the code.
| Quote: | | Having an external authority gatekeeping would make most agilists very nervous, fearing that satisfying that authority would
undermine their ability to change what they are doing at any time to suit a given situation. |
I know that "quality gates" are a common function of QA, but I would not envision such a thing in an agile environment. Agile QA would actually be
part of the team. The purpose would be on enabling the team to focus on solving the problems at hand while the QA team member focused on ensuring
nothing got dropped - specifically, issues that have to do with interacting with the larger organization. QA would not be a decision maker. QA would
provide information to the team to use in making decisions such as paying a quality bill later to allow a demo to be ready for the trade show.
| Quote: | | I speculate, however, that a qa organization could perhaps fill a role very like testing. If a test team's job is to provide
insight into the state of the product, a qa organization could perhaps provide insight into the state of the process. That could perhaps be in the
form of watching correlations between things such as execution of best practices (what does our unit test coverage look like?) vs defects introduced
or features added. |
That is very well put. I like it. I would add verifying that the process is still allowing the team to interact with the rest of the
organization.
| Quote: | | The caution with that would be to make sure that the measurements didn't become goals in themselves. |
As in "A difference that makes no difference is no difference." Important point.
| Quote: | | I don't know if such a feedback role could be called "assurance." What it would do is provide the team with better
information to aid in steering their process by, and raising flags where appropriate. |
And if it provides information to steer the team to higher quality output then ...
Thanks!
Bill Rinko-Gay
Delivery Director
Spherion
|
|
|
BillRG
Bill Rinko-Gay
Member
Posts: 24
Registered: 09 Nov 06
Location: Boiling Springs, PA
Member Is Offline
Mood: Optimistic
|
| posted on 14 Nov 06 at 02:40 PM |
|
|
| Quote: | Originally posted by IljaPreuss
I actually think that the *activity* of "QA" is so important to an Agile team, that all team members are supposed to constantly work on it.
|
While I agree, human tendency is such that when everyone owns something, nobody really does. People will do their best to do good quality work on
their own, but when the pressure is on the more philosophical questions tend to get left unasked or unanswered.
I am also speaking from experience with very large organizations with software that is developed by independent teams but which have to work together
when done. The organization would need to be agile enough to allow the teams to be agile. QA would support the individual team leaders by providing
some of the glue that keeps the iterations running synchronously.
Bill
Bill Rinko-Gay
Delivery Director
Spherion
|
|
|
WayneMack
Wayne Mack
Member
Posts: 26
Registered: 18 Sep 06
Location: Fairfax, VA US
Member Is Offline
|
| posted on 14 Nov 06 at 05:43 PM |
|
|
Bill,
Here is some untried speculation on the role of QA with Agile. First, I will assume the QA is concerned with Process Quality while QC is concerned
with Product Quality. Next I will assert that QA performs its mission by evaluating artifacts; in waterfall, artifacts are text documents while in
agile, artifacts are software code. Looking at processes, I think we can define some QA steps to ensure that they have been followed.
Test Driven Design - Verify Unit/Programmer Tests against program code to ensure that no methods are untested and each method is fully tested; i.e.,
no untested outcomes. This may need to be done on a sampling basis - identify a sample set of code modules instead of the entire code base.
Refactoring - Subjective evaluation of whether the code is clear and whether the code is simple. The first evaluation could be done by a person
without much software development expertise. The second may require a software language expert. Again, this would probably be done on a sampling
basis.
Pair Programming - Determine either by informal polling of developers or by random checks during development whether programmers are pairing. Random
checks may seem a little bit like "spying" on developers, but if they agreed to it ....
Acceptance/Functional Tests - I presume (someone please correct me if I am wrong) that there should be at least one Acceptance or Functional Test for
every User Story. QA should be able to confirm at the end of each iteration whether each story has an acceptance test.
I think steps like the above can get QA back into the job of process assurance. I would also think that if QA found a failure in one of the above,
that management should accept QA pulling the "stop cord", halting development activity, and training or taking other necessary steps. I think as
agile progresses from a developer led approach to a management directed approach, then QA will play a role in assuring that agile is being done right.
|
|
|
ehendrickson
Elisabeth Hendrickson
Member
Posts: 22
Registered: 05 Sep 06
Member Is Offline
Mood: Pensive
|
| posted on 14 Nov 06 at 08:47 PM |
|
|
I think we're perilously close to defining a Process Police role for Agile. Beware.
Agile teams are both self-organizing and self-policing. When they aren't, the XP Coach or Dev lead is the appropriate person to question the level
of test coverage, amount of pairing, or cleanliness of the code.
Furthermore, I'll suggest that an Agile team that needs a process cop is an Agile team that needs to adjust their process, because somehow their
process is no longer working for them; instead they are working for the process.
|
|
|
BillRG
Bill Rinko-Gay
Member
Posts: 24
Registered: 09 Nov 06
Location: Boiling Springs, PA
Member Is Offline
Mood: Optimistic
|
| posted on 14 Nov 06 at 09:28 PM |
|
|
| Quote: | Originally posted by ehendrickson
Furthermore, I'll suggest that an Agile team that needs a process cop is an Agile team that needs to adjust their process, because somehow their
process is no longer working for them; instead they are working for the process. |
Very well put. And does this happen? I'd assert that it will, and the QA people can be there to help ensure the process is actually achieving its
purpose rather than becoming the goal in itself.
i.e., is the team truly being agile, or acting like it? Often it's someone with a different viewpoint who can see most clearly.
One thing to keep in mind, though, is that QA is not a cop in the traditional sense. A cop is someone the townspeople hire to watch for people who
try to break the rules.
QA works with the townspeople to ensure the rules make sense so nobody wants or needs to break them (Absent theological considerations which don't
belong here.) The QA person focuses on these issues so the townspeople can focus on getting their work done.
Make sense?
Bill Rinko-Gay
Delivery Director
Spherion
|
|
|
BillRG
Bill Rinko-Gay
Member
Posts: 24
Registered: 09 Nov 06
Location: Boiling Springs, PA
Member Is Offline
Mood: Optimistic
|
| posted on 14 Nov 06 at 09:32 PM |
|
|
| Quote: | Originally posted by WayneMack
Bill,
Here is some untried speculation on the role of QA with Agile. |
Those are very helpful thoughts, Wayne, but I would agree with Elisabeth that we would need to watch out. QA would not be verifying the team did what
it was supposed to do as much as verifying that what the team was doing was adding value.
However, there may still be things that could get forgotten when the team is part of a larger organization. QA could also verify these are not
forgotten.
Examples:
Have we shared our hardware needs with the IT staff so they can purchase and provision the hardware in time?
Have we interfaced with training to allow them to prepare the training materials so the users will know how to use the new system.
Did anyone review the function list with the SOX advisory panel to ensure we will meet all SOX requirements? (Ditto for all applicable laws and
regulations.)
Does this make sense?
The lead should know about all these. The good leads will need little help from QA. Leads who haven't run too many projects within this
organization might need significant help until they become trained.
Bill Rinko-Gay
Delivery Director
Spherion
|
|
|
cricky
joey tipak
Member
Posts: 2
Registered: 20 Jul 09
Member Is Offline
|
| posted on 20 Jul 09 at 05:46 AM |
|
|
wonderful! thanks for the info..
commission de surendettement
- commission de surendettement, vous pouvez demander un dossier de surendettement.
|
|
|
tenpong
keetynice
Member
Posts: 2
Registered: 19 Aug 09
Member Is Offline
|
| posted on 21 Aug 09 at 04:30 AM |
|
|
QA could also verify these are not forgotten.
proprietaire simulation rachat credit immobilier
consommation - demander un rachat de crédit, faites une simulation rachat de credit en ligne.proprietaire simulation rachat credit immobilier
consommation
|
|
|
karoty
keetynice
New Member
Posts: 1
Registered: 24 Aug 09
Member Is Offline
|
| posted on 24 Aug 09 at 11:52 PM |
|
|
they write from slightly different angles
proprietaire simulation rachat credit immobilier
consommation - demander un rachat de crédit, faites une simulation rachat de credit en ligne.proprietaire simulation rachat credit immobilier
consommation
|
|
|
RSS Feed
