Certifying the different configurations of the same system
In the enablement projects, the HWE team usually works enabling different configurations of the same hardware (with or without bluetooth; with nVidia or Intel graphics, etc.). In Certification we are not taking care of these different configurations and usually we just certify one of the configurations.
In the case of the desktops, the HWE team normally receive just one system and the additional configuration. For example, they receive a desktop with Intel graphics and, apart, a nVidia card (the second configuration). The HWE team will install the card during the enablement process. This is not a possibility for the certification team, if we keep testing the same way we do right now.
For laptops the situation is a bit better, as the enablement team would normally receive another laptop with the second configuration. But, again, if we aim to certify all the different configurations, we need to revisit the way we test, as the growth expected for the number of certified systems can quickly overload the capacity of our labs.
This same problem occurs sometime after the system has reached RTS. After an enablement project has been finished, the customer might want to enable another configuration of the same system. This situation also needs to be handle as part of this blueprint.
Blueprint information
- Status:
- Started
- Approver:
- Kevin Krafthefer
- Priority:
- Medium
- Drafter:
- Ara Pulido
- Direction:
- Approved
- Assignee:
- None
- Definition:
- Approved
- Series goal:
- None
- Implementation:
-
Started
- Milestone target:
-
november2011
- Started by
- Victor Tuson Palau
- Completed by
Whiteboard
== Definition of done ==
* We have a frequently updated and reliable system that generates the minimum amount of systems that need to be tested for each type of regular testing (SRU, weekly).
* We have an inventory policy that improves the way we store systems in our labs, based on the activity each system has.
* The different certified configurations are shown in the public certification website in a way that is usable for the end-user and making clear which release a particular SKU was certified for, and which combination of components form a SKU
* We have a policy on the criteria on what configurations are we certifying for each system.
* The post RTS project are managed in the same way.
* Unless there is a physical exception (lack of hardware, etc.), all the different SKUs for a system are tested
The following text reflects David Bensimon views and are currently not part of the implementation plan/actions approved for the certification team (-victorp):
==DB-START==
The goal of having a certification site is making certified hardware available to end users. Without assisting customers/
For the Hardware Certification page to be useful we need to:
- Show in which markets the PC is available (country flag or country preference).
- Link to manufacturer's page for that specific Model/SKU/
- If the manufacturer does not differentiate between configurations (such is the case with Dell), we need to make this a contractual requirement.
- Keep manufacturer accountable for changes in configuration by applying pressure to accept returns if they change hardware controllers, hardware revisions, or BIOS versions without certifying that change with us first.
David Bensimon
==DB-END==
