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:
- What questions might you ask the Product Owner?
- What coordination/communication would you do at this point?
- 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 http://www.satisfice.com/articles/et-article.pdf
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. A@B.com 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:
|
Browser
|
Pass/ Fail
|
Defects
|
|
IE
|
|
|
|
Firefox
|
|
|
|
Chrome
|
|
|
|
Safari
|
|
|
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.
