doc: add TRG regarding test automation

[ds-lcapellino]

Description

Pre-review checks

Please ensure to do as many of the following checks as possible, before asking for committer review:

• DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
• Copyright and license header are present on all affected files

[rafaelmag110]

I appreciate the idea of having a TRG defining the guidelines for test automation within the overall project. However, this proposal focus in its major part on the usage of Cucumber as the solution. Even tho its stated in the last section that it is more of recommendation than a TRG, interpretation can quickly transform a recommendation in a requirement. I'd strongly advise not to push certain solutions to individual products, as it might not be well received. And indeed, products should have the freedom to chose what solution they want to implement, as long as it complies with the defined TRG's.

With that in mind, in a test automation guideline I'd expect concise decisions on the expected standard for test automation in each product. i.e What type of tests should definitely be automated. In which occasion these tests should be executed. What commitment should each product make to maintain these tests, especially if we are talking about integration tests with other tractus-x dependencies.