Everyone plays a role.

Everyone plays a role.

The role of the Quality Assurance analyst is different in Agile organizations and projects. Historically, the role of the QA was to plan, document, execute and document the results of tests. Testing was generally the last step in a long process to bring a project to conclusion.  Being the last step usually meant that the schedule would get squeezed and that if defects were found, tempers would be lost. In some organizations the QA role also included scripting automated test cases as fill-in work. In an Agile project, the QA role is much broader and reflects the team evolution toward specializing generalists. The QA role on a mature Agile team is one that includes testing, quality consulting and, to some extent, developer and business analyst roles.

One of the primary roles of a QA analyst on an Agile project is to perform and support testing related tasks. This focus should not be surprising. The typical Agile testing flow is described here. In addition to the typical activities some of the additional activities that an Agile QA will be intimately involved with include: framing the requirements and user stories, and defining acceptance test cases. While stewarding the testing process the QA should help the group continually answer whether they are testing the things that matter the most, by asking.

The second role, a new role for most QA analysts, is that of quality consultant. Tasks in Agile teams are generally not silo’ed to specific people, but rather tasks loosely belong to roles and roles can be played by anyone on the team that has the capability and capacity. The QA analyst, as a professional trained in testing, needs to help everyone else on the team learn testing concepts. Capers Jones and other researchers found that even if a person never performs a test, if they have an understanding of how to construct a proper test and how testing will done they will deliver better requirements, stories or code (and to be better testers when they take up the mantle of tester).

The QA may well assume the developer’s role during any given project.  As units of work move from story to functional code and finally completion, additional resources may be needed so that work does not pile up.  When work piles up, the pace has to be accelerated past a sustainable level (no one really should be working 80 hour weeks) for a specific role. A QA should be able to support development when needed. A second common development scenario where QAs play a role is the development of automated test scripts, coding and testing test harnesses and building program stubs so that new functions can be tested.  The all represent the development of code; something we would generally associate with a developer.  A side benefit of testers becoming more technical is that when a QA develops a working knowledge of the code being used on a project, they increase their personal utility for the team and themselves.

The typical business analyst’s role is to facilitate the development of requirements and solutions. In Agile projects, the QA can play a substantial role in generating and grooming requirements. For example, a common Agile technique called the “Three Amigos” uses a sub-team of three team members, the Product Owner (or a business analysts), a developer and a QA to generate requirements and stories. They then continually prep and groom the stories for the team. Assigning a QA as a member of the Three Amigos brings a testing flavor to activities that would typically be done by just a business analyst which will result in requirements that are easier to develop and test.

The role of the Quality Assurance analyst includes testing (no shock), consulting, developing and business analysis.  The QA role in Agile has progressed past the person or persons who were the last step in the development process (and who rarely has enough time to do their job) and has become an integral part of delivering value from the first day of every sprint.