Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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

share|improve this question
1  
What is the reason you document your test case? (a) to report what has been tested, (b) to have test cases for regression testing, or (c) something else? –  dzieciou Mar 10 at 17:45
3  
Do you want to know how to document test cases or do you want to know how to do 'agile' testing? How well did the 'traditional' approach work for you? –  Phil Kirkham Mar 10 at 18:03
    
Agile doesn't mean less systematic. Your approach will show it's benefits in the long run. –  Lord_Gestalter Mar 11 at 7:17
    
he reason for my test cases , is to both used by the tester to test the system, and also for the customers to execute the test scenarios during the UAT.. –  John John Mar 11 at 13:55
    
If you didn't give the customers step-by-step instructions, what would they do? What do they do normally, once the software is in production? –  testerab Mar 11 at 18:34

2 Answers 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.

share|improve this answer
    
the reason for my test cases , is to both used by the tester to test the system, and also for the customers to execute the test scenarios during the UAT.. –  John John Mar 11 at 13:55

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.