Custom Search

Web Terminologies: Useful for web application testers

This article basically covers following terminologies:

What is: Internet, www, TCP/IP, HTTP protocol, SSL (Secure socket layer), HTTPS, HTML, Web servers, Web client, Proxy server, Caching, Cookies, Application server, Thin client, Thick client, Daemon, Client side scripting, Server side scripting, CGI, Dynamic web pages, Digital certificates and list of HTTP status codes


A global network connecting millions of computers.

World Wide Web (the Web)

An information sharing model that is built on top of the Internet,

utilizes HTTP protocol and browsers (such as Internet Explorer) to

access Web pages formatted in HTML that are linked via hyperlinks

and the Web is only a subset of the Internet (other uses of the

Internet include email (via SMTP), Usenet, instant messaging and

file transfer (via FTP)

URL (Uniform Resource Locator)

The address of documents and other content on the Web. It is

consisting of protocol, domain and the file. Protocol can be either

HTTP, FTP, Telnet, News etc., domain name is the DNS name of

the server and file can be Static HTML, DOC, Jpeg, etc., . In other

words URLs are strings that uniquely identify resources on internet.


protocol suite used to send data over the Internet. TCP/IP

consists of only 4 layers - Application layer, Transport layer,

Network layer & Link layer

Internet Protocols:

Application Layer - DNS, TLS/SSL, TFTP, FTP, HTTP, IMAP, IRC,



Transport Layer- TCP, UDP, DCCP, SCTP, IL, RUDP,

Network Layer - IP (IPv4, IPv6), ICMP, IGMP, ARP, RARP, …

Link Ethernet Layer- Wi-Fi, Token ring, PPP, SLIP, FDDI, ATM,

DTM, Frame Relay, SMDS,

TCP (Transmission Control Protocol)

Enables two devices to establish a connection and exchange data.

In the Internet protocol suite, TCP is the intermediate layer

between the Internet Protocol below it, and an application above it.

Applications often need reliable pipe-like connections to each other,

whereas the Internet Protocol does not provide such streams, but

rather only unreliable packets. TCP does the task of the transport

layer in the simplified OSI model of computer networks.

It is one of the core protocols of the Internet protocol suite. Using

TCP, applications on networked hosts can create connections to one

another, over which they can exchange data or packets. The

protocol guarantees reliable and in-order delivery of sender to

receiver data. TCP also distinguishes data for multiple, concurrent

applications (e.g. Web server and e-mail server) running on the

same host.


Specifies the format of data packets and the addressing protocol.

The Internet Protocol (IP) is a data-oriented protocol used for

communicating data across a packet-switched internet work. IP is a

network layer protocol in the internet protocol suite. Aspects of IP

are IP addressing and routing. Addressing refers to how end hosts

become assigned IP addresses. IP routing is performed by all hosts,

but most importantly by internetwork routers

IP Address

A unique number assigned to each connected device, often assigned

dynamically to users by an ISP on a session-by-session basis –

dynamic IP address. Increasingly becoming dedicated, particularly

with always-on broadband connections – static IP address.


A portion of a message sent over a TCP/IP Network. It contains

content and destination

HTTP (Hypertext Transfer Protocol)

Underlying protocol of the World Wide Web. Defines how messages

are formatted and transmitted over a TCP/IP network for Web

sites. Defines what actions Web servers and Web browsers take in

response to various commands.

HTTP is stateless. The advantage of a stateless protocol is that hosts

don't need to retain information about users between requests, but

this forces the use of alternative methods for maintaining users'

state, for example, when a host would like to customize content for

a user who has visited before. The common method for solving this

problem involves the use of sending and requesting cookies. Other

methods are session control, hidden variables, etc

example: when you enter a URL in your browser, an HTTP

command is sent to the Web server telling to fetch and transmit the

requested Web page


HEAD: Asks for the response identical to the one that

would correspond to a GET request, but without the

response body. This is useful for retrieving metainformation

written in response headers, without

having to transport the entire content.


GET : Requests a representation of the specified

resource. By far the most common method used on

the Web today.


POST : Submits user data (e.g. from a HTML form) to

the identified resource. The data is included in the

body of the request.


PUT: Uploads a representation of the specified



DELETE: Deletes the specified resource (rarely



TRACE: Echoes back the received request, so that a

client can see what intermediate servers are adding or

changing in the request.




Returns the HTTP methods that the server supports.

This can be used to check the functionality of a web



CONNECT: For use with a proxy that can change to

being an SSL tunnel.

SSL (Secure Sockets Layer)

Protocol for establishing a secure connection for transmission, it

uses the HTTPS convention

SSL provides endpoint authentication and communications privacy

over the Internet using cryptography. In typical use, only the server

is authenticated (i.e. its identity is ensured) while the client remains

unauthenticated; mutual authentication requires public key

infrastructure (PKI) deployment to clients. The protocols allow

client/server applications to communicate in a way designed to

prevent eavesdropping, tampering, and message forgery.

SSL involves a number of basic phases:


Peer negotiation for algorithm support


Public key encryption-based key exchange and

certificate-based authentication


Symmetric cipher-based traffic encryption


During the first phase, the client and server negotiate

which cryptographic algorithms will be used. Current

implementations support the following choices:


for public-key cryptography: RSA, Diffie-Hellman,

DSA or Fortezza;


for symmetric ciphers: RC2, RC4, IDEA, DES, Triple



For one-way hash functions: MD5 or SHA.


is a URI scheme which is syntactically identical to the http: scheme

normally used for accessing resources using HTTP. Using an https:

URL indicates that HTTP is to be used, but with a different default

port and an additional encryption/authentication layer between

HTTP and TCP. This system was invented by Netscape

Communications Corporation to provide authentication and

encrypted communication and is widely used on the Web for

security-sensitive communication, such as payment transactions.

HTML (Hypertext Markup Language)

The authoring language used to create documents on the World

Wide Web

Hundreds of tags can be used to format and layout a Web page's

content and to hyperlink to other Web content.


Used to connect a user to other parts of a web site and to other web

sites and web-enabled services.

Web server

A computer that is connected to the Internet. Hosts Web content

and is configured to share that content.

Webserver is responsible for accepting HTTP requests from clients,

which are known as Web browsers, and serving them Web pages,

which are usually HTML documents and linked objects (images,




Apache HTTP Server from the Apache Software



Internet Information Services (IIS) from Microsoft.


Sun Java System Web Server from Sun Microsystems,

formerly Sun ONE Web Server, iPlanet Web Server,

and Netscape Enterprise Server.


Zeus Web Server from Zeus Technology

Web client

Most commonly in the form of Web browser software such as

Internet Explorer or Netscape

Used to navigate the Web and retrieve Web content from Web

servers for viewing.

Proxy server

An intermediary server that provides a gateway to the Web (e.g.,

employee access to the Web most often goes through a proxy)

Improves performance through caching and filters the Web

The proxy server will also log each user interaction.


Web browsers and proxy servers save a local copy of the

downloaded content – pages that display personal information

should be set to prohibit caching.

Web form

A portion of a Web page containing blank fields that users can fill in

with data (including personal info) and submits for Web server to

process it.

Web server log

Every time a Web page is requested, the Web server may

automatically logs the following information:


the IP address of the visitor


date and time of the request


the URL of the requested file


the URL the visitor came from immediately before

(referrer URL)


the visitor's Web browser type and operating system


A small text file provided by a Web server and stored on a users PC

the text can be sent back to the server every time the browser

requests a page from the server. Cookies are used to identify a user

as they navigate through a Web site and/or return at a later time.

Cookies enable a range of functions including personalization of


Session vs. persistent cookies

A Session is a unique ID assigned to the client browser by a web

server to identify the state of the client because web servers are


A session cookie is stored only while the user is connected to the

particular Web server – the cookie is deleted when the user


Persistent cookies are set to expire at some point in the future –

many are set to expire a number of years forward


A socket is a network communications endpoint.

Application Server

An application server is a server computer in a computer network

dedicated to running certain software applications. The term also

refers to the software installed on such a computer to facilitate the

serving of other applications. Application server products typically

bundle middleware to enable applications to intercommunicate

with various qualities of service — reliability, security, nonrepudiation,

and so on. Application servers also provide an API to

programmers, so that they don't have to be concerned with the

operating system or the huge array of interfaces required of a

modern web-based application. Communication occurs through the

web in the form of HTML and XML, as a link to various databases,

and, quite often, as a link to systems and devices ranging from huge

legacy applications to small information devices, such as an atomic

clock or a home appliance.

An application server exposes business logic to client applications

through various protocols, possibly including HTTP. the server

exposes this business logic through a component API, such as the

EJB (Enterprise JavaBean) component model found on J2EE (Java

2 Platform, Enterprise Edition) application servers. Moreover, the

application server manages its own resources. Such gate-keeping

duties include security, transaction processing, resource pooling,

and messaging

Ex: JBoss (Red Hat), WebSphere (IBM), Oracle Application Server

10g (Oracle Corporation) and WebLogic (BEA)

Thin Client

A thin client is a computer (client) in client-server architecture

networks which has little or no application logic, so it has to depend

primarily on the central server for processing activities. It is

designed to be especially small so that the bulk of the data

processing occurs on the server.

Thick client

It is a client that performs the bulk of any data processing

operations itself, and relies on the server it is associated with

primarily for data storage.


It is a computer program that runs in the background, rather than

under the direct control of a user; they are usually instantiated as

processes. Typically daemons have names that end with the letter

"d"; for example, syslogd is the daemon which handles the system

log. Daemons typically do not have any existing parent process, but

reside directly under init in the process hierarchy. Daemons usually

become daemons by forking a child process and then making the

parent process kill itself, thus making init adopt the child. This

practice is commonly known as "fork off and die." Systems often

start (or "launch") daemons at boot time: they often serve the

function of responding to network requests, hardware activity, or

other programs by performing some task. Daemons can also

configure hardware (like devfsd on some Linux systems), run

scheduled tasks (like cron), and perform a variety of other tasks.

Client-side scripting

Generally refers to the class of computer programs on the web that

are executed client-side, by the user's web browser, instead of

server-side (on the web server). This type of computer

programming is an important part of the Dynamic HTML

(DHTML) concept, enabling web pages to be scripted; that is, to

have different and changing content depending on user input,

environmental conditions (such as the time of day), or other


Web authors write client-side scripts in languages such as

JavaScript (Client-side JavaScript) or VBScript, which are based on

several standards:


HTML scripting



Document Object Model

Client-side scripts are often embedded within

an HTML document, but they may also be

contained in a separate file, which is referenced

by the document (or documents) that use it.

Upon request, the necessary files are sent to

the user's computer by the web server (or

servers) on which they reside. The user's web

browser executes the script, then displays the

document, including any visible output from

the script. Client-side scripts may also contain

instructions for the browser to follow if the

user interacts with the document in a certain

way, e.g., clicks a certain button. These

instructions can be followed without further

communication with the server, though they

may require such communication.

Server-side Scripting

It is a web server technology in which a user's request is fulfilled by

running a script directly on the web server to generate dynamic

HTML pages. It is usually used to provide interactive web sites that

interface to databases or other data stores. This is different from

client-side scripting where scripts are run by the viewing web

browser, usually in JavaScript. The primary advantage to serverside

scripting is the ability to highly customize the response based

on the user's requirements, access rights, or queries into data



ASP: Microsoft designed solution allowing various

languages (though generally VBscript is used) inside a

HTML-like outer page, mainly used on Windows but

with limited support on other platforms.


ColdFusion: Cross platform tag based commercial

server side scripting system.


JSP: A Java-based system for embedding code in

HTML pages.


Lasso: A Datasource neutral interpreted programming

language and cross platform server.


SSI: A fairly basic system which is part of the common

apache web server. Not a full programming

environment by far but still handy for simple things

like including a common menu.

PHP : Common opensource solution based on

including code in its own language into an HTML



Server-side JavaScript: A language generally used on

the client side but also occasionally on the server side.


SMX : Lisplike opensource language designed to be

embedded into an HTML page.

Common Gateway Interface (CGI)

is a standard protocol for interfacing external application software

with an information server, commonly a web server. This allows the

server to pass requests from a client web browser to the external

application. The web server can then return the output from the

application to the web browser.

Dynamic Web pages:

can be defined as: (1) Web pages containing dynamic content (e.g.,

images, text, form fields, etc.) that can change/move without the

Web page being reloaded or (2) Web pages that are produced onthe-

fly by server-side programs, frequently based on parameters in

the URL or from an HTML form. Web pages that adhere to the first

definition are often called Dynamic HTML or DHTML pages.

Client-side languages like JavaScript are frequently used to produce

these types of dynamic web pages. Web pages that adhere to the

second definition are often created with the help of server-side

languages such as PHP, Perl, ASP/.NET, JSP, and languages. These

server-side languages typically use the Common Gateway Interface

(CGI) to produce dynamic web pages.

Digital Certificates

In cryptography, a public key certificate (or identity certificate) is a certificate

which uses a digital signature to bind together a public key with an identity —

information such as the name of a person or an organization, their address, and

so forth. The certificate can be used to verify that a public key belongs to an


In a typical public key infrastructure (PKI) scheme, the signature will be of a

certificate authority (CA). In a web of trust s

"endorsements"). In either case, the signatures on a certificate are attestations by

the certificate signer that the identity information and the public key belong


Certificates can be used for the large-scale use of public-key cryptography.

Securely exchanging secret keys amongst users becomes impractical to the point

of effective impossibility for anything other than quite small networks. Public key

cryptography provides a way to avoid this problem. In principle, if Alice wants

others to be able to send her secret messages, she need only publish her public

key. Anyone possessing it can then send her secure information. Unfortunately,

David could publish a different public key (for which he knows the related private

key) claiming that it is Alice's public key. In so doing, David could intercept and

read at least some of the messages meant for Alice. But if Alice builds her public

key into a certificate and has it digitally signed by a trusted third party (Trent),

anyone who trusts Trent can merely check the certificate to see whether Trent

thinks the embedded public key is Alice's. In typical Public-key Infrastructures

(PKIs), Trent will be a CA, who is trusted by all participants. In a web of trust,

Trent can be any user, and whether to trust that user's attestation that a

particular public key belongs to Alice will be up to the person wishing to send a

message to Alice.

In large-scale deployments, Alice may not be familiar with Bob's certificate

authority (perhaps they each have a different CA — if both use employer CAs,

different employers would produce this result), so Bob's certificate may also

include his CA's public key signed by a "higher level" CA2, which might be

recognized by Alice. This process leads in general to a hierarchy of certificates,

and to even more complex trust relationships. Public key infrastructure refers,

mostly, to the software that manages certificates in a large-scale setting. In X.509

PKI systems, the hierarchy of certificates is always a top-down tree, with a root

certificate at the top, representing a CA that is 'so central' to the scheme that it

does not need to be authenticated by some trusted third party.

A certificate may be revoked if it is discovered that its related private key has

been compromised, or if the relationship (between an entity and a public key)

embedded in the certificate is discovered to be incorrect or has changed; this

might occur, for example, if a person changes jobs or names. A revocation will

likely be a rare occurrence, but the possibility means that when a certificate is

trusted, the user should always check its validity. This can be done by comparing

it against a certificate revocation list (CRL) — a list of revoked or cancelled

certificates. Ensuring that such a list is up-to-date and accurate is a core function

in a centralized PKI, one which requires both staff and budget and one which is

therefore sometimes not properly done. To be effective, it must be readily

available to any who needs it whenever it is needed and must be updated

frequently. The other way to check a certificate validity is to query the certificate

authority using the Online Certificate Status Protocol (OCSP) to know the status

of a specific certificate.

Both of these methods appear to be on the verge of being supplanted by XKMS.

This new standard, however, is yet to see widespread implementation.

A certificate typically includes:

The public key being signed.

A name, which can refer to a person, a computer or an organization.

A validity period.

The location (URL) of a revocation center.

The most common certificate standard is the ITU-T X.509. X.509 is being

adapted to the Internet by the IETF PKIX working group.


Verisign introduced the concept of three classes of digital certificates:

Class 1 for individuals, intended for email;

Class 2 for organizations, for which proof of identity is required; and

Class 3 for servers and software signing, for which independent verification and

checking of identity and authority is done by the issuing certificate authority (CA)

List of HTTP status codes

1xx Informational

Request received, continuing process.

100: Continue

101: Switching Protocols

2xx Success

The action was successfully received, understood, and accepted.

200: OK

201: Created

202: Accepted

203: Non-Authoritative Information

204: No Content

205: Reset Content

206: Partial Content

3xx Redirection

The client must take additional action to complete the request.

300: Multiple Choices

301: Moved Permanently

302: Moved Temporarily (HTTP/1.0)

302: Found (HTTP/1.1)

see 302 Google Jacking

303: See Other (HTTP/1.1)

304: Not Modified

305: Use Proxy

Many HTTP clients (such as Mozilla and Internet Explorer) don't correctly

handle responses with this status code.

306: (no longer used, but reserved)

307: Temporary Redirect

4xx Client Error

The request contains bad syntax or cannot be fulfilled.

400: Bad Request

401: Unauthorized

Similar to 403/Forbidden, but specifically for use when authentication is possible

but has failed or not yet been provided. See basic authentication scheme and

digest access authentication.

402: Payment Required

403: Forbidden

404: Not Found

405: Method Not Allowed

406: Not Acceptable

407: Proxy Authentication Required

408: Request Timeout

409: Conflict

410: Gone

411: Length Required

412: Precondition Failed

413: Request Entity Too Large

414: Request-URI Too Long

415: Unsupported Media Type

416: Requested Range Not Satisfiable

417: Expectation Failed

5xx Server Error

The server failed to fulfill an apparently valid request.

500: Internal Server Error

501: Not Implemented

502: Bad Gateway

503: Service Unavailable

504: Gateway Timeout

505: HTTP Version Not Supported

509: Bandwidth Limit Exceeded

What is client-server and web based testing and how to test these applications


What is the difference between client-server testing and web based testing and what are things that we need to test in such applications?

Projects are broadly divided into two types of:

  • 2 tier applications
  • 3 tier applications

This type of testing usually done for 2 tier applications (usually developed for LAN)
Here we will be having front-end and backend.

The application launched on front-end will be having forms and reports which will be monitoring and manipulating data

E.g: applications developed in VB, VC++, Core Java, C, C++, D2K, PowerBuilder etc.,
The backend for these applications would be MS Access, SQL Server, Oracle, Sybase, Mysql, Quadbase

The tests performed on these types of applications would be
- User interface testing
- Manual support testing
- Functionality testing
- Compatibility testing & configuration testing
- Intersystem testing

This is done for 3 tier applications (developed for Internet / intranet / xtranet)
Here we will be having Browser, web server and DB server.

The applications accessible in browser would be developed in HTML, DHTML, XML, JavaScript etc. (We can monitor through these applications)

Applications for the web server would be developed in Java, ASP, JSP, VBScript, JavaScript, Perl, Cold Fusion, PHP etc. (All the manipulations are done on the web server with the help of these programs developed)

The DBserver would be having oracle, sql server, sybase, mysql etc. (All data is stored in the database available on the DB server)

The tests performed on these types of applications would be
- User interface testing
- Functionality testing
- Security testing
- Browser compatibility testing
- Load / stress testing
- Interoperability testing/intersystem testing
- Storage and data volume testing

A web-application is a three-tier application.
This has a browser (monitors data) [monitoring is done using html, dhtml, xml, javascript]-> webserver (manipulates data) [manipulations are done using programming languages or scripts like adv java, asp, jsp, vbscript, javascript, perl, coldfusion, php] -> database server (stores data) [data storage and retrieval is done using databases like oracle, sql server, sybase, mysql].

The types of tests, which can be applied on this type of applications, are:
1. User interface testing for validation & user friendliness
2. Functionality testing to validate behaviors, i/p, error handling, o/p, manipulations, services levels, order of functionality, links, content of web page & backend coverage's
3. Security testing
4. Browser compatibility
5. Load / stress testing
6. Interoperability testing
7. Storage & data volume testing

A client-server application is a two tier application.
This has forms & reporting at front-end (monitoring & manipulations are done) [using vb, vc++, core java, c, c++, d2k, power builder etc.,] -> database server at the backend [data storage & retrieval) [using ms access, sql server, oracle, sybase, mysql, quadbase etc.,]

The tests performed on these applications would be
1. User interface testing
2. Manual support testing
3. Functionality testing
4. Compatibility testing
5. Intersystem testing
Some more points to clear the difference between client server, web and desktop applications:

Desktop application:
1. Application runs in single memory (Front end and Back end in one place)
2. Single user only

Client/Server application:
1. Application runs in two or more machines
2. Application is a menu-driven
3. Connected mode (connection exists always until logout)
4. Limited number of users
5. Less number of network issues when compared to web app.

Web application:
1. Application runs in two or more machines
2. URL-driven
3. Disconnected mode (state less)
4. Unlimited number of users
5. Many issues like hardware compatibility, browser compatibility, version compatibility, security issues, performance issues etc.

As per difference in both the applications come where, how to access the resources. In client server once connection is made it will be in state on connected, whereas in case of web testing http protocol is stateless, then there comes logic of cookies, which is not in client server.

For client server application users are well known, whereas for web application any user can login and access the content, he/she will use it as per his intentions.

So, there are always issues of security and compatibility for web application.

Software Testing Certifications

International Certifications:

1) Foundation Level :
Know more at :
2) Advanced Level :
Know more at :

QA institute certifications :

1) Certified Software Tester (CSTE) :
know more at :
2) Certified Software Quality Analyst (CSQA) :
know more at :
3) Certified Software Project Manager (CSPM) :
know more at :

International institute of software testing:

1) Certified Software Test Professional (CSTP) :
know more at :
2) Certified Test Manager (CTM) :
know more at :

Test plan sample: SoftwareTesting and Quality assurance Templates

Test plan is in high demand. Ya it should be! Test plan reflects your entire project testing schedule and approach. This article is in response to those who have demanded sample test plan.
Test plan will include the purpose of test plan i. e to prescribe the scope, approach, resources, and schedule of the testing activities. To identify the items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with this plan.

Test Plan Template:

(Name of the Product)

Prepared by:

(Names of Preparers)




2.1 Objectives
2.2 Tasks


4.0 Testing Strategy
4.1 Alpha Testing (Unit Testing)
4.2 System and Integration Testing
4.3 Performance and Stress Testing
4.4 User Acceptance Testing
4.5 Batch Testing
4.6 Automated Regression Testing
4.7 Beta Testing

5.0 Hardware Requirements

6.0 Environment Requirements
6.1 Main Frame
6.2 Workstation

7.0 Test Schedule

8.0 Control Procedures

9.0 Features to Be Tested

10.0 Features Not to Be Tested

11.0 Resources/Roles & Responsibilities

12.0 Schedules

13.0 Significantly Impacted Departments (SIDs)

14.0 Dependencies

15.0 Risks/Assumptions

16.0 Tools

17.0 Approvals


A brief summary of the product being tested. Outline all the functions at a high level.


2.1 Objectives
Describe the objectives supported by the Master Test Plan, eg., defining tasks and responsibilities, vehicle for communication, document to be used as a service level agreement, etc.

2.2 Tasks
List all tasks identified by this Test Plan, i.e., testing, post-testing, problem reporting, etc.

This section describes what is being tested, such as all the functions of a specific product, its existing interfaces, integration of all functions.

List here how you will accomplish the items that you have listed in the "Scope" section. For example, if you have mentioned that you will be testing the existing interfaces, what would be the procedures you would follow to notify the key people to represent their respective areas, as well as allotting time in their schedule for assisting you in accomplishing your activity?


Describe the overall approach to testing. For each major group of features or feature combinations, specify the approach which will ensure that these feature groups are adequately tested. Specify the major activities, techniques, and tools which are used to test the designated groups of features.

The approach should be described in sufficient detail to permit identification of the major testing tasks and estimation of the time required to do each one.

4.1 Unit Testing

Specify the minimum degree of comprehensiveness desired. Identify the techniques which will be used to judge the comprehensiveness of the testing effort (for example, determining which statements have been executed at least once). Specify any additional completion criteria (for example, error frequency). The techniques to be used to trace requirements should be specified.

List the names of individuals/departments who would be responsible for Unit Testing.

Describe how unit testing will be conducted. Who will write the test scripts for the unit testing, what would be the sequence of events of Unit Testing and how will the testing activity take place?

4.2 System and Integration Testing

List what is your understanding of System and Integration Testing for your project.

Who will be conducting System and Integration Testing on your project? List the individuals that will be responsible for this activity.

Describe how System & Integration testing will be conducted. Who will write the test scripts for the unit testing, what would be sequence of events of System & Integration Testing, and how will the testing activity take place?

4.3 Performance and Stress Testing

List what is your understanding of Stress Testing for your project.

Who will be conducting Stress Testing on your project? List the individuals that will be responsible for this activity.

Describe how Performance & Stress testing will be conducted. Who will write the test scripts for the testing, what would be sequence of events of Performance & Stress Testing, and how will the testing activity take place?

4.4 User Acceptance Testing

The purpose of acceptance test is to confirm that the system is ready for operational use. During acceptance test, end-users (customers) of the system compare the system to its initial requirements.

Who will be responsible for User Acceptance Testing? List the individuals' names and responsibility.

Describe how the User Acceptance testing will be conducted. Who will write the test scripts for the testing, what would be sequence of events of User Acceptance Testing, and how will the testing activity take place?

4.5 Batch Testing

4.6 Automated Regression Testing

Regression testing is the selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still works as specified in the requirements.


4.7 Beta Testing



6.1 Main Frame
Specify both the necessary and desired properties of the test environment. The specification should contain the physical characteristics of the facilities, including the hardware, the communications and system software, the mode of usage (for example, stand-alone), and any other software or supplies needed to support the test. Also specify the level of security which must be provided for the test facility, system software, and proprietary components such as software, data, and hardware.

Identify special test tools needed. Identify any other testing needs (for example, publications or office space). Identify the source of all needs which are not currently available to your group.

6.2 Workstation

Include test milestones identified in the Software Project Schedule as well as all item transmittal events.

Define any additional test milestones needed. Estimate the time required to do each testing task. Specify the schedule for each testing task and test milestone. For each testing resource (that is, facilities, tools, and staff), specify its periods of use.


Problem Reporting
Document the procedures to follow when an incident is encountered during the testing process. If a standard form is going to be used, attach a blank copy as an "Appendix" to the Test Plan. In the event you are using an automated incident logging system, write those procedures in this section.

Change Requests
Document the process of modifications to the software. Identify who will sign off on the changes and what would be the criteria for including the changes to the current product. If the changes will affect existing programs, these modules need to be identified.


Identify all software features and combinations of software features that will be tested.


Identify all features and significant combinations of features which will not be tested and the reasons.


Specify the staff members who are involved in the test project and what their roles are going to be (for example, Mary Brown (User) compile Test Cases for Acceptance Testing). Identify groups responsible for managing, designing, preparing, executing, and resolving the test activities as well as related issues. Also identify groups responsible for providing the test environment. These groups may include developers, testers, operations staff, testing services, etc.


Major Deliverables
Identify the deliverable documents. You can list the following documents:
- Test Plan
- Test Cases
- Test Incident Reports
- Test Summary Reports


Department/Business Area Bus. Manager Tester(s)


Identify significant constraints on testing, such as test-item availability, testing-resource availability, and deadlines.


Identify the high-risk assumptions of the test plan. Specify contingency plans for each (for example, delay in delivery of test items might require increased night shift scheduling to meet the delivery date).
16.0 TOOLS
List the Automation tools you are going to use. List also the Bug tracking tool here.


Specify the names and titles of all persons who must approve this plan. Provide space for the signatures and dates.

Name (In Capital Letters) Signature Date





What is actual testing process in practical or company environment?

Here I focus on software Testing actual working process in the companies. As of now I got good experience of software testing career and day to day testing activities.  So I will try to share more practically rather than theoretically.

Whenever we get any new project there is initial project familiarity meeting. In this meeting we basically discuss on who is client? what is project duration and when is delivery? Who is involved in project i.e manager, Tech leads, QA leads, developers, testers etc etc..?

From the SRS (software requirement specification) project plan is developed. The responsibility of testers is to create software test plan from this SRS and project plan. Developers start coding from the design. The project work is devided into different modules and these project modules are distributed among the developers. In meantime testers responsibility is to create test scenario and write test cases according to assigned modules. We try to cover almost all the functional test cases from SRS.  The data can be maintained manually in some excel test case templates or bug tracking tools.

When developers finish individual modules, those modules are assigned to testers.  Smoke testing is performed on these modules and if they fail this test, modules are reassigned to respective developers for fix. For passed modules manual testing is carried out from the written test cases. If any bug is found that get assigned to module developer and  get logged in bug tracking tool. On bug fix tester do bug verification and regression testing of all related modules. If bug passes the verification it is marked as verified and marked as closed. Otherwise above mentioned bug cycle gets repeated.(I will cover bug life cycle in other post)

Different tests are performed on individual modules and integration testing on module integration. These tests includes Compatibility testing i.e testing application on different hardware, OS versions,  software platform, different browsers etc. Load and stress testing is also carried out according to SRS. Finally system testing is performed by creating virtual client environment. On passing all the test cases test report is prepared and decision is taken to release the product!

So this was a brief outline of process of project life cycle.

Here is detail of each step what testing exactly carried out in each software quality and testing life cycle specified by IEEE and ISO standards:

Review of the software requirement specifications

Objectives is set for the Major releases

Target Date planned for the Releases

Detailed Project Plan is build. This includes the decision on Design Specifications

Develop Test Plan based on Design Specifications

Test Plan : This includes Objectives, Methodology adopted while testing, Features to
be tested and not to be tested, risk criteria, testing schedule, multi-
platform support and the resource allocation for testing.

Test Specifications
This document includes technical details ( Software requirements )
required prior to the testing.

Writing of Test Cases
Smoke(BVT) test cases
Sanity Test cases
Regression Test Cases
Negative Test Cases
Extended Test Cases

Development - Modules developed one by one

Installers Binding: Installers are build around the individual product.

Build procedure :
A build includes Installers of the available products - multiple platforms.

Smoke Test (BVT)  Basic application test to take decision on further testing

Testing of new features
Cross-platform testing
Stress testing and memory leakage testing.

Bug Reporting
Bug report is created

Development - Code freezing
No more new features are added at this point.

Builds and regression testing.

Decision to release the product
Post-release Scenario for further objectives.

Manual and Automation testing Challenges

Software Testing has lot of challenges both in manual as well as in automation. Generally in manual testing scenario developers through the build to test team assuming the responsible test team or tester will pick the build and will come to ask what the build is about? This is the case in organizations not following so-called ‘processes’. Tester is the middleman between developing team and the customers, handling the pressure from both the sides. And I assume most of our readers are smart enough to handle this pressure. Aren’t you?

This is not the case always. Some times testers may add complications in testing process due to their unskilled way of working. In this post I have added most of the testing challenges created due to testing staff, developing staff, testing processes and wrong management decisions.So here we go with the top challenges:

1) Testing the complete application: Is it possible? I think impossible. There are millions of test combinations. It’s not possible to test each and every combination both in manual as well as in automation testing. If you try all these combinations you will never ship the product
2) Misunderstanding of company processes:Some times you just don’t pay proper attention what the company-defined processes are and these are for what purposes. There are some myths in testers that they should only go with company processes even these processes are not applicable for their current testing scenario. This results in incomplete and inappropriate application testing.
3) Relationship with developers:Big challenge. Requires very skilled tester to handle this relation positively and even by completing the work in testers way. There are simply hundreds of excuses developers or testers can make when they are not agree with some points. For this tester also requires good communication, troubleshooting and analyzing skill.
4) Regression testing:When project goes on expanding the regression testing work simply becomes uncontrolled. Pressure to handle the current functionality changes, previous working functionality checks and bug tracking.
5) Lack of skilled testers:I will call this as ‘wrong management decision’ while selecting or training testers for their project task in hand. These unskilled fellows may add more chaos than simplifying the testing work. This results into incomplete, insufficient and ad-hoc testing throughout the testing life cycle.
6) Testing always under time constraint:Hey tester, we want to ship this product by this weekend, are you ready for completion? When this order comes from boss, tester simply focuses on task completion and not on the test coverage and quality of work. There is huge list of tasks that you need to complete within specified time. This includes writing, executing, automating and reviewing the test cases.
7) Which tests to execute first?If you are facing the challenge stated in point no 6, then how will you take decision which test cases should be executed and with what priority? Which tests are important over others? This requires good experience to work under pressure.
8 ) Understanding the requirements:Some times testers are responsible for communicating with customers for understanding the requirements. What if tester fails to understand the requirements? Will he be able to test the application properly? Definitely No! Testers require good listening and understanding capabilities.
9) Automation testing:Many sub challenges - Should automate the testing work? Till what level automation should be done? Do you have sufficient and skilled resources for automation? Is time permissible for automating the test cases? Decision of automation or manual testing will need to address the pros and cons of each process.
10) Decision to stop the testing:When to stop testing? Very difficult decision. Requires core judgment of testing processes and importance of each process. Also requires ‘on the fly’ decision ability.
11) One test team under multiple projects:Challenging to keep track of each task. Communication challenges. Many times results in failure of one or both the projects.
12) Reuse of Test scripts:Application development methods are changing rapidly, making it difficult to manage the test tools and test scripts. Test script migration or reuse is very essential but difficult task.
13) Testers focusing on finding easy bugs:If organization is rewarding testers based on number of bugs (very bad approach to judge testers performance) then some testers only concentrate on finding easy bugs those don’t require deep understanding and testing. A hard or subtle bug remains unnoticed in such testing approach.
14) To cope with attrition:Increasing salaries and benefits making many employees leave the company at very short career intervals. Managements are facing hard problems to cope with attrition rate. Challenges - New testers require project training from the beginning, complex projects are difficult to understand, delay in shipping date!
These are some top software testing challenges we face daily. Project success or failure depends largely on how you address these basic issues.