11:48 a.m.
Hi all,
The testcase in question is the base service manipulation test [0]. This
testcase is a Final-milestone test for x86_64, ARM, and cloud in the
validation test matrix [1][2][3]. It is also an optional testcase for
non-release-blocking spins [4][5].
In many of the testing scenarios that this testcase is used, the tester is
logged into and testing the machine remotely via ssh. As the testcase
stands now, the default service that is listed to test with is sshd. Since
this test requires the tester to continually enable/disable/start/stop the
sshd service, doing so on a machine that is remotely logged into will cause
problems with ssh and could leave the tester stuck out of their system. In
many cases where the tester does not have access to the hardware to login
physically, this requires spinning up a new image to test remotely
(thinking particularly of AWS), and can be quite a hassle.
Currently, there is a note listed at the beginning of the testcase that
warns the tester of these adverse effects, should the testcase be followed
explicitly on a system being used remotely [6]. It suggests using a
different, non-critical service to test the functionality, such as chronyd.
I would like to propose that we change the default service that this
testcase lists to use in the examples to something less critical to a
tester who is logged in remotely over ssh. I propose we change the service
to chronyd, but am open to other suggestions. As it stands, I don't see a
reason to use ssh over another service, especially if using ssh can
introduce some problems. The only reason I could possibly see as to why ssh
was used in the first place was that it's enabled on all spins of Fedora,
but I'm not certain of that. If someone wants to inform me as to why ssh
was originally used, please do.
This would make it easier to find a service to test with for those logged
into systems remotely while also keeping the test uniform across all arches
and spins of Fedora, as the same service could be used across all platforms.
It has been suggested to create a separate testcase specifically for
systems that are tested via remote logins, but if there is no reason to
continue using ssh in this testcase, I think it would be a good idea to
change it and keep just one testcase for all in this instance.
Comments, questions, concerns: welcome!
Geoff Marr
IRC: coremodule
[0] https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation
[1]
https://fedoraproject.org/wiki/Template:Base_test_matrix#Release-blocking...
[2]
https://fedoraproject.org/wiki/Template:Base_test_matrix#Release-blocking...
[3] https://fedoraproject.org/wiki/Template:Cloud_test_matrix
[4]
https://fedoraproject.org/wiki/Template:Base_test_matrix#Non-blocking_env...
[5]
https://fedoraproject.org/wiki/Template:Base_test_matrix#Non-blocking_env...
[6]
https://fedoraproject.org/wiki/QA:Testcase_base_service_manipulation#How_...
11:56 a.m.
On Wed, 2020-04-15 at 10:48 -0600, Geoffrey Marr wrote:
Hi all,
The testcase in question is the base service manipulation test [0]. This
testcase is a Final-milestone test for x86_64, ARM, and cloud in the
validation test matrix [1][2][3]. It is also an optional testcase for
non-release-blocking spins [4][5].
In many of the testing scenarios that this testcase is used, the tester is
logged into and testing the machine remotely via ssh. As the testcase
stands now, the default service that is listed to test with is sshd. Since
this test requires the tester to continually enable/disable/start/stop the
sshd service, doing so on a machine that is remotely logged into will cause
problems with ssh and could leave the tester stuck out of their system. In
many cases where the tester does not have access to the hardware to login
physically, this requires spinning up a new image to test remotely
(thinking particularly of AWS), and can be quite a hassle.
Currently, there is a note listed at the beginning of the testcase that
warns the tester of these adverse effects, should the testcase be followed
explicitly on a system being used remotely [6]. It suggests using a
different, non-critical service to test the functionality, such as chronyd.
I would like to propose that we change the default service that this
testcase lists to use in the examples to something less critical to a
tester who is logged in remotely over ssh. I propose we change the service
to chronyd, but am open to other suggestions. As it stands, I don't see a
reason to use ssh over another service, especially if using ssh can
introduce some problems. The only reason I could possibly see as to why ssh
was used in the first place was that it's enabled on all spins of Fedora,
but I'm not certain of that. If someone wants to inform me as to why ssh
was originally used, please do.
I picked sshd because it's really important, basically.
The reasoning being: it's almost certainly going to be baked into just
about anything we ever build, and it's also very unlikely ever to be
broken *in itself* for very long, because, well, it's sshd. If it
breaks it's gonna get fixed, in a hurry.
This would make it easier to find a service to test with for those
logged
into systems remotely while also keeping the test uniform across all arches
and spins of Fedora, as the same service could be used across all platforms.
It has been suggested to create a separate testcase specifically for
systems that are tested via remote logins, but if there is no reason to
continue using ssh in this testcase, I think it would be a good idea to
change it and keep just one testcase for all in this instance.
I definitely don't support that. I'd prefer to either just leave it as
it is, or find another service we have similar confidence will always
be present in any Fedora edition and will very rarely be broken.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
12:05 p.m.
That makes sense, using something that will almost certainly be in use in
any system we ever launch (for the foreseeable future). I would, however,
counter with chrony being a similar service that will most likely be in use
for a long time in all of our systems and is likely to be fixed very
quickly, should it ever have a problem. At this point, switching to chrony
as the default service here would solve this problem and be ubiquitous
across all our platforms.
What don't you support? Creating a separate test case specific to systems
tested via remote login, or keeping one singular testcase across all
platforms?
Geoff Marr
IRC: coremodule
On Wed, Apr 15, 2020 at 10:58 AM Adam Williamson <adamwill(a)fedoraproject.org>
wrote:
On Wed, 2020-04-15 at 10:48 -0600, Geoffrey Marr wrote:
> Hi all,
>
> The testcase in question is the base service manipulation test [0]. This
> testcase is a Final-milestone test for x86_64, ARM, and cloud in the
> validation test matrix [1][2][3]. It is also an optional testcase for
> non-release-blocking spins [4][5].
>
> In many of the testing scenarios that this testcase is used, the tester
is
> logged into and testing the machine remotely via ssh. As the testcase
> stands now, the default service that is listed to test with is sshd.
Since
> this test requires the tester to continually enable/disable/start/stop
the
> sshd service, doing so on a machine that is remotely logged into will
cause
> problems with ssh and could leave the tester stuck out of their system.
In
> many cases where the tester does not have access to the hardware to login
> physically, this requires spinning up a new image to test remotely
> (thinking particularly of AWS), and can be quite a hassle.
>
> Currently, there is a note listed at the beginning of the testcase that
> warns the tester of these adverse effects, should the testcase be
followed
> explicitly on a system being used remotely [6]. It suggests using a
> different, non-critical service to test the functionality, such as
chronyd.
>
> I would like to propose that we change the default service that this
> testcase lists to use in the examples to something less critical to a
> tester who is logged in remotely over ssh. I propose we change the
service
> to chronyd, but am open to other suggestions. As it stands, I don't see a
> reason to use ssh over another service, especially if using ssh can
> introduce some problems. The only reason I could possibly see as to why
ssh
> was used in the first place was that it's enabled on all spins of Fedora,
> but I'm not certain of that. If someone wants to inform me as to why ssh
> was originally used, please do.
I picked sshd because it's really important, basically.
The reasoning being: it's almost certainly going to be baked into just
about anything we ever build, and it's also very unlikely ever to be
broken *in itself* for very long, because, well, it's sshd. If it
breaks it's gonna get fixed, in a hurry.
> This would make it easier to find a service to test with for those logged
> into systems remotely while also keeping the test uniform across all
arches
> and spins of Fedora, as the same service could be used across all
platforms.
>
> It has been suggested to create a separate testcase specifically for
> systems that are tested via remote logins, but if there is no reason to
> continue using ssh in this testcase, I think it would be a good idea to
> change it and keep just one testcase for all in this instance.
I definitely don't support that. I'd prefer to either just leave it as
it is, or find another service we have similar confidence will always
be present in any Fedora edition and will very rarely be broken.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
test mailing list -- test(a)lists.fedoraproject.org
To unsubscribe send an email to test-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
12:14 p.m.
On Wed, 2020-04-15 at 11:05 -0600, Geoffrey Marr wrote:
That makes sense, using something that will almost certainly be in
use in
any system we ever launch (for the foreseeable future). I would, however,
counter with chrony being a similar service that will most likely be in use
for a long time in all of our systems and is likely to be fixed very
quickly, should it ever have a problem. At this point, switching to chrony
as the default service here would solve this problem and be ubiquitous
across all our platforms.
What don't you support? Creating a separate test case specific to systems
tested via remote login, or keeping one singular testcase across all
platforms?
Creating a separate test case.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
12:23 p.m.
Are you opposed to using chronyd as the service in this testcase? If so, do
you have a suggestion as to what else we could use that wouldn't need to be
changed when the system under test is logged into remotely via ssh?
Geoff Marr
IRC: coremodule
On Wed, Apr 15, 2020 at 11:15 AM Adam Williamson <adamwill(a)fedoraproject.org>
wrote:
On Wed, 2020-04-15 at 11:05 -0600, Geoffrey Marr wrote:
> That makes sense, using something that will almost certainly be in use in
> any system we ever launch (for the foreseeable future). I would, however,
> counter with chrony being a similar service that will most likely be in
use
> for a long time in all of our systems and is likely to be fixed very
> quickly, should it ever have a problem. At this point, switching to
chrony
> as the default service here would solve this problem and be ubiquitous
> across all our platforms.
>
> What don't you support? Creating a separate test case specific to systems
> tested via remote login, or keeping one singular testcase across all
> platforms?
Creating a separate test case.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
test mailing list -- test(a)lists.fedoraproject.org
To unsubscribe send an email to test-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
12:27 p.m.
On Wed, 2020-04-15 at 11:23 -0600, Geoffrey Marr wrote:
Are you opposed to using chronyd as the service in this testcase? If
so, do
you have a suggestion as to what else we could use that wouldn't need to be
changed when the system under test is logged into remotely via ssh?
Not specifically, but I also haven't checked if it's in everything we
run the test on.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
12:40 p.m.
I have tested Fedora IoT, Cloud, workstation on both ARM and x86_64,
everything this testcase blocks on, and they all include chronyd.
Geoff Marr
IRC: coremodule
On Wed, Apr 15, 2020 at 11:28 AM Adam Williamson <adamwill(a)fedoraproject.org>
wrote:
On Wed, 2020-04-15 at 11:23 -0600, Geoffrey Marr wrote:
> Are you opposed to using chronyd as the service in this testcase? If so,
do
> you have a suggestion as to what else we could use that wouldn't need to
be
> changed when the system under test is logged into remotely via ssh?
Not specifically, but I also haven't checked if it's in everything we
run the test on.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
test mailing list -- test(a)lists.fedoraproject.org
To unsubscribe send an email to test-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
6:09 a.m.
On Wed, Apr 15, 2020 at 7:41 PM Geoffrey Marr <gmarr(a)redhat.com> wrote:
I have tested Fedora IoT, Cloud, workstation on both ARM and x86_64,
everything this testcase blocks on, and they all include chronyd.
The testcase doesn't suggest chronyd but crond. So which one are we talking
about here? I tend to consider crond more important, and if we pick an
alternative, I'd pick crond (if it's installed everywhere). I have no
issues with replacing sshd in the testcase.
If you get to rewriting the testcase, can you please restructure it a bit
as well? The Expected Results section is dumb, especially the "The expected
results, in order, are:" part. You can't just follow step by step
instructions, you have to constantly jump between How To Test and Expected
Results and try to figure out what outcome is expected at that moment.
Ideally, each step in How To Test should be clear about the expected
outcome, so you can really go sequentially one by one and immediately know
when something broke. The Expected Results section would only list those
requirements which are not specific to particular steps but are valid
overall for the whole test case, or it doesn't make sense to put them in
How To Test for some other reason. I tried to use this approach in my
latest testcase [1] (there was nothing to put in Expected Results, but the
section mustn't be empty, so I used a somewhat unneeded sentence in there).
Can you try something similar?
Thanks!
[1] https://fedoraproject.org/wiki/QA:Testcase_desktop_app_basic#How_to_test
10:21 a.m.
On Thu, 2020-04-16 at 13:09 +0200, Kamil Paral wrote:
On Wed, Apr 15, 2020 at 7:41 PM Geoffrey Marr
<gmarr(a)redhat.com> wrote:
> I have tested Fedora IoT, Cloud, workstation on both ARM and x86_64,
> everything this testcase blocks on, and they all include chronyd.
>
The testcase doesn't suggest chronyd but crond. So which one are we talking
about here? I tend to consider crond more important, and if we pick an
alternative, I'd pick crond (if it's installed everywhere). I have no
issues with replacing sshd in the testcase.
If you get to rewriting the testcase, can you please restructure it a bit
as well? The Expected Results section is dumb, especially the "The expected
results, in order, are:" part. You can't just follow step by step
instructions, you have to constantly jump between How To Test and Expected
Results and try to figure out what outcome is expected at that moment.
Ideally, each step in How To Test should be clear about the expected
outcome, so you can really go sequentially one by one and immediately know
when something broke. The Expected Results section would only list those
requirements which are not specific to particular steps but are valid
overall for the whole test case, or it doesn't make sense to put them in
How To Test for some other reason. I tried to use this approach in my
latest testcase [1] (there was nothing to put in Expected Results, but the
section mustn't be empty, so I used a somewhat unneeded sentence in there).
Can you try something similar?
Thanks!
[1] https://fedoraproject.org/wiki/QA:Testcase_desktop_app_basic#How_to_test
If we're gonna write test cases like that, we should probably just have
an alternative template, or an alternative "mode" for the template we
have. I don't like using a template which clearly expects the "Here are
the steps, and here are the expected results" format but actually uses
"Step 1, step 1 expected result, step 2, step 2 expected result..."
format. Writing templates isn't that hard, so I feel like that would be
nicer :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
10:40 a.m.
Yes, the testcase suggests crond, but I suggested chronyd. I have had
trouble in the past trying to use crond on some systems (cloud, I think,
although it was a long time ago). However, I have never had an issue using
chronyd, and it has become my go-to service to use when testing this
testcase.
I'm not interested in rewriting this testcase, I feel that the current
format is fine. This mail is simply to suggest changing the default service
that the testcase uses. If we can figure this out, then perhaps we can
discuss reformatting the structure of the testcase, but let's do one thing
at a time.
Geoff Marr
IRC: coremodule
On Thu, Apr 16, 2020 at 9:22 AM Adam Williamson <adamwill(a)fedoraproject.org>
wrote:
On Thu, 2020-04-16 at 13:09 +0200, Kamil Paral wrote:
> On Wed, Apr 15, 2020 at 7:41 PM Geoffrey Marr <gmarr(a)redhat.com> wrote:
>
> > I have tested Fedora IoT, Cloud, workstation on both ARM and x86_64,
> > everything this testcase blocks on, and they all include chronyd.
> >
>
> The testcase doesn't suggest chronyd but crond. So which one are we
talking
> about here? I tend to consider crond more important, and if we pick an
> alternative, I'd pick crond (if it's installed everywhere). I have no
> issues with replacing sshd in the testcase.
>
> If you get to rewriting the testcase, can you please restructure it a bit
> as well? The Expected Results section is dumb, especially the "The
expected
> results, in order, are:" part. You can't just follow step by step
> instructions, you have to constantly jump between How To Test and
Expected
> Results and try to figure out what outcome is expected at that moment.
> Ideally, each step in How To Test should be clear about the expected
> outcome, so you can really go sequentially one by one and immediately
know
> when something broke. The Expected Results section would only list those
> requirements which are not specific to particular steps but are valid
> overall for the whole test case, or it doesn't make sense to put them in
> How To Test for some other reason. I tried to use this approach in my
> latest testcase [1] (there was nothing to put in Expected Results, but
the
> section mustn't be empty, so I used a somewhat unneeded sentence in
there).
> Can you try something similar?
>
> Thanks!
>
> [1]
https://fedoraproject.org/wiki/QA:Testcase_desktop_app_basic#How_to_test
If we're gonna write test cases like that, we should probably just have
an alternative template, or an alternative "mode" for the template we
have. I don't like using a template which clearly expects the "Here are
the steps, and here are the expected results" format but actually uses
"Step 1, step 1 expected result, step 2, step 2 expected result..."
format. Writing templates isn't that hard, so I feel like that would be
nicer :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
test mailing list -- test(a)lists.fedoraproject.org
To unsubscribe send an email to test-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
8:37 a.m.
On Thu, Apr 16, 2020 at 5:42 PM Geoffrey Marr <gmarr(a)redhat.com> wrote:
Yes, the testcase suggests crond, but I suggested chronyd. I have
had
trouble in the past trying to use crond on some systems (cloud, I think,
although it was a long time ago). However, I have never had an issue using
chronyd, and it has become my go-to service to use when testing this
testcase.
If it's preinstalled everywhere, I don't have a problem with that change.
11:24 a.m.
On 4/16/20 11:21, Adam Williamson wrote:
If we're gonna write test cases like that, we should probably
just have
an alternative template, or an alternative "mode" for the template we
have. I don't like using a template which clearly expects the "Here are
the steps, and here are the expected results" format but actually uses
"Step 1, step 1 expected result, step 2, step 2 expected result..."
format. Writing templates isn't that hard, so I feel like that would be
nicer :)
We certainly have test cases where the results are open to
interprettation and so the test case results could be centralized and
allow for that interpretation.
We also have test cases where there are specific steps with specific
actions that are required to produce specific results. An example is the
Services Manipulation test case. In a tests like this, it has always
served me well, to have the Expected Results for each step of the test
case at the end of each test case step. This eliminates confusion over
what the results for a step must be and so increases the accuracy of the
test case results. In a test case like this, I don't think we want
people interpreting the results.
Two templates might be the right thing to do. One for exact tests and
one for tests where interpretation is or is likely to be involved.
Stay Well Stay Safe
Pat (tablepc)
11:44 a.m.
On Thu, 2020-04-16 at 12:24 -0400, pmkellly(a)frontier.com wrote:
On 4/16/20 11:21, Adam Williamson wrote:
> If we're gonna write test cases like that, we should probably just have
> an alternative template, or an alternative "mode" for the template we
> have. I don't like using a template which clearly expects the "Here are
> the steps, and here are the expected results" format but actually uses
> "Step 1, step 1 expected result, step 2, step 2 expected result..."
> format. Writing templates isn't that hard, so I feel like that would be
> nicer :)
>
We certainly have test cases where the results are open to
interprettation and so the test case results could be centralized and
allow for that interpretation.
We also have test cases where there are specific steps with specific
actions that are required to produce specific results. An example is the
Services Manipulation test case. In a tests like this, it has always
served me well, to have the Expected Results for each step of the test
case at the end of each test case step. This eliminates confusion over
what the results for a step must be and so increases the accuracy of the
test case results. In a test case like this, I don't think we want
people interpreting the results.
Two templates might be the right thing to do. One for exact tests and
one for tests where interpretation is or is likely to be involved.
It's not about interpretation or not, it's just about a preference for
this:
Test Steps
----------
1. Step 1
2. Step 2
3. Step 3
Expected Results
----------------
1. Expected result 1
2. Expected result 2
3. Expected result 3
versus this:
Test Steps and Expected Results
-------------------------------
1. Step 1
2. Expected result 1
3. Step 2
4. Expected result 2
5. Step 3
6. Expected result 3
Our current template really only handles the first style, if you want
to do the second style you have to do some kind of 'hack' like kparal
did. I'm just saying if the second style is clearly better for some
test, we should probably add an alternative template or tweak the
existing template to have a 'mode' which works better for that style.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
12:57 p.m.
It's not about interpretation or not, it's just about a preference for
this:
Test Steps
----------
1. Step 1
2. Step 2
3. Step 3
Expected Results
----------------
1. Expected result 1
2. Expected result 2
3. Expected result 3
versus this:
Test Steps and Expected Results
-------------------------------
1. Step 1
2. Expected result 1
3. Step 2
4. Expected result 2
5. Step 3
6. Expected result 3
Our current template really only handles the first style, if you want
to do the second style you have to do some kind of 'hack' like kparal
did. I'm just saying if the second style is clearly better for some
test, we should probably add an alternative template or tweak the
existing template to have a 'mode' which works better for that style.
Sorry for the misunderstanding. I think the second format would serve us
best.
1. Step 1
2. Expected result 1
3. Step 2
4. Expected result 2
This makes the test case easier to read with lower chance of confusion.
Be Well Be Safe
Pat (tablepc)
3:48 p.m.
On Thu, 2020-04-16 at 13:57 -0400, pmkellly(a)frontier.com wrote:
> It's not about interpretation or not, it's just about a
preference for
> this:
>
> Test Steps
> ----------
>
> 1. Step 1
> 2. Step 2
> 3. Step 3
>
> Expected Results
> ----------------
>
> 1. Expected result 1
> 2. Expected result 2
> 3. Expected result 3
>
> versus this:
>
> Test Steps and Expected Results
> -------------------------------
>
> 1. Step 1
> 2. Expected result 1
> 3. Step 2
> 4. Expected result 2
> 5. Step 3
> 6. Expected result 3
>
> Our current template really only handles the first style, if you want
> to do the second style you have to do some kind of 'hack' like kparal
> did. I'm just saying if the second style is clearly better for some
> test, we should probably add an alternative template or tweak the
> existing template to have a 'mode' which works better for that style.
>
Sorry for the misunderstanding. I think the second format would serve us
best.
1. Step 1
2. Expected result 1
3. Step 2
4. Expected result 2
This makes the test case easier to read with lower chance of confusion.
I think there are cases where each works better, there's no harm in
supporting both.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4:38 p.m.
On 4/16/20 16:48, Adam Williamson wrote:
On Thu, 2020-04-16 at 13:57 -0400, pmkellly(a)frontier.com wrote:
>> It's not about interpretation or not, it's just about a preference for
>> this:
>>
>> Test Steps
>> ----------
>>
>> 1. Step 1
>> 2. Step 2
>> 3. Step 3
>>
>> Expected Results
>> ----------------
>>
>> 1. Expected result 1
>> 2. Expected result 2
>> 3. Expected result 3
>>
>> versus this:
>>
>> Test Steps and Expected Results
>> -------------------------------
>>
>> 1. Step 1
>> 2. Expected result 1
>> 3. Step 2
>> 4. Expected result 2
>> 5. Step 3
>> 6. Expected result 3
>>
>> Our current template really only handles the first style, if you want
>> to do the second style you have to do some kind of 'hack' like kparal
>> did. I'm just saying if the second style is clearly better for some
>> test, we should probably add an alternative template or tweak the
>> existing template to have a 'mode' which works better for that style.
>>
>
> Sorry for the misunderstanding. I think the second format would serve us
> best.
>
> 1. Step 1
> 2. Expected result 1
> 3. Step 2
> 4. Expected result 2
>
> This makes the test case easier to read with lower chance of confusion.
I think there are cases where each works better, there's no harm in
supporting both.
That's true
Be Well and Safe
Pat (tablepc)
1491
days inactive
1493
days old
15 comments
4 participants
participants (4)
-
Adam Williamson -
Geoffrey Marr -
Kamil Paral -
pmkellly＠frontier.com