Skip to content

Test Plan

onTy edited this page Apr 23, 2018 · 3 revisions

Test Plan for Simple Webmail System

onTy Toom onty@artofsoftware.io

Last updated 2018-04-04

​1.​ Intro

This document is a test plan for the Simple Webmail System.

This document seeks to address:

  • Identify software under test
  • What and how to test
  • Infrastructure required for the software to run
  • Skills required to execute the tests
  • When to test
  • To whom and what to report
  • Total efforts required to complete the test
  • When to stop testing and release the software.

​1.1.​ Data

Entry Point http://onty-webmail-ruby.herokuapp.com/
Source code https://github.com/ontytoom/onty-webmail-ruby
Code for C#+Selenium automation framework https://github.com/ontytoom/Onty.SeleniumTest.Webmail
Code for Java+Cucumber+Selenium? framework https://github.com/ontytoom/onty-webmail-selenium-java
Test cases https://drive.google.com/open?id=1hxc1LASnJ_M30EnT9Xi47JCnI1yKDrufgPfumXYvEgk

​2.​ What Should be Tested

In this section I am philosophising about the functionality, with the goal of identifying all areas in which testing will be necessary.

The system consists of a series of interconnected pages.

​2.1.​ Domain Objects and Their Behavior

# Domain Object Analysis
1 Account In order to be able to use our system, each individual person will need to create him or herself an account. (Theoretically, a person can open as many accounts as he/she wishes, but the said person will need to use a different email address on each.) Once a person has an account with SWS, we call them a User.

Once account exists, the user can access SWS at any time.

Each Account contains: User name (must be unique across all Accounts) Password Full name External email address (must be unique across all Accounts)

Currently, accounts never expire.

There is currently no password reset feature.

2 User Is a Person who has an account with SWS Users can: write Messages to each other, Read each other’s accoumnt details.
3 Message A Message is arbitrary blob of text which one user sends to another user.

Each Message contains: From To Subject Text/Body

In addition, the system keeps track of: Status: read or unread In Which folder (each message is always in exactly 1 folder)

When userA sends a message to userB, 2 nearly identical yet separate copies of the message are actually created: First is placed into sender’s Sent folder Second is placed into recipient’s Inbox

User can move Messages between folders, but only his own folders (not another user’s).

Deleting messages is currently not supported.

4 Folder Folder is a container for Messages. Each folder contains 0 or more messages.

Each folder is owned by a specific user. Folders cannot be shared, so userA should never see userB’s folders.

There are 3 built in folders, which every user always has: Inbox Sent Archived

Any user can create any number of custom folders. Each folder had Name, which must be unique for this user. UserA cannot have more than 1 folder with a given name. However, this should not prevent other users from creating custom folders with any name of their choosing.

​2.2.​ Pages and Transitions

​2.2.1.​ Login Page / Logout

Both positive and negative testing.

​2.2.2.​ Account Page

Should appear after valid login.

Can be navigated to via menu Account.

Should list current user info: user name, email, number of logins, and when account was created

​2.2.3.​ Account - Password change

Should require old password to have been correctly specified.

New password is entered twice, and must match.

​2.2.4.​ Account - Users

Should display full list of current system users. Each username should be a link to user details page for that user.

​2.2.5.​ Mailbox Page

Should show how many folders user has, including system folders.

Should show a list of folders, where each name is a link to folder details page.

​2.2.6.​ Mailbox - Folders Page

Should show how many folders user has, including system folders.

Should show a table with a list of folders:

  • Folder Name, is a link to folder details page. For each folder should display

  • Folder type (system or custom)

  • Stats (total number of messages in the folder, and number of unread messages)

  • Link to Edit Folder (only for custom folders)

​2.2.7.​ Mailbox - View system folder: inbox, sent, archive

Should display messages in the said folder.

User can click Read link to view any message.

​2.2.8.​ Mailbox - View message

Message details are displayed:

  • Message ID
  • From
  • To
  • Subject
  • Text

System also knows:

  • Status: read or unread
  • In which folder, and therefore which user owns this message

​2.2.9.​ Mailbox - Send message

From name must always be current user. To name can be selected from dropdown.

User should specify some subject and text, and click Create Message. Blank may be allowed.

​2.2.10.​ Mailbox - Create custom folder

User must specify valid folder name. When user clicks Create Folder button, the system tries to create the requested custom folder. If operation was successful, the new folder should be immediately listed in the Mailbox Home.

​2.2.11.​ Mailbox - View custom folder

Should display messages in the said folder.

User can click Read link to view any message.

​2.2.12.​ Mailbox - Edit custom folder

Only rename operation is supported.

​2.2.13.​ Mailbox - Move message

User should be able to move messages among any of his/her folders, system or custom.

3.​ Conclusion

It is very unlikely that the Simple Webmail System will ever be actually used by anyone to send and receive real email. However, the principles and methodologies we use in this project are real.