Writing Test cases in an agile approach

Question

I use to develop test cases in the traditional way by defining the following for each test senario:-

1. Test case name. “View Current Transaction”

2. Pre-condition.

   • Valid “Username & password”

   • The system is up and running

3. Test Case Steps
   • Login to the system.
   • Click on “manage account”
   • Click on “view current transactions”
4. Expected Results
   • The system should display the user transactions starting from the most recent one.

And I have to create separate test case for any exceptional scenario such as ; when a transaction failed, transaction require approval , etc….

The above approach will work fine , but it require a lot of time and the test cases document will be very large (depending on the project size of-course). So is this the right approach to document test cases ? or there is a more agile approach which lead to the same results but in less time and efforts ? Thanks

Answer 1

I think Agile testers should assist their Product Owner with writing Acceptance Criteria in the user stories. If you write scenario's in Gherkin you can create manual test cases that match your four criteria of a test.

  Scenario: Some action (1. Name)
    Give I am logged in (2. Pre-condition)
     And I setup something else
    When I do some action (3. Test case steps)
     And I click somewhere
    Then I get some result (4. Expected results)
     And I verify there are no errors

Personally I love the Cucumber framework as you can re-use your cases as automated tests, see http://cukes.info/ or read the Cucumber book for starters http://pragprog.com/book/hwcuc/the-cucumber-book

The main reason to write Scenario's upfront (before development) is to get the feedback loop started as soon as possible. By writing down high level cases your Product Owner is forced to think about its user stories. Although I see added value in a manual test suite, I would push for an automated suite of tests instead, since you want feedback as soon as possible and the team should not want to wait for the QA team to finish their testing.

Ask yourself, how can I (as a tester) help the team getting the PBI done and deliverable within the iteration, instead of testing after the development team is done and giving feedback after some days or weeks.

Other reads:

• https://less.works/less/technical-excellence/specification-by-example.html

Answer 2

Depends on the quality requirements of the project and the maturity of its user stories. If the test has to be done once by the same person who has written the test cases, then documenting the test case steps would not be essential or indespensable. On the other hand, a project requiring different phases of regression testing over a long period of time with frequent deliveries especially involving multiple testers, needs your methodology. Each bug is linked to its test case which is linked to its corresponding user story. Based on the test case result and its linked bugs, the status of the user story can be concluded to know if it is shippable or not. The test case also documents the behaviour of the product so that it would be easy to check the various scenarios while introducing a change requirement. The effort and the quality of the test suite thus depends on how much quality is and shall be invested to ship the product.