Mozillians/Test-Plan: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
=Test Plan=
=Test Plan=
 
<!--
==Analysis==
==Analysis==


Line 23: Line 23:
===4. Bug fixes:===
===4. Bug fixes:===
*Do not need verification prior to releases. They may be verified by a developer, or by QA in production.  
*Do not need verification prior to releases. They may be verified by a developer, or by QA in production.  
-->


==Risk areas==
==Risk areas==
Line 45: Line 46:
[2] can fail for up to an hour<br>
[2] can fail for up to an hour<br>


<!--
==Risk plan and tools==
==Risk plan and tools==
====1. Risk: Less critical tests will not be covered with automation.====
====1. Risk: Less critical tests will not be covered with automation.====
Line 64: Line 66:
====6. Risk: We don't have a current baseline for quality.====
====6. Risk: We don't have a current baseline for quality.====
*We are gathering data all the time with new services. It is really difficult to measure the current level of regression and new bugs which are sent out in releases. The entire team is keeping an eye on quality in order to keep the levels up. In order to maintain current levels of quality we will keep an eye on regressions and feedback.
*We are gathering data all the time with new services. It is really difficult to measure the current level of regression and new bugs which are sent out in releases. The entire team is keeping an eye on quality in order to keep the levels up. In order to maintain current levels of quality we will keep an eye on regressions and feedback.
-->

Revision as of 20:14, 8 October 2012

Test Plan

Risk areas

The lower the number the higher the risk.

1. API - returns correct vouched status & information
1. Existing User Login
1. New User registration
1. User editing/saving account information

2. User vouching
2. Invite New User
2. View Profile
2. View Groups
2. Mozillians Search (web ui)
2. API - new account request


Legend

[1] must have good enough coverage that we feel comfortable a regression will be caught quickly be pushed out to production if broken
[2] can fail for up to an hour