|
TestCase
Test PlanScopeA test plan for the cs2450 library simulator team. ReferencesThe Project home QA MeetingsNo 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). Test planPurposeThis 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. OutlineTest plan identifierThe 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 |- | | | | | |- | | | | | |- | | | | | |- |} IntroductionTesting 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. Test itemsAccording 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.'' DatabaseX UICheck inCheck outPatronsAdd 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 GuidelinesTests shall be automated whenever possible. Time constraint is not a good excuse not to automate. No regularly scheduled meetings at this time Item pass/fail criteriaThe 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 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 requirementsSuspension 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 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 ResponsibilitiesAll 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 needsQA 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 |