Tuesday, July 14, 2009

[bug] Shopping Cart page re-directs when non-number QTY entered -- on the new Hautelook.com

Web site under test: hautelook.com

Designer and maintainer of Website: hautelook.com

Business background: "HauteLook Launches Redesigned Website on July 11, 2009"

Date discovered: 7/12/09, 17:00hrs NYC Time -- consistent fail.

Date retested: 7/15/09, 10:10hrs NYC Time -- consistent fail. But did seem to see one intermittent 'pass' though -- which is strange.

Severity: Normal.

Priority: Normal.

Tested against the following clients:

- Mac 10.5.6 / FF 3.0.11 -- fail. (I suspect that this issue would be browser agnostic -- so, I have decided to not run the test against other OS/browser combinations).

TITLE: During the first step of the check-out process, while at the Shopping cart page, if the user changes the quantity of one of the items in the cart from a valid whole number (say, "2" to a non-number (say "aaa"), then, upon clicking on the "checkout (step-2)" button, then, even though a pop-up error message is then properly presented to the user ('invalid quantity'), the site still redirects the user to the "checkout step-2" page (*) (fail).

The "pass" criteria is that NO page re-direction shall occur.

(*) MORE DETAILS:

(A) If there is a valid credit card already in the system, then, upon clicking on the "checkout (step-2)" button (in order to save the change in quantity (that is currently the only update mechanism for the user to commit the QTY change)), then, the user will then be redirected from the /billing page to the /confirm page (fail) -- (provided that the user enters the "CC security code" before clicking said button.

(A1) If there is a valid credit card already in the system, then, upon clicking on the "checkout step-2" button, then, the user will NOT be redirected from the /billing page to the /confirm page (quasi-pass) -- provided that the use forgets to enter the "CC security code" before clicking said button.

(Note: In this scenario, (A1), two error messages are presented to the user: (i) the "invalid qty" error (as described above), and (ii), the "wrong CC security code" error. (Side issue (a): For (ii) it should say something like "You forgot to enter your 'CC security Code.' Entering your 'CC Security Code' is required everytime you make a purchase. Please enter your 'CC security Code.' -- if the user has left this field as null. Side issue (b): Their seems to be a usability issue here: First time users to the new site (like me) did not know to know to 're-enter the CC security code' for each purchase/transaction)).

(B) If there is NO (valid) credit card already in the system (i.e. the CC fields in the dbase are null), then, upon clicking on the "checkout step-2" button, then, the user will redirected from the /billing page to the /billing-new page (fail).

WORKAROUND: None.

DISCUSSION: The issue highlights a "corner case" usability issue for the user, who, while in the shopping cart (at /billing), when editing the quantity of an item, ends-up accidentally entering a non-positive integer. He did not mean to enter an non-positive integer but accidentally did -- and, then, he then sees the application redirect him.

PROPOSED SOLUTION: For editing (and removing) the quantity of an item (while in a shopping cart), take a look at how Gilt Groupe provides this functionality to the user -- it seems to me to work really well.

~~~

Preconditions for the Test Case:

0.1 Run the following test with the follow precondition: Precondition-1: The user account has no CC in the system.

0.2 Run the following test with the follow precondition: Precondition-2: The user account has a CC in the system and the user, at check-out, properly re-enters the 'CC Security Code'.

0.2 Run the following test with the follow precondition: Precondition-3: The user account has a CC in the system and the user, at check-out, forgets to enter the 'CC Security Code'.

Testing steps / how to reproduce:

1. Ensure that the Shopping Cart has no items in it.

2. Place item-1 -- with qty-1, into the Shopping Cart.

3. Place item-2 -- with qty-1, into the Shopping Cart.

4. Repeat step-3 to the bring the qty of item-2 from 1 to 2.

5. Enter the Shopping Cart.

6. Change the quantity of item-2 from "2" to "aaa" (or from "2" to "-1").

6.1 Click on the "Checkout" button -- in order to commit the quantity change -- (Note: As currently implemented, there is no explicit "update quantity" function made available to the user. An explicit "update quantity" function may need to introduced. Currently, one needs to the click on the "Checkout" button -- in order to commit the quantity change).

6.1.1 Expected result: (1) An error message shall be displayed to the user and the previous quantity shall be restored (and the state of the quantity shall remain in the "editable" state). (2) The application shall NOT redirect to another page.

6.1.2 Actual result: (1) The error message(s) display(s) properly to the user -- (pass). (2) The application re-directs -- (fail).

6.1.2.1 If using precondition-2, then, upon clicking on "checkout (step-2)", then the original quantities for each item remain (correct) and the system redirects from /billing to /confirm (fail). While in /confirm, by design, the quantity of the items in the cart transition to the "non-editable" state (correct). While in /confirm, if the user wishes to go back to the /billing page -- so that he can reedit the quantities, then he needs to click on the "small checkout button located in the upper right hand corner of the page" -- to be taken back to /billing.

6.1.2.2 If using precondition-1, then, upon clicking on "checkout (step-2)", then the original quantities for each item remain (correct) and the system redirects from /billing to /billing-new (fail). While in /billing-new, by design, the quantity of the items in the cart transition to the "non-editable" state and are not viewable to the user (correct). While in /billing-new, if the user wishes to go back to the /billing page -- so that he can reedit the quantities, then he needs to click on the "small checkout button located in the upper right hand corner of the page" -- to be taken back to /billing -- but this action FAILS and keeps the user at /billing-now (This is a side-issue is a bug. (The workaround for this side issue to click on any other link to get out of /billing-new, THEN click on the "small checkout button located in the upper right hand corner of the page" -- to be taken back to /billing)).


The following are the screen captures for this test case -- when using pre-condition-2:

1 of x

2 of 5

3 of 5


4 of 5

5 of 5

Monday, July 6, 2009

[bug] Unable to switch to International -- on drugstore.com

Web site under test: drugstore.com

Designer and maintainer of Website: drugstore.com

"International" plug-in provided by third party: The third party company is E4X under the brand name "FiftyOne."

Title: Unable to switch from US http://www.drugstore.com/ (or http://www.drugstore.com/default.asp) to International http://international.drugstore.com/default.asp -- under certain conditions.

Further description: If the user is on the "https-based" "welcome | sign in" page, then, upon switching to International (choosing any country), then the http://international.drugstore.com/default.asp page does not appear for said country selected.

WORKAROUND: When switching to International, do so from an "http-based" page instead of from an "https-based" page.

Date discovered: 7/6/09, 14:46hrs NYC Time.

Severity: Minor.

Priority: Minor.

Tested against the following clients:

- Mac 10.5.6 / FF 3.0.11 -- fail.

- Mac 10.5.6 / Safari 3.2.1 -- fail.

- Win XP SP2 / IE 7.0 -- fail.

- Win XP SP2 / FF 3.0.11 -- fail.

Testing steps / how to reproduce:

1. Navigate to http://www.drugstore.com/

2. Click on "welcome (sign in)" located in the upper-right-hand corner of the page.

Note: An https page is presented to the user.

3. Click on "international" located in the upper-right-hand corner of the page.

3.1 Select country (say CANADA).

3.2 The "Select Currency field should auto-populate. If not, then select CAD.

IE7.0


FF 3.0.11

3.3 Click on the "Update country $ currency" button.

3.3.1 Expected result: The site shall transition to http://international.drugstore.com/default.asp (and the Canadian flag shall be presented to the user).

3.3.2 Actual result: The site does NOT transition to http://international.drugstore.com/default.asp and presents either a non-drugstore.com error page or an entirely blank page to the user.

IE7.0


FF 3.0.11

[bug] If Search field is null, then error message is returned twice -- on everydayhealth.com

Web site under test: everdayhealth.com

Designer and maintainer of Website: waterfrontmedia.com

Title: If Search field value is null, then, upon submit, then error message is returned twice -- under certain conditions.

Date discovered: 7/6/09, 13:37hrs NYC Time.

Severity: Minor.

Priority: Minor.

Tested against the following clients:

- Mac 10.5.6 / FF 3.0.11 -- fail.

- Mac 10.5.6 / Safari 3.2.1 -- fail.

- Win XP SP2 / IE 7.0 -- pass.

- Win XP SP2 / FF 3.0.11 -- fail.

Testing steps / how to reproduce:

Test A:

A1. Navigate to everydayhealth.com.

A2. Do not log-in.

A3. Place the cursor into the search bar located in the upper-right-hand corner of the page and do NOT type in any text.

A4. Click the "search" button.

A4.1 Expected results: The error message, "Please enter your search criteria", shall only appear to the user once.

A4.2 Actual results: The error message "Please enter your search criteria" appears to the user twice.

Note: If the user does a search, using any search string, then, at the bottom of the search results page, there will be presented to the user a search field. If the user then places the cursor into this search field (located at the bottom of the results) and does NOT type in any text and then clicks on submit, then the error described in this report (that of the 'error message' being returned twice) does NOT manifest. The 'error message' is only returned once -- which is the correct behavior.

Test B:

B1. Navigate to everydayhealth.com.

B2. Log-in.

B3. Place the cursor into the search bar located in the upper-right-hand corner of the page and do NOT type in any text.

B4. Click the "search" button.

B4.1 Expected results: The error message, "Please enter your search criteria", shall only appear to the user once.

B4.2 Actual results: The error message "Please enter your search criteria" appears to the user twice.

Note: If the user does a search, using any search string, then, at the bottom of the search results page, there will be presented to the user a search field. If the user then places the cursor into this search field (located at the bottom of the results) and does NOT type in any text and then clicks on submit, then the error described in this report (that of the 'error message' being returned twice) does NOT manifest. The 'error message' is only returned once -- which is the correct behavior.

Saturday, July 4, 2009

Master search engine on everydayhealth.com went down with error message

July 4th, 2009 -- 00:21 hours NYC time

The outage appeared to only last 5 to 10 minutes but could have lasted longer.

If the search engine application was down for routine or scheduled maintenance, then the "error" message presented to the user should be replaced with a "maintenance" message.

Website under test: everydayhealth.com

~~~

How to reproduce.

A1. Navigate to everydayhealth.com.

A2. Do not log-in.

A3. Type in an appropriate search term.

A4. Click the "search" button.

A4.1 Expected results: Search results are presented to the user for the search term entered.

A4.2 Actual results: An error message is presented to the user.

~~~

B1. Navigate to everydayhealth.com.

B2. Log-in.

B3. Type in an appropriate search term.

B4. Click the "search" button.

B4.1 Expected results: Search results are presented to the user for the search term entered.

B4.2 Actual results: An error message is presented to the user.

Notice on the "search engine error page" -- for the logged-in scenario, that it presents to the user the "appearance" to the user that the user is no longer logged in. (The user is really logged in).


Thursday, May 28, 2009

[bug] Firefox and Opera rendering failures -- on spincontrol.biz

Web site under test: spincontrol.biz

Web page under test: All four pages.

URL of web page under test: Not visible (it is a frame based site showing only the main url at all times).

Title: Firefox and Opera rendering failures

Date discovered: 5/28/09, 13:00hrs NYC Time

Severity: Normal (Note: Set to Normal and not Minor -- because FF is a very popular browser).

Description:

The Firefox browser renders only a very small amount of the content (text content) -- that this website intends to display to the user. The bottom portion of the content is "clipped off" -- so to speak.

The Opera browsers renders no content (text content) -- that this website intends to display to the user.

Also, upon first going to site, the Firefox and Opera browsers render the introductory "animated gif / splash movie" only partially (the top portion of it is "clipped off" -- so to speak). Also, the same thing occurs for the "animated gif / splash movie" called "last word."

This issue is seen in Firefox and Opera -- running on top of OS Mac 10.5.6 and Win XP Pro SP2.

This issue is NOT seen in Safari -- running on top of OS Mac 10.5.6 and Win XP Pro SP2.

This issue is NOT seen in IE and Google Chrome -- running on top of Win XP Pro SP2.

Workaround: When viewing spincontrol.biz, use IE, Safari, or Google Chrome.

Summary of results:

Pass = The content, appearing on any given page, fully displays

Fail = The content, appearing on any given page, does NOT fully display

Win XP SP2 / IE 7.0 -- pass

Win XP SP2 / FF 3.0.10 -- fail

Win XP SP2 / Google Chrome 2.0 -- pass

Win XP SP2 / Opera 9.64 -- fail

Win XP SP2 / Sarafi 3.2.1 -- pass

Mac 10.5.6 / Sarafi 3.2.1 -- pass (see attached picture).

Mac 10.5.6 / FF 3.0.10 -- fail (see attached picture).

Mac 10.5.6 / Opera 9.64 -- fail

See the links to the two pictures for a visual of the pass and fail in Safari and Firefox, respectively:

Attachments:

* Picture 11 saf321 pass.png: http://bit.ly/h5qSC

* Picture 12 ff3010 fail.png: http://bit.ly/13vpDz

Test details:

Summary: web page header

1) Load the web page into a browser.

2) FAILED: => The way the browser renders the content shall look consistent across the various web browsers

Link to test case: http://bit.ly/14F6FW

Generated by http://www.testuff.com

Battle of the Twitter Apps Bug Battle

A Bug Battle to test & compare the top six Twitter desktop apps is being held by uTest.

If you are already a registered user of uTest.com, then log-in here to start testing the twitter applications listed in the "Battle of the Twitter Apps" Bug Battle!

If you are not already a uTest.com member (registration and membership is free), then continue reading.

(For those of you who do not know, uTest.com is an on-demand software testing services platform that matches businesses that need software applications tested with software testers that have the skills to test the software applications. The businesses and the software testers register for free at the uTest.com site. Information about testing progress is exchange between the businesses and the software testers via the site. If the company approves a bug that a software tester finds, then the software tester gets paid. This service is a "software testing through crowd-sourcing" service).

Occasionally (as in once per quater), uTest.com will hold a "Bug Battle" for its community of software testers. This current Bug Battle runs from May 28 to June 3, 2009. Over $3000 in prize money will be awarded.

Before you can participate in a uTest Bug Battle, you need to first register with the uTest.com site. This takes about 20 minutes to do so. It is encouraged that you fill out the sign-up form thoroughly (it is painless).

After you confirm your uTest.com registration, then log-in to the uTest.com user portal. Then, click on "Releases", then (in this case), click on "Bug Battle Twitter" -- to get the details/instructions (always read very carefully), and then, start testing! When you find a bug, you then submit it by clicking on the "Report a New Bug" button and filling out the "bug report" form.

Oh, and definitely check out the uTest User Forum.

Happy bug finding!

Tuesday, May 26, 2009

[bug] The inconsistent header of the Crystal Smiles template -- on theonlinepractice.com's customer sites

Web site under test: Any one of theonlinepractice.com's customer sites

Web page under test: The customer's Home page (Note: A customer that is using the Crystal Smiles template as their website template)

URL of web page under test: http://bit.ly/9a3Hx

Title: The inconsistent header of the Crystal Smiles template

Date discovered: 5/21/09, 18:00hrs NYC Time

Severity: minor

Description:

In the header of the Crystal Smiles template, the font type of the Doctor's name / Practice name displays differently -- in certain web browsers.

This issue is seen in "all browsers" that are running on top of OS Mac 10.5.6.

This issue is NOT seen in browsers that are running on top of OS Win XP Pro SP2.

Summary of results:

Pass = The font type is clear and easy to read. The font appears to be "Times New Roman."

Fail = The font type is not clear and not easy to read and not consistent with the font displayed in browser running on top of Win XP Pro SP2.

Win XP SP2 / IE 7.0 -- pass

Win XP SP2 / FF 3.0.10 -- pass (see attached picture).

Win XP SP2 / Google Chrome 2.0 -- pass

Win XP SP2 / Opera 9.64 -- pass

Win XP SP2 / Safari 3.2.1 -- pass

Mac 10.5.6 / FF 3.0.10 -- fail (see attached picture).

Mac 10.5.6 / Safari 3.2.1 -- fail

Mac 10.5.6 / Opera 9.64 -- fail

See the links to the two pictures for a visual of the fail and pass in Firefox:

* Picture 7y - ff3010 - fail.png: http://bit.ly/j72U

* Picture 8y - ff3010 - pass.png: http://bit.ly/vaBJo

Test details:

Summary: web page header

1) Load the web page into a browser.

2) FAILED: => The header of the web page shall look consistent across various web browsers

Link to test case: http://bit.ly/5IO7B

Generated by http://www.testuff.com