My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
TestCase  

testplan
Updated Feb 4, 2010 by decrip...@gmail.com

Test Plan

Scope

A test plan for the cs2450 library simulator team.

References

The Project home
The Product wiki
The Project source
The Project bugs
The Project downloads

QA Meetings

No meetings scheduled

Definitions

.NET C#---(pronounced "C Sharp") is an object-oriented programming language developed by Microsoft Corporation as part of their .NET initiative in response to the success of Sun Microsystems' Java programming language. C# source code—as well as those of other .NET languages—is compiled into an intermediate byte code called Microsoft Intermediate Language (MSIL).

SQLite---SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine.

Test plan

Purpose

This document is a comprehensive test strategy to be used by testers to ensure proper and exhaustive testing. It also acts as a reference for all stakeholders wishing to obtain information on current and past testing efforts.

Outline

Test plan identifier

The purpose of this section is to identify the current and previous versions of the test plan, its level, and the version of software it pertains to. {| class="wikitable" border="1" style="text-align:center" |- ! ID ! Level ! Software Version ! Modify Time ! Author |- | Librarysim-TP-V0.1 | Draft | N/A | 04-01-2009 | Stephen |- | | | | | |- | | | | | |- | | | | | |- |}

Introduction

Testing efforts will be related to the project goals, which are:

Create a system that managers patrons, books, and media. Be able change dates

This plan includes integration, system, and acceptance testing.

Integration testing to be completed in 2009.

System testing will be performed in 2009.

Acceptance testing will be performed later in 2009 before the product is released. During system testing, the product should be tested in its entirety from the end user's point of view.

Test items

According to the project plan, test items is below:

Test Components: {| class="wikitable" border="1" style="text-align:center" |- ! Test Items ! Priority(S1/S2/S3) ! Schedule |- | X | S1 | |- | Y | S1 | |- | Z | S1 | |- | | S1 | |- | | S1 | |- |}

Software risk issues

''This section describes any risks resulting from lack of time and/or resources.'' frequent changes to requirements and/or design. loss of time

Features to be tested

''Abstraction of test items. What will be tested from the user or customer point of view.''

Database

X

UI
Check in
Check out
Patrons

Add a patron Remove a patron

Features not to be tested

''Any features that will not be tested and why. Decisions not to test a feature should be based on priority and risk. If a feature will not be tested, define what features (class, methods, properties) will not be tested.''

At this time we plan to test all features exhaustively.

Approach

''A description of how and where testing will be performed and explain any issues that have a major impact on the success of testing and ultimately on the project.''

General Guidelines

Tests shall be automated whenever possible. Time constraint is not a good excuse not to automate.

Test plan will be developed using the IEEE Std. 829-1998 Standard for Software Test Documentation.

All bugs shall be logged in Issues at the time they are found.

When a bug's status is changed to VERIFIED in Bugzilla, the reporter of the bug should change the bug's status to CLOSED or reopen the bug as soon as possible. If the person who reported the bug verifies the bug, the bug can be closed without having its status changed to VERIFIED. A bug should not be closed by someone who did not report the bug unless the reporter is unavailable.

Types of system testing include function, performance, security, load, reliability, usability, documentation testing.

Acceptance criteria for patch acceptance: Before a patch is accepted, a QA engineer must ensure that the patch submitted from developer passes QA testing. A build engineer must ensure the patch builds properly and meets packaging standards. QA and build engineers will then create a patch acceptance report, and the patch can be included in the product.

Testers may perform system testing on the product only after development has verified that they have completed a development milestone and the build team has created a stable release.

No regularly scheduled meetings at this time

Minor editing (grammar and spelling corrections) of this test plan can be done at any time. Any change to the test plan that changes how the product will be tested shall be approved by the QA team who will determine if the changes are large enough to require a change to the test plan identifier.

Black box and white box testing methods are both acceptable. However, it is anticipated that black box testing will be the norm.

Integration testing will involve the iterative testing of new developer code as it becomes available and it is integrated into the product. System testing will begin after provider and client pieces has been implemented and released.

Exit criteria has yet to be established. This should be discussed with project management.

Item pass/fail criteria

The pass/fail criteria for each of the items described in Test Items section.

Criteria for Test Components: {| class="wikitable" border="1" style="text-align:center" |- ! Test Items
! Pass ! Fail |- | | ? | |- | | ? | |- | | ? | |- | | ? | |- | | ? | |- | | ? | |- |}

Individual test case pass/fail criterion is defined by the automated script which performs the testing. Upon failure of a test case, the script should will log the failure.

Suspension criteria and resumption requirements

Suspension criteria: Unavailability of external dependency during execution. When a defect is introduced that cannot allow any further testing (i.e., a blocker bug). Critical path deadline is missed so that the client will not accept delivery even if all testing is completed. A specific holiday shuts down both development and testing. Lack of testing resources (e.g., testers, hardware, etc).

Resumption requirements: When the external dependent systems become available again. When a fix is successfully implemented and the testing team is notified to continue testing. The contract is renegotiated with the client to extend delivery. The holiday period ends. Testing resources become available

A failed build would not constitute suspension as we could generally continue to use the previous build. Major or critical defects would also not constitute suspension as other areas of the system could continue to be tested.

Test deliverables

''All documents, tools, and other components that are to be developed and maintained in support of the testing effort'' Test plan (this document) Test cases - none at this time Custom tools - test harness, test scripts, sample applications Defect reports - none at this time Test summary reports - none at this time Other - none at this time

Testing preparation and setup

''set of tasks necessary to prepare for and perform testing''

Team Setup: {| class="wikitable" border="1" style="text-align:left" |- ! Task
! Finished |- |Obtain testable build |X |- | |X |- | |X |- | |X |}

X = Done P = In Progress

Individual Preparation: Create a google account Install VS and/or monodevelop Install most recent .NET and/or Mono

Environmental needs

''Hardware, software, data, interfaces, facilities, publications, other requirements that pertain to the testing effort''

Testing may be done on physical and virtual machines.

All tests must be performed on the most recent official release of the following platforms:

{| class="wikitable" border="1" style="text-align:center" |- ! ! x86 ! x86_64 |- | windows | X | X |- | openSUSE | X | X |- | | | |}

Hardware: No specific hardware requirements at this time

Software: .NET or Mono - most recent release VS or monodevelop

Responsibilities

All testers can work wherever they are needed, however, below is where our team focuses their efforts at this time:

'''X Tests:''' team-member1 '''Y Tests:''' team-member2 '''Z Harness:''' team-member3

Staffing and training needs

QA Engineer (3) Solid programming experience (C#) QA Engineer experience

Schedule

{| class="wikitable" border="1" style="text-align:left" |- ! Task ! Start Time ! End Time ! Owner |- | Design test plan | Apr. | Apr. | Stephen & |- | | Apr. | Apr. | |- | | Apr. | Apr. | |- | | Apr. | Apr. | |- | | Apr. | Apr. | |- |}

Risks and contingencies

''Any activity that jeopardizes the testing schedule is a planning risk'' Program release schedule delay will jeopardizes testing schedule Program quality of release version couldn't satisfy with acceptance criteria Test environmental stuff unobtainable easily Delays in necessary QA training (e.g., understanding what needs to be tested, writing sample applications, test tools, and automation scripts) Tester staff change or lack of tester resources Changes to the original requirements or Designs Frequent program design changes

Approvals

''Persons who declare that the software is ready to move to the next stage''

User 1
User 2
User 3

Powered by Google Project Hosting