What I mean is that often in the first few iterations, if there’s misspelling or a formatting problem, no one takes fixing it seriously, and it stays around until the end. In a lot of cases, QA will not report it because programming staff will think they are picking on unimportant things. I often see programmers say – “yes, we know that’s not working”.

When nothing concrete is working for QA people and all they can constructively contribute are UI, usability issues, that needs to be respected. If you are serious about delivering a great product, that’s what it’s going to take.

I understand that work needs to be triaged, but the work will have to be done eventually, and easy fixes are good to intersperse a developer’s workload.

All the TDD and automated testing is about programmers catching mistakes, and has a limited effect on overall QA which (if programmers are catching their mistakes themselves) should essentially then be freed up to ensuring that the product is meeting the stakeholders goals and finding design flaws and conceptual errors which are going to make the software harder to use or accept.

Yet, they do fall into the same category more or less that they are finding more important bugs at the end. But that is not because of something inherently flawed in the team, its jsut that at the end of a release cycle more extensive testing is going on. So a solution to this that we’ve found is the all-hands test days where everyone tests a segment of the product rigourously (2-3 hours, not exactly a whole day) and then the QA team then consolidates the defects and isssues found. This is turning out to be a lot better approach.

On a side note, i think the agile developer’s responsibility is to make QA team out of business. They should write unit tests, integration tests and much more to minimize workload on QA team. Only then can you ensure product quality.

If you have 5 week iteration, this framework tends to come online after about 3-4 weeks, at which point people start actually writing tests.

For check in the box coverage this is ‘good’, but for picking up bugs early…

not so much.

@kschlab #Agile – why QA / testing resources shine in the spotlight on agile projects [Johanna Rothman] http://bit.ly/tevLe

“They are also suspicious of testing done during development” — that’s where a really good QA team that’s involved during development can start to engineer their tests to ensure that the delivered system can pass the strong tests they want, but do it in a way that they can automate reliably.

Think about the QA team using unit test-like techniques, but applied to the whole system — not just low-level routines. If done correctly, this lets the QA team create “strong, independent” tests earlier in the process, and implemented with automated tools.

I tend to see testers, themselves, willing to engage in as agile a way as possible, but test management being concerned about “independence” and “due diligence.” Having spent a lot of time talking to test folks, it is clear they are sensitive to complaints targted at them if defects escape to customers. Since they get the system last, they are viewed as responsible for quality and accountable to keep problems from escaping.

Thus, test management is not likely to want to give up on strong, independent, end of development testing as the approach to take. They are also suspicious of testing done during development as they are used to it being poorly done, e.g., getting defects that decent unit testing should catch, tests done only on “correct” input, and testing done to confirm belief in correctness not disprove it.

Traditional models of developer departments and seperate qa departments….. that’s not going to work in an environment where communication is key which is agile.

And a lot of automation by good qa coders, qa should not be looked at weak coders there are some really good ones out there who know how to do lots of automation with ruby, watir etc.

I have actually heard the reverse where the QA is using SCRUM but the dev team is just doing stuff i.e feature building monkey

http://blog.componentoriented.com/2009/09/the-role-of-qa-its-not-just-testing-anymore/

I think QA has to become more proactive about building testability into the application. If QA really adopts this stance, they’ll be forced to engage in design in a way that will force bugs out early.