Acceptance Testing – Writing Effective Acceptance Test Cases

acceptance-testingdocumentationtesting

We are integrating a testing process in our SCRUM process. My new role is to write acceptance tests of our web applications in order to automate them later. I have read a lot about how tests cases should be written, but none gave me practical advices to write test cases for complex web applications, and instead they threw conflicting principles that I found hard to apply:

  • Test cases should be short: Take the example of a CMS. Short test cases are easy to maintain and to identify the inputs and outputs. But what if I want to test a long series of operations (eg. adding a document, sending a notification to another user, the other user replies, the document changes state, the user gets a notice). It rather seems to me that test cases should represent complete scenarios. But I can see how this will produce overtly complex test documents.

  • Tests should identify inputs and outputs:: What if I have a long form with many interacting fields, with different behaviors. Do I write one test for everything, or one for each?

  • Test cases should be independent: But how can I apply that if testing the upload operation requires that the connect operation is successful? And how does it apply to writing test cases? Should I write a test for each operation, but each test declares its dependencies, or should I rewrite the whole scenario for each test?

  • Test cases should be lightly-documented: This principles is specific to Agile projects. So do you have any advice on how to implement this principle?

Although I thought that writing acceptance test cases was going to be simple, I found myself overwhelmed by every decision I had to make (FYI: I am a developer and not a professional tester). So my main question is: What steps or advices do you have in order to write maintainable acceptance test cases for complex applications. Thank you.

Edit: To clarify my question: I am aware that Acceptance testing should start from the requirement and regard the whole application as a black box. My question relates to the practical steps to write the testing document, identify the test cases, deal with dependencies between tests…for complex web applications

Best Answer

In my acceptance suites I have stayed away from using technology specific controls i.e for web applications don't use css dont use html elements if you need to fill in a form do the specifics in the steps to setup the SUT not the actual acceptance tests

I use cucumber for my acceptance and have the following

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

this example is back by a web application but I can still use the test to test against a desktop application as the steps are used to setup the SUT not the acceptance tests

this test sits at the end of a purchase which goes

Generate -> Confirm -> Payment -> Print Receipt

the test above is for the payment step the other steps are setup in other tests due to the application being able to setup into these states with data or http actions in this case the payment has a given which does the confirm steps and the confirm does the generate steps so they are a bit brittle at the minute

Related Topic