Testing Strategy

A good testing strategy ensures that defects are discovered as early in the developmental cycle as possible.

*Stories should be analyzed and written in such a way that any gaps and ambiguities in the requirements have been flushed out and questions such as whether the story is testable have been addressed.

*Acceptance tests (both manual and automation) are written for the story covering as many scenarios as possible (viz. edge cases, positive & negative paths ) based on the requirements. This should be done before a story is made available to developers, as it makes their lives a lot easier.

*Automation tests should be written in Cucumber using Ruby Mine. These tests need to be successfully up and running as part of the build by the time the story is completed by the developers. The best way of implementing these tests would be by pairing with the developers on their machines.

*Once the developers have finished their bit, the story ideally needs to be tested on a “production like” environment covering all the acceptance tests. Regression testing (mainly areas which are not covered under automation tests) would be good to check system integrity.

*Any defects that creep up can be captured on the “Default Wall” in Mingle or the GitHub bug tracker to be picked up by developers and fixed. Automation tests should be written if possible as part of the fix. A story should be closed only after all the major defects against the story have been fixed.

H3.Testing Non-Functional Requirements (Performance & Load):

*As the system evolves over time, we need to ensure that the user experience in terms of page load response time (Performance) is up to the expectations. At the same time we should ensure that the system does not crash when the number of hits exceed a certain limit (Load). It is ideal to have a separate performance environment for these kind of testing.

*Security also needs to be covered here. We need to look out for things like session time outs, multiple logins through multi browsers / locations.

*The user interface and user experience should be verified against the design specifications. Testing the application across well known browsers is highly recommended to ensure compatibility.

H3.Sample Story along with acceptance tests:

Story #41 Edit a user’s details

Requirements
*An adminstrator can edit a user’s details from the list of users
Any field can be edited
*Admin can save changes
**Updated information is shown in list of users

Acceptance Tests
As an admin,
*Given that I am on the user listing view page,
*When I click on the edit link against any record,
*Then I should be taken to a page where I can edit the user details.

As an admin,
*Given that I am on the edit user details page,
***Then I should not be able to edit the “username” field

As an admin,
*Given that I edit user details,
*When I click on update button
*Then the changed user details should be updated and the others should remain the same.

As a user,
*Given that I am on the edit user record page,
***Then all the validations of the fields should still hold true