This is replacing
HW partners will need a mechanism to download verification documentation, and possibly also use it automatically for their self created QBSP files. We will use Testrail tool for this.
Partners may not use Testrail for other reasons than exporting documentation on test cases and steps. This is due to Testrail may or may not be compatible for partner own RTA and verification usage.
Hardware partners are working on new hardware and that details in confidential. If partner is using Testrail for other use cases that test case documentation source the visibility of partner used hardware must be confidential and limited to partner only. When needed, partner may make that public to TQC or to the other users of Testrail.
Should partner be able to use the system as part of their own CI and RTA they will need API access to Testrail.
It should be possible to use a Qt account against Testrail. This will simplify partner account creation, maintenance and access.
We need to decide how partners can provide test case updates and improvements to the overall test set, and how HW (or OS) specific variations are managed.
Optimally, test results (based on Testrail QBSP test cases) can also be inside the QBSP package (QTBUG-72815). What would be the defined format and location inside QBSP? Should that be machine readable so that when we get a QBSP form a partner we could automate a simple check does the QBSP pass?
Different stakeholders will have different level needs for existence and use etc of the created system. Examples on partner side is their own sales, technical support, engineering and TQC internally our own R&D, sales, tech sales, technical support, marketing, professional services, product management etc. This means all kinds of documentation from powerpoint slideware and emails to blog posts and actual technical documentation files.
<Asmo to add links to Wikis and Sharepoints>