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