Totally agree with Steve here. My official job title includes "QA" however I condider my (main) responsibility to be testing. The "whole team approach" to me does not necessarily mean that each person does every job, however the responsibility for Quality and delivering the product as a whole works at the team rather than individual or role level. In this way you can still have individuals who's primary responsibility is testing, with the idea of quality assurance being something that is taken on by the team through the process of regular retrospectives and process evolution.
With regard to the non-testing QA, I've not personally encountered this role. I have in the past, however, been audited for the purposes of ISO accreditation and it seems to me that the individuals who had the responsibility of documenting procedures and ensuring accordance with them covered very much the same area. I wonder if the non-testing QA role that is being referred to has, for some organisations, ben superceded by the one responsible for attaining certification standards conformance?
Adam.
----------------------------------------
http://a-sisyphean-task.com/
twitter: adampknight
----------------------------------------
--- In agile-testing@yahoogroups.com, Steven Gordon <sgordonphd@...> wrote:
>
> In Agile, the whole team is responsible for this. Having any particular
> person officially fulfill this role dilutes that responsibility. It might
> seem more effective to have such a role in the short term, but it would
> erode agility in the long term.
>
> So, while QA still exists under Agile as a responsibility, QA should be a
> shared, collaborative, continuous responsibility not a role that specific
> people play at specific points in time and others do not.
>
> SteveG
>
> On Fri, Jan 6, 2012 at 1:43 PM, karthikeyan M gotukarthik@... wrote:
>
> > **
> >
> >
> >
> > Personally I feel QA -> Quality Analyst -> means a person whose job role
> > is is to analyze the flow of the project and ensure quality of the
> > project deliverable. The deliverable could be Production Code,
> > Unit/Integration Test Code, Functional Test Code, Any documentation like
> > Release Notes etc... There are also other deliverables like Stories written
> > for every iteration, and those stories should be reviewed by the QA to
> > ensure there is no functional Gap's (sometimes BAs might miss to add an
> > acceptance criteria). Now to emphasize Quality in all these places, the QA
> > can chose to use any appropriate method to achieve the same. When he tests
> > the application to ensure the production code is of good quality, he is
> > referred to as a tester but Philosophically the job doesn't end only with
> > that.
> >
> > - Karthik
> >
>
0 comments:
Post a Comment