Language Testing Plan/LanguageTestingWorkflow

THIS IS A PROPOSAL

The Wikimedia Language Engineering team presently uses the Cucumber and Selenium to test implemented features in web-browsers. Besides these automated tests implemented using Ruby, the team also tests manually when automated tests are not feasible or not implemented. For all tests the scenarios to be tested are written in the Given-When-Then format. This can be explained as:

Given a Situation When a certain event occurs Then a certain result is expected

This document outlines the process and best practices to implement tests that fully cover the user interface functionalities for repeated runs.

Phase 0: Conceptualization
When a feature is identified for implementation, the details of its functionalities, interface design and interactions are ascertained by the Product Owner in consultation with other stakeholders and described in the design documents. These descriptions are the blueprints for the developers when they implement the functionalities through code. It is imperative that the functionalities are clearly described for all possible user activity. A means to this end is the conceptualization of the individual Given-When-Then scenarios, that provide the developers with the description of the events that can be executed under different conditions and the intended reactions.

Phase 1: Scenario Building
The Given-When-Then scenarios are the smallest levels of activities that can be put together to describe a functionality. It is if extreme important to create the scenarios from the defined designs, including user interface mockups. This ought to be done by simulating interactions by the user on the dialogs, forms, buttons, input boxes and other user interaction elements described in the mock-up.

The number of scenarios can be extremely elaborate at this stage.

Completed: A list of Given-When-Then scenarios of possible user activities for all functionalities is prepared

 People Involved: QA

Phase 2: Feature Review and Consensus
The list of scenarios created in Phase I is the foundation for all tests that need to be run against the feature. This exercise of granularity may also identify any missing functionalities or scenarios that may have been overlooked during the original design decisions. At this stage it is important to verify these inconsistencies with the Product Owner or UI Designer. This may or may not require the scenarios to be rewritten or modified.

In cases where the scenarios are written for extension of already implemented features, the original developers' may also be consulted.

Completed: The GWT scenario list is ratified for consistency with intended feature

 People Involved: QA, PO, UI Designer, (Developers)