Test plan for application
Test Plan
Prepared by:
04/30/2017
Table of Contents 1 INTRODUCTION ...................................................................................................................... 3
2 TESTING OBJECTIVES .............................................................................................................. 3
2.1 Objectives ....................................................................................................................... 3
3 SCOPE AND LIMITATIONS OF TEST PLAN ............................................................................... 3
4 BUSINESS EXPERTISE .............................................................................................................. 3
5 DEVELOPMENT EXPERTISE ..................................................................................................... 4
6 SOURCES OF TEST DATA ......................................................................................................... 4
7 TESTING STRATEGY ................................................................................................................. 4
7.1 Static Testing .................................................................................................................. 6
7.2 Unit Testing .................................................................................................................... 8
7.3 System and Integration Testing ...................................................................................... 8
7.4 Performance Testing ...................................................................................................... 9
7.5 User Acceptance Testing .............................................................................................. 10
7.6 Automated Regression Testing .................................................................................... 10
8 TEST ENVIRONMENT REQUIREMENTS ................................................................................. 11
8.1 Workstation .................................................................................................................. 11
8.2 Network ........................................................................................................................ 11
8.3 Server ............................................................................................................................ 11
9 CONTROL PROCEDURES ....................................................................................................... 12
10 FEATURES TO BE TESTED .................................................................................................. 13
10.1 Test Cases ..................................................................................................................... 18
11 FEATURES NOT TO BE TESTED .......................................................................................... 46
12 RESOURCES/ROLES & RESPONSIBILITIES .......................................................................... 47
13 SCHEDULES ....................................................................................................................... 47
14 SIGNIFICANTLY IMPACTED DEPARTMENTS ...................................................................... 47
15 DEPENDENCIES ................................................................................................................. 47
16 RISKS/ASSUMPTIONS........................................................................................................ 48
17 TOOLS ............................................................................................................................... 49
18 APPROVALS ...........................................................................Error! Bookmark not defined.
1 INTRODUCTION Chegg is a website application that its main purpose is to help students with
their homework. It is a paid service that you need to subscribe in order to get help with homework. It does not only provide their customers a big database of textbook solutions in high detail, but also provides tutors that can help in any question. Anyone could apply to be a tutor in Chegg website.
You can play different roles in Chegg website. You can be a tutor and teach; be a student and get help with questions from Chegg’s database or from the tutors; sell a book to Chegg; buy a book from Chegg; rent a book from Chegg; prepare for tests, like SAT and ACT; get help to find internships; get help to find colleges and scholarships; search for universities; search for textbook questions, with their solutions too.
For this course, Chegg would be a good example of an application to back engineer in this course. Because its Domain Class Model has multiple things to test, as we will see next.
2 TESTING OBJECTIVES
2.1 Objectives
This Test Plan must be monitored by the PMO and instructed clearly to all the developer team that is working on Chegg’s application. Additionally, the PMO must consider a reasonable amount of money for the testing budget.
The methodology that we will use with this application development is Agile with sprints of 2 weeks, so that the application is developed on time and the probability of other companies developing an application with the same functionality is lower.
3 SCOPE AND LIMITATIONS OF TEST PLAN The testing team won’t be able to test every specification and feature of the
application, since the PMO limited the budget for this test plan. Because of that, we have prioritized the features that must be tested, leaving the low priority features out of our scope according to what the budget will allow us to test. The features that will be tested, as well as the features that won’t be tested can be found in sections 10 and 11.
4 BUSINESS EXPERTISE The development team will have a business expertise who will help them build
the application from a marketing perspective, providing feedback on their work. Additionally, that business expertise will help the development team to keep the
application’s scope in the correct business context, since that expertise knows better the market needs.
The business expertise will also help the testing team in discovering test cases from a business perspective. Even though that expertise is not a software tester, he or she can help the team in finding some test cases that usually normal users would encounter.
5 DEVELOPMENT EXPERTISE The testing team will have a development expertise who will help them design
and build the software in the correct way, making sure that the application uses the right data structures and the right algorithms. Additionally, he will establish the coding format protocols for the development team to use it.
The development expertise will help both the testing team as well as the development team, even though both teams will have a chief leader that will guide them all the time through the software life cycle. In addition, the development expertise will also instruct the development team in adding the code earmarks in the Defect Tracking Log, whenever they add corrections to the software.
6 SOURCES OF TEST DATA The testing team will use a lot test data to test its test cases the way they
should be tested. Most of the test data will come from the internet and third party
databases that focus on delivering test data. Some other part of the test data will
come from our testing team, because a small number of features require specific
data.
The test data from the internet will be things like credit card information;
different types of strings for creating usernames, passwords, names, emails, and
addresses; numbers for the telephone field, and ISBN search field; different types
and sizes of photos for a profile picture; short and long string texts for searching
book titles, names, authors, and tutors.
7 TESTING STRATEGY Our overall approach to the testing strategy is to incrementally test the
application with all the test techniques that are effective for a web based application,
in which are: Static Testing, Unit Testing, System and Integration Testing, Performance
Testing, User Acceptance Testing, and Automated Regression Testing.
In Static Testing, we will test the initial part of the application, such as the
requirements, specifications, data design, interface design, database structure design,
etc. Since 85% of the errors in any application are introduced in this phase, we will put
a lot of efforts into it.
In Unit Testing we will test specific aspects of the application individually, so that
it will be easier to tell if a function is properly working (easier to spot bugs). Also, by
doing that, we will be able to test all, or most of, the individual functions of the
application.
In System and Integration Testing (Black Box Testing) we will be performing
testing against specific parts of the system as well as the whole system. This test will be
made by just observing the input/output behavior of the application in contrast with its
specifications. In other words, we will be checking the actual output of the application
with the expected output, to see if everything match as it should.
In Performance Testing (Load Testing), we will already know that the application
works correctly, but here we will be testing the application limits such as the maximum
number of active users in the website, the maximum number of accounts in the
database, the response time for a system request, etc.
In User Acceptance Testing we will observe what real users think of the software
by letting them use them as a way of testing the application. By doing that, we will be
able to see if the application complies with its requirements in a real-world scenario. In
addition, the users will give their opinion in any missing feature that they think the
application should have, as well as any functionality that they think the application
doesn’t addresses properly.
Finally, in Automated Regression Testing, we will use old testing scripts to test
new versions of the application, so then we can check if new added features or new
bug fixes didn’t introduce new bugs into the software. Furthermore, we will use all
three automated tests available to date: Simulation, Benchmarking, and Testing
Environment.
In Simulation, we will simulate the hardware and software behavior of the
application. Since that type of testing is more much cheaper than the other ones, we
will include it in our test plan. In Benchmarking, we will basically test the application’s
performance under a high controlled environment, which will help us compare our
product with other similar products available in the market, by a score. Since the
benchmarking runs at very unusual conditions to test the application's performance,
and it cannot test the application's functionality, then we can say that the
benchmarking is very limiting if used alone to test an application. Therefore, we won’t
use much benchmarking to test the application, but just as a complementary way of
testing it. In Test Environment, we will use computers, with very similar environments
as the target or production environment, to run scripts and check the actual output
against the expected output. The scripts will be recorded by the testing team and will
be ran in the test machines.
7.1 Static Testing
Software Platform Layers Preliminary Investigation, Analysis and Design
Application Is what is being developed and is the primary focus of the test plan.
- Inspection reviews - Software requirement specification - Risk mitigation planning - Project Charter - Project Plan - Test cases - Test plan - Software specifications - Interfaces - Screen/window/page specifications - Report specification - Business process diagram - Schedule - Data flows - Process maps - Retrospective reports - Competition Analysis - Use cases - Interface control document - Logical/physical models
Connectivity Provides interchange of tasks and data among software components.
- Data flow diagrams - Online operating environment specifications - Connectivity specifications - Report specification - Interface control document
Data Resources Provides file or database management of the data stores.
- Database and file design - Report specification - Database management system documentation - Setup/installation
Security Restricts/allows access to all layer activities above.
- Security specifications - Report specification - Profile procedure/workflow
Operating System Manages the computer hardware and software.
- Batch operating environment specifications - Report specification - Hardware-software requirement - Installation
Software Platform Layers Preliminary Construction
Application Is what is being developed and is the primary focus of the test plan.
- Inspection reviews - Code
Connectivity Provides interchange of tasks and data among software components.
Data Resources Provides file or database management of the data stores.
Security Restricts/allows access to all layer activities above.
Operating System Manages the computer hardware and software.
Software Platform Layers Final Construction
Application Is what is being developed and is the primary focus of the test plan.
- Inspection reviews
Connectivity Provides interchange of tasks and data among software components.
Data Resources Provides file or database management of the data stores.
Security Restricts/allows access to all layer activities above.
Operating System Manages the computer hardware and software.
Software Platform Layers Installation
Application Is what is being developed and is the primary focus of the test plan.
- Inspection reviews - Installation guides - User Guides
- Help screens - Training manuals - Test Environment Specifications
Connectivity Provides interchange of tasks and data among software components.
Data Resources Provides file or database management of the data stores.
- Test Data Sources and Preparation
Security Restricts/allows access to all layer activities above.
Operating System Manages the computer hardware and software.
- Support Guides - Test Tool Installation and Operation
7.2 Unit Testing
The units tested will be tested using both Black Box testing and White Box Testing. In addition, the test scripts for Black Box testing will be built by the testing team, but the scripts will be managed by the tester Chief.
To write those scripts, the testing team will analyze the application’s features/functionalities sequentially, and write all the tests for each one of them.
Depending on the size of the testing team, the tester Chief will divide the team in pairs, in which each pair will work on one test script of a feature. The testing team will also write the scripts more carefully and organized, since they will still be used in the future for Automated Regression Testing. In sprints of 2 weeks, the testing team will do an inspection review on all the unfinished test scripts and the test scripts that were done on less than 2 weeks ago.
7.3 System and Integration Testing
In this part, the tester Chief will conduct its testing team to do a series of Black Box scripts. Those scripts will basically test the different input/output behaviors of the application against its requirements. The testing team will also write the scripts more carefully and organized, since they will still be used in the future for Automated Regression Testing.
The Black Box scripts will be built by pairs of testers and in sprints of 2 weeks, those scripts will be reviewed through an inspection review. Before the inspection reviews, the testing team will also utilize desk checks for a better preparedness on the inspection review. In addition, the scripts will be periodically changed when needed; for instance, when the developer team adds a new functionality on top of
the old code, making the old script invalid and useless.
7.4 Performance Testing
After the preliminary construction, in other words, after the application is built and tested properly, the testing team will start to work on the performance testing. The tester Chief will be the one who will organize and set everything up for the testing team to perform all the tests. After everything is set up, the testing team will start to analyze the application’s performance by the help of professional third party testing tools.
The performance testing will be helpful to test the non-functional requirements of the application, like speed, request time, submit time, response
time, workload limit, user accounts limit, data speed limit, server response time limit, etc. This test will be very important to make sure that the end users will have a good experience with the application’s response time. Additionally, the testing team will use automated testing tools, such as Benchmarking, to help them do a systematical comparison with other applications in the market, by using the score report of the benchmark test.
The following table represents 10 performance test cases done in different times of a day and different days of a week:
Transaction Group Timing Day and Time
Search books by ISBN 2.69 sec. Monday, 6:00 PM
2.12 sec. Tuesday, 1:00 AM
2.24 sec. Tuesday, 12:00 PM
2.12 sec. Tuesday, 4:00 PM
Search books by title 2.31 sec. Monday, 6:00 PM
2.57 sec. Tuesday, 1:00 AM
2.78 sec. Tuesday, 12:00 PM
2.36 sec. Tuesday, 4:00 PM
Search books by author 2.45 sec. Monday, 6:00 PM
2.61 sec. Tuesday, 1:00 AM
2.51 sec. Tuesday, 12:00 PM
2.57 sec. Tuesday, 4:00 PM
User login with email 1.84 sec. Monday, 6:00 PM
1.93 sec. Tuesday, 1:00 AM
1.98 sec. Tuesday, 12:00 PM
2.11 sec. Tuesday, 4:00 PM
User login with Facebook
2.38 sec. Monday, 6:00 PM
2.72 sec. Tuesday, 1:00 AM
2.18 sec. Tuesday, 12:00 PM
2.05 sec. Tuesday, 4:00 PM
User logout 1.34 sec. Monday, 6:00 PM
1.22 sec. Tuesday, 1:00 AM
1.14 sec. Tuesday, 12:00 PM
0.87 sec. Tuesday, 4:00 PM
Add item to cart 2.13 sec. Monday, 6:00 PM
2.25 sec. Tuesday, 1:00 AM
2.06 sec. Tuesday, 12:00 PM
2.58 sec. Tuesday, 4:00 PM
Remove item from cart 0.99 sec. Monday, 6:00 PM
0.88 sec. Tuesday, 1:00 AM
1.66 sec. Tuesday, 12:00 PM
0.81 sec. Tuesday, 4:00 PM
Search question 5.68 sec. Monday, 6:00 PM
5.18 sec. Tuesday, 1:00 AM
5.52 sec. Tuesday, 12:00 PM
5.91 sec. Tuesday, 4:00 PM
Bookmark question 0.81 sec. Monday, 6:00 PM
0.88 sec. Tuesday, 1:00 AM
0.62 sec. Tuesday, 12:00 PM
0.68 sec. Tuesday, 4:00 PM
7.5 User Acceptance Testing
The User Acceptance Testing will occur during the final installation phase of the application, so that the end user can test the application as if it was already deployed. The tester Chief and the business expertise will conduct this test by selecting several people to use the application in exchange of money. The selected people will then be playing/using the application as long as the tester Chief thinks it’s enough for the test. After some time, the tester Chief and the business expertise will then meet those users and talk with them to see what bugs they encountered. In addition, the users will tell them if there’s a feature missing or if an existent one needs to be better designed on the application’s front-end part, so that the application has more chances of being accepted by the overall public and thus be successful.
7.6 Automated Regression Testing
The testing team should perform Automated Regression Testing along the entire software life cycle of the application, to make sure that new bugs are not introduced by mistake when new implementations or new bug fixes are done in the code. This testing technique should be used whenever there is an inspection review for the code or when new code is added to the project, so that the testers can minimize the inspection time by fixing possible errors in advance. Part of the Regression Testing scripts should be
already available by previous Unit Testing and System and Integration Testing phases, that are done in every sprint (2 weeks). However, the majority of the scripts will be created by the testing team, with maybe additional help of the testing tool’s personnel. Essentially, the scripts will be built only once, and changed whenever needed. The testing team will be using both Foreground Touchpoint and Background Touchpoint techniques to test the application, giving more emphasis to the best cost/benefit technique. They will also take advantage of the Test Execution Harness Management, to help them execute specific regression testing scripts whenever they need. To summarize, the Regression Testing will be the procedure of constantly running these test scripts, to validate the correctness of the code’s behavior.
8 TEST ENVIRONMENT REQUIREMENTS
8.1 Workstation
The test team, with maybe the help of other personnel, will setup all the workstations required for them to run the test scripts. For the workstation specifically, the test team will have to setup the operating system, the file systems, and the workstation security. Sometimes, if these environment components are complex, then additional help from experts may be needed. In most cases, however, the test team will be able to handle the setup by themselves, especially if the application is small. For Chegg, the test team will probably be able to do the setup by themselves.
8.2 Network
For the network, the test team will be responsible for the connectivity
component of the test environment. Here, the test team will set up all that apply to the
application’s requirement: LANs, WANs, Satellite, Wireless, and Internet. For Chegg, the
test team will have to set up only the Internet component, since Chegg is a web-based
application and therefore is accessed from the web browser.
8.3 Server
The server component of the test environment won’t be set up by the test
team. Instead, the tester Chief will contact third parties’ server companies to do
this for them, choosing the one the best fit their needs and budget.
The server will have to handle a fairly big number of active workstations for the
test team successfully use the Foreground Touchpoint technique and to do load
testing. In addition, the server will have to handle accesses from all parts of the
world, without sacrificing speeds for U.S. users, since the U.S. users are the target
consumer. Moreover, the server will need to have support for the desired
performance test tools chosen by the test team, otherwise the test team won’t be
able to run the test tools in the server, to do performance testing. Additionally, the
server will need to have support for additional security components chosen by the
test team, to simulate better the production environment, in which will have these
or similar security components too.
9 CONTROL PROCEDURES The control procedures for error logging will be to fill up a Defect Tracking Log
document that can be found below this text. This log document will need to be fill out by the person who found the error and will need to be submitted to the PMO, in which will take care of either storing the log document as digital copy and a hardcopy or only as a digital copy. Because the testing team needs to have online read-only access all the time to the log documents. Any modifications to an already submitted document will need to be through the PMO, or the tester Chief, or the developer Chief. In addition, any other documents that have relation to a previous document, for instance a bug fix issue report and a bug report, will be grouped/attached together. Even though everyone in the testing team will have online access to the log documents, none of the team members will be able to make modifications to them; only the PMO, the tester Chief, and the developer Chief. The developer team will also have to fill the Defect Tracking Log whenever they fix bugs, by grouping all of those fixes together and assigning an earmark to them. However, they will have to go through either the PMO or the developer Chief to get temporary access to the specific documents they need to modify. That earmark will be mentioned in the defects in which it applies, making easier for the test team to know what defects were fixed in which earmark. Also, there will be a table for the earmarks, in which will point out the number of defects fixed in that earmark, as well as the percentage of defects fixed. The Defect Tracking Log, the earmark table, and the Defect Backlog are the following: Defect Tracking Log:
Code Earmark Table:
Defect Backlog:
10 FEATURES TO BE TESTED
Domain Class Diagram:
High Level Features of Chegg:
• Allows the customer to find textbook solutions
• Allows the customer to find an online tutor
• Allows the customer to message tutors
• Allows the customer to request a written lesson from a tutor
• Allows the customer to post study questions
• Allows the customer to comment on posted solutions
• Allows the customer to rent books
• Allows the customer to buy books
• Allows the customer to sell books
• Allows the customer to get quotes on books you want to sell
• Allows the customer to register/subscribe (monthly) to their service
• Allows the customer to pause their subscription of Chegg service
• Allows the customer to purchase test prep services (SAT and ACT)
• Allows the customer to go find internships online (through another website
provided by Chegg) [a Chegg service though]
• Allows the customer to find colleges in US. Also provide information of them
• Allows the customer to bookmark specific textbook solutions for later
• Allows the customer to rate tutors
• Allows the customer to rate solutions
• Allows the customer to bookmark other peoples’ questions
• Allows the customer to report questions
• Allows the customer to browse through the entire textbook solutions by its
chapter and exercises
• Allows the customer to see their orders
• Allows the customer to edit their account
10.1 Test Cases
Functional Tests: 1. Buy book 2. Credit Card transaction 3. PayPal transaction 4. Masterpass transaction 5. Search books by ISBN 6. Search books by title 7. Search books by author 8. Bookmark question 9. Rate solution 10. Report user question 11. Pause subscription 12. Cancel subscription 13. Subscribe to service 14. Create a student account 15. User login with email
<TC_FT_1.0> <Buy Book>
Description: The purpose of this test is to validate the application's ability of selling a book to a registered user. Development Phase: Final Construction. Goals: The goal of this test is to make sure that the application successfully display the correct amount of money for the book, by either new or used books. Also, validate the application’s functionality of making a transaction. Test Data: The test data for this test will be a list of books with both of “used book” and “new book” prices included. Test Tools: Test Startup Procedure: Test Closedown Procedure:
1. Test Case
Preconditions:
1. The user trying to buy the book must be registered in the application.
2. The user must be logged in.
4. The user must have already chosen before checkout that the book is new or used.
3. The user must be already in the checkout page for the book that he or she wants to buy.
Test Steps:
1. Fill Shipping Address information.
2. Fill the method of payment with your credit card or PayPal or MasterPass.
3. Fill Billing Address information accordingly with your method of payment.
4. Click on “CONTINUE”
5. Click on “PLACE ORDER”
Expected Results:
1. The application should make the transaction for the book and register in its server, as well as
in the user’s account, in “Orders” section.
2. The application should go to a new page displaying: that the order was successful, the amount
of money that the transaction was, and the order ID for that order.
3. The application should also show the price of the book with its taxes, shipping cost, and selling
fee. The application should sum up these costs and display the final cost too.
4. The application should send an email with the order ID and the summary of the user’s order.
User Actions/ Expected Results Comments
<TC_FT_2.0> <Credit Card Transaction>
Description: The purpose of this test is to validate the application’s functionality of making a credit card transaction when a user is bu ying something from the website. Development Phase: Final Construction. Goals: The goal is to make sure that any registered user can purchase a product from the website user a credit card. Additionally, t he application must validate the user credit card by his credit card information (expiration date, security code, name, etc) and by the billing address filled by the user. Test Data: The test data used is a list of fake credit card numbers with billing information linked to them, to simulate real credit cards. Test Tools: Test Startup Procedure: Test Closedown Procedure:
2. Test Case
Preconditions:
1. The user must be registered in the application.
2. The user must be logged in.
3. The user must be in the checkout page for either buying a book or a service.
Test Steps:
1. Fill Shipping Address information.
2. Fill the method of payment with your credit card.
3. Fill Billing Address information accordingly with your method of payment.
4. Click on “CONTINUE”
5. Click on “PLACE ORDER”
Expected Results:
1. Right after filling the credit card information, the application should turn the color of the
credit card’s font to red and display a red message saying that it’s not valid, IF the credit card is
not successfully validated with the credit card validation tool.
2. The application should validate the billing address after the user clicks on “PLACE ORDER”,
stopping the order to get processed if the billing address is invalid for the credit card. If it is
invalid, go back to the previous page and show a red message right next to the billing address
box, indicating that it was invalid, and turn the old billing address font to red.
3. If the credit card information with the billing address is validated, then process the order
normally.
4. If a credit card is used in more than 5 failed transaction attempts within 1 hour, then the
application must display a message saying that the user won’t be able to make any more
transactions with that same credit card in a period of 1 week. And it should tell the user that if
he wants to make that purchase, he or she will need to either use a new credit card or contact
customer support over the telephone.
User Actions/ Expected Results Comments
<TC_FT_3.0> <PayPal Transaction>
Description: The purpose of this test is to validate the application’s functionality of making a PayPal’s transaction when a user is buying something from the website. Development Phase: Final Construction. Goals: The goal of this test is to make sure that any user in the website can use their PayPal account to purchase something from the application. Test Data: The test data is a list of fake PayPal accounts, to simulate real accounts. Also, each fake PayPal account will have its user name with its password, so we can test if the application successfully authenticates those users based on their login information. Test Tools: Test Startup Procedure: Test Closedown Procedure:
3. Test Case
Preconditions:
1. The user must be registered in the application.
2. The user must be logged in.
3. The user must be in the checkout page for either buying a book or a service.
4. The user must have a valid PayPal account.
Test Steps:
1. Fill Shipping Address information.
2. Click on the PayPal button.
3. Type your PayPal information (email and password) and click on “Log In”
4. Select a credit card from your list of credit cards in your PayPal account or add a new credit
card with its billing address.
5. Click on “Add” if you chose to type a new credit card and billing address, or click on one pre-
existent credit card that is displayed there.
6. Click on “CONTINUE”
7. Click on “PLACE ORDER”
Expected Results:
1. As soon as you click in the PayPal button, you should be redirected to PayPal’s website to put
your login information.
2. If your PayPal login and password is invalid, then PayPal should prompt you to retype again,
displaying a message that says that the login and password combination is wrong.
3. After clicking “Log In” in step 3, you should be redirected to a new PayPal page in which you
will be prompted to select one of your pre-defined credit cards or add a new one. Also, there
should be Chegg’s logo on the top-left corner of that page.
4. If you try to add a new credit card instead of selecting a pre-existent one, then PayPal should
take care of authenticating that new credit card for you.
5. If you select a pre-existent credit card, then you should be redirected to a new page to choose
whether or not you want to continue and place the order.
6. If you choose to place the order, then Chegg should send the transaction request to PayPal
and process the order for you, redirecting you to a new page showing your order number and a
message of success. If you choose to not place the order, then Chegg should cancel the order
and go back to Chegg’s homepage.
User Actions/ Expected Results Comments
<TC_FT_4.0> <Masterpass Transaction>
Description: The purpose of this test is to validate the application’s functionality of making Masterpass’s transaction when a user is buying something from the website. Development Phase: Final Construction. Goals: The goal of this test is make sure that any user can buy something from the application website using his or her Masterpass’s account. Test Data: The test data for this test would be a list of fake Masterpass’s accounts, with a login and password each. Test Tools: Test Startup Procedure: Test Closedown Procedure:
4. Test Case
Preconditions:
1. The user must be registered in the application.
2. The user must be logged in.
3. The user must be in the checkout page for either buying a book or a service.
4. The user must have a valid Masterpass account.
Test Steps:
1. Fill Shipping Address information.
2. Click on the Masterpass button.
3. Type your Masterpass email or mobile number, click on I’m not a robot”, and click on “Sign In”
4. Select a credit card from your list of credit cards in your Masterpass account or add a new
credit card with its billing address.
5. Click on “Add” if you chose to type a new credit card and billing address, or click on one pre-
existent credit card that is displayed there.
Expected Results:
1. As soon as you click in the Masterpass button, you should be redirected to Masterpass’s
website to put your login information.
2. If your Masterpass login and password is invalid, then Masterpass should prompt you to
retype again, displaying a message that says that the login and password combination is wrong.
3. After clicking “Sign In” in step 3, you should be redirected to a new Masterpass page in which
you will be prompted to select one of your pre-defined credit cards or add a new one.
4. If you try to add a new credit card instead of selecting a pre-existent one, then Masterpass
should take care of authenticating that new credit card for you.
5. If you select a pre-existent credit card, then you should be redirected to a new page to choose
whether or not you want to continue and place the order.
6. If you choose to place the order, then Chegg should send the transaction request to
Masterpass and process the order for you, redirecting you to a new page showing your order
number and a message of success. If you choose to not place the order, then Chegg should
cancel the order and go back to Chegg’s homepage.
User Actions/ Expected Results Comments
<TC_FT_5.0> <Search Books by ISBN>
Description: The purpose of this test is to test the application’s functionality of searching for books by their ISBN number, by either ISBN-10 or ISBN-13, if present. Development Phase: Final Construction. Goals: The goal of this test is to successfully find any book that it’s in Chegg’s book database, by searching for their ISBN number, by either ISBN-10 or ISBN-13, if present. Test Data: The test data for this test is a list of books that have 2 ISBN number associated with them. Test Tools: Test Startup Procedure: Test Closedown Procedure:
5. Test Case
Preconditions:
1. The ISBN number to be searched must be valid.
2. The book must be in Chegg’s database to be found.
3. The user must be in the “Chegg Study” webpage.
Test Steps:
1. Type in the search bar the ISBN number for the book you want to find.
2. Hit “ENTER”
Expected Results:
1. Chegg’s website should show the first few relevant results below the search bar, right after
the user types the ISBN number (before pressing “ENTER”).
2. If the ISBN number is valid, a new webpage should load, showing the book that corresponds
to that ISBN. Additionally, that webpage of the book would show the book’s information and the
buy/rent options too.
3. If the ISBN number is not valid, a new webpage should load, saying that the application was
not able to find that ISBN number.
• Chegg’s website must have that book in its
database to be searchable
by an ISBN number.
• Chegg’s database must have at least the ISBN-13
number for all their
books, since some books
just don’t have an ISBN-
10 number associated
with them.
User Actions/ Expected Results Comments
<TC_FT_6.0> <Search Books by Title>
Description: The purpose of this test is to test the application’s functionality of searching a book by its title. Also, this test should test if given a partial title (word contained in the original title), the application can return a list of books that match that word. Development Phase: Final Construction. Goals: The goal for this test is for the application to be able to find a book by its full title and find several books by one word or more that are in their title. Test Data: The test data is a list of books with titles. Test Tools: Test Startup Procedure: Test Closedown Procedure:
6. Test Case
Preconditions:
1. The book’s title to be searched must be valid.
2. The book must be in Chegg’s database to be found.
3. The user must be in the “Chegg Study” webpage.
Test Steps:
1. Type in the search bar the title of the book you want to find.
2. Hit “ENTER”
Expected Results:
1. Chegg’s website should show the first few relevant results below the search bar, right after
the user types the book’s title (before pressing “ENTER”).
2. A new webpage should load, showing a list of books that match the words typed in the search
bar. Even if there are no books with those words in their title, there could still be some book
results showing in the webpage, due to automatic author search (if the words typed match with
any author name).
User Actions/ Expected Results Comments
<TC_FT_7.0> <Search Books by Author>
Description: The purpose of this test is to test the application’s functionality of searching a book by its author. Also, this test should check if given an author, the application can return a list of books that have that author. Development Phase: Final Construction. Goals: The goal for this test is for the application to be able to find all the books that have that author. Test Data: The test data is a list of books that have at least one author associated with each of them. Additionally, more than one book would need to share the same author. Test Tools: Test Startup Procedure: Test Closedown Procedure:
7. Test Case
Preconditions:
1. The book’s author to be searched must be valid.
2. The book must be in Chegg’s database to be found.
3. The user must be in the “Chegg Study” webpage.
Test Steps:
1. Type in the search bar the author of the book you want to find.
2. Hit “ENTER”
Expected Results:
1. Chegg’s website should show the first few relevant results below the search bar, right after
the user types the book’s title (before pressing “ENTER”).
2. A new webpage should load, showing a list of books that have that author in common. Even if
there are no books associated with that author, there could still be some book results showing in
the webpage, due to automatic book title search (if the words typed match with any book title).
User Actions/ Expected Results Comments
<TC_FT_8.0> <Bookmark Question>
Description: The purpose of this test is to test the application’s functionality of bookmarking a question (book question and expert Q&A). Additionally, the application should store the bookmarked questions of that user for later. Development Phase: Final Construction. Goals: The goal for this test is to make sure that a registered user can bookmark any of the 2 possible questions (book question and expert Q&A) and that he or she can later see in their account the bookmarked questions, with a link to the question webpage. Test Data: The test data is a list of questions from expert Q&A and from books. Test Tools: Test Startup Procedure: Test Closedown Procedure:
8. Test Case
Preconditions:
1. The user must be registered in Chegg.
2. The user must have the Chegg Study membership.
3. The user must be in the question webpage.
Test Steps:
1. Click on either the bookmark logo or the word “Bookmark”, next to the question.
Expected Results:
1. When the user clicks on “Bookmark”, the website should update the “Bookmark” icon to
orange color and update the text to “Bookmarked”. Additionally, it should update the counter of
bookmarks inside the parenthesis too (only for Q&A questions). Furthermore, it should save that
question to either bookmarked book question or bookmarked Q&A question, depending on
where it belongs.
2. If the question is already bookmarked, then the website should update the “Bookmark” icon
to gray color and update the text to “Bookmark”. Additionally, it should update the counter of
bookmarks inside the parenthesis too (only for Q&A questions). Furthermore, it should delete
that question to either bookmarked book question or bookmarked Q&A question, depending on
where it belongs.
3. If the question is already bookmarked and it’s a Q&A question, then whenever the user puts
their mouse cursor on top of the “Bookmark” logo or text, they should see a little menu pop
below it. That menu should show 2 options: “Rate the answer” and “View all your saved
questions”. These options should have one link each that allows the user to do what it’s saying in
them. If the question is not bookmarked, then it shouldn’t display anything when the mouse
cursor goes on top of it.
User Actions/ Expected Results Comments
<TC_FT_9.0> <Rate Solution>
Description: The purpose of this test is to test the application’s functionality of rating a solution (book solution and expert Q&A solution). Additionally, the application should be able to remember your solution ratings. Development Phase: Final Construction. Goals: The goal for this test is to make sure that registered users can rate any solutions (book solution and expert Q&A solution). Test Data: The test data is a list of mixed solutions from both books and expert Q&A. Test Tools: Test Startup Procedure: Test Closedown Procedure:
9. Test Case
Preconditions:
1. The user must be registered in Chegg.
2. The user must have the Chegg Study membership.
3. The user must be in the question webpage.
Test Steps:
1. Click on the “thumbs up” or “thumbs down” button, right next to the solution/answer you
want to rate.
2. If you clicked in the “thumbs down” button, select one of the 3 reason why the question was
not helpful or select “Other” and write your own reasons.
3. Click “SUBMIT” to submit your answer or click on “Cancel” to cancel the “thumbs down”
process.
Expected Results:
1. Only by putting the mouse cursor on top of the button, it should pop up a little text box
showing a message below the button. Additionally, it should shade the button with a gray color,
to show the user that it’s a button. For the “thumbs down” button, it should say “Sorry!
Sometimes we make mistakes. Let us know so we can fix it.”. For the “thumbs up” button, it
should say “Sweet! Glad to be of help!”.
2. When clicking the “thumbs up” button, the website should update the thumbs up counter (n +
1) and the button to a green color. When clicking the “thumbs down” button, the website should
drop a little menu below the button that you can choose the reason why the answer was not
helpful. By choosing any option in that menu, the menu should draw a green checkmark next to
the option you selected, allowing you to click on “SUBMIT”. After submitting the “thumbs down”
request, the website should update the counter (n – 1) for that and update the button to the red
color.
User Actions/ Expected Results Comments
<TC_FT_10.0> <Report User Question>
Description: The purpose of this test is to test the application’s functionality of reporting a question made by another user. Development Phase: Final Construction. Goals: The goal for this test is to make sure that a registered user can report other user’s questions and that those reports get received by the application server. Test Data: The test data is a list of questions made by different users. Test Tools: Test Startup Procedure: Test Closedown Procedure:
10. Test Case
Preconditions:
1. The user must be registered in Chegg.
2. The user must have the Chegg Study membership.
3. The user must be in the question webpage.
Test Steps:
1. Click on the little flag logo that is right next to the “Bookmark” button.
2. Select one of the 2 reasons to why you are reporting the abuse or select “Other” and write
your own reasons.
3. Click on “REPORT ABUSE” to submit or click on “Cancel” to cancel the report process.
Expected Results:
1. When putting the mouse cursor on top of the flag logo, the website should update the flag’s
color to red (while the mouse is on top of it).
2. After clicking on the logo, it should drop a little menu that you select what type abuse you are
going to report.
3. After choosing one of the options, the menu should draw a green checkmark right next to the
option you have selected, allowing you to then click on “REPORT ABUSE”.
4. After submitting the request, the application should send that request to its report server,
with the information that the user provided.
User Actions/ Expected Results Comments
<TC_FT_11.0> <Pause Subscription>
Description: The purpose of this test is to test the application’s functionality of pausing a subscription that a user currently has. Development Phase: Final Construction. Goals: The goal for this test is to make sure that the user can pause his or her subscription at any time and not be billed while the membership is paused. Test Data: The test data is a list of different fake users that use different methods of payment each one. The methods of payment of each one of them would also be fake. Test Tools: Test Startup Procedure: Test Closedown Procedure:
11. Test Case
Preconditions:
1. The user must be registered in Chegg.
2. The user must be subscribed to a Chegg membership.
3. The user must be in the Account Overview webpage.
Test Steps:
1. Click on “PAUSE SUBSCRIPTION”.
2. Select the amount of time you want your subscription to be paused (from 1 month up to 6).
3. Click on “PAUSE SUBSCRIPTION” to submit the request or on “GO BACK” to cancel the request.
Expected Results:
1. After clicking in “PAUSE SUBSCRIPTION” in step 1, it should pop up a menu asking for the
amount of time you want your subscription to be paused.
2. By clicking in “PAUSE SUBSCRIPTION” again in step 3, the menu should disappear, the pause
request should be sent to the subscription server, and the subscription section in your Account
Overview webpage should show that the subscription is paused.
3. By clicking in the “GO BACK” button, the menu should disappear and the pause request should
be canceled.
4. After the request is sent to the server, the user shouldn’t be billed monthly anymore for the
subscription until the pause period is over, unless he or she resumes the subscription again
(unpause).
User Actions/ Expected Results Comments
<TC_FT_12.0> <Cancel Subscription>
Description: The purpose of this test is to test the application’s functionality of canceling a subscription that a user currently has. Development Phase: Final Construction. Goals: The goal for this test is to make sure that a registered user can cancel his or her subscription at any time, and by consequence, not be able to access the subscription features. Additionally, the application should take him or her out of the automatic billing list, since he or she is subscribed to that service anymore. Test Data: The test data is a list of fake registered users that have multiple subscriptions with different fake methods of payment, to test if the application can take care of all different automatic methods of payment. Test Tools: Test Startup Procedure: Test Closedown Procedure:
12. Test Case
Preconditions:
1. The user must be registered in Chegg.
2. The user must be subscribed to a Chegg membership.
3. The user must be in the Account Overview webpage.
Test Steps:
1. Click on “Cancel subscription”
2. Select one of the 6 available options to indicate why you are canceling your membership and
click on “CONTINUE” or select “Other” and write your own reasons and click on “CONTINUE” or
click on “Skip” to skip this step.
Expected Results:
1. After clicking on “Cancel subscription” in step 1, the application should load a new webpage
and prompt you to select one of the reasons you are canceling the membership.
2. If the user clicks on “CONTINUE” the application should check whether he or she filled the
reason of the subscription canceling, preventing the user to continue. If he or she already filled
that part, then the application should send the request to the server and open a new webpage
showing success.
3. If the user clicks on “Skip” the application should skip this part and continue with the
canceling process. Additionally, the application should send the request to the server and open a
new webpage showing success.
4. If the canceling process proceeds successfully, then the application should take that user’s
payment method out of the application’s automatic billing list and update the Account Overview
webpage showing if you want to buy the subscription you just canceled.
User Actions/ Expected Results Comments
<TC_FT_13.0> <Subscribe to Service>
Description: The purpose of this test is to test the application’s functionality of subscribing to a service (Chegg Study membership or Chegg Tutors membership). Development Phase: Final Construction. Goals: The goal for this test is to make sure that a registered user can subscribe to a service, and thus have access to the subscription features, such as access to textbook solutions (Chegg Study). Test Data: The test data is a list of fake registered users that have either fake credit cards registered in their Chegg account or no credit crads at all. Test Tools: Test Startup Procedure: Test Closedown Procedure:
13. Test Case
Preconditions:
1. The user must be registered in Chegg.
2. The user must not be already subscribed to the Chegg membership that he or she wants to
subscribe.
3. The user must be in the Account Overview webpage.
Test Steps:
1. Click on “SUBSCRIBE” on either Chegg Study or Chegg Tutors membership.
2. Select if you want to use a credit card that already is defined in your Chegg account, or select
to use a new credit card or click on the PayPal button to buy the service with your PayPal
account.
3. If you selected to use an already defined credit card, then click on “START MEMBERSHIP”. If
you selected to add a new credit card, then fill your credit card information and click on “START
MEMBERSHIP”. If you clicked on the PayPal button, then enter your PayPal’s login and password
and click on “Log In”.
4. If you are still paying with PayPal, then select a credit card from your list of credit cards in your
PayPal account or add a new credit card with its billing address.
• After subscribing to any
of the 2 Chegg services,
the user must be able
to fully access the
features provided by
that service,
immediately.
5. Click on “Add” if you chose to type a new credit card and billing address, or click on one pre-
existent credit card that is displayed there.
6. Click on “CONTINUE”.
7. Click on “START MEMBERSHIP”.
Expected Results:
1. After clicking “SUBSCRIBE” in step 1, a new webpage should load, showing you 3 options to
subscribe to the Chegg service.
2. The option of using an already defined credit card should be selected by default. If you select
to add a new credit card, then the website should pop up a text input box below that option, in
which you can put your credit card information there. If you click in the PayPal button, you
should be redirected to new PayPal webpage in a new tab.
3. After the login in PayPal, you should be redirected to a new PayPal webpage where you can
select to add a new credit card or just select an existent credit card from your account.
4. After clicking on “CONTINUE” in step 6, you should be redirected to a Chegg webpage showing
you the button “START MEMBERSHIP”.
5. After clicking on “START MEMBERSHIP” in step 7, you should be redirected to your Account
Overview page in the Chegg’s website, showing that you are already subscribed to that service.
User Actions/ Expected Results Comments
<TC_FT_14.0> <Create a Student Account>
Description: The purpose of this test is to test the application’s functionality of creating a user account. Development Phase: Final Construction. Goals: The goal for this test is for a person to be able to create an account in Chegg’s website. Test Data: The test data is a list of fake unused emails and fake used emails to create an account, different types of passwords (small, long, Chinese characters, numerical, mixed, text, etc), and real college names. Test Tools: Test Startup Procedure: Test Closedown Procedure:
14. Test Case
Preconditions:
1. The user must not be registered already or be logged out at the moment of creating a new
account.
2. The user must be in the Chegg’s “create account” page.
Test Steps:
1. Select the option “Student” to create a student account.
2. Type an email that is not already in the system (associated with another account).
3. Type a password that follows these rules: at least 6 characters, upper and lower case letters,
and at least one number or punctuation.
4. Click in one of these 2 options: “I’m in college” or “I’m in high school”.
5. If you selected “I’m in college”, then type your college name and select what year you are in
college. If you selected “I’m in high school”, then select what year are you graduating.
6. Click on “CREATE ACCOUNT” button.
Expected Results:
1. If you typed an email that is already registered, then a red message should appear under the
email field saying that the email typed is already registered in the system.
2. When you start typing your password, you should see the password rules (at least 6
characters, upper and lower case letters, and at least one number or punctuation) below the
password field, being check marked according to what you are typing. If all the rules are met,
then it means you have a valid password to use.
3. In step 4, if you select “I’m in college”, then the website should show an input box for you to
type the name of your college. As you type the name of your college, college names that match
what you typed should appear right below that input box. If your college is listed in their
database, then the website should display 5 buttons for the years you are in college, right below
the college name input box.
4. In step 4, if you select “I’m in high school” either one of 4 options, corresponding to what year
you are graduating. The last option “Other”, once pressed, should pop an option box showing
more 4 graduation dates.
5. After clicking on “CREATE ACCOUNT”, the server should register that user in their database,
send an email to that new user, and login that user in the website.
User Actions/ Expected Results Comments
<TC_FT_15.0> <User Login with Email>
Description: The purpose of this test is to test the application’s functionality of any user to login in Chegg’s website using their email and password. Development Phase: Final Construction. Goals: The goal for this test is to make sure that a registered user can login successfully to his or her account, by using email and password. Test Data: The test data is a list of fake registered emails with right and wrong passwords. Test Tools: Test Startup Procedure: Test Closedown Procedure:
15. Test Case
Preconditions:
1. The user must be logged out.
2. The user must be in the Chegg’s login page.
Test Steps:
1. Type the email of that account.
2. Type the password of that account.
3. Click on “SIGN IN”.
Expected Results:
1. After clicking in “SIGN IN”, the website should authenticate that user by the email and
password typed earlier and either login them in the website or display a red error message
saying that the email and password combination is wrong.
User Actions/ Expected Results Comments
11 FEATURES NOT TO BE TESTED The below features won’t be tested because the PMO restricted the budget for the
testing team, and consequently only the features with high priorities will be tested.
Additionally, some of the following features have already been tested before.
1. Find textbook solutions
2. Find an online tutor
3. Message tutors
4. Request a written lesson from a tutor 5. Post study questions
6. Comment on posted solutions
7. Rent books
8. Sell books
9. Get quotes on books you want to sell
10. Purchase test prep services (SAT and ACT)
11. Find internships online (through another website provided by Chegg) [a Chegg
service though]
12. Find colleges in US. Also provide information of them. 13. Rate tutors
14. Browse through the entire textbook solutions by its chapter and exercises
15. See orders
16. Edit account
12 RESOURCES/ROLES & RESPONSIBILITIES The tester Chief will manage the testing team and the testing procedures. The developer Chief will manage the developer team and their work through the construction phase, especially. The business expertise will be orienting both tester and developer Chiefs to make sure that the application’s scope doesn’t change throughout the project. Additionally, the business expertise will make sure that the project remains in the right business context. The PMO, the developer Chief, and the tester Chief will be the only ones with access to the Defect Tracking Log. Which means that all the modifications will either need to go through one of them, or they will give a temporary
access to either the developer or the tester for them to add a new defect or code
earmark. The PMO will be the one monitoring the budget at all time, to make sure everything goes alright according to the plan. Any changes in the budget will be addressed by him with the help of the business expertise, which later will then notify the other members of the project team.
13 SCHEDULES The main deliverable documents will be delivered in the schedule provided by the
PMO. The documents will be the following: • Test Plan • Test Cases • Test Incident Reports • Test Summary Reports • Project Charter • High Level Requirements • Software Requirement Specification • Defect Tracking Log (with code earmarks table) • Defect Backlog
14 SIGNIFICANTLY IMPACTED DEPARTMENTS The significantly impacted departments for this test plan will be the PMO
department and business department, since they will manage everything that goes on the project. Since the developer team and the tester team are dependent on the PMO and the business expertise, they won’t be accounted as significant impacted departments.
15 DEPENDENCIES The main constraint in this testing plan will be the budget. Even though there will
be some features and some functionalities of Chegg that will have some limitation in its testing, the main limitation of the test plan is the budget. Regarding time and schedule, the project is fine; the stakeholders are very flexible with the schedule since they care more about the final look of the application.
Some functionalities of Chegg, like “Browse through the entire textbook solutions
by its chapter and exercises”, will be hard to test since it will require better test tools than the ones the test team already has; and since the budget is low, we either test more functionalities using three cheap test tools, than test a little set of functionalities using only one expensive test tool.
16 RISKS/ASSUMPTIONS In this test plan, we will have to assume possible risks that we may have
throughout the development of the application. Although there are some high-risks
in the table below, their contingency plan is simple to execute.
No. Risk Likelihood of
Occurrence
Impact Priority Contingency Plan
1. Delay in
delivery
4 4 16 The testing team and
developer team will have
to work additional hours
per week or over
weekends to finish the
project in time
2. Low budget for
testing
3 5 15 The PMO will have to cut
costs of some parts of
the application or
prioritize the testing
procedures according to
the budget
3. Lack of
documentation
3 2 6 The developer Chief will
need to make sure that
its team is documenting
everything in every
inspection review and
the developer team will
need to spend more time
per week to document
every change they make
in the code
4. New language
being used
1 4 4 The developer Chief will
need to meet their
developer team and
switch the whole project
to an old language that
they are more
familiarized with
17 TOOLS
Since the budget of the project is low, we will have to use cheap automated test tools, which also include free test tools as well. The main requirements for them will be to have some essential features that the test team already defined:
• Foreground Touchpoint
• Background Touchpoint
• Test Script Library Management
• Test Execution Harness Management
• General Test Management (for actual expected vs. actual values comparison)
Although the automatic test tools below don’t have every feature defined by the test team, they have some other helpful features built in them, and they will be the initial test tools used by the test team:
• Jenkins o Automatic integration with Git functionalities o Integration with automated build tools o Wide variety of supported languages o Automatic code reports with information regarding bugs, code smells,
memory leaks, code reliability, code duplications, code complexity, and general code information (number of functions, lines, classes, statements, etc)
o Automatic bug tracking functionality
• Telerik o Easy script language to build test scripts o Ability to test web based applications on multiple web browsers o Automatic successful messages when the test cases are successful o Foreground Touchpoint o Test Execution Harness Management o Test Script Library Management
• WebLoad o WebLoad IDE integration
o Foreground Touchpoint o Background Touchpoint o Automatic performance reports o Test Execution Harness Management o Test Script Library Management
APPROVALS Name (In Capital Letters) Signature Date 1. 2. MARK DAUSCH 3. (PMO) 4. (developer Chief) 5. (tester Chief)