This has probably been discussed to death in various books, discussion forums and groups. What i present here is an observation of 5 years of agile practices in 2 different companies (1000+ employees and the other 100+ employees) and about 12 different projects.

Initial reactions on Agile ( 5 years ago) :

• WTF is this ?
• Never gonna work.
• So are we winging it ?
• Is someone gonna tell us how the dev-qa handover should be ?
• where are the specs ?

Observations now :

• Works for products / companies where the sales team are still trying to define what the market is. If you are working on something mission critical that would mean life or death, I would suggest to look elsewhere and have a *classical* process with vigorous checkpoints.
• Rapid Iterations mean exactly what you think it means most of the time (buggy and unstable), needs a full regression cycle to make sure other stuff dint break or a robust automated suite of end to end tests. If your rapid iterations was perfect and dint have any bugs – you are lying 🙂
• Code inevitably gets merged at the end of sprint, tendency to mark story as complete if QA work is pending, QA work adds up quickly and accumulates.
• Tester role needs to be redefined and reinterpreted, there is no “tester” anymore whats needed is a term I would coin as “DesTer” aka Dev-Tester.
• The old days where terms like a “manual” tester did this or “automation” tester did that doesn’t work. There’s only one goal of getting the product with quality out. “DesTers” need to be focused on that. Whatever that gets it done is what the team needs to do. Try helping folks who are hard set in their belief on what qa or dev need to be doing, if it fails weed them out.
• With progression of time no one remembers what the original functionality of a piece of logic was. I call this time slicing and is inherent to the way scrum is everyone remembers a snapshot but not the cumulative addition of functionality on a piece of logic or why it was done in the first place.
• Every new architect/dev who joins the team wants to re-invent the wheel. if its Java convert to C#, if its C# move to python. if there are 2 layers we want 4 to “modularize” it, if there are 4 layers we want to internally call methods to speed it up . Takes a brave soul to really look at something and say this could be good AS is or not.
• Independent of Dev or QA -> What does failing a story mean ? the interpretations vary wildly and your management should define what would happen in this case, especially if after a few failed stories you are starting to develop a thick skin and getting used to the idea that stories can fail.
• Stop creating new test cases if you are reworking existing functionality you’ll have an un-wieldy test set within a few months. You dont have to prove you have x number of test cases and the amount of work you have to do. All that matters is that you are confident that you have a reasonable coverage and confident in the build released.
• As a QA person remember you are here to support and progressively move a product forward, support your dev team but hold your ground if you think something is not right.
• Dont whine without reason, if you are stuck jump on a call with dev and see if theres anything you can do to help progress forward, remember the agile manifesto one person clears obstacles and the other person paves the road. Its a team effort.
• Documentation or the lack of it. Lets face it no one likes to document things. Human nature leans towards attaining a lower entropy. This is a problem when the company or team is larger than a certain size and communication needs to happen.

Judging the true performance of a QA team :

The question comes down to this, what contributes to an efficient QA team ?
Number of test cases run per regression cycle ? Raw defect count in a build ?

After countless projects some of them which have been shelved have come to the conclusion that although the above 2 are factors are useful they dont tell the full story. To make this synopsis on Agile QA quanitifcation I’ve boldly decided to take the next step and provide a solution for judging QA effectiveness in an agile world :

Below assumes your team does a regression activity before putting it into Production
QA Team efficiency coefficient  (working with various QA folks in various companies for a definition) : ** Check back later

[Update] 2015 – So Just read this http://spectrum.ieee.org/view-from-the-valley/computing/software/yahoos-engineers-move-to-coding-without-a-net

Says “there was less bugs” and couldnt help smiling. Of course there are less bugs when the folks validating stuff works are laid off. These erosions are long viewed.  @Yahoo  – They only matter if your company plans to stay in business long 🙂