Practical Approach in Creating Agile Test Cases


  • Test case discovery happens throughout the sprint process.
  • Exploratory testing will uncover the hidden cases and expand to better coverage.
  • Overall, finding test cases in agile is a challenging process.
  • Definition of “done” of a story/feature is not clearly quantifiable.
  • Start with happy path and take following step by step approach to expand coverage.
  • Full step by step test case documentation is overkill, rather use summary test cases.
  • Most part, acceptance criteria defines the “done” for a Sprint story.

Introduction

Identifying test cases in Agile is a somewhat difficult task.  In traditional waterfall or RUP, there will always be galore of documents to deduce this information from and in most cases every test case can be traced from some kinds of documented business/ system/ technical/ functional requirements.  Agile by its nature is very lean in documentation. This will create an issue in defining completion point for a feature distributed across several stories. This article defines the process of finding most test cases documented and undocumented with in a feature/story.

Step 1: Input points for test case scenarios

Traditional Agile scrum has following input points where test case scenarios can be uncovered. Every input provides different information. The list below is not conclusive.

  • Story documentation: Generally very slim.  Intention is to start conversation and get confirmation on requirements and definition of “done”.
  • Acceptance criteria for story: Talks about final intent of the story and definition of what makes story “done”.
  • Use cases /Requirement docs (if any)/UI specification (if any): Most cases use cases can be converted to test cases. Well written requirement will be very rare in agile stories.  If it exists, mapping every requirement to test case is an easy task.
  • Sprint planning discussion: Discuss almost all flows including happy path, alternate flows and exceptions flows. Discussion also includes boundary conditions, business rules, existing functionality changes etc.
  • Sprint standup: Discuss daily issues.  Always listen to change in flows as well as corner conditions.
  • Discussion with Developer/Product Owner: Works as a confirmation on numerous information received.
  • Sprint retrospect: Why test coverage is not enough for stories? Test case modification happens after the fact.
  • Exploratory testing: Testing through system without a specific test case.  This is the most effective method to find missing test case. This is method has been very successful with several agile teams.

 Step 2: Collecting Data

  • Tester is involved in all steps of sprint process. Following information should be sourced during all meetings in step 1.
  • Change in any existing functionality: This will results in modification/adding of existing test cases.
  • Happy path:  Tester will hear this several times during the process. Similarly alternate path/flow is also important.  Identify the number of alternate flows and make sure all flows are working.
  • Path of failures: Popularly called exception flow, flow terminated due to errors
  • Guard conditions: Example, login time out
  • Boundary Conditions: Also called as corner conditions. This will make sure that application will work for intended range of input data.
  • Business Rules: Group the business rules and test for one group at a time
  • Event based notifications: Any trigger point for any of the available functionality
  • Non-Functional requirements: Like performance or load of the system
  • Data mapping documents: Test cases can directly be derived from data mapping document.
  • Assumptions
  • Constraints
  • External Dependency: Is this dependent of any external interface for data pull or data push.

Even though all of these conditions (if exits) will result in test cases, every story will not have all of the above scenarios

Step 3:  Organizing the test cases

Since agile input points are many, it is possible that test cases closely related to each other will duplicate across locations.  Always organize test cases by functionality if possible.

Step 4:  Examining coverage

Most testers like to have 100% test coverage. Exploratory testing is the most viable solution to reach 100% test coverage. Since traditional RTM is missing in agile, acceptance criteria will also determine the coverage of test cases required.  Creating an “Acceptance Traceability Matrix” will help to cross check the coverage.

Step 5: Review

After completing test cases, always make sure to be reviewed by product owner or scrum master/developer.  Any coverage miss derived during the review process will be added/updated to test cases.

Step 6: Continuous integration from defects and enhancements

Product defects as well as enhancements will add/modify test cases. Defects generally indicates overlook of test coverage during the sprint testing.

More details contact author: Joseph Vargheese PMP CISA CSM, Joevgh@gmail.com,

Advertisements

About Joseph Vargheese
email:joevgh@gmail.com.

2 Responses to Practical Approach in Creating Agile Test Cases

  1. -RP- says:

    Very informative and easy to understand.

  2. Pingback: Countries and Rates for off-shore software development | josephvargheese

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: