42 lines
4.5 KiB
Plaintext
42 lines
4.5 KiB
Plaintext
|
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 Arial;}{\f1\fswiss\fprq2\fcharset0 Arial;}{\f2\froman\fprq2\fcharset2 Symbol;}}
|
|||
|
|
{\colortbl ;\red0\green0\blue0;}
|
|||
|
|
{\stylesheet{ Normal;}{\s1 heading 1;}{\s2 heading 2;}}
|
|||
|
|
\viewkind4\uc1\pard\fi-1800\li1800\tx1800\cf1\b\f0\fs20 From:\b0\tab Nathan Cornillon\par
|
|||
|
|
\b Sent:\b0\tab Friday, January 28, 2000 12:46 PM\par
|
|||
|
|
\b To:\b0\tab Farzana Rahman; Michele Freed; Murthy Srinivas; Nathan Cornillon; Alex Armanasu; Jimin Li; Gigel Avram\par
|
|||
|
|
\b Subject:\b0\tab User State Migration Tool: Closing on the ship date - Meeting Minutes\par
|
|||
|
|
\pard\keepn\s1\cf0\b\f1\fs24 User State Migration Tool - Closing on the ship dates\par
|
|||
|
|
\pard\fs20 Date\b0 :\tab\tab Thursday, January 27, 2000.\par
|
|||
|
|
\b Goal\b0 :\tab\tab Come to an agreed upon target ship date for the tool.\par
|
|||
|
|
\b Participants\b0 :\tab Farzana, Michele, Murthy, Nathan, Alex, Jimin Gigel\par
|
|||
|
|
\par
|
|||
|
|
\pard\keepn\s2\b Agenda\par
|
|||
|
|
\pard\fi-360\li720\tx720\b0\f2\'b7\tab\f1 Quickly review Jimin\rquote s schedule break down document.\par
|
|||
|
|
\pard\fi-360\li720\f2\'b7\tab\f1 Discussion options to ship in April.\par
|
|||
|
|
\pard\par
|
|||
|
|
\pard\keepn\s2\b Resolutions\par
|
|||
|
|
\pard\fi-360\li720\tx720\b0\f2\'b7\tab\f1 We will have single rolling regression to meet the Supported Beta ship date of April 15, 2000 for JDP and RDP customers.\par
|
|||
|
|
\pard\fi-360\li720\f2\'b7\tab\f1 Version 1 of the tool will be released with the summer refresh of the ResKit. We are targeting a test completion date of 6/6/2000. (The exact needed dates for inclusion with the summer refresh of the ResKit will follow in early next week.)\par
|
|||
|
|
\pard\par
|
|||
|
|
\pard\keepn\s2\b Action Items\par
|
|||
|
|
\pard\fi-360\li720\tx720\b0\f2\'b7\tab\f1 NathanC - Drill down with the IE test team and the DUN folks to identify which specific versions of Win9X we need to focus on for testing? (Which ones have different DUN.) We need this information ASAP.\par
|
|||
|
|
\pard\fi-360\li720\f2\'b7\tab\f1 NathanC - Do the same with the items from the User Data & Profile sections for Win9X. Can we reduce the number of versions we are testing? We need this information ASAP.\par
|
|||
|
|
\f2\'b7\tab\f1 NathanC - Get a prioritized list of OS version, Outlook versions, and IE versions to test. Make sure these priorities are also reflected in the spec. Do this by EOD Friday 1/28.\par
|
|||
|
|
\f2\'b7\tab\f1 NathanC - Get the ResKit submission dates and ship dates. Send this to team by early next week.\par
|
|||
|
|
\f2\'b7\tab\f1 JiminLi - Once NathanC delivers the information on needed versions and prioritizations, update the breakdown documents to reflect the new dates.\par
|
|||
|
|
\pard\par
|
|||
|
|
\pard\keepn\s2\b Details\par
|
|||
|
|
\pard\b0 We spent the first part of the meeting going over Jimin\rquote s breakdown. Most of the test areas took one or two weeks per configuration. The critical path items were Automated Testing Algorithm verification and Win9X System Settings (DUN).\par
|
|||
|
|
\par
|
|||
|
|
The test team is made up of 2 SDET (local), 2 STE (local), 2 SDET (off-site), and 3 STE (off-site) for 9 testers (not including management/leads).\par
|
|||
|
|
\par
|
|||
|
|
We primarily address option 6 seeming to be the best compromise on being able to meet the customer need to have something for the April date while also being able to meet tests quality bar. We decided we should ship a supported beta 4/15/2000 to JDP/RDP customers. Then we will include the version 1 of the tool in the ResKit release targeted for summer 2000. There is a risk, we don\rquote t know the exact dates for submissions for the summer ResKit release. We need to get these dates (assigned to NathanC) and verify that we can meet them.\par
|
|||
|
|
\par
|
|||
|
|
To meet this date it was agreed we would use a \ldblquote rolling regression\rdblquote test method. This means when a bug is fixed, the previous tests that passed are not retested. The only additional testing is to target that bug was fixed (and any areas directly identified as needing testing as a result of the fix by dev). There is a risk associated with this approach. The risk is we will miss a bug caused be a fix in a seemingly unrelated area. For the April release, we are willing to live with this risk.\par
|
|||
|
|
\par
|
|||
|
|
The final part of the meeting was spent trying to identify test configuration which might not need specific coverage. It was decided we didn\rquote t have enough information and needed to research this more (assigned to NathanC). We also agreed it was important to have very clear priorities on the order versions of the OS, Outlook, and IE should be tested (assigned to NathanC).\par
|
|||
|
|
\par
|
|||
|
|
\f0\par
|
|||
|
|
\pard\fi-1800\li1800\tx1800\cf1\par
|
|||
|
|
}
|
|||
|
|
|