| How to control test steps? [message #1639674] |
Fri, 27 February 2015 19:18  |
 Chynte Levkudus
Messages: 2
Registered: February 2015 |
Junior Member |
|
|
Hi list,
I'm not sure, I mark me as an idiot with my question. But after searching and trying for more than 2 weeks, it's time to ask for help.
I want to test a widget which asks for a path (text string) and a name for the project (also a text string).
If the path is invalid or there exists already a project with the same name and path, the OK button is greyed out.
So I have lot of different valid and invalid pairs of strings (path & project name) and for each a boolean parameter, with which I mark this pair as "expect OK button greyed out".
WIth this I have three different "end situations":
1. OK Button is active and the boolean parameter expected that. Then I will press the OK-Button. Test is passed.
2. OK Button is active and the boolean parameter expected, it is inactive. Then the test should fail and I need to press the Cancel-Button
3. OK Button is greyed out and boolean parameter expected that. Then I will press the Cancel-Button and the Test is passed.
4. OK Button is greyed out and boolean parameter expected, it is active. Then I need to press the Cancel button and the test should fail.
I'm not able implement a test case with the above described behaviour. I fear, I do not understand the Events correctly or I miss an important point. But all the forums, manuals and my friend Google could not help.
Is my concept for this test wrong?
I could imagine to divide it into two tests (one test where normally the OK Button is active and another testm where normally the OK button is greyed out).
But in my mind, it makes managing allowed and not allowed combination to complicate.
Thanks for any comment
|
|
|
| Re: How to control test steps? [message #1645610 is a reply to message #1639674] |
Mon, 02 March 2015 15:54  |
Alexandra Schladebeck
Messages: 1613
Registered: July 2009 |
Senior Member |
|
|
Hi there,
Thanks for your description.
As with so many aspects of test design, you can make a choice here:
1. You could write a module that enters the path and checks the button. This module can be parametrised (which path to enter, the expected state of the button) and therefore reused. Then, depending on the case, you reuse this module in separate test cases that will press OK or press cancel, e.g:
- Enter path and check button state [PATH; ENABLED] (expected = enabled)
- Click OK
- Enter path and check button state [PATH; ENABLED] (expected = disabled)
- Click Cancel
This works for your positive tests. If the test fails, you can react with an Event Handler to press either cancel or escape, or to abandon this entire use case and continue with the next one (check out the articles on event handlers on the portal:
http://testing.bredex.de/test-cases-for-continuous-integration.html
http://testing.bredex.de/test-design.html?file=files/content_closed/documents/publications/testingexperience01_10_Imrie_Tiede.pdf
2. The other option is to write specific modules for the context and structure your test like this:
- Enter path into field [PATH]
- Check enablement of button [ENABLEMENT]
- Click OK
- Enter path into field [PATH]
- Check enablement of button [ENABLEMENT]
- Click cancel
In this case, the only difference is in the path entering and checking the button. Here, you use two well-named modules so that you know what the test does more easily.
Regardless of the way you choose, you should think about event handling - this topic will come up in multiple other tests too. There are ways (using "retry" event handlers) that let you respond to expected deviations and continue the test, but in the case you've described, the errors are actually errors. So I'd recommend having a general event handler concept that e.g. restarts the AUT and brings it into the correct state for the next test.
Hope that helps!
Alex
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02601 seconds
] 
Search
Help
Register
Login
Home
