Home : Project Tracker Documentation : 3. For Developers : 3.7. Test Cases 

3.7. Test Cases

Table of Contents

3.7.1. Installation
3.7.2. Initialization
3.7.3. Setting parameters
3.7.4. Permissions
3.7.5. Dimensional sliders and anchor tags
3.7.6. Basic creation
3.7.7. Submitting addition
3.7.8. Task Assignment
3.7.9. Modifying task states in PT
3.7.10. PT WF synchronization after task is started
3.7.11. Revision History

Test cases for Project Tracker web interface. PL/SQL API tests are included in the /project-tracker/sql/tests directory. These tests require utPL/SQL, which can be obtained from here. The tests here requires that the PL/SQL tests were successful.

3.7.1. Installation

Goal

Installing Project Tracker

Scope

Data model

Case Triggers

  • Install Project Tracker using the APM from the file system

  • Install Project Tracker from the package repository

Primary Actors
  • Site Administrators

Secondary Actors
  • None

Preconditions
  • Project Tracker files must be in .apm format

  • Project Tracker must be entered in the repository

Success End Conditions

  • Installation is successful, there are no error messages logged

Failure End Conditions

  • Installation is not successful, error messages are logged

Case Description

This is the very first step towards using Project Tracker, all other tests are futile if this is not successful.

3.7.2. Initialization

Goal

Initializing Project Tracker

Scope

Web interface, access control. /project-tracker/www/admin/initialize

Case Triggers

  • User mounts PT in a subsite and goes to the url, enters plain text info.

Primary Actors
  • Subsite administrators

Secondary Actors
  • The general public

  • Users with write permission

  • Users with read permission

Preconditions
  • PT is test-installation

  • PT is mounted and permissions are set in the site-map for the different classes of users.

Success End Conditions

  • The only page available to the user is /project-tracker/www/admin/initialize

  • Only admin users can access this page

  • Only logged in users can access this page, if user is not logged in, they are redirected

  • Once initialization is complete, users cannot access this page

  • When the information is submitted, DML is performed and user is redirected to the admin/index page where they can set parameters for PT or begin working on their project.

Failure End Conditions

  • /project-tracker/www/admin/initialize is not available

  • Users without admin privilege can access the page

  • Users that are not logged in can access the page

  • The admin/initialize page can be accessed multiple times after the page is initialized

  • The user is not redirected to admin/index

Case Description

Test for the web interface for calling pt_project.new. Because there is only one root task per PT instance, this page should be accessible only once, and it should be the first page available to the user.

3.7.3. Setting parameters

Goal

Setting parameters for Project Tracker

Scope
  • admin/index

  • pt_callback

  • pt_util

  • project-tracker.info

  • permissions

Case Triggers

  • Attempt to set parameters for PT

Primary Actors
  • Admin users

Secondary Actors
  • Users with write permission

  • Users with read permission

  • Users that are not logged in

Preconditions
Success End Conditions

  • Only admin users can access the page

  • Users that are not logged in cannot access the page

  • Notification sender can be set

  • Parameters that are set is displayed

  • User can move to www/index

  • Only users with admin privilege can be set as the notification sender

Failure End Conditions

  • Users that are not logged in can access the page

  • Current parameter setting is not viewable

  • Notification sender cannot be set

Case Description

Notification sender is the from: address in the notification email. This parameter is optional and defaults to registered users. It requires that the .info file is configured correctly. pt_util get's the current notification sender from the database.

3.7.4. Permissions

Goal

Access control enforcement in Project Tracker

Scope
  • www/index

  • www/task-view

Case Triggers

  • User with admin privilege accesses the page

  • User with write privilege accesses the page

  • User with read privilege accesses the page

  • User that is not logged in accesses the page

Primary Actors
  • Admin users

  • Users with write permission

  • Users with read permission

  • General public with admin/read permissions

Secondary Actors
  • none

Preconditions
Success End Conditions

  • read users can only see the read-only view. Links to default view and admin views are not available. Only name, description, and state are displayed. There are no links available in the task list.

  • Write users have the option to see the read-only view, but not the admin view. They can access task specific information. Links in the task list are active: edit, add, move, assign links are available.

  • Admin users have the option to see the read-only, default, and admin views. They can access specific task information. Links in the task list are active: edit, add, move, assign links are available.

  • General public with write/admin permissions can view the read-only view. Links to default and admin views are active, however, when these links are requested, they are asked to log in

Failure End Conditions

  • Modification links are available to the general public and attempt to modify information results in Oracle error.

Case Description

PT's response to user privileges. The worst case is if General public can access the data manipulation options which would result in an Oracle error.

3.7.5. Dimensional sliders and anchor tags

Goal

Ease of navigation by preserving URL query strings (page parameters)

Scope
  • www/index.tcl

  • Any other page that redirects to index

Case Triggers

  • User sets parameters for the task-list display that is different from the default

  • Task list is modified, and user is redirected back to the task list after modification. The parameters stays constant.

Primary Actors
  • Users with write permissions and more

Secondary Actors
  • none

Preconditions
Success End Conditions

Since these parameters are cached, you need to sign off to check these. Also check for #number at the end of the url string for the anchor tags. Possible actions that user can execute:

  • Add/Edit (form, DML)

  • Move (target link, DML)

  • Delete/Reactivate/Drop

  • Suspend/cancel/resume

  • Assignment: Check for regular quick link assignment,search, search not found, and search again.

  • Zoom

  • Notify

The page parameters should be persistent through the above transactions

Failure End Conditions

  • Parameters are lost and user is redirected to index page without url query string

Case Description

  • Add/Edit (form, DML) [ok]

  • Move (target link, DML) [ok]

  • Delete/Reactivate/Drop [ok]

  • Suspend/cancel/resume [failed for resume, typo fixed]

  • Assignment (panel, DML) [ok]

  • Zoom [not sticky about view types?]

  • Notify [ok]

3.7.6. Basic creation

Goal

Creating a task in project tracker (form generation in task-list)

Scope

primary task

Case Triggers

  • User clicks on "add" link to create a task

Primary Actors
  • User (requires write access)

Preconditions
  • Add link must be available via the UI

Success End Conditions

  • Blank web form is visible in the correct location

  • Web form is indented properly

  • Previously set page parameters (level, detail, dropped/not dropped) are preserved

  • Default view link becomes active, and can be used to get out of the add mode

  • If level is set to the same level as the parent task, the level is automatically increased by 1 to bring other tasks in the same level as the task being added into view

Failure End Conditions

  • Web form does not appear

  • Web form appears but is not visible and requires scrolling to find it

  • Web form appears in the incorrect position

  • Web form is not indented to the same level as the parent task

  • Previously defined view options (level, detail, dropped/not dropped) are lost when web form appears

  • Default view link is grayed out and is not active

Case Description

Test for entering add mode in the task list.

3.7.7. Submitting addition

Goal

New task data is entered into the database

Scope

DML into PT task and redirection

Case Triggers

  • User enters information into the add form and submits form

  • Try html and plain text

Primary Actors
  • User with write permission

Secondary Actors
  • None

Preconditions
  • Task form generation * i want an anchor reference here...

Success End Conditions

  • A new task is created as a subtask of the spawning task

  • The redirected page should have the new task visible within the screen without scrolling

  • Page parameters (level, detail, dropped/all) are preserved

  • Under the view option default view is no longer active (grayed out)

  • If the spawning task was a child task, it is now a parent task and is displayed in bold

  • If the spawning task was a child task, it becomes a parent task. Estimate, deadline, and workflow case information are deleted. NB. PL/SQL API, tested in utPL/SQL

Failure End Conditions

  • The new task is not displayed as a subtask of the spawning task (must be under the spawning task, and indented one level)

  • It is difficult to find the newly created task

  • Page parameters are not preserved

  • Default view link is still active

  • If the spawning task was a leaf task: spawning task is not in bold

  • If the spawning task was a leaf task: spawning task still has attributes unique to leaf tasks (estimate, deadline, state) NB. PL/SQL API, tested in utPL/SQL

Case Description

Basic creation and transition from parent task to child task

3.7.8. Task Assignment

Goal

Users with the right permissions can be assigned to a task

Scope

Assignment panel (www/assignment-panel)

Case Triggers

  • User tries to assign a leaf task

Primary Actors
  • Team members/admins

Secondary Actors
  • Users with write permission

  • Users with read permission

  • Users that are not logged in

Preconditions
Success End Conditions

  • There is a list of assignable users (users with write permission) to choose who to assign

  • If the number of possible assignees are greater than 10, there is a search box and it works.

  • After the search there is an option to search again

  • Searching for more than one word (like "Nobuko Asakai")

  • Searching for a non existent user (maybe Minnie Mouse) returns a no match found message and another opportunity to search.

  • Putting sql fragments in the search box (should be rejected)

  • Assignment takes effect and is viewable on the task list

Failure End Conditions

  • Assignment is not successful

  • Object 0 (root context) is one of the options

  • General public is one of the options

Case Description

Test for setting assignments for a task. Should not be able to assign General public as this includes users that are not logged in. Assignment panel has a constraint added to not include object id's 0 and -2

3.7.9. Modifying task states in PT

Goal

Task modifications in PT is in sync with task description in Workflow.

Scope
  • data model: pt_task, pt_util, pt_callback, pt-workflow-create.sql

  • index.tcl, task-view.tcl

Case Triggers

User alters leaf task states editing task attributes after notification is complete (workflow case is started)

  • Edits task estimate and deadline

  • Cancels case

  • Resumes case

Primary Actors
  • Write users

Secondary Actors
  • Users with write permission

  • Users with read permission

  • Users that are not logged in

Preconditions
Success End Conditions

  • Estimate and deadline are the same in PT and workflow

  • Tasks appears as cancelled in wf, when it is cancelled in PT

  • Tasks appears as active (resumed) when it is resumed in PT

Failure End Conditions

  • PT and WF are not in sync

Case Description

Ensuring that PT and WF are in sync. This is related to the interface between PT and WF. The same should be repeated by changing states in WF and confirming synchronization in PT.

3.7.10. PT WF synchronization after task is started

Goal

Ensure that PT and WF continues to stay in sync after task is started, especially after workflow task is canceled and and resumed.

Scope

PT WF interface, .tcl page query

Case Triggers

  • Task is assigned and notification is sent.

  • Assignee "starts" the task in workflow, then cancels it (NB. not the cancel case option)

Primary Actors
  • Assigned users

Secondary Actors
  • Users with write permission

  • Users with read permission

  • Users that are not logged in

Preconditions
Success End Conditions

  • PT display returns to "needs to be started"

  • When the task is started, it is displayed as needs to be completed, and task cancel option is also available

Failure End Conditions

  • State display does not reflect changes in WF

  • As new wf tasks are created in response to cancellation, duplicate assignments are displayed.

Case Description

When a task gets canceled in wf, wf creates a new instance of the case that is labeled enabled, and leaves the canceled task behind. The correct wf_task must be queried and displayed to show useful information.

3.7.11. Revision History

Document Revision #Action Taken, NotesWhen?By Whom?
0.1Created3/13/2001Nobuko Asakai