Page Flow Challenge Clarification

The Page Flow Challenge in my previous post warrants a bit of clarification. A few readers had questions about the usefulness or sanity of certain steps in the test scenario. I'll go through the scenario and highlight what is being tested in each of the steps.

1. Start the page flow
2. On Page 1, enter "foo" and click Next
   You should end up on Page 2 where "foo" is displayed as input from page 1
3. On Page 2, enter "baz" and click Next
   You should end up on Page 3 where "foo" and "baz" are displayed as input from the previous pages
4. Click the browser back button
   Without any browser warnings you should end up on Page 2, where "foo" is still displayed as input from page 1

The first part of the scenario sets up a basic set of data associated with the page flow: "foo" and "baz" at this point. At step 4 we're using the browser back button to backtrack. This tests POST-REDIRECT-GET behaviour: if the application does not use POST-REDIRECT-GET, the browser will show a warning before displaying Page 2 again. This is so because Page 2 is the result of posting the HTML form on Page 1, and modern browsers never automatically resubmit post data. Essentially we're protecting the user from accidental resubmits. Not having the browser show ugly warnings about resubmitting also makes the application feel stable and trustworthy.

5. Right click the Back link on the page and do Open Link in New Window
   The new window should show Page 1 where "foo" is displayed in the input field
6. In the new window, enter "kit" (replacing "foo") and click Next
   You should end up on Page 2 where "kit" is displayed as input from page 1
7. In the new window, on Page 2 enter "kat" and click Next
   You should end up on Page 3 where "kit" and "kat" are displayed as input from the previous pages
8. In the original window, click the browser refresh button
   Without any browser warnings you should see Page 2 again with "foo" as input from page 1

Step 5, admittedly a contrived step, simulates the user branching off the page flow into two separate windows. The point of doing this is testing whether or not the two branches are isolated. In steps 6 and 7 new data is entered ("kit" and "kat") that potentially interferes with the previously entered data ("foo" and "baz"). Step 8 verifies that no interference happened: the page flow in the original window still has "foo" as data.

9. In the original window, enter "bar" and click Next
   You should end up on Page 3 with "foo" and "bar" as input from previous pages
10. In the original window, click Finish
    You should end up on the start page of the application: the page flow has finished
11. In the original window, click the browser back button
    You should either receive an error immediately, or when you try to resubmit by clicking Finish again

In step 9 and 10, we complete the page flow and finally submit values "foo" and "bar". At this point the page flow has finished. The state and navigation management of the framework should have invalidated the page flow at this point, making it impossible to resubmit. Step 11 verifies this: if you go back using the browser back button, you should not be allowed to resubmit. This part of the scenario tests intentional double submit protection (classically solved with something like a synchronizer token).

12. (For extra bonus points) In the new window, (where you still are on Page 3) click Finish
    You should receive an error of some sort (potentially a automatic page flow restart)

The final step of the scenario tests whether or not the framework tracks the two branches of the page flow as being part of the same original conversation. This is an advanced form of double submit protection. In most cases this is a beneficial extra protection. In some cases this might not be what you want.

To make all of this a bit more tangible, let's suppose this is an airline ticket booking flow. The scenario would go something like this:
In step 2, on Page 1, the users fills in basic traveller information (name, age, seating class) and advances forward. In step 3, on Page 2, he selects a seating preference. Page 3 in step 4 shows an overview of the captured information and asks for confirmation. The user notices that he made a mistake and backs up.
Steps 5, 6 and 7 has the user thinking he might want to try a seat in a different seating class and compare the prices. Page 3 in step 7 displays an overview of the price with the new seating class.
In step 8 and 9 the user completes the page flow with the original seating class. On step 10 he compares the prices of the two alternatives and decides to submit the first of the two alternatives.
Steps 11 and 12 verify that the user cannot accidentally book two tickets, either by resubmitting the first alternative or submitting the second alternative. If he really wants another ticket, he'll have to start the ticket booking process (the page flow) again.

I hope this clarifies things a bit and shows that the test scenario is actually somewhat realistic.