Writing Test cases in an agile approach
I use to develop test cases in the traditional way by defining the following for each test senario:-
- Test case name. “View Current Transaction”
Valid “Username & password”
The system is up and running
- Test Case Steps
- Login to the system.
- Click on “manage account”
- Click on “view current transactions”
- 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
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.