Confirmed users
1,867
edits
Websites/Affiliates/Test Plan: Difference between revisions
Jump to navigation
Jump to search
→2. Automated testing:
| Line 39: | Line 39: | ||
===2. Automated testing:=== | ===2. Automated testing:=== | ||
A carefully defined Selenium automated test suite will be created. Tests will focus on areas that cannot be covered in unit tests. Example: Python cannot test CSRF functionality because the python suite disables it. | |||
*Selenium tests will only be for use cases which cannot be covered by Python or | *Selenium tests will only be for use cases which cannot be covered by Python or QUnit. | ||
*This test suite will be run for each code check-in, and will only be run in staging or the developer environment. Each test will qualify as a deployment blocker if it fails. | *This test suite will be run for each code check-in, and will only be run in staging or the developer environment. Each test will qualify as a deployment blocker if it fails. | ||
Tests will cover critical areas such as: | Tests will cover critical areas such as: XXX | ||
*All other automated tests will be deleted or removed. | *All other automated tests will be deleted or removed. | ||
*In production automated tests will be run that verify the environment and services are all working | *In production automated tests will be run that verify the environment and services are all working. | ||
*We could have more tests run in production, although only ones that do not create or destroy content. It is important not to create unnecessary data | *We could have more tests run in production, although only ones that do not create or destroy content. It is important not to create unnecessary data. Features are fully tested after each check-in. | ||
===3. Releases:=== | ===3. Releases:=== | ||