Thursday, August 18, 2016

Registration Site Testplan

The following was requested by some folks at an online education company.  The assignment was the following

I would also like you to include the following: 

  1. What questions might you ask the Product Owner?
  2. What coordination/communication would you do at this point?
  3. What suggestions would you have to make this User Story and Acceptance Criteria better or more clear?

User Story: 
As a training attendee, I want to be able to fully register online, so that I can register quickly, painlessly and reduce overall paperwork

Acceptance Criteria: 
  •     All the mandatory fields are required for a user to submit the form.
  •     Protection against spam is functioning properly.
  •     Information from the form is stored in the correct database and the data is in tact.
  •     Payment can be made via credit card in a secure way.
  •     An acknowledgment email is sent to the user after submitting the form which includes how to get started.

My questions to the product owner are here below
1.    What sort of training is this?  Is this just a training session or something more like a convention or seminar.  
1.a.  Are there different options or packages the user can sign up for.  The test plan assumes only on session of training that is at a single price.  If this is the case we will need to create testcases around all costs and options.
1.b.  Is there a need for the user to schedule anything within this training.  Seminars may have a single cost but the user may need to schedule what sessions or panels they attend.  The test plan assumes just a single training without sub events.  This could be a secondary page with many testing permutations.
2.   While this training happen again?  Is it a single even or a regular training our company performs.
2.a. If there are many dates the training occurs that the user can pick from I need to capture this.  My tests assume the even occurs only once.
2.b. If it is annual we may be doing extra mailings to advertise to previous attendees for future training.
3.   Who is the host of this event?
3.a. If we are hosting do we need to provide food to the attendees?  Me may need to add a choice of food as an option to select. 
4.    Is a Hotel connected to this event?
4.a. Do we need to book the hotel room along with the training registration?
4.b. Do we need to sell or include parking passes?
5.    What materials are given out
5.a. We should have digital versions when out with confirmation email.
5.b. Are there options here like purchase of software? 
6.    Do we limit who can come to this training in anyway?
6.a. A black list of banned persons not allowed to the training.  I would need to test to include exclusion of these people.
6.b. A white list or qualification that must be met.  I don't know if only people from a particular company are allowed or if there are other qualifiers.  I would need to test.

And finally the test plan itself.
Training Registration Web Site Test plan
1.       Introduction:  Through this document I will outline my testing strategy for a training registration web site.  The goal is to list the broad areas of testing here, including general test descriptions.  Further I will be documenting dependencies and resources the test testing team will require for successful validation. 
1.1.    In scope items:  Payment system flow.  Email confirmation.  Validation of the Database through system test flows.   Cross browser web validation and checking of anti-spam/ real person validation.
1.2.    Out of scope items:  Benchmarks of speed and performance, Internationalization and localization testing.    We are assuming a single training event that does not repeat annually that will occur within an unnamed US city.
2.       Required Resources:  I am assuming a standard web site configured on a generic web server environment that is generic but standard to industry.
2.1.    Test and live environments
2.2.    Database set up and access to said database
2.3.    Deployment system, perhaps Jenkins.
2.4.    Automation environment if there are to be future training sessions.
3.       Test Approach:  My general methodologies for testing will be exploratory testing to validate code is ready to move onto functional test.  Functional verification will validate positive and negative flows of the ticket registration system.  Regression will be marked for the future as we are starting at square one there is not existing code to validate against.  
3.1.    Exploratory testing:  We will be performing two rounds of unstructured tests.  The first will explore areas broadly to determine they are functionally ready to enter testing.  The second round will start after sign up and billing flows are functional.
3.1.1.  Both rounds will be reported through James Bach exploratory testing format as documented at
3.1.2.  Round 1 will be 30 minutes. Goal will me verification of base functionality
3.1.3.  Round 2 will be a 1 -2 hour block.  Goal will be familiarization of tester to execution and basic detection of issues.  Further UI will be evaluated for user friendly interface, basic look and feel, etc.
3.2.    Functional testing:  This will need to have sign off by both development and the product owner before execution.   I will send it out with at least three days to prior to estimated code delivery for sign off and update with feedback.
3.2.1.  (Regression) Verify the registration flow through purchase of a single purchase.
3.2.2.  Verify Name, Email, Credit Card, and Billing information fields are mandatory
3.2.3.  Verify the standard email compliance is required for entry of email field. should be required at minimum. Verify Credit Card information maintain 16 digit minimum digit number entry.  Error should be issued if less or more digits are entered.
3.2.4. Verify visa 4 prefix and master card 5 prefix are required for credit card entry.  Error should be issued if combinations are not correct.
3.2.5. Verify CVV is alerted for and explained within credit card information.
3.2.6. Verify can set billing information to same as address with checkbox.
3.2.7. Verify Company and address fields are not mandatory.
3.2.8. Verify 3 digits are required for all except Amex which is 4 digit.
3.2.9. Verify a test number set to be rejected by the processor displays appropriate message within purchase flow.
3.2.10.    (Regression) Verify routes through HTTPS for purchase information.
3.2.11.    Verify entry of Real Person verification is enforced as a mandatory field.
3.2.12.    Verify the user is alerted when entering invalid Real Person information.
3.2.13.    (Regression) Verify we can positively proceed through Real Person validation with correct information.
3.2.14.    Verify user can enter not standard characters from UTF-8 set in name and email fields.
3.2.15.    (Regression) Upon completion of purchase, verify correct email is sent to user.
3.2.16.    (Regression) Upon completion of purchase, verify database tables are updated with registration information
3.2.17.    (Regression) Upon completion of purchase, verify the funds delivered to our accounts from credit card processor.
3.2.18.    (Regression) Upon completion of purchase, verify web page alerts user with confirmation test and confirmation number.
3.2.19.    Attempt to register as a banned individual, verify user can not purchase attendance to training.
3.2.20.    Attempt to register as a user that has already registered with completely matching information. Verify user can not purchase second attendance to training.  Should be alerted they are already signed up.
3.2.21.    Attempt to book a number of users beyond the limit of the particular training, verify the user can not purchase attendance to training.  Web site should alert people to coming to site that the training is now full.
3.2.22.    Attempt to cancel scheduled training either through database or backend, verify email is sent to all registered users that the training has be cancelled.
3.2.23.    Attempt to purchase when the server time is now after the scheduled training, verify user can not purchase attendance to the training.  User really should not be given option to see that as a valid item for purchase.
3.2.24.    (Regression) Verify we can refund a purchase through backend flows.
3.2.25.    Verify you can purchase two different users attendance with the same credit card.
3.2.26.    Verify card maintains information if the browser session is ended but cache has not been cleared.
3.3.    Brower Testing Matrix:
Pass/ Fail




4.       Entrance criteria:  Full functionality of website checked into source management.  No blocking issues that prevent testing from proceeding. 
5.       Exit criteria:  Functional testing, including negative tests, have passed validation.  Only low priority defects remain unfixed.  Regression of the live site has been completed which conforms to marked Regression set above.
6.       Deliverables: The following items the Quality team recognizes as their responsibility to provide.
·                       Final test plan document
·                       Detailed test cases.
·                       Sign of functional tests in staging or QA environment
·                       Sign of functional regression in live environment
7.       Risks:  Late delivery and schedule compression beyond control of quality team.  Also third party systems which would include the credit card processor and provider of Real Person validation.
8.       Schedule: This will be determined by SDLC style, Scrum sprints are usually two weeks in duration.  I am assuming testing will need to be completed within the confines of a two week cycle.   This would include reporting defects and revalidation of those defects when they have been fixed.   Regression of the live site would also be completed within the duration of the two week sprint cycle.

No comments: