Seems like once you set the Testers field on a Test Case in MTM, it will not allow you to clear it. You are only allowed to change it to a different value. Has anyone found a way to clear this field?
It is important to not get the "Assigned" Tester field confused with the Assigned To field. They are distinct fields on a Test Case work item. One reason why someone might want the Tester field to be blank is if a team all pitches in to help with testing during an iteration and leaving the assigned tester blank allows the team to know that no one has "picked up" this test to execute. The team member could then assign the test to his or herself and execute it.
The template pulls the Assigned Tester Values from a list using the 'AllowedValues' tag. Instead, simply change this to 'SuggestedValues'. That will allow for empty values - easy as that.
If you'd rather not allow free entry, you can also add a default value such as 'None' and use that rather than blank.
Unless you've customized your work item type, this field should never be blank after being saved. It defaults to the person who created the bug in all Microsoft supported process templates, and a value is required by default.
That being said, why would you want to change it to blank?
If you really, really want to be able to blank it out (which I don't think is a good idea at all), you'll need to customize your template. See the below guidance:
http://msdn.microsoft.com/en-us/library/ms243849(v=vs.110).aspx
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 have the first parameter (client drop down) that passes an ID to the second parameter to be used in the 3rd and 4th parameter. During testing all the parameters are set to visible to verify what's being passed. As soon as I hide that second parameter the rest don't refresh. Again, visible, correct info flowing through, hidden, DOA. I have this set up exactly like this on at least a dozen other reports with no issue. I'm not real sure where this going wrong since I can see the correct value being passed while visible?
I was able to duplicate your issue. While I can't find a reference to support my supposition, I believe that hidden parameters (even those with a default value) are not evaluated until rendering, which would explain this behavior. Data sets that drive parameter values are run prior to the report being rendered.
As you're talking about having trouble with dependencies between the parameter values, I assume you're using queries to drive your available values for parameters three and four. If this is the case, then simply embed the logic that relates the value(s) of parameter 1 to the value(s) of parameter 3 into the query that drives parameter 3's available values. By cutting out Parameter 2 and incorporating it into the query logic for parameter 3, you will work around this issue.
If you're having trouble accomplishing this, reply in a comment and I'll see if I can help. As it stands, I don't know enough about what you're trying to do to help any more.
I wrote a feature to test the default configuration of my web app using Cucumber and Capybara. Part of the feature looked like this:
And the page has a photo labeled "Device"
And the page has a checkbox labeled "Device"
And I check "Device"
And I submit the form
Then the resulting page has no photo labeled "Device"
It worked great. I want users who have installed and configured the web app on their own servers to be able to run the test to help confirm that their configuration is correct. And "Device" is a string in the default config file that the user can change. It's an element in an array and they can add to or remove from the array when configuring their instance of the app.
Is this a sensible use of the tools or am I abusing Cucumber and/or Capybara? If it's sensible, how would I do it? If it's a bad idea, what tools might I use for this instead, if anything?
Here's how I got it to work. I'm just not sure this is the best way to do it.
For this to work, the feature would have to look more like this:
And the page has at least 3 photos, let us call the last one "third_photo"
In the corresponding step definition, I use an XPath to pull out the corresponding label string for the first photo and assign it to a Hash object stored in a class variable.
And /^I the page has at least (\d*) photos, let us call the last one "([^\"]*)"$/ do |n, name|
if ! defined?(#note)
#note = Hash.new;
end
#note[name] = find(:xpath, '//ol[#id="menu"]/li[' +n+ ']/a').text;
end
Subsequent step definitions can now access the value, whatever it was.
So, another feature might be:
Then I uncheck "third_item"
And the corresponding step definition might be:
Then /I uncheck "([^\"]*)"/ do |item|
uncheck(#note[item])
end
But I don't feel good about it. If nothing else, I imagine there might be a name collision with another instance variable defined outside the step definitions.
It feels like I'm either Doing It Wrong or else I'm Using The Wrong Tool. What is the right way to do this?
Don't know what you are fishing after, but it feels like your tests and implementation are quite tightly coupled. Maybe that's the feeling you are having, that it seems like you are describing your app in tests.
I don't have a good answer to your questions, merely because I don't "understand" it. I would however urge you to try to decouple your tests from your implementation and see if there's any abstraction there waiting to be found.
There's a blog post about using instance variables in step definitions at http://www.cloudspace.com/blog/2010/06/23/using-instance-variables-with-cucumber-steps/.
Commenters talk about the coupling this entails and at least one possible way around it.
In particular, davetron5000 says:
What we do is to not use instance variables at all, but instead
provide a has that shared state can go in. This hash is cleared after
each test run. Not ideal, but it's a bit cleaner than random instance
variables all over the place (and also ensures a reasonably clean
state before each test)
I made a report with about 30 different rectangles and textboxes that have different visibility expressions depending on the parameters. (It's a student invoice and many different messages have to appear depending on the semester) When I made all the expressions I coded in the parameters in all upper case. Now I have a problem when users enter lowercase letters, the SQL all works fine since it is not case sensitive, but the different rectangles and textboxes don't show. Is there a way in the report code to first capitalize all the parameters before running the SQL? Or do I actually have to go back to every visibility expression and add separate iif's for upper and lower case? (That seems incredibly silly to have to do). I can't change my parameters to numbers because I have been given strict requirements for input. Thanks.
I do not know if this is the most elegant solution, but you could accomplish this by following this procedure for every parameter on the Report Parameters page:
1)Re-name the parameter, leaving its prompt as that of the old parameter.
2)Add a new parameter with the same name as the old parameter.
3)Mark this new parameter as Hidden.
4)Make sure that the new parameter's available values are marked as non-queried(available values will never be actually used.)
5)Mark the Default Values as Non-queried, using the following syntax:
=ucase(Parameters!OldParameterName.Value)
Can't you just UCASE the params (do it in the xml view, it will be quicker and you might even be able to do a regex find/replace)
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.