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).