RECRUITMENT TEST

Your company is developing the credit-card payment page for an online

flower
Shop. The payment form will contain these fields:

Purchase of 12 roses for US$ 12.95

Please input your credit card details:

Name on card: _____________________

Card type: [Visa/MasterCard]
Card number: _____________________
Expiry date (MM/YY): _____________________
Last 3 digits on back of Card: _____________________
Submit

SPECIFICATIONS
1. Write a design and usability specification for this form.
2. Write a functional specification for this form.
3. Write a security specification for this form.

QUALITY
4. Specify your quality requirements for the form and payment process.

TESTING
5. Write a test plan for this form, covering unit tests, security tests,
Acceptance tests, integration tests, stress tests and such other tests as you
think may be required.

---------------------------------------------------------------------------------------------------------
---
Answers

1.a) Design of the Form:

A Design document generally describes the look and feel of the user interface. It tells about
the specified and intended design that is being wanted by the customers. The Design for the
above given form can be illustrated in to the following points.

 D 1.1: The Upper Portion of the form displays the transaction details (E.g. Purchase of 12
roses for US$ 12.95)

 D1.2: The Form will be mentioning (should specify) the user to enter the Credit card
details.

 D1.3: The Body of the form should contain the following fields in the specified order:
 D1.3.1 Name on Card
D1.3.2 Card Type
D1.3.3 Card Number
D1.3.4 Expiry Date
D1.3.5 Last 3 Digits on back of card

 D1.4: Against each of the D1.3.1, D1.3.3, and D1.3.5 Fields there should be a Text box.

 D1.5: Against the Field D1.3.2 there should be two radio buttons with the options as Visa
and MasterCard.

 D1.6: Against the Field D1.3.4 there should be two dropdown boxes providing the options
for all the months in the first dropdown and a range of few years in the second
dropdown.

 D1.7: The Form will be ending with a submit button.

1.b) Usability Specification of the Form:

The Usability Specification document gives an insight to the users specifying the different
ways to use the application. It helps them understand the application and guides them while
putting the same to usage. Following are the main points that come under ‘usability
specification’ for the form that was provided in the test.

 U1.1: The user performing the online transaction is supposed to type in the name as
it appears on his/her credit card in the ‘Name on card’ field (D1.3.1) of the form

 U1.2: User should select the correct ‘Card Type’ (D1.3.2) according to the
Visa/MasterCard card type that is provided on the credit card.

 U1.3: User should provide the sixteen-digit card number that appears on the credit
card in the ‘Card number’ (D1.3.3) field of the Form.

 U1.4: User is supposed to fill in the ‘Expiry date’ (D1.3.4) with the appropriate Month
and Year that will be specified on the credit card.

 U1.5: ‘Last three digits on back of the card’ (D1.3.5) field should be populated with
the last three digits that appear on the rear side of the credit card.

 U1.6: The user should make sure that he/she provides all the required Fields that are
mentioned in the Functional specification doc with out fail.

2) Functional Specification:

The Functional specification is the documentation that describes the requested behavior of
any system. The documentation typically describes what is needed by the system user as well as the
requested properties of inputs and outputs. It mainly helps in finding out the navigations that happen
in the system. Following is the functional specification for the Form provided in the test.

 When the user is directed to the above Form, it is expected that the system is holding the
value of the transaction amount in some variable at the back end. This value is fetched and
displayed on top of the Form.
 After providing the required details in the form, user clicks [Submit].
  Once [Submit] is clicked a validation will be done to verify whether all the mandatory fields
are filled, in any case if they are not entered a message will be displayed to the user on the
page highlighting the fields to be entered.
 Once the validation is passed the user will be directed to a user authentication page asking
for a transaction password if any based on the credit card type.
 Meanwhile the system is expected to store and keep track of the values that were entered in
the previous page i.e. our Test Form. These details will be sent to the corresponding bank of
the credit card via a payment gateway for the authorization and approval of the transaction
made by the user.

3) Security Specification:

The Security specification document contains the guidelines that need to be followed and
maintained while implementing a design and making an application. Following points come under the
security specification of the given Form.

 SS1.1: Make sure that the ‘Card Number’ field accepts only sixteen digits and
alphabets or any other special characters are not allowed.

 SS1.2: When typed in the field ‘last three digits on back of card’, make sure that the
numbers are not visible and a special character asterisk appears in place of each
number typed in.

 SS1.3: When clicked [Submit], see that the entered values are not being displayed in
the address bar of the browser. Follow a method such that these values are
encrypted and sent when they move from one page to another in the application.

 SS1.4: Disable the automatic cookie storage (data that might be saved in the
browser) properties, as the Form contains confidential information that can be
misused when disclosed.

4) Quality Requirements:

Quality Requirements are nothing but the customer's expectations for quality, the internal
process and product attributes that indicate whether the quality factors are being satisfied, and the
measures to be used to give visibility to the levels of quality being achieved.

QR1.1: Using a Front-end verification technique, make the ‘Card Number’ field
accept only sixteen digits and rejects alphabets or any other special characters; it
helps the customers Focus on their necessary inputs alone. It narrow downs the
options to give a wrong input, there by improving the quality of the Form. This
saves the customer time as well.

QR1.2: A similar kind of Front-end verification for the remaining fields helps in
improving the quality and robustness of the form.

QR1.3: Taking proper care of the Font size and placement of all the fields of the
Form in an appropriate manner also contribute to the enhancement of the Form’s
Quality.
5) Test Plan:

A Test plan reflects your entire project testing schedule and approach. Following is
how a test plan looks like for the given Form. Most of the Fields are left blank, as they require much
more information than that is given access to. By talking to the concerned BA (Business Analyst) or a
Functional Lead who has access to all the information, we can produce a clear and better Test Plan.
Here I am just trying to give an idea about how a test plan looks like and what fields will be part of
it.

Name of the Application: Payment Gateway Form for an Online Flower shop
Prepared by: Srilakshmi P
Date: 6 February 2010

Contents:

1.0 INTRODUCTION:

The Form under test is an online payment gateway form. It helps in capturing the credit card
details and performing the transaction, dealing with the corresponding bank.

2.0 OBJECTIVES AND TASKS:

2.1 Objectives

To test the Payment Gateway Form for an Online Flower shop thoroughly as per the
specification/requirement given by the Business, so that it can be acceptable by the customer.

2.2 Tasks

1. Requirement Collection and finalize the expectation from customer/business.

2. In scope and Out Scope points identification
3. Timeline
4. Hardware requirements
5. Test Strategy
6. Test Preparation
7. Test Execution
8. Bug Fix test
9. Regression tests
10. Acceptance Test (Alpha and Beta)
11. Test Report Share

3.0 SCOPE:

4.0 Testing Strategy

4.1 Alpha Testing (Unit Testing):
A unit test is ideally written by a developer who is aware of the internal code and
functionality of the Form.
4.2 System and Integration Testing: With the available information we won’t be able to perform the
system and Integration tests. We need the overall application and the environment details.

4.3 Performance and Stress Testing

4.4 User Acceptance Testing
4.5 Batch Testing
4.6 Automated Regression Testing
4.7 Beta Testing

5.0 Hardware Requirements

6.0 Environment Requirements

6.1 Main Frame
6.2 Workstation

7.0 Test Schedule

8.0 Control Procedures

9.0 Features to Be Tested

10.0 Features Not to Be Tested

11.0 Resources/Roles & Responsibilities

12.0 Schedules

13.0 Significantly Impacted Departments (SIDs)

14.0 Dependencies

15.0 Risks/Assumptions

16.0 Tools

17.0 Approvals
----------------------------------------------------------------------------------------------------------------------------
-
Thank You - End of Test