0% found this document useful (0 votes)
9 views8 pages

Software Deployment and Testing Guide

The document discusses the deployment process for software. It begins by explaining that deployment consists of interrelated activities that can occur at the producer site, consumer site, or both. Testing is a key part of the deployment process and involves various types of testing like unit testing, integration testing, system testing, and stress testing to ensure quality. The document also discusses test cases, which are a set of conditions or variables used to determine if a software system is working correctly. Test cases help verify that requirements have been met before the system is released.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views8 pages

Software Deployment and Testing Guide

The document discusses the deployment process for software. It begins by explaining that deployment consists of interrelated activities that can occur at the producer site, consumer site, or both. Testing is a key part of the deployment process and involves various types of testing like unit testing, integration testing, system testing, and stress testing to ensure quality. The document also discusses test cases, which are a set of conditions or variables used to determine if a software system is working correctly. Test cases help verify that requirements have been met before the system is released.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Chapter No.

5 Deployment

5.1 DEPLOYMENT PLAN

The general deployment process consists of several interrelated activities with possible
transitions between them. These activities can occur at the producer site or at the consumer
site or both. Because every software system is unique, the precise processes or procedures
within each activity can hardly be defined. Therefore, "deployment" should be interpreted as
a general process that has to be customized according to specific requirements or
characteristics.

Why became Became donor Search donor


donor


Implementation

The implementation stage of software development is the process of converting a system


specification into an executable program. It almost always involves processes of software
design and programming .In other words, it is a process of converting system requirements
into program codes.


Operational Problem

Once the initial implementation exercise is completed and changeover has been successfully
concluded, it is still dangerous to starting on your laurels, as other factors can improve
troublesome at a later stage.


Management Problem

Many problems in the world of computerized system derive from the lack of understanding
of some of the golden rules for implementation and operation by the management.

Live Blood Donor’s Management System 45


Chapter No.5 Deployment

5.1.1 Testing the System

Testing is a process of executing an implementation of a system with test data and


examining the output of the system and its operational behavior to check whether it is
performing as required. One of the main objectives of testing is to establish the presence of
defect in a program. Testing can only establish the existence of defects whereas debugging
locates and corrects these defects.

Testing can also judge whether or not this particular application is usable in practice.
Therefore a suitable approach must be chosen to reduce the possibility of errors. Among the
rules that serve well as program testing objectives are:

• Testing is a process of program execution with explicit intents to find errors and
run-time program bugs.
• A successful test is not one that uncovers only few expected errors, but it is also
one that constantly provides new challenges to its programmer over time.
• An effective test case is one that contains unexpected testing record sets with
high probability of detecting undiscovered errors during the program design and
development phases.

5.1.2 Regression Testing


Quality is usually appraised by a collection of regression tests forming a suite of programs
that test one or more features of the system.
A regression test is written and the results are generated. If the results are in error, then the
offending bug is corrected. A valid regression test generates verified results. These verified
results are called the “Gold Standard”. This term is borrowed from financial markets where
paper money issue by governments was backed by real gold.
Ideally, the validity of a test result is driven by the requirement document, in practice; the
implementation team is responsible for validity interpretation.
The tests are collected, as well as their gold standard result, into regression test suite. As
development continues, more tests are added, while old test may remain valid. Because of
new development, an old test may no longer be valid. If this is the case, the old test results
are altered in the “Gold Standard” to match the current expectations. The test suite is run
generating new results. These new results are then compared with the Gold-Standard results.
If they differ, then a potential new fault has entered the system. The fault is corrected and

Live Blood Donor’s Management System 46


Chapter No.5 Deployment

the development continues. This mechanism detects when new development invalidates
existing development, and thus prevents the system from regressing into a fault state.

5.1.3 Internal Testing


Internal testing deals with low-level implementation. Here each function or component is
tested. This testing is accomplished by the implementation teams. This focus is also called
clear-box testing, or sometimes white-box testing, because all details are visible to the test.
Internal limits are tested here.

5.1.4 Unit Testing


Unit testing deals with testing a unit as a whole. This would test the interaction of many
functions but confine the test within one unit. The exact scope of a unit is left to
interpretation. Supporting test code, sometimes called scaffolding, may be necessary to
support to an individual test. This type of testing is driven by the architecture and
implementation teams. This focus is also called black-box testing because only the details of
the interface are visible to the test. Limits that are global to a unit are tested here.

5.1.5 Application Testing


Application testing deals with tests for the entire application. This is driven by the scenarios
from the analysis team. Application limits and features are tested here.
The application must successfully execute all scenarios before it is ready for general
customer availability. After all, the scenarios are a part of the requirement document and
measure success. Application testing represents the bulk of the testing done by industry.
Unlike the internal and unit testing, which are programmed, these tests are usually driven by
scripts that run the system with a collection of parameters and collect results. In the past,
these scripts may have been written by hand but in many modern systems this process can
be automated.
5.1.6 Stress Testing
Stress testing deals with the quality of the application in the environment. This idea is to
create an environment more demanding of the application than the application would
experience under normal workloads. This is the hardest and most complex category of
testing to accomplish and it require a joint effort from all teams.
A test environment is established with many testing stations. At each station, a script is
exercising the system. These scripts are usually based on the regression suite. More and

Live Blood Donor’s Management System 47


Chapter No.5 Deployment

More stations are added, all simultaneous hammering on the system, until the system
breaks. The system is repaired and the stress test is repeated until a level of stress is reached
that is higher than expected to be present at a customer site.
Race condition and memory leaks are often found under stress testing. A race condition is a
conflict between at least two tests. Each test works correctly when done in isolation. When
the two tests are run in parallel, one or both of the tests fail. This is usually due to an
incorrectly managed lock.
A memory leaks happens when a test leaves allocated memory behind and doesn’t correctly
return the memory to the memory allocation scheme. The test seems to run correctly, but
after being exercised several times, available memory is reduced until the system fails.

5.2 Test Cases


A test case in software engineering is a set of conditions or variables under which a tester
will determine whether an application or software system is working correctly or not. The
mechanism for determining whether a software program or system has passed or failed such
a test is known as a test oracle. In some settings, an oracle could be a requirement or use
case, while in others it could be a heuristic. It may take many test cases to determine that a
software program or system is considered sufficiently scrutinized to be released. Test cases
are often referred to as test scripts, particularly when written. Written test cases are usually
collected into test suites.

After Deployment there is an important phase to test some of the important use cases these
are known as test cases these all are given from next page.

Live Blood Donor’s Management System 48


Chapter No.5 Deployment

Test Case Title: Registration/Login

Test case 1: Registration/Login Priority (H, L):


High
Test Objective: For Verifying Registration
Test Description: “Admin enters the required fields, presses register button”, client program
contacts with server, server contacts with the database, database updates and sends result to
the back.
Requirements Verified: Yes
Test Environment: IIS must be in running state, Database Should contain appropriate
table and link must be established between server and client program.
Test Setup/Pre-Conditions: IIS should be in running state. All the mandatory fields must
be entered.

Actions Expected Results


The admin will register to access application. “Registered successfully”, Displays Main
Menu.
Pass: Yes Conditions pass: Yes Fail: No
Problems / Issues: NIL
Notes: Successfully Executed

Live Blood Donor’s Management System 49


Chapter No.5 Deployment

Table 5.1

Test Case Title: Search donor

Test case 2: Viewing details Priority (H, L): High

Test Objective: Search donor’s


Test Description: “Blood needy selects the required blood group from the list, client program
contacts with server, server contacts with the database, database updates and sends result to the user.
Requirements Verified: Yes
Test Environment: IIS must be in running state, Database Should contain appropriate table and
link must be established between server and client program.

Test Setup/Pre-Conditions: IIS should be in running state. The user must has to select one of the option.

Actions Expected Results


The user will register to access application. Displays Details.
Pass: Yes Conditions pass: Yes Fail: No
Problems / Issues: NIL
Notes: Successfully Executed

Live Blood Donor’s Management System 50


Chapter No.5 Deployment

Table 5.2

Test Case Title: Became donor

Test case 3: Became a Donor Priority (H, L): High

Test Objective: For adding Donor


Test Description: “User clicks the Became donor and fills the required field and then click
the submit button program contacts with server, server contacts with the database, database
updates and display message “Record successfully Added”.
Requirements Verified: Yes
Test Environment: IIS must be in running state, Database Should contain appropriate
table and link must be established between server and client program.

Test Setup/Pre-Conditions: IIS should be in running state. The user must have to select
the link.

Actions Expected Results


The user will add the details to the database. Displays “Added successfully”.
Pass: Yes Conditions pass: Yes Fail: No
Problems / Issues: NIL
Notes: Successfully Executed

Live Blood Donor’s Management System 51

You might also like