[Starlingx-discuss] Test Case Submission in rst format
Hi Abraham, We are currently in process of submitting our test cases in stx-test git repository. There has been a request to upload manual tests is rst format so that they can be visible on a wiki. Conversion of test cases from plain text format to rst format is causing a lot of pain and time lost. At the same time it is also not an absolute requirement as any tester who wants to execute these test cases can easily access them from git in text format. I am not sure about how much time is spent by Ada's team in converting these test cases but I would suggest that we should submit them in plain text format and if documentation team wants to convert them in rst then they can update them. Secondly, if these test cases are to be shown in Wiki, what is your plan for showing them in next release? Would there be a release specific Wiki or a selection available to check test cases for each release? Thanks, Numan.
Hi Numan,
We are currently in process of submitting our test cases in stx-test git repository. There has been a request to upload manual tests is rst format so that they can be visible on a wiki.
Thanks to you and all test team for all the support to take advantage of existing documentation infrastructure and give it a try to have it under our official documentation channel at starlingx.io
Conversion of test cases from plain text format to rst format is causing a lot of pain and time lost. At the same time it is also not an absolute requirement as any tester who wants to execute these test cases can easily access them from git in text format.
We understand this is a time consuming process considering the number of test cases you have and the ramp up in the learning of the RST format if automated tools are not used. Agree that the format is not relevant to execute a test case.
I am not sure about how much time is spent by Ada's team in converting these test cases but I would suggest that we should submit them in plain text format and if documentation team wants to convert them in rst then they can update them.
Let's add this option to the table. At the end, you as a team has the final decision and decide what is the best approach that works for you, here you have the existing options: [ Option A ] Convert all test cases to RST format and merge. [ Option B ] Keep all test cases in X format and merge. [ Option C ] Only merge what has been converted to RST format. There is no right option, again, it all depends on the needs and priorities of the team, your call.
Secondly, if these test cases are to be shown in Wiki, what is your plan for showing them in next release?
The test cases could land (one commit away to make this happen) under our official StarlingX documentation site at: https://docs.starlingx.io/ Our proposal is to add "Test" down to "Tools", under "There are several supporting projects and repositories": - Tools < pointing to https://docs.starlingx.io/stx-tools/index.html - Test < pointing to https://docs.starlingx.io/stx-test/index.html This way we are taking full advantage of the StarlingX documentation infrastructure based in OpenStack guidelines and giving a standard and formal way to present it to the community.
Would there be a release specific Wiki or a selection available to check test cases for each release?
We can discuss what are your needs in terms of versioning in our weekly meeting. As an example, we are currently working to split the installation documentation in 2 versions based in "directories": 1. Version one: old way to deploy StarlingX 2. Version two: new containerized way to deploy StarlingX More information about this "versioning" task under our meeting minutes here: https://etherpad.openstack.org/p/stx-documentation Please let us know any other question you might have. More than happy to support your team objectives.
Well, based on the amount of work that rst formatting is requiring, and being as close as we are to the release testing, I support the submission of manual test cases (to our repo) using txt format. We can continue the effort of translating those into rst in the following months, so we can align to the project documentation standards. Please raise the concerns you might have regarding this topic Ada
-----Original Message----- From: Arce Moreno, Abraham Sent: Friday, March 8, 2019 3:45 PM To: Waheed, Numan <Numan.Waheed@windriver.com>; Cabrales, Ada <ada.cabrales@intel.com>; starlingx-discuss@lists.starlingx.io Subject: RE: Test Case Submission in rst format
Hi Numan,
We are currently in process of submitting our test cases in stx-test git repository. There has been a request to upload manual tests is rst format so that they can be visible on a wiki.
Thanks to you and all test team for all the support to take advantage of existing documentation infrastructure and give it a try to have it under our official documentation channel at starlingx.io
Conversion of test cases from plain text format to rst format is causing a lot of pain and time lost. At the same time it is also not an absolute requirement as any tester who wants to execute these test cases can easily access them from git in text format.
We understand this is a time consuming process considering the number of test cases you have and the ramp up in the learning of the RST format if automated tools are not used. Agree that the format is not relevant to execute a test case.
I am not sure about how much time is spent by Ada's team in converting these test cases but I would suggest that we should submit them in plain text format and if documentation team wants to convert them in rst then they can update them.
Let's add this option to the table. At the end, you as a team has the final decision and decide what is the best approach that works for you, here you have the existing options:
[ Option A ] Convert all test cases to RST format and merge. [ Option B ] Keep all test cases in X format and merge. [ Option C ] Only merge what has been converted to RST format.
There is no right option, again, it all depends on the needs and priorities of the team, your call.
Secondly, if these test cases are to be shown in Wiki, what is your plan for showing them in next release?
The test cases could land (one commit away to make this happen) under our official StarlingX documentation site at: https://docs.starlingx.io/
Our proposal is to add "Test" down to "Tools", under "There are several supporting projects and repositories":
- Tools < pointing to https://docs.starlingx.io/stx-tools/index.html - Test < pointing to https://docs.starlingx.io/stx-test/index.html
This way we are taking full advantage of the StarlingX documentation infrastructure based in OpenStack guidelines and giving a standard and formal way to present it to the community.
Would there be a release specific Wiki or a selection available to check test cases for each release?
We can discuss what are your needs in terms of versioning in our weekly meeting. As an example, we are currently working to split the installation documentation in 2 versions based in "directories":
1. Version one: old way to deploy StarlingX 2. Version two: new containerized way to deploy StarlingX
More information about this "versioning" task under our meeting minutes here: https://etherpad.openstack.org/p/stx-documentation
Please let us know any other question you might have. More than happy to support your team objectives.
Hi Ada, We discussed this topic in stx-test call and Abraham was fine with us submitting our test plans in txt format. Thanks, Numan. -----Original Message----- From: Cabrales, Ada <ada.cabrales@intel.com> Sent: March-13-19 5:01 PM To: Arce Moreno, Abraham <abraham.arce.moreno@intel.com>; Waheed, Numan <Numan.Waheed@windriver.com>; starlingx-discuss@lists.starlingx.io Subject: RE: Test Case Submission in rst format Well, based on the amount of work that rst formatting is requiring, and being as close as we are to the release testing, I support the submission of manual test cases (to our repo) using txt format. We can continue the effort of translating those into rst in the following months, so we can align to the project documentation standards. Please raise the concerns you might have regarding this topic Ada
-----Original Message----- From: Arce Moreno, Abraham Sent: Friday, March 8, 2019 3:45 PM To: Waheed, Numan <Numan.Waheed@windriver.com>; Cabrales, Ada <ada.cabrales@intel.com>; starlingx-discuss@lists.starlingx.io Subject: RE: Test Case Submission in rst format
Hi Numan,
We are currently in process of submitting our test cases in stx-test git repository. There has been a request to upload manual tests is rst format so that they can be visible on a wiki.
Thanks to you and all test team for all the support to take advantage of existing documentation infrastructure and give it a try to have it under our official documentation channel at starlingx.io
Conversion of test cases from plain text format to rst format is causing a lot of pain and time lost. At the same time it is also not an absolute requirement as any tester who wants to execute these test cases can easily access them from git in text format.
We understand this is a time consuming process considering the number of test cases you have and the ramp up in the learning of the RST format if automated tools are not used. Agree that the format is not relevant to execute a test case.
I am not sure about how much time is spent by Ada's team in converting these test cases but I would suggest that we should submit them in plain text format and if documentation team wants to convert them in rst then they can update them.
Let's add this option to the table. At the end, you as a team has the final decision and decide what is the best approach that works for you, here you have the existing options:
[ Option A ] Convert all test cases to RST format and merge. [ Option B ] Keep all test cases in X format and merge. [ Option C ] Only merge what has been converted to RST format.
There is no right option, again, it all depends on the needs and priorities of the team, your call.
Secondly, if these test cases are to be shown in Wiki, what is your plan for showing them in next release?
The test cases could land (one commit away to make this happen) under our official StarlingX documentation site at: https://docs.starlingx.io/
Our proposal is to add "Test" down to "Tools", under "There are several supporting projects and repositories":
- Tools < pointing to https://docs.starlingx.io/stx-tools/index.html - Test < pointing to https://docs.starlingx.io/stx-test/index.html
This way we are taking full advantage of the StarlingX documentation infrastructure based in OpenStack guidelines and giving a standard and formal way to present it to the community.
Would there be a release specific Wiki or a selection available to check test cases for each release?
We can discuss what are your needs in terms of versioning in our weekly meeting. As an example, we are currently working to split the installation documentation in 2 versions based in "directories":
1. Version one: old way to deploy StarlingX 2. Version two: new containerized way to deploy StarlingX
More information about this "versioning" task under our meeting minutes here: https://etherpad.openstack.org/p/stx-documentation
Please let us know any other question you might have. More than happy to support your team objectives.
On 2019-03-08 14:12:21 +0000 (+0000), Waheed, Numan wrote:
We are currently in process of submitting our test cases in stx-test git repository. There has been a request to upload manual tests is rst format so that they can be visible on a wiki.
Which wiki are you using? If this is for wiki.openstack.org it does not support reStructuredText format, but rather a special MediaWiki markup language.
Conversion of test cases from plain text format to rst format is causing a lot of pain and time lost. At the same time it is also not an absolute requirement as any tester who wants to execute these test cases can easily access them from git in text format. [...]
If this is in service of being able to build static HTML representations with Sphinx, a useful stepping-stone is to create empty rst documents (perhaps with just a page heading) and then use the include:: directive with the :literal: argument to embed preformatted text from another file elsewhere in the same Git repository. -- Jeremy Stanley
participants (4)
-
Arce Moreno, Abraham
-
Cabrales, Ada
-
Jeremy Stanley
-
Waheed, Numan