Agile Testing-5 Steps to QA Adaptation

[article]
Member Submitted
Summary:

There are various agile methodologies that are adopted in test teams and, needless to say, not one adaptation fits all organizations. Our QA agile adaptation engages the entire testing staff in a knowledge sharing forum to promote better test coverage and to help manage a meaningful test library.

There are 5 major components in our Agile QA Adaptation which includes:

  1. User Story Impact Review,
  2. Initial Test Case Abstract,
  3. Workflow Review,
  4. Test Execution, and
  5. Test Run Check Points.

Each component has the following sections (a) problem, (b) purpose, (c) process, timing & frequency, and (d) outcome.

1. User Story Impact Review
Problem

  • User stories are one of the key ingredients in building test cases, and too often individual QA engineers are isolated on their own to build these test cases based on their interpretation and experience with the software.

Purpose

  • The main purpose in this task is for the QA team to fully assess the overall impact required in the testing activities by:
  1. collaboratively understanding user stories from different perspectives,
  2. increasing the knowledge distribution in the team,
  3. discussing ambiguities, and
  4. gaining a better understanding of the potential risk areas that may need focused testing

Process, Timing and Frequency

  • We start with a collaborative discussion of the user stories between each QA engineer. Each QA engineer will review and share their interpretation of each user story and identify areas of ambiguity.
  • Generally, this is a 1 hour meeting which occurs within one to three days after each initial PM & Dev User Story Reading. Additional meetings might be required to review all user stories.

Outcome

  • The QA engineer assigned to a user story should have a better understanding when compiling all related user stories into one meaningful 'Test Case Abstract'.

2. Initial Test Case Abstract
Problem

  • Test cases vary in scope from basic CRUD (Create, Read, Update, and Delete), functional, acceptance, workflow, system, integration, boundary test cases, and so on. Additionally, test cases may or may not address the overall impact of the application.

Purpose

  • The purpose of this task is for the QA team to develop initial abstracts of all related user stories into a meaningful abstract:
  1. collaboratively reviewing the abstract of each QA engineer,
  2. Initial Test Case Abstract,
  3. identifying any testing gaps,
  4. consolidating related test case abstracts into meaningful workflows and
  5. extending the knowledge distribution within the team

Process, Timing and Frequency

  • At this point the QA team will review the test case abstracts from each QA engineer. The abstract is an outline level (table of contents) test case where similar/related user stories are combined into 1 or a few useful test case abstract. At a minimum, the outline should include (1) a reference to each user story, (2) personas, (3) a description of the feature to test, (4) expected results, (5) areas to reconcile [check and balance].\
  • Generally, this is a 1 hour meeting which occurs within one to two days after the first step in the QA methodology. Additional meetings might be required to review all test cases.

Outcome

  • A comprehensive and meaningful workflow test case that holistically verifies the application.

Workflow Review
Problem

  • Test libraries may range from one to several hundred test cases, and eventually, a large test library may bury very important test cases.

Purpose

  • The purpose of this task is for the QA team to review workflows (consolidated and transformed from test case abstracts). Workflows should have (a) a reference to each user story, (b) persona(s), (c) a description of the activity being tested, (d) expected results, and (e) areas to reconcile [check and balance]. We accomplish this task by:
  1. collaboratively reviewing the new or updated workflow test cases,
  2. identifying any testing gaps,
  3. reviewing potential risk areas to test,
  4. further consolidating of workflows according to appropriate personas and
  5. extending the knowledge distribution within the team

Process, Timing and Frequency

  • This is where the QA team shares and reviews their constructed workflow test case(s). QA engineers will have either created or updated existing workflow test cases from their test case abstracts. The preference, if possible, is to update existing workflows so our existing test library is always up to date.
  • Generally, this is a 1 hour meeting which occurs within one to five days after the first step in the QA methodology. Additional meetings might be required to review all test cases.

Outcome

  •  A holistic workflow that reflects the persona(s) of an actual application user.

Test Execution
Problem

  • Generally, the testing efforts are at risk when new features are not fully understood, features are delivered late, or the test execution is delayed or rushed.

Purpose

  • The purpose of this task is for the QA team to review the test execution progress by:
  1. collaboratively discussing the areas that have been tested and not tested,
  2. review heuristic and exploratory testing opportunities,
  3. identify any testing gaps (ad hoc application changes),
  4. assess automated regression testing, and
  5. extending the knowledge distribution within the team

Process, Timing and Frequency

  • During the QA test cycle the QA team shares and reviews the progress of their (1) workflow test execution, and (2) identify any test execution obstacles or serious defects.
  • Generally, this is a 1 hour meeting which occurs usually one day after each build is deployed to the QA environment.

Outcome

  • Assessment of the testing progress, as well as, identifying obstacles that interfere with the testing phase.

Test Run Check Points
Problem

  • Producing status reports reduces valuable testing time from each QA engineer, implementing developer or product management test case reviews also reduces their time to address code or design flaws.

Purpose

  • The purpose of this task is for the QA team to take ownership for the testing progress at both the feature (functionality) and workflow levels.
  1. Report on the areas that have been tested and not tested,
  2. Report any major obstacles that prevent/block testing,
  3. Re-prioritize or shuffle testing efforts,
  4. Escalate issues to development and/or product management,
  5. Create awareness within the team to (a) reduce duplicated testing efforts, and (b) reduce duplicated issues reported in the defect tracking system, and
  6. Address automated regression scripts.

Process, Timing and Frequency

  • During the QA test cycle the QA team shares and reviews the progress of their (1) workflow test execution, and (2) identify any test execution obstacles.
  • Generally, this is a 1 hour meeting which occurs usually one day after the 1st build, at the mid-point of the testing phase, and daily during the last week in the QA cycle.

Outcome

  • Continual testing progress assessment, prioritization of test efforts, and a method to address to obstacles in the testing phase.

Our Agile QA Adaptation has been put into practice and has proven itself with low production defects (averaging less than 3% of production issues are defects). Whether you have local or remote teams, the QA Agile Adapation works nicely to help you gain a better understanding of each person's aptitude in your application, and supports new staff members by leveraging the knowledge of each person on the team.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.