I have an activity with spinners (3), an EditText (1), buttons (2). I would like to test whether the order of user interactions with these elements does not matter for the outcome (=display of some string in a TextView). For example it should not matter whether I first type something in the EditText and then select a spinner or whether I first do the spinner selection and then type something in the EditText, etc.
Due to the number of elements, there are many variations of how user interactions could happen. Is there a way to either:
generate automatically all possible combinations of user interactions/testing code
or
Test a single, but random user interaction
?
I am aware of The Monkey, but that seems to be for stress testing only!?
According to this:
generate automatically all possible combinations of user interactions/testing code
Sorry, but I don't see any rational way to test it in the other way than in monkey.
Please read more about this tool here: http://developer.android.com/tools/help/monkey.html
and Trust me, there's no reason to be afraid of this great tool.
Finally, monkey also gives you well-detiled logs, as you can see on this video: https://www.youtube.com/watch?v=wdDVHXo4obY
Related
I'm trying to get a text from a textfield with Get Text, but in some cases this field is optional and the robot crashes because it doesn't have anything in the field.
You have multiple options. It's hard to say which one fits best you so here is a pool of possible solutions:
when NOT using the Modern Design, you can easily use the Element exists activity, self explaining
if you use the Modern Design and miss old activities like Element exists, go to the filter dropdown and select Show Classic, this way you are now also able to choose Element exists
you could also wrap such failing activities into a Try Catch, then your process wont fail, but a Try Catch should always be the last way out
when using the Modern Design, you can try Find Element, if the returned object is empty you know that it was not found, make sure to set a proper Timeout here, otherwise you wait for 30 seconds
but on your case it could be better to use an Image exists or Find Image Matches as you said you are looking for text in a textfield, just inverse it and look for an empty textfield, and if you have no matches all is fine
But to be honest, I would go for the Element exists. Give this a try, but be aware that in the future this activity might be replaced by something else and your process will need a little bit of rework.
I am looking for a low code solution for a Wix website I am creating. I have the website done except for the gamified task. I am looking to present the user with 3 or 4 pictures on the page, and they must make a selection of the available pictures. The selection is either correct or incorrect based on a pre-determined decision, and the click and selection need to be stored and saved in a database. Following correctly choosing the correct or incorrect answer, the user is presented with the next question. I was wondering if anyone had any key terms to look up that are no code/low code solutions to a task like this, or examples that anyone has seen of tasks that have been made in wix/corvid like this. Any help is greatly appreciated.
You will need some code to do this. It shouldn't be too difficult to do, but there's some work involved.
Some of the APIs you'll need to use are
$w.Image.onClick()
wix-data.insert() (or wix-dataset.save())
In general how does one test a various parts of a GUI? What are good practices? (Yes I am being overly general here).
Let take for Notepad's Find dialog box:
Notepad's Find dialog box http://img697.imageshack.us/img697/5483/imgp.png
What are some things that can be tested? How does one know its working correctly? What are edge cases to look out for? Stress tests?
Here.
I doubt any good generalization can be made about this - it always depends on the situation.
When someone asks for tests for GUI I always assume that that mean 'this part of application that is accessible via this GUI'. Otherwise it would mean testing the only the GUI without any logic hooked. Dunno why no one never actually asked for testing if the events are fired when button is pressed or is displayed window acquiring focus.
Anyway back to the question. First of all find out about equivalence classes, boundary conditions other testing techniques. Than try to apply it for given problem. Than try to be creative.
All those should be applied when creating following tests:
1) happy path tests - application acts right when given input is good
2) negative tests - application acts right when given input is bad
3) psychotic user behavior (I saw someone use this term, and I find it to be great) - that one user that has nothing better to do than break your application or is to stupid to actually know how bad and horrible things he is doing with your app.
After all this if all tests are passing and you can't figure out other, than you don't know is it working properly, but you can say that it passed all tests and it seems to be working correctly.
As for given GUI example.
1)
Is the application finding string that is in opened file?
Is the application finding character that is in opened file?
How is it reacting to reaching end of file during search?
Is it finding other appearances of given string/character or just one, when there are many of those appearances ?
Is it handling special search characters like * or ? correctly?
Is it searching in desired direction?
Is it 'Mach case ' option working properly?
When opening find setting some criteria, canceling search and launching it again - are search criteria back to default values? Or are they set as you left them when clicking Cancel?
2)
Is it informing user that no mach was found when trying to search for data that is not in opened file?
Is it reacting properly when trying to search down form end of file?
Is it reacting properly when trying to search up form beginning of file?
How search feature is reacting when no file is loaded? (in MS notepad it can be done, but in other editors you can launch editor without opening a file hence this test)
Can I mark both Up and Downs search direction?
3)
Is it working properly on 4GB file?
Can I load 4 GB string in 'Find What:' field and search for it?
Can I provide as input special characters by providing ASCII codes? (it was done like pressing Alt and number of character... or something like that)
Can I search for empty character (there was something like that in character table).
Can I search for characters like end of line or CarretReturn?
Will it search for characters form different languages? (Chinese, or other non-english alphabet characters)
Can I inject something like ') DROP ALL TABLES; (if that would be web based search).
Will I be able to launch proper event twice by really fast double click on search button? (easier on web apps)
With reasonable test suite you know it seems to work correctly.
I think it is better to separate out functional aspects and the usability aspects for the GUI testing.
Let us say in the above example take the use case of user entering some text and hitting the Find button. From the functional aspect I would say your tests should check whether this user action (event) calls the appropriate event handler methods. These can be automated if your code has good separation between the GUI display code and the
functional part.
Testing of usability aspect would involve checking things like whether the display occurs correctly in multiple platforms. I think this needs to be verified manually. But I think there are some tools that automate this kind of GUI testing as well but I've no experience with them.
It's difficult and error-prone to test finished UIs.
But if you are more interested form the programmer's perspective, please have a read of the paper The Humble Dialog. It presents an architecture for creating UIs whose functionality can be tested in code using standard testing frameworks.
Very simple question: should a dropdown list be used to populate state abbreviations? From my experience, I think most e-commerce sites do this so I would expect that it's acceptable. However, Jakob Nielsen has something to say about this.
I think I disagree; I use the tab key then type the first letter of my state. Heck, even if it wasn't the first entry, I've done this enough times, I would hit the letter repeatedly and get to what I need. I never need the scroll wheel or mouse.
Is there any additional concrete guidance out there on this particular question?
I think this will become less of an issue now that most modern browsers scroll the drop down lists based on each consecutive letter you type, not just reading the first letter as they once did. So, If you type N-Y, the drop down list will scroll directly to NY and you do not have to hit N a bunch of times.
Since a state is a two letter abbreviation, I wouldn't put a drop downlist, I would put a textbox, but I would validate it using AJAX or Javascript to warn the user about an error, right after he entered something wrong.
DropDown / Auto-completion (in my opinion) is useful when the data to enter is longer / more error-prone.
If you insist on using auto-completion or dropdown, you should put long state names, not just the abbrev.
I don't know about concrete guidance, but one alternative I would consider is using an autocomplete text box that forces you to choose from one of the available choices. I agree that a 50-item drop down list is too long and using autocomplete with enforced choice accomplishes the same purpose -- consistent data -- and has the advantage that it is much easier for the user to navigate. If you don't want to limit the choices to just US states you could drop the enforced choice and just let the autocomplete work as a suggestion with the user being able to enter free-form input.
EDIT: As #Martin suggests, I would probably have the autocomplete show the full state name, even if it only entered the abbreviation. This would solve issues of people getting the abbreviation wrong as well, though you could do the same thing in a drop down -- display the name with the abbreviation as the value.
I was going to post NYSystemsAnalyst's answer, but he beat me. I will instead add a caveat... If you use a dropdown list, it must be complete. Do not forget the obvious DC, or the less common but plausible PR or AE/AA/AP, or the rather improbable but still valid AS, FM, MH, MP, PW, and VI.
The official list
I think it depends on if you are asking a user to enter their own address or someone else's address (ship to address). Everyone knows their own state abbreviation, but may know all the state abbreviations.
So for entering your own address a textbox is the quickest and easiest way, but if you are asking the user to potentially enter someone else's address a drop down is probably best.
Of course, if you site has a combination of both types of address, you want your UI to be consistent and use the drop down for both. Also, if you are using a drop down, I would suggest using the state abbreviation and name (AZ - Arizona) when the drop down is expanded (but just show the abbreviation when it is collapsed).
I'm willing to bet that half the users of online e-commerce sites don't know the abbreviations for the states. Think if you're shipping a gift to someone and you can't remember whether its MS, MO or MI. Dropdowns are fine.
I've never had an issue with state drop down boxes (and this is from someone routinely at the bottom in West Virginia). I've gotten into the habit of just tabbing and pressing W and then it will either recognize the "E" and give me the correct state, or it will not recognize the "E" and then I have to hit the down key once or twice (depending on sort order) to get the proper state.
So all in all I am looking at 5 key presses max to get to my state. I don't think it's that bad.
How about a textbox with validation, and a drop-down list if the state abbreviation is invalid?
I've long thought (but never practiced for some reason) that a dropdown menu that is dynamically generated and only contains one item, should automatically select that item. This would opposed to the typical approach that I've observed where a blank entry is made at the top and you still have to interact with the menu to make the single available selection.
An example is when I login to my online banking and select "View Paper Statements". I've only got one account so the next step in the process is to present me with a dropdown where I have to select that single account to proceed. In this case, by implementing the solution above, it would take one less click to select the account and proceed to viewing it. Even better in this case would be to eliminate the dropdown menu step altogether and go right to the statement.
Can you think of a case where auto-select of a single item would produce undesirable results?
Can you think of a case where auto-select of a single item would produce undesirable results?
Yes - any case where the user has the option not to select any option.
In your bank account example, pre-selecting the only value makes sense. But if you have e.g. some kind of form where users can provide voluntary information, they will need the possiblity to leave that field blank or otherwise give a possible incorrect answer.
So it really should depend on the nature of the data in that dropdown whether pre-selection is a good idea or not.
I completely agree, in the case you describe. But there are times where you want to force the user to make a selection actively -- e.g., when the value of the field is somehow optional or additive.
In your case, without selecting an account, there's probably no useful way to proceed, so automatic selection does make sense. But for example, an application I'm working on allows the user to specify a number of descriptive fields (movie metadata, basically -- title, release year, genre, etc.), many of which are optional, and some of them are represented by drop-down menus. Allowing the user to leave the default selection blank lets him tell us, effectively, "I don't want to use this field," so we leave it blank, and the data remains clean.
Just one example, although you're right -- in your case, I can see how that'd be annoying. :)
If there is truly only one possibility you shouldn't ask a user to decide between Option A. (Bad grammar to illustrate the point)
If the field can be left blank, it's not an option with a single answer. Instead you have a choice between Option A "meaningful data" and Option B "".
Iif list has blank option but the form does not allow that to be blank, it's a choice between Option A. (Bad grammar to illustrate the point)
Sometimes you want the user to explicitly select an option, even when it's the only option. If the option is selected automatically, the user may never even realise it, even though they may not be happy with the result.
For example, I'm reviewing my savings account on my internet bank site. Then I go to set up a payment. As it happens, I'm not allowed to make payments from my savings account, so the payment form automatically selects my only other account. If I don't notice this then I will end up making the payment from my other account when I was expecting to use my savings account. If I had known, I wouldn't have made the payment at all.
Perhaps this is slightly contrived. But unless you can be certain that the user will be happy with the (only) choice, you should ensure that they choose it explicitly.
I agree. If there's only one item in the dropdown and it's required that the user select something, then just default to the single item. I can't think of any negative effects of this (but I'm certainly not a UI expert)
What I like to do in this instance depends on a few factors.
If the dropdown is a required field and ends up with only one item due to dynamic generation, I try to avoid displaying it as a dropdown entirely. I end up showing it as an uneditable text field instead (or not displaying it at all if it isn't necessary). Why make it even look like it's a choice when it isn't?
If the dropdown is not required, then it makes total sense to display a blank choice in addition to the single value.
If it's REQ and there's a single record/value .. I'd try and change the control to a Display field rather than the Drop Down.