Using Excel for acceptance tests?

Question

I am new to testing and am wondering how to write acceptance tests based on User stories, and what tools I can use?

Can I use excel to write acceptance tests? Or is that only for test cases?

Answer 1

the answer to your first question is YES. You can definitely use Excel for creating acceptance tests. There are different types of acceptance testing:

1. User Acceptance test
2. Operational Acceptance test
3. Contract Acceptance testing
4. Compliance acceptance testing

So, I am assuming that you are planning to create acceptance tests for User Acceptance testing.

To keep things simple, I would suggest you to write end to end positive scenarios as part of acceptance test cases. These cases should be good enough to assure the users that the expected functionalities are working fine. You can also use a subset of your functional test cases.

So, the characteristics of acceptance test cases are as follow:

1. Acceptance test cases are high level (not as detailed as system test cases).
2. You can ignore negative test cases
3. But should must include positive scenarios covering end to end flow of the application.
4. The test cases should be written in a way so that they help the user to evaluate overall quality of the implementation so that the user can accept or reject the product. And while writing acceptance test cases, you should more focus on functional coverage and should think beyond user story level.

Let me know if you have any further questions.

Answer 2

You should choose a tool and format that is acceptable to the people interested in the acceptance scenarios; probably, we are talking about the testers, developers and the client (the one who says 'Ok, good to go').

Some methodologies don't differentiate stories and acceptance tests, what is to be built is describe as testable scenarios; that's called Behaviour-Driven Development. Maybe using this approach can remove over-head of keeping stories and acceptance tests in sync, but this need to be introduced by the whole team.

Answer 3

You can use whatever tool you want. Excel, Word, NotePad, Confluence, etc.

The important thing is that the tests themselves are easy to understand, easy to maintain, reflect domain knowledge and are logical to execute. Frequently the driving factor on which tool will be the existing company tools in use.

For automated tests, Cucumber and Capybara are two examples of tools used for the UI feature testing that is often used for more technically based acceptance tests.

Answer 4

I'm a bit of a purist when it comes to User Stories and User Tests, or User Acceptance Tests. I feel they should be written by the user to demonstrate to the user the correctness or data and operation of their system.

To be fair, there will be some internal IT tests that come off technical IT tasks that you are implementing as part of your product backlog.

For each User Story, there could be a number of acceptance tests, which will need to be satisfied, but these tests could cover a number of User Stories.

It is dependent upon a few things that will enable you to choose the correct tool for testing.

• the number of tests
• the style of tests (database testing or user interface testing)
• the depth of testing
• the amount of repetition of your testing
• are you going to re-use your tests as regression tests?

As far as tool suggestions, I think you need to understand the answers to these questions and then perhaps ask a further focussed question of this forum.

Answer 5

Probably you can, you can use Excel for anything it seems. Should you? Probably not.

Keep the acceptance criteria close the user story itself, not in a separate system. We document them the description of the user story. Others keep them on the physical Scrum-Board on post-its. Keep the process simple and effective.

Keep the Agile manfesto in mind:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Wondering about Excel and documenting these acceptance criteria sounds like tools and documentation. What does your cycle need? Can you keep it simpler? Discuss with your team what you need to create working software.