So I see 3 actions from integration today’s call: 1) Find out what documentation is relevant for test end users (e.g. developers, integration people). This may include:
- Feature/functionality description. - High level test plan. - Detailed test cases description. 2) Look at what of the above can be automatically generated from the robot test itself, either using robot parsing scripts or creating our own. Note: we can use doc hackathon for this. 3) Review test documentation strategy (we already have some stuff in place but maybe not working the way we want), spread this in the community and start enforcing things we need to meet the test documentation requirements. Comments? BR/Luis > On Jan 30, 2017, at 1:19 PM, Robert Varga <n...@hq.sk> wrote: > > On 01/30/2017 04:59 PM, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES > at Cisco) wrote: >> Current cluster suites do contain documentation, >> >> but it is focused on tester point of view only. >> >> I will be creating new integration/test: docs/ files >> >> to bridge the gap. >> > > It would be great to have these as test plans, so we can easily > cross-reference scenarios and have an understanding what our scenario > coverage is. > > Regards, > Robert > > _______________________________________________ > controller-dev mailing list > controller-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/controller-dev _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
