post mortem and wrap up

pying828

powedeyingiXYZBankSoftwareTestPlan.docx

Home >Computer Science homework help >post mortem and wrap up

XYZ Bank Software Test Plan

Student Name: powede yingi

Software Test Plan

Project Name: XYZ Bank Software Test Plan

Purpose of Project: To prepare an effective software test plan for testing the organization software components and functionalities.

Features To Be Tested/Not To Be Tested

The features to be tested in this project include;

i. Software application units

ii. Software system

iii. Software integration

iv. Software performance and stress

v. Software user acceptance

vi. Software automatic regression

vii. Software beta requirements

On the other hand, the following feature will not be tested

i. Software batch. This feature will not be tested since it has low risk based on the previous risk assessment conducted.

Testing Pass/Fail Criteria

Feature	Pass/Fail Criteria (Pass definition)
Software application units	All test cases completed All codes covered
Software system	All test cases completed All codes covered
Software integration	All test cases completed All codes covered
Software performance and stress	All test cases completed
Software user acceptance level	All test cases completed
Software automatic regression	All test cases completed
Software beta requirements	All test cases completed

Testing Approach

Execution of this project applied the box approach. This is a hybrid method combing the two traditional approaches. White-box and black-box testing are two types of software testing methods. These two methodologies are applied in the description of tester's point of view when creating test cases. Grey-box testing is a hybrid approach to software testing methodology that can be used. The above "arbitrary distinction" among black- and white-box testing has faded somewhat as the concept of grey-box testing—which develops tests from specific design elements—has gained traction.

White-box testing verifies a program's internal structures or workings rather than the functionality that is visible to the end user. In white-box testing, test cases are created using an internal perspective of the system (the source code) and programming skills. The tester selects inputs in order to exercise code paths and determine appropriate outputs. It includes API testing, code coverage, fault injection among others.

On the other hand, black-box testing looks at the program as if it were a "black box," assessing functionality without knowing how it works inside or viewing the source code. The testers only know what the program should do, not how it should do it. Use case testing, exploratory testing, equivalence partitioning, state transition tables, among others are all examples of black-box testing techniques.

Testing Cases

This project implementation requires implementation of the following use cases;

Test Case	Test Case Description	Test Data	Expected Result	Actual Result	Pass/Fail
1	Launch application	www.google.com	Google.com	Google.com	Pass
2	Enter valid email and password	Email: [email protected] Password: ******	The password entered is incorrect, forgotten password?	The password entered is incorrect, forgotten password?	Pass
3	Login	Email: [email protected] Password: ******	Login needs to be successful	Login successful	Pass
4	Verify user settings page	N/A	User preference page should be displayed	User preference page is displayed	Pass

Testing Materials (Hardware/Software Requirements)

Hardware requirements:

i. Modems

ii. Computers

Software requirements:

i. Workstation

ii. Mainframe

iii. Operating system

Testing Schedule

Testing Activity	Duration	Resource	Comments
Test Plan Creation	5 days	Test Manager	Planning entails preparation details to carry out the identified tests
Test Specification Creation	10 days	Test Leads	This phase entail identification of specific tests to be carried out.
Test Specification Team Review	5 days	Project Team	The team is selected and reviewed by defining specific roles of each member.
Component Testing	20 days	Component Testers	Individual components are tested
Integration Testing	20 days	Component and System Testers	The integration of different components is tested.
System Testing	15 days	System Testers	The complete system is tested
Performance Testing	5 days	System Testers	The performance of the system is tested.
Use Case Validation	10 days	System Testers	All the use cases defined validated.
Alpha Testing	5 days	Product Managers/Analysts	The product release details are tested
Beta Testing/Pilot Program	20 days	Pilot Program End-Users	The end user’s capability to use the software is tested.

Risks and Contingencies Matrix

Risk	Probability	Risk Type	Owner	Contingencies/Mitigation Approach
Do not have enough skilled workers to test components as they are ready for testing.	25%	Project Resources	Testing Manager	Testing schedule will be adjusted based on available resources.
Testing team member turnover	10%	Project Resources	Testing Manager	Adjust testing schedules. Make sure testing team members are cross-trained on testing techniques in case a team member leaves the organization.
Software hacking	50%	Project resources	Security Manager	Training of end users. Implementing data and information security techniques and procedures.
Inaccurate estimations	30%	Project resources	Project Manager	Consider uncertainty while estimating Allocate duties to different team leaders. Effective communications.
End user engagement	25%	Project resources	Testing Manager	Ensure end users are involved in all necessary phases of the project.
Poor quality code	8%	Project resources	Testing Manager	Code reviews. Clear coding standards and policies Testing all the codes