Testing Methods

1. White Box
Also called ‘Structural Testing / Glass Box Testing’ is used for testing the code
keeping the system specs in mind. Inner working is considered and thus
Developers Test..
o Mutation Testing
Number of mutants of the same program created with minor changes
and none of their result should coincide with that of the result of the
original program given same test case.

o Basic Path Testing

Testing is done based on Flow graph notation, uses Cyclometric
complexity & Graph matrices.

o Control Structure Testing

The Flow of control execution path is considered for testing. It does
also checks :-
Conditional Testing : Branch Testing, Domain Testing.
Data Flow Testing.
Loop testing :Simple, Nested, Conditional, Unstructured Loops.
2. Gray Box

3. Black Box
Also called ‘Functional Testing’ as it concentrates on testing of the
functionality rather than the internal details of code.
Test cases are designed based on the task descriptions
o Comparison Testing
Test cases results are compared with the results of the test Oracle.

o Graph Based Testing

Cause and effect graphs are generated and cyclometric complexity
considered in using the test cases.

o Boundary Value Testing

Boundary values of the Equivalence classes are considered and tested
as they generally fail in Equivalence class testing.

o Equivalence class Testing

Test inputs are classified into Equivalence classes such that one input
check validates all the input values in that class.

Levels of Testing

1. Unit Testing.
o Unit Testing is primarily carried out by the developers themselves.

Page 1 of 27
 o Deals functional correctness and the completeness of individual
program units.
o White box testing methods are employed

2. Integration Testing.
o Integration Testing: Deals with testing when several program units are
integrated.
o Regression testing : Change of behavior due to modification or
addition is called ‘Regression’. Used to bring changes from worst to
least.
o Incremental Integration Testing : Checks out for bugs which
encounter when a module has been integrated to the existing.
o Smoke Testing : It is the battery of test which checks the basic
functionality of program. If fails then the program is not sent for further
testing.
3. System Testing.
o System Testing - Deals with testing the whole program system for its
intended purpose.
o Recovery testing: System is forced to fail and is checked out how
well the system recovers the failure.
o Security Testing: Checks the capability of system to defend itself
from hostile attack on programs and data.
o Load & Stress Testing : The system is tested for max load and
extreme stress points are figured out.
o Performance Testing : Used to determine the processing speed.
o Installation Testing : Installation & uninstallation is checked out in
the target platform.
4. Acceptance Testing.
o UAT ensures that the project satisfies the customer requirements.
o Alpha Testing: It is the test done by the client at the developer’s site.
o Beta Testing: This is the test done by the end-users at the client’s
site.
o Long Term Testing: Checks out for faults occurrence in a long term
usage of the product.
o Compatibility Testing : Determines how well the product is
substantial to product transition.

Software Testing

Testing involves operation of a system or application under controlled conditions and

evaluating the results. Every Test consists of 3 steps :
Planning : Inputs to be given, results to be obtained and the process to proceed is to
planned.
Execution: preparing test environment, Completing the test, and determining test
results.
Evaluation: compare the actual test outcome with what the correct outcome should
have been.

Automated Testing

Page 2 of 27
Automated testing is as simple as removing the "human factor" and letting the
computer do the thinking. This can be done with integrated debug tests, to much
more intricate processes. The idea of the these tests is to find bugs that are often
very challenging or time intensive for human testers to find. This sort of testing can
save many man hours and can be more "efficient" in some cases. But it will cost
more to ask a developer to write more lines of code into the game (or an external
tool) then it does to pay a tester and there is always the chance there is a bug in the
bug testing program. Reusability is another problem; you may not be able to transfer
a testing program from one title (or platform) to another. And of course, there is
always the "human factor" of testing that can never truly be replaced.

Other successful alternatives or variation: Nothing is infallible. Realistically, a

moderate split of human and automated testing can rule out a wider range of
possible bugs, rather than relying solely on one or the other. Giving the testere
limited access to any automated tools can often help speed up the test cycle.

Release Acceptance Test

The release acceptance test (RAT), also referred to as a build acceptance or smoke
test, is run on each development release to check that each build is stable enough
for further testing. Typically, this test suite consists of entrance and exit test cases
plus test cases that check mainstream functions of the program with mainstream
data. Copies of the RAT can be distributed to developers so that they can run the
tests before submitting builds to the testing group. If a build does not pass a RAT test,
it is reasonable to do the following:

• Suspend testing on the new build and resume testing on the prior build until
another build is received.
• Report the failing criteria to the development team.
• Request a new build.

Functional Acceptance Simple Test

The functional acceptance simple test(FAST) is run on each development release to

check that key features of the program are appropriately accessible and functioning
properly on the at least one test configuration (preferable the minimum or common
configuration).This test suite consists of simple test cases that check the lowest level
of functionality for each command- to ensure that task-oriented functional
tests(TOFTs) cna be performed on the program. The objective is to decompose the
functionality of a program down to the command level and then apply test cases to
check that each command works as intended. No attention is paid to the combination
of these basic commands, the context of the feature that is formed by these
combined commands, or the end result of the overall feature. For example, FAST for a
File/Save As menu command checks that the Save As dialog box displays. However, it
does not validate that the overall file-saving feature works nor does it validate the
integrity of save files.

Deployment Acceptance Test

The configuration on which the Web system will be deployed will often be much
different from develop-and-test configurations. Testing efforts must consider this in
the preparation and writing of test cases for installation time acceptance tests. This

Page 3 of 27
type of test usually includes the full installation of the applications to the targeted
environments or configurations.

Task-Oriented Functional Test

The task-oriented functional test (TOFT) consists of positive test cases that are
designed to verify program features by checking the task that each feature performs
against specifications, user guides, requirements, and design documents. Usually,
features are organized into list or test matrix format. Each feature is tested for:

• The validity of the task it performs with supported data conditions under
supported operating conditions.
• The integrity od the task's end result
• The feature's integrity when used in conjunction with related features

Forced-Error Test

The forced-error test (FET) consists of negative test cases that are designed to force
a program into error conditions. A list of all error messages thatthe program issues
should be generated. The list is used as a baseline for developing test cases. An
attempt is made to generate each error message in the list. Obviously, test to
validate error-handling schemes cannot be performed until all the handling and error
message have been coded. However, FETs should be thought through as early as
possible. Sometimes, the error messages are not available. The error cases can still
be considered by walking through the program and deciding how the program might
fail in a given user interface such as a dialog or in the course of executing a given
task or printing a given report. Test cases should be created for each condition to
determine what error message is generated.

Real-world User-level Test

These tests simulate the actions customers may take with a program. Real-World
user-level testing often detects errors that are otherwise missed by formal test types.

Exploratory Test

Exploratory Tests do not involve a test plan, checklist, or assigned tasks. The strategy
here is to use past testing experience to make educated guesses about places and
functionality that may be problematic. Testing is then focused on those areas.
Exploratory testing can be scheduled. It can also be reserved for unforeseen
downtime that presents itself during the testing process.

Compatibility and Configuration Testing

Compatibility and configuration testng is performanced to check that an application

functions properly across various hardware and software environments. Often, the
stragegy is to run the functional acceptance simple tests or a subset of the task-
oriented functional tests on a range of software and hardware configurations.
Sometimes, another strategy is to create a specific test that takes into account the
error risks associated with configuration differences. For example, you might design
an extensive series of tests to check for browser compatibility issues. Software
compatibility configurations include variances in OS versions, input/output (I/O)

Page 4 of 27
devices, extension, network software, concurrent applications, online services and
firewalls. Hardwere configurations include variances in manufacturers, CPU types,
RAM, graphic display cards, video capture cards, sound cards, monitors, network
cards, and connection types(e.g. T1, DSL, modem, etc..).

Documentation

Testing of reference guides and user guises check that all features are reasonably
documented. Every page of documentation should be keystroke-tested for the
following errors:

• Accuracy of every statement of fact

• Accuracy of every screen shot, figure and illustation
• Accuracy of placement of figures and illustation
• Accuracy of every tutorial, tip, and instruction
• Accuracy of marketing collateral (claims, system requirements,and screen
shots)
• Accuracy of downloadable documentation(PDFs, HTML, or test files)

Online Help Test

Online help tests check the accuracy of help contents, correctness of features in the
help system, and functionality of the help system.

Install/uninstall Test

Web system often require both client-side and server-side installs. Testing of the
installer checks that installed features function properly--including icons, support
documentation , the README file, and registry keys. The test verifies that the correct
directories are created and that the correct system files are copied to the appropriate
directories. The test also confirms that various error conditions are detected and
handled gracefully.

Testing of the uninstaller checks that the installed directories and files are
appropriately removed, that configuration and system-related filea are also
appropriately removed or modified, and that the operating environment is recovered
in its original state.

User Interface Tests

Easy-of-use UI testing evaluates how intuitive a system is. Issues pertaining to

navigation, usability, commands, and accessibility are considered. User interface
functionality testing examines how well a UI operates to specifications.

AREAS COVERED IN UI TESTING

• Usability
• Look and feel
• Navigation controls/navigation bar
• Instructional and technical information style
• Images

Page 5 of 27
 • Tables
• Navigation branching
• Accessibility

External Beta Testing

External beta testing offers developers their first glimpse at how users may actually
interact with a program. Copies of the program or a test URL, sometimes
accompanied with letter of instruction, are sent out to a group of volunteers who try
out the program and respond to questions in the letter. Beta testing is black-box,
real-world testing. Beta testing can be difficult to manage, and the feedback that it
generates normally comes too late in the development process to contribute to
improved usability and functionality. External beta-tester feedback may be reflected
in a README file or deferred to future releases.

Security Tests

Security measures protect Web systems from both internal and external threats. E-
commerce concerns and the growing popularity of Web-based applications have
made security testing increasingly relevant. Security tests determine whether a
company's security policies have been properly implemented; they evaluate the
functionality of existing systems, not whether the security policies that have been
implemented are appropriate.

PRIMARY COMPONENTS REQUIRING SECURITY TESTING

• Application software
• Database
• Servers
• Client workstations
• Networks

Unit Tests

Unit tests are positive tests that eveluate the integrity of software code units before
they are integrated with other software units. Developers normally perform unit
testing. Unit testing represents the first round of software testing--when developers
test their own software and fix errors in private.

Click-Stream Testing

Click stream Testing is to show which URLs the user clicked, The Web site's user
activity by time period during the day, and other data otherwise found in the Web
server logs. Popular choice for Click-Stream Testing statistics include KeyNote
Systems Internet weather report , WebTrends log analysis utility, and the
NetMechanic monitoring service.

Disadvantage: Click-Stream Testing statistics reveal almost nothing about the user's
ability to achieve their goals using the Web site. For example, a Web site may show a
million page views, but 35% of the page views may simply e pages with the message
"Found no search results," With Click-Stream Testing, there's no way to tell when user
reach their goals.

Page 6 of 27
Click-stream measurement tests

Makes a request for a set of Web pages and records statiestics about the response,
including total page views per hour, total hits per week, total user sessions per week,
and derivatives of these numbers. The downside is that if your Web-enabled
application takes twics as many pages as it should for a user to complete his or her
goal, the click stream test makes it look as though your Web site is popular, while to
the user your Web site is frustrating.

HTML content-checking tests

HTML content checking tests makes a request to a Web page, parses the response for
HTTP hyperlinks, requests hyperlinks from their associated host, and if the links
returned successful or exceptional conditions. The downside is that the hyperlinks in
a Web-enalbled application are dynamic and can change, depending on the user's
actions. There is little way to know the context of the hyperlinks in a Web-enabled
application. Just checking the links' validity is meaningless if not misleading. These
tests were meant to test static Web sites, not Web-enabled application

Web-Enabled Application Measurement Tests

1. Meantime between failures in seconds

2. Amount of time in seconds for each user session, sometimes know as
transaction
3. Application availability and peak usage periods.
4. Which media elements are most used ( for example, HTML vs. Flash,
JavaScript vs. HTML forms, Real vs. Windows Media Player vs. QuickTime)

Ping tests

Ping tests use the Internet Control Message Protocol(ICMP) to send a ping request to
a server. If the ping returns, the server is assumed to be alive and well. The downside
is that usually a Web server will continue to return ping requests even when the Web-
enable application has crashed.

Unit Testing

Unit testing finds problems and errors at the module level before the software leaves
development. Unit testing is accomplished by adding a small amount of the code to
the module that validates the module's responses

System-Level Test

System-level tests consist of batteries of tests that are designed to fully exercise a
program as a whole and check that all elements of the integrated system function
properly.

Functional System Testing

System tests check that the software functions properly from end-to-end. The
components of the system include: A database, Web-enable application software
modules, Web servers, Web-enabled application frameworks deploy Web browser

Page 7 of 27
software, TCP/IP networking routers, media servers to stream audio and video, and
messaging services for email.

A common mistake of test professionals is to believe that they are conducting system
tests while they are actually testing a single component of the system. For example,
checking that the Web server returns a page is not a system test if the page contains
only a static HTML page.

System testing is the process of testing an integrated hardware and software system
to verify that the system meets its specified requirements. It verifies proper
execution of the entire set of application components including interfaces to other
applications. Project teams of developers and test analysts are responsible for
ensuring that this level of testing is performed.

System testing checklist include question about:

• Functional completeness of the system or the add-on module

• Runtime behavior on various operating system or different hardware
configurantions.
• Install ability and configurability on various systems
• Capacity limitation (maximum file size, number of records, maximum number
of concurrent users, etc.)
• Behavior in response to problems in the programming environment (system
crash, unavailable network, full hard-disk, printer not ready)
• Protection against unauthorized access to data and programs.

"black-box" (or functional) testing

Black Box Testing is testing without knowledge of the internal workings of the item
being tested. The Outside world comes into contact with the test items, --only
through the application interface an internal module interface, or the INPUT/OUTPUT
description of a batch process. They check whether interface definitions are adhered
to in all situation and whether the product conform to all fixed requirements. Test
cases are created based on the task descriptions.

Black Box Testing assumes that the tester does not know anything about the
application that is going to be tested. The tester needs to understand what the
program should do, and this is achieved through the business requirements and
meeting and talking with users.

Functional tests: This type of tests will evaluate a specific operating condition using
inputs and validating results. Functional tests are designed to test boundaries. A
combination of correst and incorrect data should be used in this type of test.

Scalability and Performance Testing

Scalability and performance testing is the way to understand how the system will
handle the load cause by many concurrent users. In a Web environment concurrent
use is measured as simply the number of users making requests at the same time.

Page 8 of 27
Performance testing is designed to measure how quickly the program completes a
given task. The primary objective is to determine whether the processing speed is
acceptable in all parts of the program. If explicit requirements specify program
performance, then performance test are often performed as acceptance tests.

As a rule, performance tests are easy to automate. This makes sense above all when
you want to make a performance comparison of different system conditions while
using the user interface. The capture and automatic replay of user actions during
testing eliminates variations in response times.

This type of test should be designed to verify response and excution time.
Bottlenecks in a system are generally found during this stage of testing.

Stress Testing

Overwhelm the product for performance, reliability, and efficiency assessment; To

find the breakpoint when system is failure; to increase load regressively to gather
information for finding out maximum concurrent users.
Stress tests force programs to operate under limited resource conditions. The goal is
to push the upper functional limits of a program to ensure that it can function
correctly and handle error conditions gracefully. Examples of resources that may be
artificially manipulated to create stressful conditions include memory, disk space, and
network bandwidth. If other memory-oriented tests are also planned, they should be
performed here as part of the stress test suite. Stress tests can be automated.
Breakpoint:
The capabilities and weakness of the product:

• High volumes of data

• Device connections
• Long transaction chains

Stress Test Environment:

As you set up your testing environment for a stress test, you need to make sure you
can answer the following questions:

• Will my test be able to support all the users and still maintain performance?
• Will my test be able to simulate the number of transactions that pass through
in a matter of hours?
• Will my test be able to uncover whether the system will break?
• Will my server crash if the load continues over and over?

The test should be set up so that you can simulate the load; for example:

• If you have a remote Web site you should be able to monitor up to four Web
sites or URLs.
• There should be a way to monitor the load intervals.
• The load test should be able to simulate the SSL (Secure Server)

Page 9 of 27
 • The test should be able to simulate when a user submits the Form Data (GET
method)
• The test should be set up to simulate and authentical the keyword verification.
• The test should be able to simulate up to six email or pager mail addresses
and an alert should occur when there is a failure.

It is important to remember when stressing your Web site to give a certain number of
users a page to stress test and give them a certain amount of time in which to run
the test.
Some of the key data features that can help you measure this type of stress test,
determine the load, and uncover bottlenecks in the system are:

• Amount of memory available and used

• The processor time used
• The number of requests per second
• The amount of time it takes ASP pages to be set up.
• Server timing errors.

Load Testing

The process of modeling application usage conditions and performing them against
the application and system under test, to analyze the application and system and
determine capacity, throughout speed, transation handling capabilities, scalabilities
and reliability while under under stress.

This type of test is designed to identify possible overloads to the system such as too
many users signed on to the system, too many terminals on the network, and
network system too slow.

Load testing a simulation of how a browser will respond to intense use by many
individuals. The Web sessions can be recorded live and set up so that the test can be
run during peak times and also during slow times. The following are two different
types of load tests:

Single session - A single session should be set up on browser that will have one or
multiple responses. The timing of the data should be put in a file. After the test, you
can set up a separate file for report analysis.

Multiple session - a multiple session should be developed on multiple browsers with

one or multiple responses. The multivariate statistical methods may be needed for a
complex but general performance model

When performing stress testing, looping transactions back on themselves so that the
system stresses itself simulates stress loads and may be useful for finding
synchronization problems and timing bugs, Web priority problems, memory bugs, and
Windows problems using API. For example, you may want to simulate an incoming
message that is then put out on a looped-back line; this in turn will generate another
incoming message. The nyou can use another system of comparable size to create
the stress load.

Memory leaks are often found under stress testing. A memory leak occurs when a
test leaves allocated memory behind and does not correctly return the memory to

Page 10 of 27
the memory allocation scheme. The test seems to run correctly, but after several
iteration available memory is reduced until the system fails.

Peak Load and Testing Parameters:

Determining your peak load is important before beginning the assessment of the Web
site test. It may mean more than just using user requests per second to stress the
system. There should be a combination of determinants such as requests per second
, processor time, and memory usage. There is also the consideration of the type of
information that is on your Web page from graphics and code processing, such as
scripts, to ASP pages. Then it is important to determine what is fast and what is slow
for your system. The type of connection can be a critical component here, such as T1
or T3 versus a modem hookup. After you have selected your threshold, you can
stress your system to additional limits.

As a tester you need to set up test parameters to make sure you can log the number
of users coming into and leaving the test. This should be started in a small way and
steadily increased. The test should also begin by selecting a test page that may not
have a large amount of graphics and steadily increasing the complexity of the test by
increasing the number of graphics and image requests. Keep in mind that images will
take up additional bandwidth and resources on the server but do not really have a
large impact on the server's processor.

Another important item to remember is that you need to account for the length of
time the user will spend surfing each page. As you test, you should set up a log to
determine the approximate time spend on each page, whether it is 25 or 30 seconds.
It may be recorded that each user spends at least 30 seconds on each page, and that
will produce a heightened response for the server. As the request is queued, and this
will be analyzed as the test continues.

Load/Volume Test

Load/volume tests study how a program handles large amounts of data, excessive
calculations, and excessive processing. These tests do not necessarily have to push
or exceed upper functional limits. Load/volume tests can, and usually must, be
automated.

Focus of Load/Volume Testing

• Pushing through large amounts of data with extreme processing demands.

• Requesting many processes simultaneously.
• Repeating tasks over a long period of time

Load/volume tests, which involve extreme conditions, are normally run after the
execution of feature-level tests, which prove that a program functions correctly under
normal conditions.

Difference between Load and Strees testing

The idea of stress testing is to find the breaking point in order to find bugs that will
make that break potentially harmful. Load testing is merely testing at the highest

Page 11 of 27
transaction arrival rate in performance testing to see the resource contention,
database locks etc..

Web Capacity Testing Load and Stress

The performance of the load or stress test Web site should be monitored with the
following in mind:

• The load test should be able to support all browser

• The load test should be able to support all Web server.
• The tool should be able to simulate up 500 users or playback machines
• The tool should be able to run on WIndows NT, Linux, Solaris, and most Unix
variants.
• There should be a way to simulate various users at different connection
speeds.
• After the tests are run, you should be able to report the transactions, URL, and
number of users who visited the site.
• The test cases should be asssembled in a like fashion to set up test suites.
• There should be a way to test the different server and port addresses.
• There should be a way to account for the user's cookies.

Performance Test

The primary goal of performance-testing is to develop effective enhancement

strategies for maintaining acceptable system performance. Performance testing is a
capacity analysis and planning process in which measurement data are used to
predict when load levels will exhaust system resources.

The Mock Test

It is a good idea to set up s mock test before you begin your actual test. This is a way
to measure the server's stressd performance. As you progress with your stress
testing, you can set up a measurement of metrics to determine the efficiency of the
test.

After the initial test, you can determine the breaking point for the server. It may be a
processor problem or even a memory problem. You need to be able to check your log
to determine the average amount of time that it takes your provessor to perform the
test. Running graphics or even ASP pages can cause processor problems and a
limitation every time you run your stress test.

Memory tends to be a problem with the stress test. This may be due to a memary
leak or lack of memory. You need to log and monitor the amount of disk capacity
during the stress test. As mentioned earlier, the bandwidth can account for the slow
down of the processing of the Web site speed. If the test hangs and there is a large
waiting period, your processor usage is too low to handle the amount of stress on the
system.

Simulate Resources
It is important to be able to run system in a high-stress format so that you can
actually simulate the resources and understand how to handle a specific load. For
example, a bank transaction processing system may be designed to process up to

Page 12 of 27
150 transactions per second, whereas an operating system may be designed to
handle up to 200 separate terminals. The different tests need to be designed to
ensure that the system can process the expected load. This type of testing usually
involves planning a series of tests where the load is gradually increased to reflect the
expected usage pattern. The stress tests can steadily increase the load on the
system beyond the maximum design load until the system fails.

This type of testing has a dual function of testing the system for failure and looking
for a combination of events that occur when a load is placed on the server. Stress
testing can then determine if overloading the system results in loss of data or user
sevice to the customers The use of stress testing is particularly relevant to an
ecommerce system with Web database.

Increase Capacity Testing

When you begin your stress testing, you will want to increase your capacity testing to
make sure you are able to handle the increased load of data such as ASP pages and
graphics. When you test the ASP pages, you may want to create a page similar to the
original page that will simulate the same items on the ASP page and have it send the
information to a test bed with a process that completes just a small data output. By
doing this, you will have your processor still stressing the system but not taking up
the bandwidth by sending the HTML code along the full path. This will not stress the
entire code but will give you a basis from which to work. Dividing the requests per
second by the total number of user or threads will determine the number of
transactions per second. It will tell you at what point the server will start becoming
less efficient at handling the load. Let's look at an example. Let's say your test with
50 users shows your server can handle 5 requests per second, with 100 users it is 10
requests per second, with 200 users it is 15 requests per second, and eventually with
300 users it is 20 requests per second. Your requests per second are continually
climbing, so it seems that you are obtaining steadily improving performance. Let's
look at the ratios:

05/50 = 0.1
10/100 = 0.1
15/200 = 0.075
20/300 = 0.073

From this example you can see that the performance of the server is becoming less
and less efficient as the load grows. This in itself is not necessarily bad (as long as
your pages are still returning within your target time frame). However, it can be a
useful indicator during your optimization process and does give you some indication
of how much leeway you have to handle expected peaks.

Stateful testing

When you use a Web-enabled application to set a value, does the server respond
correctly later on?

Privilage testing

Page 13 of 27
What happens when the everyday user tries to access a control that is authorized
only for administrators?

Speed testing

Is the Web-enabled application taking too long to respond?

Boundary Test

Boundary tests are designed to check a program's response to extreme input values.
Extreme output values are generated by the input values. It is important to check
that a program handles input values and output results correctly at the lower and
upper boundaries. Keep in mind that you can create extreme boundary results from
non-extreme input values. It is essential to analyze how to generate extremes of both
types. In addition. sometime you know that there is an intermediate variable involved
in processing. If so, it is useful to determine how to drive that one through the
extremes and special conditions such as zero or overflow condition.

Boundary timeing testing

What happens when your Web-enabled application request times out or takes a really
long time to respond?

Regression testing

Did a new build break an existing function? Repeat testing after changes for
managing risk relate to product enhancement.

A regression test is performded when the tester wishes to see the progress of the
testing processes by performing identical tests before and after a bug has been fixed.
A regression test allows the tester to compare expeted test results with the actual
results.

Regression testing's primary objective is to ensure that all bugfree features stay that
way. In addition, bugs which have been fixed once should not turn up again in
subsequent program versions.

Regression testing: After every software modification or before next release, we

repeat all test cases to check if fixed bugs are not show up again and new and
existing functions are all working correctly.

Regression testing is used to confirm that fixed bugs have, in fact, been fixed and
that new bugs have not been introduced in the process, and that festures that were
proven correctly functional are intact. Depending on the size of a project, cycles of
regression testing may be perform once per milestone or once per build. Some bug
regression testing may also be performed during each acceptance test cycle,
focusing on only the most important bugs. Regression tests can be automated.

CONDITIONS DURING WHICH REGRESSION TESTS MAY BE RUN Issu fixing cycle. Once
the development team has fixed issues, a regression test can be run t ovalidate the
fixes. Tests are based on the step-by-step test casess that were originally reported:

Page 14 of 27
 • If an issue is confirmeded as fixed, then the issue report status should be
changed to Closed.
• If an issue is confirmed as fixed, but with side effects, then the issue report
status should be changed to Closed. However, a new issue should be filed to
report the side effect.
• If an issue is only partially fixed, then the issue report resolution should be
changed back to Unfixed, along with comments outlining the oustanding
problems

Open-status regression cycle. Periodic regression tests may be run on all open issue
in the issue-tracking database. During this cycle, issue status is confirmed either the
report is reproducible as is with no modification, the report is reproducible with
additional comments or modifications, or the report is no longer reproducible

Closed-fixed regression cycle. In the final phase of testing, a full-regression test cycle
should be run to confirm the status of all fixed-closed issues.

Feature regression cycle. Each time a new build is cut or is in the final phase of
testing depending on the organizational procedure, a full-regression test cycle should
be run to confirm that the proven correctly functional features are still working as
expected.

Database Testing

Items to check when testing a database

What to test Environment toola/technique

System test Black Box and White Box

Search results
environment technique

Response System test

Sytax Testing/Functional Testing
time environment

Development
Data integrity White Box testing
environment

Development
Data validity White Box testing
environment

Query response time

The turnaround time for responding to queries in a database must be short; therefor,
query response time is essential for online transactions. The results from this test will
help to identify problems, such as possible bottlenecks in the network, sspecific
queries, the database structure, or the hardware.

Page 15 of 27
Data integrity
Data stored in the database should include such items as the catalog, pricing,
shipping tables, tax tables, order database, and customer information. Testng must
verify the integrity of the stored data. Testing should be done on a regular basis
because data changes over time.

Data integrity tests

Data integrity can be tested as follows to ensure that the data is valid and not
corrupt:

• Test the creation, modification, and deletion of data in tables as

specified in the business requirement.
• Test to make sure that sets of radio buttons represent a fixed set of
values. You should also check for NULL or EMPTY values.
• Test to make sure that data is save to the database and that each
values gets saved fully. You should watch for the truncation of strings
and that numeric values are not rounded off.
• Test to make sure that default values are stored and saved.
• Test the compatibility with old data. You should ensure that all updates
do not affect the data you have on file in your database.

Data validity
The most common data errors are due to incorrect data entry, called data validity
errors.

Recovery testing

• The system recovers from faukts and resumes processing within a predefined
period of time.
• The system is fault-tolerant, which means that processing faults do not halt
the overall functioning of the system.
• Data recovery and restart are correct in case of automatic recovery. If
recovery requires human intervention, the mean time to repair the database is
within predefined acceptable limits.

When testing a SQL server

• If the Web site publishes from inside the SQL Server straight to a Web page, is
the data accurate and of the correct data type?
• If the SQL Server reads from a stored procedure to produce a Web page or if
the stored procedure is changed, does the data on the page change?
• If you are using FrontPage or interDev is the data connection to your pages
secure?
• Does the database have scheduled maintenance with a log so testers can set
changes or errors?
• Can the tester check to see how back ups are being handled?
• Is the database secure?

Page 16 of 27
When testing a Access database

• If the database is creating Web pages from the datbase to a URL, is the
information correct and updated? If the pages are not dynamic or Active
Server pages, they will not update automatically.
• If the tables in the database are linked to another database, make sure that all
the links are active and giving reevant information.
• Are the fields such as zip code, phone numbers, dates, currency, and social
security number formatted properly?
• If there are formulas in the database, do they work? How will they take care of
updates if numbers change (for example, updating taxes)?
• Do the forms populate the correct tables?
• Is the database secure?

When test a FoxPro database

• If the database is linked to other database, are the links secure and working?
• If the database publishes to the Internet, is the data correct?
• When data is deployed, is it still accurate?
• Do the queries give accurate information to the reports?
• If the database performs calculations, are the calculatons accurate?

Other important Database and security feature

• Credit Card Transaction

• Shopping Carts
• Payment Transaction Security

Secure Sockets Layer (SSL)

SSL is leading security protocol on the Internet.
When an SSL session is started, the server sends its publice key to the browser,
which the browser uses to send a randomly generated secret key back to the server
to have a secret key exchange for that session.
SSL is a protocol that is submitted to the WWW consortium (W3C) working group on
security for consideration as a standard security hanhshake that is used to initiate
the TCP/IP connection. This handshake results in the client and server agreeing on the
level of security that they will use, and this will fulfill any authentication requirements
for the connection. SSL's role is to encrypt and decrypt the byte stream of the
application protocol being used. This means the all the inofrmation in both the HTTP
request and the HTTP response are fully encrypted, including the URL the client is
requesting, any submitted form contents (such as credit card numbers), anty HTTP
access authorization information (user names and passwords), and all the data
returned from the server to the client.

Transport Layer Security (TLS)

TLS is a mayo security standard on the internet. TLS is backward compatible with SSL
and use Triple Data Encryption Standard (DES) encryption.

Three Waves of Software Development

Page 17 of 27
 Type of
Wave Development Style Test style
application

Event-Driven framework
surrounds individual procedural Test each function agaist
1. Desktop functions The common style is to a written functions
have a hierarchical set of menus specification.
presenting a set of commands.

Structured programming
command organized into
Test each function against
hierachical menu lists with each
a written functional
client function having its own
2. Client/Server specification and test the
code. The common style is to
server for its throughput
combine a common dropdown
to server clients.
menu bar with graphical
windows contain controls.

Visual Integrated development

tools facilitate object-oriented Capture/record/ playable
design patterns. The common watches how an
style is to provide multiple paths application is used and
Web-
3. to accomplishing tasks. (The net then provides reports
enabled
effect is that you can't just walk comparing how the
through a set of hierarchical playback differed from
menus and arrive at the same the original recording.
test result any more.)

Desktop application development and Test automation

The software was written to provide a friendly interface for information workers:
Spreadsheet jockeys, business people needing written reports, and game players.
The full spectrum of desktop software could pretty well be categorized into
spreadsheet, wordprocessor, database, and entertainment categories since desktop
computers were rarely networked to other information resources. Desktop
applications used the keyboard, and then later a mouse, to navigate through
windows and a drop-down menu. Inside a desktop application software package one
would find an event-driven framework surrounding individual procedural functions.
The automation focused on improving the time it took to test a desktop application
for functionality. The test utilities link into desktop applications and try each
command as though a user were accessing the menu and window commands. Most
QA technicians testing a desktop application compare the function of all the menus
and windows to a written functional specification document. The variation from the
document to the performance shows the relative health of a desktop application.

Client/Server Development and Test automation

The original intent for client/server applications was to separete presentation logic
from business logic. In an ideal system design, the client was reponsible for
presenting the user interface, command elements (drop-down menus, buttons,

Page 18 of 27
controls), displayed results information in a set of windows, charts, and dials. The
client connected to a server to process functions and the server responded with data.

In a client/server environment the protocols are cleanly defined so that all the clients
use the same protocols to communicate with the server.

The client-side frameworks to provide the same functionality of desktop application

frameworks plus most of the needed communication code to issue commands to the
server and the code needed to automatically update a client with new functions
received from the server.The server-side frameworks provide code needed to
received and handle requests from multiple clients, and code to connect to database
for data persistence and remote information providers. Additionally, these
frameworks need to handle stateful transations and intermittent network
connections. Stateful transactions require multiple steps to accomplish a task.

Client/server applications are normally transactional in nature and usually several

interactions with the user are needed to finish a single request. For example, in a
stock trading application the user begins a transaction by identifying themselves to
the server, looking up an order code, and then submitting a request to the server,
and receives and presents the results to the user. The client-side application normally
knows something about the transaction - for example, the client-side application will
normally store the user identification and a session code such as cookie value across
the user's interaction with the server-based application. Users like it better when the
client-side application knows about the transaction because each step in a request
can be optimized in the client application. For example. in the stock trading example
the client application could calculate a stock trade commission locally without having
to communication with server.

Client/server application test automation provides the functionality of desktop

application test automation plus these:

• Client/server applications operate in a network environment. The tests need to

not only check for the function of an application, they need to test how the
application handles slow or intermittent network performance.
• Automated test are ideal to determine the number of client applications a
server is able to efficiently handle at any given time.
• The server is usually a middle tier between the client application and several
data sources. Automated tests need to check the server for correct
functionality while it communicates with the data source.

Black-Box testing on Window-based Application

Editable Fields Checking and Validation:

• Valid/invalid characters/strings data in all editable fields

• Valid minimum/maximum/mid range values in fields
• Null strings (or no data ) in required fields
• Record length (character limit)in text/memo fields
• Cut/copy/paste into/from fields when possible

Not Editable Fields Checking:

Page 19 of 27
 • Check for all test/spelling in warnings and error messages/dialogs
• Invoke/check all menu items and their options

Application Usability:

• Appearance an outlook (Placement an alignment of objects on screen)

• User Interface Test (open all menus, check all items)
• Basic functionality checking (File+Open+Save, etc..)
• Right mouse clicking sensitivity
• Resize/min/max/restore app, windows (check min app size)
• Scroll ability when applicable (scrollbars, keyboard, autoscrolling)
• Keyboard and mouse navigation, highlighting, dragging, drag/drop
• Print in landscape an portrait modes
• Check F1, What's This , Help menu
• Short-cut and Accelerator keys
• Tab Key order and Navigation in all dialog boxes and menus

Web-Enabled Development and Test automation

Web-Enabled application goes further in these areas:

• Web-enabled applications are meant to be stateless. HTTP was designed to be

stateless. Each request from a Web-enabled application is meant to be atomic
and not rely on any previous requests. This has huge advantages for system
architecture and datacenter provisioning. When requests are stateless, then
any sserver can respond to the request and any request handler on any server
may service the request.
• Web-enabled applications are platform independent. The client application
may be written for Windows, Macintosh, Linux, and any other platform that is
capable of implementing the command protocol and network connection to
the server.
• Web-enabled application expect the client application to provide presentation
rendering and simple scripting capabilities. The client application is usually a
browser, however, it may also be a dedication client application such as a
retail cash register, a Windows-based data analysis tool, ot an electronic
address book in your mobile phone.

The missing context in a Web-enabled application test automation means that

software developers and QA technicians must manually script tests for each Web-
enalbled application. Plus, they need to maintain the test scriots as the application
changes. Web-enabled application test automation tools focus on making the scriot
writing and maintenance tasks easier. The test automation tool offers these features:

• A friendly, graphical user interface to integrate the record, edit, and run-time
script functions.
• A recorder that watches how an application is used and writes a test script for
you.
• A playback utility that drives a Web-enalbed application by processing the test
script and logging. The playback utility also provides the facility to play back

Page 20 of 27
 several concurrently running copies of the same script to check the system for
scalability and load testing.
• A report utility to show how the playback differed from the original recording.
The differences may be slower or faster performance times, errors, and
incomplete transactions.

Testing Web Sites Applications

Many developers and testers are making the transition from testing traditional
client/server, PC, and/or mainframe systems, to testing rapidly changing Web
applications.

Web test: This testing focuses on how well all parts of the web site hold together,
whether inside and outside the website are working and whether all parts of the
website are connected.

Web sites Server consist of three back-end layer:

• Web server
• Application server
• Data layers

Black Box testing for web-based application: (1)

1. Browser functionality:

• Is the browser compatible with the application design?

• There are many different types of browsers available.

GUI design components

• Are the scroll bars, buttons, and frames compatible with the browser and
functional?
• To check the functionality of the scroll bars on the interface of the Web page
to make sure the the user can scroll through items and make the correct
selection from a list of items.
• The button on the interface need to be functional and the correct hyperlink
should go to the correct page.
• If frames are used on the interface, they should be checked for the correct
size and whether all of the components fit within the viewing screen of the
monitor.

2. User Interface
One of the reasons the web browser is being used as the front end to applications is
the ease of use. Users who have been on the web before will probably know how to
navigate a well-built web site. While you are concentrating on this portion of testing it
is important to verify that the application is easy to use. Many will believe that this is
the least important area to test, but if you want to be successful, the site better be
easy to use.

Page 21 of 27
3. Instructions
You want to make sure there are instructions. Even if you think the web site is simple,
there will always be someone who needs some clarification. Additionally, you need to
test the documentation to verify that the instructions are correct. If you follow each
instruction does the expected result occur?

4. Site map or navigational bar

Does the site have a map? Sometimes power users know exactly where they want to
go and don't want to wade through lengthy introductions. Or new users get lost
easily. Either way a site map and/or an ever-present navigational bar can help guide
the user. You need to verify that the site map is correct. Does each link on the map
actually exist? Are there links on the site that are not represented on the map? Is the
navigational bar present on every screen? Is it consistent? Does each link work on
each page? Is it organized in an intuitive manner?

5. Content
To a developer, functionality comes before wording. Anyone can slap together some
fancy mission statement later, but while they are developing, they just need some
filler to verify alignment and layout. Unfortunately, text produced like this may sneak
through the cracks. It is important to check with the public relations department on
the exact wording of the content.
You also want to make sure the site looks professional. Overuse of bold text, big fonts
and blinking (ugh) can turn away a customer quickly. It might be a good idea to
consult a graphic designer to look over the site during User Acceptance Testing. You
wouldn't slap together a brochure with bold text everywhere, so you want to handle
the web site with the same level of professionalism.
Finally, you want to make sure that any time a web reference is given that it is
hyperlinked. Plenty of sites ask you to email them at a specific address or to
download a browser from an address. But if the user can't click on it, they are going
to be annoyed.

6. Colors/backgrounds
Ever since the web became popular, everyone thinks they are graphic designers.
Unfortunately, some developers are more interested in their new backgrounds, than
ease of use. Sites will have yellow text on a purple picture of a fractal pattern. (If
you've never seen this, try most sites at GeoCities or AOL.) This may seem "pretty
neat", but it's not easy to use.
Usually, the best idea is to use little or no background. If you have a background, it
might be a single color on the left side of the page, containing the navigational bar.
But, patterns and pictures distract the user.

Black Box testing for web-based application: (2)

7. Images
Whether it's a screen grab or a little icon that points the way, a picture is worth a
thousand words. Sometimes, the best way to tell the user something is to simply
show them. However, bandwidth is precious to the client and the server, so you need
to conserve memory usage. Do all the images add value to each page, or do they
simply waste bandwidth? Can a different file type (.GIF, .JPG) be used for 30k less?
In general, you don't want large pictures on the front page, since most users who
abandon a page due to a large load will do it on the front page. If you can get them to
see the front page quickly, it will increase the chance they will stay.

Page 22 of 27
8. Tables
You also want to verify that tables are setup properly. Does the user
constantly have to scroll right to see the price of the item? Would it be
more effective to put the price closer to the left and put miniscule
details to the right? Are the columns wide enough or does every row
have to wrap around? Are certain columns considerably longer than
others?

9. Wrap-around
Finally, you will want to verify that wrap-around occurs properly. If the text refers to
"a picture on the right", make sure the picture is on the right. Make sure that
widowed and orphaned sentences and paragraphs don't layout in an awkward
manner because of pictures.

10. Functionality
The functionality of the web site is why your company hired a
developer and not just an artist. This is the part that interfaces with the
server and actually "does stuff".

11. Links
A link is the vehicle that gets the user from page to page. You will need to verify two
things for each link: that the link brings you to the page it said it would and that the
pages you are linking to actually exists. It may sound a little silly but I have seen
plenty of web sites with internal broken links.

12. Forms
When a user submits information through a form it needs to work
properly. The submit button needs to work. If the form is for an online
registration, the user should be given login information (that works)
after successful completion. If the form gathers shipping information, it
should be handled properly and the customer should receive their
package. In order to test this, you need to verify that the server stores
the information properly and that systems down the line can interpret
and use that information.

13. Data verification

If the system verifies user input according to business rules, then that
needs to work properly. For example, a State field may be checked
against a list of valid values. If this is the case, you need to verify that
the list is complete and that the program actually calls the list properly
(add a bogus value to the list and make sure the system accepts it).

14. Cookies
Most users only like the kind with sugar, but developers love web cookies. If the
system uses them, you need to check them. If they store login information, make
sure the cookies work. If the cookie is used for statistics, verify that totals are being
counted properly. And you'll probably want to make sure those cookies are encrypted

Page 23 of 27
too, otherwise people can edit their cookies and skew your statistics.
Application specific functional requirements Most importantly, you want to verify the
application specific functional requirements. Try to perform all functions a user would:
place an order, change an order, cancel an order, check the status of the order,
change shipping information before an order is shipped, pay online, ad naseum.
This is why your users will show up on your doorstep, so you need to make sure you
can do what you advertise.

Black Box testing for web-based application: (3)

16. Interface Testing

Many times, a web site is not an island. The site will call external servers for
additional data, verification of data or fulfillment of orders.

16. Server interface

The first interface you should test is the interface between the browser and the
server. You should attempt transactions, then view the server logs and verify that
what you're seeing in the browser is actually happening on the server. It's also a good
idea to run queries on the database to make sure the transaction data is being stored
properly.

17. External interfaces

Some web systems have external interfaces. For example, a merchant might verify
credit card transactions real-time in order to reduce fraud. You will need to send
several test transactions using the web interface. Try credit cards that are valid,
invalid, and stolen. If the merchant only takes Visa and MasterCard, try using a
Discover card. (A script can check the first digit of the credit card number: 3 for
American Express, 4 for Visa, 5 for MasterCard, or 6 for Discover, before the
transaction is sent.) Basically, you want to make sure that the software can handle
every possible message returned by the external server.

18. Error handling

One of the areas left untested most often is interface error handling. Usually we try to
make sure our system can handle all of our errors, but we never plan for the other
systems' errors or for the unexpected. Try leaving the site mid-transaction - what
happens? Does the order complete anyway? Try losing the internet connection from
the user to the server. Try losing the connection from the server to the credit card
verification server. Is there proper error handling for all these situations? Are charges
still made to credit cards? Is the interruption is not user initiated, does the order get
stored so customer service reps can call back if the user doesn't come back to the
site?

19. Compatibility
You will also want to verify that the application can work on the machines your
customers will be using. If the product is going to the web for the world to use, you
will need to try different combinations of operating system, browser, video setting
and modem speed.

20. Operating systems

Does the site work for both MAC and IBM-Compatibles? Some fonts are not available
on both systems, so make sure that secondary fonts are selected. Make sure that the
site doesn't use plug-ins only available for one OS, if your users will use both.

Page 24 of 27
21. Browsers
Does your site work with Netscape? Internet Explorer? Lynx? Some HTML commands
or scripts only work for certain browsers. Make sure there are alternate tags for
images, in case someone is using a text browser. If you're using SSL security, you
only need to check browsers 3.0 and higher, but verify that there is a message for
those using older browsers.

22. Video settings

Does the layout still look good on 640x400 or 600x800? Are fonts too small to read?
Are they too big? Does all the text and graphic alignment still work?

23. Modem/connection speeds

Does it take 10 minutes to load a page with a 28.8 modem, but you tested hooked up
to a T1? Users will expect long download times when they are grabbing documents or
demos, but not on the front page. Make sure that the images aren't too large. Make
sure that marketing didn't put 50k of font size -6 keywords for search engines.

Black Box testing for web-based application: (4)

24. Printers
Users like to print. The concept behind the web should save paper and reduce
printing, but most people would rather read on paper than on the screen. So, you
need to verify that the pages print properly. Sometimes images and text align on the
screen differently than on the printed page. You need to at least verify that order
confirmation screens can be printed properly.

25. Combinations
Now you get to try combinations. Maybe 600x800 looks good on the MAC but not on
the IBM. Maybe IBM with Netscape works, but not with Lynx.
If the web site will be used internally it might make testing a little easier. If the
company has an official web browser choice, then you just need to verify that it
works for that browser. If everyone has a T1 connection, then you might not need to
check load times. (But keep in mind, some people may dial in from home.) With
internal applications, the development team can make disclaimers about system
requirements and only support those systems setups. But, ideally, the site should
work on all machines so you don't limit growth and changes in the future.

26. Load/Stress
You will need to verify that the system can handle a large number of users at the
same time, a large amount of data from each user, and a long period of continuous
use. Accessibility is extremely important to users. If they get a "busy signal", they
hang up and call the competition. Not only must the system be checked so your
customers can gain access, but many times crackers will attempt to gain access to a
system by overloading it. For the sake of security, your system needs to know what
to do when it's overloaded and not simply blow up.
Many users at the same time
If the site just put up the results of a national lottery, it better be able to handle
millions of users right after the winning numbers are posted. A load test tool would be
able to simulate large number of users accessing the site at the same time.
Large amount of data from each user
Most customers may only order 1-5 books from your new online bookstore, but what
if a university bookstore decides to order 5000 different books? Or what if grandma
wants to send a gift to each of her 50 grandchildren for Christmas (separate mailing
addresses for each, of course.) Can your system handle large amounts of data from a

Page 25 of 27
single user?
Long period of continuous use
If the site is intended to take orders for flower deliveries, then it better be able to
handle the week before Mother's Day. If the site offers web-based email, it better be
able to run for months or even years, without downtimes.
You will probably want to use an automated test tool to implement these types of
tests, since they are difficult to do manually. Imagine coordinating 100 people to hit
the site at the same time. Now try 100,000 people. Generally, the tool will pay for
itself the second or third time you use it. Once the tool is set up, running another test
is just a click away.

27. Security
Even if you aren't accepting credit card payments, security is very important. The
web site will be the only exposure some customers have to your company. And, if
that exposure is a hacked page, they won't feel safe doing business with you.

Black Box testing for web-based application: (5)

28. Directory setup

The most elementary step of web security is proper setup of directories. Each
directory should have an index.html or main.html page so a directory listing doesn't
appear.
One company I was consulting for didn't observe this principal. I right clicked on an
image and found the path "...com/objects/images". I went to that directory manually
and found a complete listing of the images on that site. That wasn't too important.
Next, I went to the directory below that: "...com/objects" and I hit the jackpot. There
were plenty of goodies, but what caught my eye were the historical pages. They had
changed their prices every month and kept the old pages. I browsed around and
could figure out their profit margin and how low they were willing to go on a contract.
If a potential customer did a little browsing first, they would have had a definite
advantage at the bargaining table.
SSL Many sites use SSL for secure transactions. You know you entered an SSL site
because there will be a browser warning and the HTTP in the location field on the
browser will change to HTTPS. If your development group uses SSL you need to make
sure there is an alternate page for browser with versions less than 3.0, since SSL is
not compatible with those browsers. You also need to make sure that there are
warnings when you enter and leave the secured site. Is there a timeout limit? What
happens if the user tries a transaction after the timeout?

29 Logins
In order to validate users, several sites require customers to login. This makes it
easier for the customer since they don't have to re-enter personal information every
time. You need to verify that the system does not allow invalid usernames/password
and that it does allow valid logins. Is there a maximum number of failed logins
allowed before the server locks out the current user? Is the lockout based on IP? What
if the maximum failed login attempts is three, and you try three, but then enter a
valid login? What are the rules for password selection?

30. Log files

Behind the scenes, you will need to verify that server logs are working properly. Does
the log track every transaction? Does it track unsuccessful login attempts? Does it

Page 26 of 27
only track stolen credit card usage? What does it store for each transaction? IP
address? User name?

31. Scripting languages

Scripting languages are a constant source of security holes. The details are different
for each language. Some exploits allow access to the root directory. Others allow
access to the mail server. Find out what scripting languages are being used and
research the loopholes. It might also be a good idea to subscribe to a security
newsgroup that discusses the language you will be testing.

32. Web Server Testing Features

• Feature: Definition
• Transactions: The nunber of times the test script requested the current URL
• Elapsed time: The number of seconds it took to run the request
• Bytes transferred: The total number of bytes sent or received, less HTTP
headers
• Response time: The average time it took for the server to respond to each
individual request.
• Transaction rate: The average number of transactions the server was able to
handle per second.
• Transference: The average number of bytes transferred per second.
• Concurrency: The average number of simultaneous connections the server
was able to handle during the test session.
• Status code nnn: This indicates how many times a particular HTTP status code
was seen.

Page 27 of 27