UAT, ime, should include the complete steps that the actual end user of the app would perform according to your scenarios, from start to finish, and also including expected and actual results in the tcs, e.g.

step 1. open browser/browser is launched, step 2. go to www.blah.com/blah.com is loaded, step 3. click on login field (if you need to get specific) and enter username/field is selected and username is entered.....all the way to the end path you need to test.

You should have performed your functional tests before running UAT cases so you don't necessarily have to validate each field in UAT tcs but make sure you or your team is smoke/functional testing before UAT.

I also agree with the previous poster regarding splitting up your test cases into specific parts which of course depends on what you're doing exactly. TC1_Navigate to Page TC2_Login TC3 Fill PersonalInfo(Or by form section) TC4_Fill IncomeInfo...blahblah.

For each tc after the first one, you can continue from the last tc's step, you don't have to start each test case after #1 from "open browser", and include all the tests together as one test set which will be comprised of the multiple testcases.

Since you are using an element with type 'date', it is up to the browser to render the calendar, or anything else to allow users to select the date. The date picker is not part of your web page and so you would not be able to find its locators in the conventional ways.

I believe your testing requirement is to be able to check how your application behaves when different dates are selected, rather than to see if the date picker works (which the browser would take care for you).

In order to select dates, you should be able to use send keys if you gave the value in the right format (yyyy-MM-dd). I tested with the given website using Selenium IDE and things seem to work.

WebElement selectCustomerDOB = driver.findElementById("dob"); // While xPath is great and your xPath is valid - I feel ID is much faster.
selectCustomerDob.sendKeys("2011-12-21");

I'm actually on a testing team, and a lot of what we do is verification and software breaking, but that's only part. We also maintain automated tests of the products so that bugs are caught earlier in the development cycle and run large scalability tests in cooperation with development in order to push the limits of our product and find the areas that can be updated to allow for further scalability in the future.

I think we're being pretty effective in our goals of getting the best product possible into the hand of our users, and simple verification is an important part of that process.

Also... I think that in a lot of ways QA is limited by the resources they are given, and we're lucky enough to have a lot of access to development tools, large scale virtual environments (as well as decent hardware based machines), and we're given enough freedom to actually experiment with the product.

Some of the testing is by necessity "run these test cases" types of deals, but that's only one portion.

Free cross-browser tools:

• http://browsershots.org/
• https://www.browserling.com/
• http://netrenderer.com/

Paid cross-browser tools:

• https://www.browserstack.com/
• https://crossbrowsertesting.com/
• http://www.browseemall.com/

If I think that some functionality is not working correctly, regardless of the developer's opinion, I write out a bug and ask the project manager to clarify this functionality. Further, the developer write a comment that this is not a bug, but a feature. And if later it turned out that this is a bug, and this bug went to the customer, then I just show the bug to developer and so that was not my fault. I advise you to do the same.

How would you describe different testing levels?