Tech Landmark Inc. 71 Pond Street 23A, Quincy, MA 02169 [email protected] Private & Confidential 1

Tech Landmark Inc.71 Pond Street 23A, Quincy, MA 02169

[email protected]

Private & Confidential 1

According to the PMBOK: “A project is a temporary endeavor

undertaken to create a unique product or service. ◦ Temporary means that the project has an end date.

◦ Unique means that the project's end result is different than the

results of other functions of the organization.”

Operations is defined as “the recurring activities of an

organization directed toward producing a product or rendering

a service. such activities may include, but are not limited to,

marketing, sales, production, purchasing, human resources,

finance and accounting.”


Project management is concerned with the overall planning & co-

ordination of a project from inception to completion aimed at meeting the

client's requirements & ensuring completion on time, within cost and

required quality standards.

Project management is the application of knowledge, skills, tools and

techniques to a broad range of activities in order to meet the requirements

of the particular project. Project management knowledge and practices are

best described in terms of their 5 component processes.◦ Initiating,

◦ Planning,

◦ Executing,

◦ Controlling and

◦ Closing.


Sign-off - The process of agreeing in writing, to the scope of a project or the

acceptability of a deliverable.

Stakeholders - Specific people or groups who have a stake in the outcome of

the project. Normally they are from within the company, & include internal

clients, management, employees, administrators, etc.

Methodology - A methodology represents a package of practical ideas and

proven practices for a given area of activity, such as the planning, design

development or management of IT-based systems.

Project Plan - A description of the project that divides it into sub-projects,

including start and completion times, responsible parties, interdependence of

work steps, and resources needed.


Business Analysts are responsible for identifying the business needs of

their clients and stakeholders to help determine solutions to business

problems.

Translate what the user is asking for into a technical form that the

programmer or web developer can understand.

Business Analyst elicits, analyzes, validates and documents business,

organizational and/or operational requirements.

The Business Analyst is a key facilitator within an organization, acting as

a bridge between the client, stakeholders and the solution team.


QA analyst is required to create and execute test scripts / cases and validate expected results and log defects.

Such individuals develop and use stringent testing methods.

Creates test plans and executes test cases; by reviewing technical documentation that includes business requirements, functional specs, design, and release content documents.

Software QA involves the entire software development PROCESS:◦ Monitoring and improving the process, making sure that any agreed-upon

standards and procedures are followed, ◦ and ensuring that problems are found and dealt with. It is oriented to

'prevention‘.



The Software Development Life Cycle is a conceptual model used in project

management that describes the stages involved in an IS development project, from

an initial feasibility study through maintenance of the completed application.

Software development is the process of developing software through successive

phases in an orderly way. It is a complicated process as it requires careful planning

and execution to meet the goals. Different phases in this development process

include the actual writing of code, preparation of requirements and objectives, the

design of what is to be coded, and confirmation that what is developed has met

objectives.

Prior to SDLC methods, the development of new systems or software was often

carried out by using the experience and intuition of management and technical

personnel.


The existing system is evaluated. Deficiencies are identified. This can be done by

interviewing users of the system and consulting with support personnel.

The new system requirements are defined. In particular, the deficiencies in the

existing system must be addressed with specific proposals for improvement.

The proposed system is designed. Plans are laid out concerning the physical

construction, hardware, operating systems, programming, communications, and

security issues.

The new system is developed. The new components and programs must be

obtained and installed. Users of the system must be trained in its use, and all

aspects of performance must be tested. If necessary, adjustments must be made at

this stage.


The system is put into use. This can be done in various ways.

The new system can phased in, according to application or

location, and the old system gradually replaced. In some

cases, it may be more cost-effective to shut down the old

system and implement the new system all at once.

Once the new system is up & running, it should be

exhaustively evaluated. Maintenance must be kept up

rigorously at all times. Users of the system should be kept up-

to-date concerning the latest modifications and procedures.


Various SDLC methodologies have been developed to

guide the processes involved, including but not limited

to:

◦ Rational Unified Process,

◦ SUMMIT,

◦ Brainstorming,

◦ The Waterfall Model,

◦ Rapid Application Development (RAD),

◦ Joint Application Development (JAD)

◦ The Fountain Model and,

◦ The Spiral Model.


The Rational Unified Process is an iterative software design method that

describes how to deploy software effectively using commercially proven

techniques.

It is not a rigid process but a process framework that encompasses a

large number of different activities, and is designed to be

tailored/customized according to requirements.

The RUP consists of 4 major stages:

◦ Inception

◦ Elaboration

◦ Construction &

◦ Transition.


The Inception Phase:◦ In this phase a business case which includes: business context, success

factors such as (expected revenue, market recognition, etc), and financial

forecast are established.

◦ Besides a business case, a basic use case model, project plan, initial risk

assessment and a document that generally describes the project (the core

project requirements, constraints and key features) are realized.

The Elaboration Phase:◦ The Elaboration phase is where big things happen, in this phase the problem

domain analysis is made and also the architecture of the project gets its basic

form.

◦ There is big step from this to next because this step means transition from

low-risk operation to high-risk operation.


The Construction Phase◦ In this phase the main focus goes to the development of components and

other features of the system that is being developed. This is the phase

when coding takes place.

◦ At the end of this phase the first release of the software product is

expected and this is a major criterion of its milestone.

The Transition Phase◦ In the transition phase the product moves from the development

organization to the end user. In software world the first release of a

product doesn't mean that the whole system under development will

work.

◦ A subset of the system or the whole system is completed against an

acceptable quality level and after that new releases will be made to the

system until completion and the expected quality level is reached.


The SUMMIT (a.k.a. SUMMIT Ascendant) Tool is an IBM product that contains a wealth of information, standards and proven processes for to help deliver technology projects.

SUMMIT Ascendant is a process solution that delivers a comprehensive library of methods for planning and managing enterprise IT project and programs.

The process framework is supported by tools for planning, estimating, and monitoring a project or portfolio of projects.


Requirements Analysis Phase:

◦ The purpose of this phase is to document the scope, business

objectives, and requirements of the system.

◦ Based upon this input, the project team can then examine the

alternative approaches that can be used to solve the business

problem and recommend an approach.

◦ If business processes have been redesigned in a business process

reengineering or strategy project, then the requirements should be

based on the new processes.


System Prospectus:

◦ Provide the project stakeholders & team with scope, business

objectives, and requirements of the system as well as alternative

approaches that can be used to solve the business problem.

Requirements Specification:

◦ Provides the project stakeholders & team with the complete baselined

set of requirements to solve business problem/opportunity identified

in the Project Charter. Attached as appendix document in the System

Prospectus.

Test Strategy:

◦ Sets the framework for the testing effort, which is expanded in the

Test Plan. Attached as appendix in the System Prospectus.


Solution Definition Phase:

◦ The objective of this phase is a functional or external description for

user approval. This is sometimes called external design.

◦ The System Delivery Specification is the documentary key

deliverable developed during the Solution Definition phase.

◦ It includes information on functions, user interfaces, manual

processes, automated processes, data structures, security, control,

back-up and contingency requirements, as well as relevant error

handling procedures.


System Delivery Specification:

◦ Expands upon the user requirements and outline design documented in the System Prospectus to produce a detailed specification of the system to be delivered.

◦ The focus is still on user requirements; however, the emphasis is on WHAT the system is to do rather than HOW it is to be implemented.

Test Plan:

◦ Expands upon the high-level planning documented in the Test Strategy document.

◦ The combination of the Test Plan and the Test Strategy describe in detail the scope, approach, resources and schedule of the testing activities.


Design Phase:

◦ The Design phase of the project consists of the tasks necessary to describe how the proposed system is to be built or work is to be done. This is sometimes called technical design.

◦ During the Design phase, internal system design will be completed. Upon completion of the Design phase, the Technical System Design Document will be produced.


Technical System Design◦ Describes how the proposed system is to be built, continuing from

the System Delivery Specification document.

Test Case Log◦ Provide a place to track all test cases for all testing stages for the

project and to use as a "Status" of the testing effort.

Defect Reporting Form◦ Provides a structured format for documenting defects that are

identified during testing.

Test Report Form ◦ Summarizes the outcome of the completed test stage and a

recommendation on whether or not the project should proceed to the next Test stage.


Build & Test Phase:

◦ The objective of the Build and Test phase is to construct and test

the final system solution.

◦ During the Build and Test phase the actual programming of the

system, the design and development of user procedures, and the

system and user testing of the entire system will be completed.


◦ Consolidated User Procedures The User Procedures Development tasks produce the following

three documentary deliverables: User Procedures Manual User Staff and Resources Requirements Training Program.

◦ Accepted System The Accepted System is the new system that is accepted by the

user before it moves to production. The Accepted System

documentation includes the following:


◦ Acceptance Approvals

These are formal documents received from the User accepting the

new system.

◦ Unresolved Issues

This is a list of all issues that were documented from the user

acceptance tests. Identify each issue along with the action plan and

responsible person to resolve it.

◦ Acceptance Tested Software

The Acceptance Tested Software is the new system supported by

the assurance that it has been successfully tested from the user

perspective and has satisfactorily met the user expectations.


Transition Phase:

◦ The objective of the final phase of most projects is to transition to live operation. It should also set the stage for a Post-Implementation Review on larger projects.


The key or major client deliverables of the Transition phase activities

include the Converted Data and the Production System supported by

the Production System Review Report.

The user accepted production system from the Testing phase is

converted into a production system. Following the User Transition Sign-

Off directive, the new system is the only production system that is

officially supported by the IT staff and user management.

The Production System Review Report is completed in a few weeks

following the official cut over date. It is used by IT and user

management as a base for action to resolve any pending problems and

reassurance that the project is completed and the user is getting the

expected benefits.


The Waterfall Model is a software development model describing the naive

approach to software development in which development is seen as

flowing steadily through the phases of requirements analysis, design,

implementation, testing (validation), integration, and maintenance.

Often considered the classic approach to the SDLC, the Waterfall Model

describes a development method that is linear and sequential.

Waterfall development has distinct goals for each phase of development.

Once a phase of development is completed, the development proceeds to

the next phase and there is no turning back.


It is a method used to generate ideas on causes and possible solutions

to process problems. A brainstorming session usually involves a group

of people getting together and listing ideas. Analysis and commentary

on ideas is held off until after the brainstorming session has concluded.

A group process used to generate a large number of ideas about

specific issues in a non-judgmental environment.

Brainstorming is typically used as a synonym for ”talking in a group”. It

is a highly structured process to help generate ideas that is based on

the principle that you cannot generate & evaluate ideas at the same

time. You must first gain agreement from the group to try brainstorming

for a fixed interval.


Rational Unified Process

SUMMIT Methodology

Waterfall Method

Inception Requirements Analysis Requirements Analysis

Elaboration Solution Definition Design

Construction Design Implementation

Transition Build and Test Testing

Transition Integration

Maintenance


In software engineering, a requirement is a description of what a

system should do. Systems may have from dozens to hundreds of

requirements.

A requirement describes a condition to which a system must conform;

either derived directly or indirectly from user needs. A requirement for a

computer system specifies what you want or desire from a system.

Requirements should be:

◦ unique in scope,

◦ precise in wording,

◦ bounded by concrete expectations and

◦ irrefutably testable.


Is it Unique?◦ Is this the only requirement that defines this particular objective?

Is it Precise?◦ Are there any vague words that are difficult to interpret?

Is it Bounded?◦ Are there concrete boundaries in the objectives?

Is it Testable?◦ Can you build one or more test cases that will completely verify all

aspects of this requirement?


Example:◦ “The system response time shall always be reasonable

for all critical transactions.”

Revised Answer: “The system response time for “end-to-end transactions” for

“Download” shall always be “less than 5 seconds.””


There is a distinct difference between requirements and

specifications.◦ A requirement is a condition needed by a user to solve a problem or

achieve an objective.

◦ A specification is a document that specifies, in a complete, precise,

verifiable manner, the requirements, design, behavior, or other

characteristics of a system, and often, the procedures for determining

whether these provisions have been satisfied.

For example, a requirement for a car could be that the maximum

speed to be at least 120mph. The specification for this

requirement would include technical information about specific

design aspects.


An SRS is basically an organization's understanding (in writing) of a

customer or potential client's system requirements and dependencies

at a particular point in time (usually) prior to any actual design or

development work.

It's a two-way insurance policy that assures that both the client and

the organization understand the other's requirements from that

perspective at a given point in time.

The SRS document itself states in precise and explicit language those

functions and capabilities a software system (i.e., a software

application, an eCommerce Web site, and so on) must provide, as well

as states any required constraints by which the system must abide.


The SRS also functions as a blueprint for completing a project with as

little cost growth as possible. The SRS is often referred to as the

“parent” document because all subsequent project management

documents, such as design specifications, statements of work,

software architecture specifications, testing and validation plans, and

documentation plans, are related to it.

It's important to note that an SRS contains functional and

nonfunctional requirements only; it doesn't offer design suggestions,

possible solutions to technology or business issues, or any other

information other than what the development team understands the

customer's system requirements to be.


SRS is typically developed during the first stages of “Requirements

Development” which is the initial product development phase in which

information is gathered about what requirements are needed or not. This

information-gathering stage can include onsite visits, questionnaires,

surveys, interviews, and perhaps a (ROI) analysis or needs analysis of the

customer or client's current business environment.

A well-designed, well-written SRS accomplishes four major goals:◦ It provides feedback to the customer. An SRS is the customer's assurance that

the development organization understands the issues or problems to be solved

and the software behavior necessary to address those problems. Therefore, the

SRS should be written in natural language versus a formal language in an

unambiguous manner that may also include charts, tables, data flow diagrams,

decision tables, and so on.


◦ It decomposes the problem into component parts. The simple act of writing

down software requirements in a well-designed format organizes information,

places borders around the problem, solidifies ideas, and helps break down

the problem into its component parts in an orderly fashion.

◦ It serves as an input to the design specification. As mentioned previously, the

SRS serves as the parent document to subsequent documents, such as the

software design specification and statement of work. Therefore, the SRS

must contain sufficient detail in the functional system requirements so that a

design solution can be devised.

◦ It serves as a product validation check. The SRS also serves as the parent

document for testing and validation strategies that will be applied to the

requirements for verification.


The User Requirements Specification is a document produced by, or on behalf

of your organization, which documents the purposes for which a system is

required - its functional requirements - usually in order of priority / gradation.

While the URS will not usually probe the technical specification, it will

however outline the expectations and, where essential may provide further

detail e.g. the UI, say Microsoft Windows, & the expected hardware platform

etc.

The URS is an essential document which outlines precisely what the user is

expecting from this system. The term User Requirement Specification can

also incorporate the functional requirements of the system or may be in a

separate document labeled the Functional Requirements Specification - the

FRS.


These are the requirements that express what a software solution should do to

solve some customer problem. Traditionally, functional requirements describe

what tangible outputs are produced by a software solution for a given suite of

inputs.

Functional requirements capture the intended behavior of the system. This

behavior may be expressed as services, tasks or functions the system is

required to perform.

Functional requirements also include behavior rules, standards, policies, and

other factors from the customer problem space that affect what the software

needs to do to the inputs in order to provide the specified outputs.

These are the type of behavior you want the system to perform.


If you were buying vehicles for a business your functional

requirement might be:◦ The vehicle should be able to take a load from a warehouse to a

shop.

Similarly for a computer system you define what the system is

to do. For example:◦ The system should store all details of a customer’s order.

The important point to note is that WHAT is wanted is

specified, and not HOW it will be delivered.


A Use Case is a top level category of system functionality (i.e.: Log on,

Shut down, etc.). A Use Case has graphical representation and/or a

text description.

The diagram or description identifies all the actors (outside of the

system) involved in the function, as well as an indication of how the

Use Case is initiated. The collection of Use Case diagrams provides a

‘context’ diagram of system interfaces.

Each Use Case constitutes a complete list of events initiated by an

Actor and it specifies the interaction that takes place between an

Actor and the System. In a Use Case the system is viewed as opaque,

where only the inputs, outputs, and functionality matter.


A use case defines a goal-oriented set of interactions between external

actors and the system under consideration. Actors are parties outside

the system that interact with the system.

◦ A primary actor is one having a goal requiring the assistance of the system. A

secondary actor is one from which the system needs assistance.

A use case is initiated by a user with a particular goal in mind, and

completes successfully when that goal is satisfied. It describes the

sequence of interactions between actors and the system necessary to

deliver the service that satisfies the goal. The Use Case also includes

possible variants of this sequence, e.g., alternative sequences that may

also satisfy the goal, sequences that may lead to failure to complete the

service due to exceptional behavior, error handling, etc.


The system is treated as a "black box", and the interactions with

system, including system responses, are as perceived from outside

the system.

Thus, use cases capture who (actor) does what (interaction) with

the system, for what purpose (goal), without dealing with system

internals.

A complete set of use cases specifies all the different ways to use

the system, and therefore defines all behavior required of the

system, bounding the scope of the system.


The Use Case diagram just provides a quick overview of the

relationship of actors to Use Cases. The meat of the Use Case is the

text description. This text will contain the following:◦ Name

◦ Brief Description

◦ SRS Requirements Supported

◦ Pre & Post Conditions

◦ Event Flow

The requirements in the SRS are each uniquely numbered so that they

may be accounted for in the verification testing. These requirements

should be mapped to the Use Case that satisfies them for

accountability.


The Pre-Condition specifies the required state of the system

prior the start of the Use Case. This can be used for a similar

purpose in the Test Case.

The Post-Condition is the state of the system after the actor

interaction. This may be used for test pass/fail criteria.

The event flow is a description (usually a list) of the steps of the

actor’s interaction with the system and the system’s required

response. Recall that system is viewed as a black box. The

event flow contains exceptions, which may cause alternate

paths through the event flow.


Monitor and control the normal entry and exit of building

occupants through the use of personal security cards.

This includes entry and exit of the building proper, and

entry and exit from particular security zones within the

building.

The system controls the locks on the doors, and will not

unlock a door unless the appropriate security card is

swiped through the card reader by the door.


Enter Building Event Flow

◦ Use case starts when user slides card through card-reader

◦ Card-reader scans employee ID from card [E1]

◦ System validates employee access [E2]

◦ System unlocks door for configured time period [E3]

◦ Employee opens door [E4]

◦ Employee enters and door shuts [E5]

◦ System locks door [E6],

◦ Use Case ends


The following events and the associated exceptions can then be generated for the

Enter Building use case.◦ Use case starts when the user slides a card through the card-reader

◦ Card-reader scans employee ID from card

Exception 1: ◦ Card can’t be read

◦ Log event

◦ Use case ends

◦ System validates employee access

Exception 2:◦ Employee ID is invalid

◦ Log event

◦ Use case ends

◦ System unlocks door for configured time period


Exception 3: ◦ System unable to unlock door

◦ Log event

◦ Use case ends

◦ Employee opens door

Exception 4: ◦ Door is not opened

◦ System waits for timeout

◦ System locks door

◦ Use case ends

◦ Employee enters and door shuts


Exception 5:◦ Door is not shut


◦ System attempts to lock door

◦ Log event

◦ Set alarm condition

◦ Use case ends

◦ System locks door, Use case ends

Exception 6:◦ Door fails to lock


◦ System attempts to lock door

◦ Log event

◦ Set alarm condition

◦ Use case ends


For this Use Case, based on the above events and exceptions, we

have derived the following Test Case.

Test Condition 1:◦ Happy days scenario – valid employee card is used

◦ Swipe card

◦ Verify door is unlocked

◦ Enter building

◦ Verify door is locked

Test Condition 2:◦ Card can’t be read

◦ Swipe a card that is not valid

◦ Verify event is logged


Test Condition 3:◦ Invalid employee ID

◦ Swipe card with invalid employee ID

◦ Verify door is not unlocked


Test Condition 4:◦ System unable to unlock door

◦ Swipe card

◦ “Injected” failure of unlocking mechanism


Test Condition 5:◦ Door is not opened

◦ Swipe card

◦ Verify door is unlocked

◦ Don’t open the door and wait until timeout is exceeded

◦ Verify door is locked


Test Condition 6:◦ Door is not shut after entry

◦ Swipe card

◦ Enter building

◦ Hold door open until timeout is exceeded

◦ Verify alarm is sounded


Test Condition 7:◦ Door fails to lock

◦ Swipe card

◦ Enter building

◦ “Injected” failure of locking mechanism

◦ Verify alarm is sounded



The requirements traceability matrix is a table used to trace project

life cycle activities and work products to the project requirements.

The matrix establishes a thread that traces requirements from

identification through implementation.

In a software development process, the traceability matrix is a table

that correlates the high-level requirements (sometimes known as

Marketing Requirements) and detailed requirements of the software

product to the matching parts of high-level design, detailed Design,

test plan (a.k.a. Test Outline), and test case. It can also be used

between any two documents that require a many to many relationship

to determine completeness.


In information technology, gap analysis is the study of the differences

between two different information systems or applications, often for the

purpose of determining how to get from one state to a new state.

A gap is sometimes spoken of as “the space between where we are and

where we want to be.” Gap analysis is undertaken as a means of bridging

that space.

The process of determining, documenting, and approving the variance

between business requirements and system capabilities in terms of

packaged application features and technical architecture.

The process of determining and evaluating the variance or distance between

two items’ properties being compared. It is an analysis of the gap between

requirements that are met and not met; a deficiency assessment.


The identification of critical business processes, and the potential damage or loss that

may be caused to the organization resulting from a disruption to those processes.

Business impact analysis (BIA) is an essential component of an organization's business

continuance plan; it includes components to reveal any vulnerabilities, and a planning

component to develop strategies for minimizing risk. The result of analysis is a BIA report,

which describes the potential risks specific to the organization studied.

One of the basic assumptions behind BIA is that every component of the organization is

reliant upon the continued functioning of every other component, but that some are more

crucial than others and require a greater allocation of funds in the wake of a disaster.

For example, a business may be able to continue more or less normally if the cafeteria

has to close, but would come to a complete halt if the information system crashes.


The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems.

UML includes a standardized graphical notation that may be used to create an abstract model of a system: the UML model.

The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems.

The UML is a very important part of developing object oriented software and the software development process.

The UML uses mostly graphical notations to express the design of software projects.

Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.


UML diagrams commonly created in visual modeling tools include:

◦ Use Case Diagram displays the relationship among actors and use cases.

◦ Class Diagram models class structure and contents using design elements

such as classes, packages and objects. It also displays relationships such as

containment, inheritance, associations and others.

◦ Interaction Diagrams Sequence Diagram displays the time sequence of the objects

participating in the interaction. This consists of the vertical dimension

(time) and horizontal dimension (different objects). Collaboration Diagram displays an interaction organized around the

objects and their links to one another. Numbers are used to show the

sequence of messages.


◦ State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and actions.

◦ Activity Diagram displays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal processing.

◦ Physical Diagrams Component Diagram displays the high level packaged structure of the code

itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some components exist at compile time, at link time, at run times well as at more than one time.

Deployment Diagram displays the configuration of run-time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units.


A use case is a set of scenarios that describing an interaction

between a user and a system. A use case diagram displays the

relationship among actors and use cases. The two main

components of a use case diagram are use cases and actors.

An actor represents a user or another system that will interact

with the system you are modeling. A use case is an external

view of the system that represents some action the user might

perform in order to complete a task.


Actor Use Case

Activity diagrams describe the workflow behavior of a system. Activity diagrams are similar to state diagrams because activities are

the state of doing something. The diagrams describe the state of activities by showing the sequence

of activities performed. Activity diagrams can show activities that are

conditional or parallel. The main reason to use activity diagrams is to model the workflow

behind the system being designed. Activity Diagrams are also useful for analyzing a use case by

describing what actions need to take place and when they should

occur; describing a complicated sequential algorithm; and modeling

applications with parallel processes.



Objects have behaviors and state. The state of an object depends on its

current activity or condition. A statechart diagram shows the possible

states of the object and the transitions that cause a change in state.

As shown in example, the notation set of the statechart diagram has five

basic elements: the initial starting point, which is drawn using a solid

circle; a transition between states, which is drawn using a line with an

open arrowhead; a state, which is drawn using a rectangle with rounded

corners; a decision point, which is drawn as an open circle; and one or

more termination points, which are drawn using a circle with a solid circle

inside it.

To draw a statechart diagram, begin with a starting point and a transition

line pointing to the initial state of the class.



Identifies the data required by the business. An entity corresponds to a

person, place thing, event, or concept about which we are interested in

recording data.

Entities must be clearly defined so that all understand exactly what is

being represented.

2 entities whose information is somehow dependent on one another or

connected with each other are said to have a relationship between them.

Relationships are evaluated in both directions to determine what type of

relationship exists (e.g. “1 friend may have many telephones”, and “1

telephone belongs to a single friend”).


Entities are drawn in boxes. Entities should be expressed in the plural. The existence of a relationship between two entities is drawn as a line

connecting the entities. Arrows at the ends of the lines indicate different types of relationships (one-to-

one, one-to-many, many-to-many). Verbs may be placed on the relationship lines that describe what the

relationships mean (e.g. “addresses locate businesses”, where “addresses” and

“businesses” are related entities, and “locate” is the verb describing the

relationship). Lists of attributes are developed as you go. (An attribute is a single piece of

information that is descriptive of an entity, e.g. friend name, friend e-mail). A single attribute for each entity is selected (or an arbitrary one is assigned) as

being the unique identifier for each occurrence of the entity (e.g. business id

number to uniquely identify a business).


SELECT Statement - The SELECT statement is used to select data from a table.◦ SELECT column_name(s)

FROM table_name

INSERT INTO Statement - The INSERT INTO statement is used to insert new rows into a table.◦ INSERT INTO table_name (column1, column2,...)

VALUES (value1, value2,....)

UPDATE Statement - The UPDATE statement is used to modify the data in a table.◦ UPDATE table_name

SET column_name = new_value WHERE column_name = some_value


UPDATE Statement - The UPDATE statement is used to modify the data in a table.◦ UPDATE table_name

SET column_name = new_value WHERE column_name = some_value

DELETE Statement - The DELETE statement is used to delete rows in a table.◦ DELETE FROM table_name

WHERE column_name = some_value

ORDER BY - The ORDER BY keyword is used to sort the result.◦ SELECT column_name1, column_name2 FROM table_name

ORDER BY cloumn_name1



Programmers are experts at building software.

Testers are experts at breaking software.

Programmers & Testers have a common objective.

Destructive attitude while testing.

Constructive attitude for dealing with the developer.


The function of software quality that assures that the standards,

processes, and procedures are appropriate for the project and are

correctly implemented.

Quality assurance is the planned and systematic set of activities that

ensures that software processes and products conform to

requirements, standards, and procedures.

◦ Processes include all of the activities involved in designing, developing,

enhancing, and maintaining software.

◦ Products include the software, associated data, its documentation, and all

supporting and reporting paperwork.


The process of exercising software to verify that it satisfies specified

requirements and to detect errors.

Testing involves operation of a system or application under controlled

conditions to evaluate results.

The controlled conditions should include both normal and abnormal

conditions.

Testing should intentionally attempt to make things go wrong to

determine if things happen when they shouldn't or things don't

happen when they should. It is oriented towards “detection”.


Programmers are too close to their product.

Misinterpretation of the specifications.

Programmers usually do not test from product point of view.

Developers are building more complex systems in shorter time.

Need to ensure system works before its is turned over to the business.

Track defects in the newly developed software/system.


Miscommunication or lack of communication.

Software Complexity / Software Development Tools.

Programming Errors.

Changing Requirements.

Time Pressures.

Poorly Documented Code.


A test case is a document that describes an input, action, or event and an

expected response.

A QA engineer or other tester performs the test case scenario to determine if a

specific feature of an application is working correctly.

The process of developing test cases can help find problems in the

requirements or design of an application since test case development requires

thinking through the complete operation of the application. For this reason, it is

useful to prepare test cases early in the development cycle.

A test case contains:

◦ Detailed test set-up instructions.

◦ Detailed test procedure, including all steps or actions.

◦ Expected results and pass/fail criteria.


Requirement writers and developers often do not know the full scope

of how the system will be used.

Test the system in a way that it is not intended to be used.

Deviations may occur due to the variety of reasons:

◦ User Errors.

◦ Program Errors.

◦ Data Errors.

System should handle deviations gracefully.


Use your imagination and ask “How can I break the system?”

◦ Invalid data (type, size, structure, special symbols, etc)

◦ Invalid syntax (keywords, delimiters, separators, terminators,

operators, constructions, combinations, etc)

◦ Invalid objects/resources (non-existent, invalid type, inaccessible,

protected, etc.)

◦ Invalid sequence (operations, tasks, keystrokes, mouse clicks, etc.)

◦ Invalid limits (data, items, characteristics, number of data items,

table size, query size, I/O streams, file size).

◦ Invalid configuration parameters (home directory, log file location,

database connection names, maximum number of resources, etc.) Therefore we should have positive scenarios and negative scenarios.


Commonly used to refer to the instructions for a particular test that

will be carried out by an automated test tool.

Test script refers to a short program usually written in scripting

language which can test some set of features of the system under test

(SUT). Test scripts are used to automate software testing.

Automatically executed test scripts are used for regression testing.

This is a document, developed alongside the functional specification,

which provides a checklist for testing your system after release from

the programmers. It outlines the tasks that the system should be able

to perform and the people who can perform those tasks.


Requirements Phase◦ Determine the test strategy.

◦ Determine adequacy of requirements.

Design Phase◦ Determine consistency of design with requirements.

◦ Determine adequacy of design.

◦ Generate structural and functional test conditions.

Program (Build) Phase◦ Determine consistency with design.

◦ Determine adequacy of implementation.

◦ Generate structural and functional test conditions for programs/units.


Test Phase◦ Determine adequacy of the test plan.

◦ Test application system.

Installation Phase◦ Place tested system into production.

Maintenance Phase◦ Modify and retest.


What is Positive Testing?◦ Positive testing is that testing which attempts to show that

a given module of an application does not do what it is

supposed to do.

What is Negative Testing?◦ Negative testing is that testing which attempts to show

that the module does something that it is not supposed to

do.


Verification:◦ Involves reviews and meetings to evaluate documents,

plans, code, requirements and specifications. Verification

checks whether we are building the right system.

Validation:◦ Involves actual testing and takes place after verification.

Validation checks whether we are building the system right.


Verification Strategy

Explanation Deliverable

Requirements Review

The study and discussions of the computer system requirements to ensure they meet stated user needs and are feasible.

Reviewed statement of requirements.

Design Review The study and discussion of the computer system design to ensure it will support the system requirements.

System Design Document, Hardware Design Document.

Code Walkthrough

Informal analysis of the program source code to find defects and verify coding techniques.

Software ready for initial testing by the developer.

Code Inspection

Formal analysis of the program source code to find defects as defined by meeting system design specification.

Software ready for testing by the testing team.


Validation Strategy


Unit Testing Testing of single program, modules, or unit of code.

Software unit ready for testing with other system component.

Integration Testing

Testing of related programs, modules, or units of code.

Portions of the system ready for testing with other portions of the system.

System Testing

Testing of entire computer system. This kind of testing can include functional and structural testing.

Tested computer system, based on what was specified to be developed.

Performance Testing

Testing of the application for the performance at stipulated times and stipulated number of users.

Stable application performance.


Validation Strategy


Alpha Testing

Testing of the entire computer system before rolling out to the UAT.

Stable application.

User Acceptance Testing (UAT)

Testing of computer system to make sure it will work in the system regardless of what the system requirements indicate.

Tested and accepted system based on the user needs.

Installation Testing

Testing of the Computer System during the Installation at the user place.

Successfully installed application.

Beta Testing Testing of the application after the installation at the client place.

Successfully installed and running application.


Acceptance Testing ◦ Testing the system with the intent of confirming readiness of the product and customer

acceptance.

Ad Hoc Testing ◦ Testing without a formal test plan or outside of a test plan. With some projects this type of

testing is carried out as an adjunct to formal testing. If carried out by a skilled tester, it

can often find problems that are not caught in regular testing. Sometimes, if testing occurs

very late in the development cycle, this will be the only kind of testing that can be

performed. Sometimes ad hoc testing is referred to as exploratory testing.

Alpha Testing ◦ Testing after code is mostly complete or contains most of the functionality and prior to

users being involved. Sometimes a select group of users are involved. More often this

testing will be performed in-house or by an outside testing firm in close cooperation with

the software engineering department.


Automated Testing ◦ Software testing that utilizes a variety of tools to automate the testing process and when

the importance of having a person manually testing is diminished. Automated testing still

requires a skilled quality assurance professional with knowledge of the automation tool

and the software being tested to set up the tests.

Beta Testing ◦ Testing after the product is code complete. Betas are often widely distributed or even

distributed to the public at large in hopes that they will buy the final product when it is

released.

Compatibility Testing ◦ Testing used to determine whether other system software components such as browsers,

utilities, and competing software will conflict with the software being tested.


Configuration Testing◦ Testing to determine how well the product works with a broad range of

hardware/peripheral equipment configurations as well as on different operating systems

and software.

Functional Testing ◦ Testing two or more modules together with the intent of finding defects, demonstrating

that defects are not present, verifying that the module performs its intended functions as

stated in the specification and establishing confidence that a program does what it is

supposed to do.

Independent Verification and Validation (IV&V) ◦ The process of exercising software with the intent of ensuring that the software system

meets its requirements and user expectations and doesn't fail in an unacceptable manner.

The individual or group doing this work is not part of the group or organization that

developed the software. A term often applied to government work or where the

government regulates the products, as in medical devices.


Installation Testing ◦ Testing with the intent of determining if the product will install on a variety of platforms

and how easily it installs.

Integration Testing ◦ Testing two or more modules or functions together with the intent of finding interface

defects between the modules or functions. Testing completed at as a part of unit or

functional testing, and sometimes, becomes its own standalone test phase. On a larger

level, integration testing can involve a putting together of groups of modules and

functions with the goal of completing and verifying that the system meets the system

requirements. (see system testing)

Load Testing ◦ Testing with the intent of determining how well the product handles competition for

system resources. The competition may come in the form of network traffic, CPU

utilization or memory allocation.


Performance Testing◦ Testing with the intent of determining how quickly a product handles a variety of events.

Automated test tools geared specifically to test and fine-tune performance are used most

often for this type of testing.

Pilot Testing ◦ Testing that involves the users just before actual release to ensure that users become

familiar with the release contents and ultimately accept it. Often is considered a Move-to-

Production activity for ERP releases or a beta test for commercial products. Typically

involves many users, is conducted over a short period of time and is tightly controlled.

(see beta testing)

Regression Testing ◦ Testing with the intent of determining if bug fixes have been successful and have not

created any new problems. Also, this type of testing is done to ensure that no degradation

of baseline functionality has occurred.


Security Testing◦ Testing of database and network software in order to keep company data and resources

secure from mistaken/accidental users, hackers, and other malevolent attackers.

Software Testing ◦ The process of exercising software with the intent of ensuring that the software system

meets its requirements and user expectations and doesn't fail in an unacceptable manner.

The organization and management of individuals or groups doing this work is not relevant.

This term is often applied to commercial products such as internet applications. (contrast

with independent verification and validation)

Stress Testing ◦ Testing with the intent of determining how well a product performs when a load is placed

on the system resources that nears and then exceeds capacity.


System Integration Testing◦ Testing a specific hardware/software installation. This is typically performed on a COTS

(commercial off the shelf) system or any other system comprised of disparent parts where

custom configurations and/or unique installations are the norm.

User Acceptance Testing◦ Same As Acceptance Testing.


Types Of Testing


Requirements Review

Design Review

Code Walkthrough

Code Inspection

Integration Testing

Unit Testing

System Testing

Performance Testing

Alpha Testing

User Acceptance Testing

Installation Testing

Beta Testing

Test Phases

A software testing technique whereby the internal workings of the item being tested are not known by the tester.

For example, in a black box test on a software design the tester only knows the inputs and what the expected outcomes should be and not how the program arrives at those outputs.

The tester does not ever examine the programming code and does not need any further knowledge of the program other than its specifications.

Black-box test design treats the system as a "black-box", so it doesn't explicitly use knowledge of the internal structure.

Black-box test design is usually described as focusing on testing functional requirements.

Synonyms for black-box include: behavioral, functional, opaque-box, and closed-box.


Advantages:◦ The test is unbiased because the designer and tester are independent of

each other.

◦ The tester does not need knowledge of any programming languages.

◦ The test is done from the point of view of the user, not the designer.

◦ Test cases can be designed as soon as the specifications are complete.

Disadvantages:◦ The test can be redundant if the software designer has already run a test

case.

◦ The test cases are difficult to design.

◦ Testing every possible input stream is unrealistic because it would take a

inordinate amount of time; therefore, many program paths will go untested.


Black Box Testing

A software testing technique whereby explicit knowledge of the internal

workings of the item being tested are used to select the test data.

White-box test design allows one to peek inside the "box" & focuses

specifically on using internal knowledge of the software to guide the selection

of test data.

Synonyms for white-box include: structural, glass-box and clear-box.

Unlike black box testing, white box testing uses specific knowledge of

programming code to examine outputs.

The test is accurate only if the tester knows what the program is supposed to

do. He or she can then see if the program diverges from its intended goal.


Navigation:

◦ Web-based applications allow the users to move around in a way that is much more unpredictable that in more traditional applications.

◦ Hyperlinks allow jumping between screens, data, applications, and servers in more arbitrary sequence.

◦ Testing user workflow for such applications is not straightforward as for more traditional applications.

◦ However, it should still be possible to construct reasonable workflow scenarios that many users may want to pursue.


Creative:

◦ Deviations to the workflow should be tested, such as jumping in and

out of a specific workflow and repeatedly revisiting certain areas.

◦ Testers should now verify that all hyperlinks are complete and

resources that are not reachable from anywhere else in the

application.

◦ In Web world resources are reachable in more than one way; for

example a section of a document can be reached either by scrolling

or by a direct jump through a hyperlink.


◦ Tester should explore what occurs if a hyperlink does a non-

existent, inappropriate, or damaged object.

◦ The environment in which web-based applications run is more

unpredictable and chaotic.

◦ Performance testing or stress testing of this environment will be

determined if the product will be used on the internet or intranet.

◦ Different types of http browsers with their own distinct behavior.


Test Environment consists of hardware, software, test data, test scripts and test automation tools.

Test Environment should be on different machines, network and have an independent set of libraries from development environment.

The Test Environment should documented in the Test Strategy document.

The Test Environment must be ready before testing starts.

It is critical that developers should not be updating the software.


Nonconformance to requirements or functional / program

specification.

A discrepancy between a test case and the product

requirements, design, or implementation. Defects can also

occur in the test case itself.

Popularly known as a bug. A programming error that causes

the program to fail, i.e. not accomplish its nominal task.

is a failure to conform to requirements.



The Tester finds the Bug while testing.

Tester reports the Defect in the Defect Tracking Tool w/

Status “Open”

The concerned developer is informed about the Defect.

The Developer fixes the Defect.

The Developer changes the Status to “Resolved”.

The Tester Re-Tests and changes Status to “Closed”.

If the Defect re-occurs, the status changes to “Re-Open”

Defect Tracking Life Cycle

This section defines a defect Severity Scale framework for determining defect

criticality and the associated defect Priority Levels to be assigned to errors

found in the software/application being tested.

The defects can be classified as follows:

◦ Critical: There is s functionality block. The application is not able to proceed any further.

◦ Major: The application is not working as desired. There are variations in the functionality.

◦ Minor: There is no failure reported due to the defect, but certainly needs to be rectified.

◦ Cosmetic: Defects in the User Interface or Navigation.

◦ Suggestion: Feature which can be added for betterment.


The priority level describes the time for resolution of the defect. The priority level would be classified as follows:

Immediate: Resolve the defect with immediate effect.

At the Earliest: Resolve the defect at the earliest, on priority at the second level.

Normal: Resolve the defect whenever possible.

Later: Could be resolved at the later stages.


A software project test plan is a document that describes the

objectives, scope, approach, and focus of a software testing effort. The

process of preparing a test plan is a useful way to think through the

efforts needed to validate the acceptability of a software product.

The completed document will help people outside the test group

understand the 'why' and 'how' of product validation. It should be

thorough enough to be useful but not so thorough that no one outside

the test group will read it.

The following are some of the items that might be included in a test

plan, depending on the particular project:


Title of the Project Identification of document including version numbers Revision history of document including authors, dates, approvals Table of Contents Purpose of document, intended audience Objective of testing effort Software product overview Relevant related document list, such as requirements, design documents, other

test plans, etc. Relevant standards or legal requirements Traceability requirements Relevant naming conventions and identifier conventions Test organization and personnel/contact-info/responsibilities Assumptions and dependencies


Project risk analysis Testing priorities and focus Scope and limitations of testing Test outline - a decomposition of the test approach by test type, feature,

functionality, process, system, module, etc. as applicable Outline of data input equivalence classes, boundary value analysis, error

classes Test environment - hardware, operating systems, other required software, data

configurations, interfaces to other systems Test environment setup and configuration issues Test data setup requirements Database setup requirements Outline of system-logging/error-logging/other capabilities, and tools such as

screen capture software, that will be used to help describe and report bugs Test automation - justification and overview


Discussion of any specialized software or hardware tools that will be used by

testers to help track the cause or source of bugs Test tools to be used, including versions, patches, etc. Test script/test code maintenance processes and version control Problem tracking and resolution - tools and processes Project test metrics to be used Reporting requirements and testing deliverables Software entrance and exit criteria Initial sanity testing period and criteria Test suspension and restart criteria Personnel pre-training needs Test site/location Relevant proprietary, classified, security, and licensing issues. Appendix - glossary, acronyms, etc.


Collection of Test Metrics must be done every week during product test.

The Test metrics required by QMO are:◦ Total Tests.◦ Tests Run.◦ Tests Passed.◦ Tests Failed.◦ Tests Deferred.◦ Tests passed the first time.

The QMO quality records generated during System testing are◦ The final pass/fail status of each test case.◦ List of MRs.


Functional areas should be vigorously tested as long as error detection %

exhibits upward trend. If the trend is downward, then testing effort might be shifted to other areas. The probability of the existence of more errors in a section of a program is

proportional to the number of errors already found in that section. Therefore

high error areas should be thoroughly checked. Testing should continue until error detection is within an acceptable level of

quality. All areas of product should be tested because errors are not uniformly

distributed, due to different developers. Regression testing is very important. Rerun all the tests during regression,

because any code change can potentially cause new problems in area not

associated with the area where code is changed.


System testing encompasses a wide variety of areas that should be tested.

Features

◦ Functional - The product should be tested against the

requirements.

Limits - System limits should be tested at and around their boundaries,

both for input and output. This should be done not only for data value

ranges, But also for size of input and output, whether it be total bytes,

number of rows, etc.

Storage - Storage specifications should be tested whether the storage

system can successfully accommodate required amount of data.


◦ Industrial Strength:

Performance - Timings for both read and update transactions should be gathered to determine whether system functions are being performed in an acceptable timeframe. This should be done in stand-alone, and in multi-user environment.

Volume - Large volume of data should be fed to the system to make sure it can correctly process such amount. Systems can often respond unpredictably when large volume causes files to overflow

Stress - Loads that results from a large number of simultaneous users, transactions, and/or devices are needed to test the system to determine whether it can handle peak usage periods. Throughput and system stability should be monitored.

Recovery - A system should be tested to see how it responds to errors and abnormal conditions, such as System crash, loss of device, communication, or power.


Reliability/Availability - It is concerned with the issues such as mean-time-to failure, and usually requires extensive testing over long periods of time.

Security - The system should be secure from the unauthorized use and unauthorized data access.

◦ Environment:

Installation - The tester should install the system (with a variety of options) to determine whether the installation is viable. The installation document must be followed in order to determine its accuracy.


Configuration - The system should be tested to determine whether it works correctly with appropriate hardware and software configurations.

Compatibility - The system should be tested to determine whether it is compatible with other systems that it needs to interface with.

◦ Usability Error - The system should exit gracefully upon an error and leave

its environment in a predictable state. Appropriate error message should be generated.

Documentation - The documentation for a system should be correct, complete, and easy to understand.


What to Test For? – Contd.

Testing tools automates the process of testing and can save a large amount of time: Regression testing tools captures your tests and play them back whenever required. A successful regression testing tool must have following features:

◦ Easy to install and maintain

◦ Keep track of test cases and selectively run the test cases

◦ Must be able to reuse the captured scripts on different browsers on multiple

platforms.

◦ Capture the mouse clicks and hyperlink jumps between web pages as objects and

not as absolute locations on the window.

◦ Edit the script to include new data values for regression tests.

◦ Play back the scripts and adjust the speed of playback

◦ Compare the regression run with the expected results and produce the differences in

concise reports. These reports should be able to filter errors. Support various HTML releases. Check for valid URLs


The following are some of the steps to consider:

◦ Obtain requirements, functional design, & internal design specifications

◦ Obtain schedule requirements

◦ Determine project-related personnel and their responsibilities, reporting

requirements.

◦ Identify application's higher-risk aspects, set priorities, and determine scope and

limitations of tests.

◦ Determine test approaches and methods - unit, integration, functional, system, load,

usability tests.

◦ Determine test environment requirements (hardware, software, communications,

etc.)

◦ Determine tool requirements (record/playback tools, coverage analyzers, defect

tracking, etc.)

◦ Determine test input data requirements

◦ Identify tasks, those responsible for tasks.


Determine input equivalence classes, boundary value analyses, error classes Prepare test plan document and have needed reviews/approvals Write test cases Have needed reviews/inspections/approvals of test cases Prepare test environment and tools, obtain needed user manuals/reference

documents/configuration guides/installation guides, set up test tracking

processes, set up logging and archiving processes, set up or obtain test input

data Obtain and install software releases Perform tests Evaluate and report results Track problems/bugs and fixes Retest as needed Maintain & update test plans, test cases, test environment, and tools through

life cycle


Each of the five phases of Project Delivery Lifecycle will incorporate QA

activities & deliverables that off-set the risks of common project problems. This

summary of Project Delivery Lifecycle is a high-level list of QA activities &

deliverables related to each phase.

Assessment Phase◦ Assessment process consists of market research and a series of structured

workshops that the and client teams participate in to discuss and analyze the

project objectives and develop a strategic plan for the effort. The products of these

meetings, combined with market research, form the basis for the final output of the

assessment: a tactical plan for realizing specific business and project objectives.

◦ QA Deliverables QA Editor submits revised and approved deliverable documents.


Planning Phase◦ In the Planning phase, the team defines specific system requirements and develops

strategies around the information architecture (static content and information flows) and

the business functions that will be addressed.

QA Activities◦ Establishing Standards and Procedures: QA records the set requirements.

◦ Planning (Test Matrix): QA develops a test matrix. QA confirms that all set requirements

are testable and coincide with the project objectives.

◦ Auditing Against Standards and Procedures: QA editor edits the documents and confirms

that they meet the objectives and the quality standards for documents.

◦ Establishing Completion Criteria: QA records the completion criteria for the current phase.

QA Deliverables◦ QA submits an initial test matrix.

◦ QA Editor submits revised and approved deliverable documents.


Design Phase◦ During the Design phase, the team identifies all of the necessary system components

based on the requirements identified during the Assessment and Planning phases. The

team then creates detailed design specifications for each component and for the

associated physical data requirements.

◦ QA Activities Auditing Standards and Procedures: QA confirms that all designs meet the set requirements and notes

any discrepancies. Additionally, QA identifies any conflicts or discrepancies between the final design of

the system and the initial proposal for the system and confirms that an acceptable resolution has been

reached between the project team and the client.

◦ Planning (QA Plan, QA Test Plan): QA begins developing the QA Plan. QA revised the test matrix to reflect any changes and/or additions to the system.

◦ QA Deliverables QA presents the initial QA test plan. QA submits a revision of the test matrix.


Development Phase

◦ During the Development phase, the team constructs the components specified during the Design Phase.

◦ QA Activities Planning (Test Cases): Using the test matrix, QA develops a set of test cases for all

deliverable functionality for the current phase.

◦ Prepare for Quality Assurance Testing: QA confirms that all test cases have been written according to the guidelines set in the

QA test plan. Quality Assurance works closely with the Configuration Management group to prepare

a test environment.

◦ QA Deliverables QA submits a set of Test Cases. QA Environment is set up.


Implementation Phase

◦ In the Implementation phase, the team focuses on testing and

review of all aspects of the system. The team will also develop

system documentation and a training or market test plan in

preparation for system launch.

◦ QA Activities QA Testing: QA executes all test cases in the QA testing cycle.

◦ QA Deliverables Test Results Defect Reports


Shortage of time and resources How does a tester best deal with this Coverage of test cases by breadth and depth testing. Breadth of coverage addresses the number of areas, features, and options. Depth of coverage addresses the extent to which different tests are run for an

area feature or option. Breadth of testing should be covered well. Otherwise there is a danger of having

basic features that simply do not work. How to make decision what to test in depth:

◦ perform depth testing in the problematic areas shown in the breadth or

depth testing proven problematic in the previous versions of software.

◦ Critical areas require depth testing simply because of their importance.


Should tests in the same functional area be grouped together, or should they be

mixed? Grouping tests in the same or related areas makes it easier for tester track and

understand an area, mixing increases the odds that you will identify problematic

area early in the testing and pursue depth testing where it is needed. Should tests to break the system be grouped by type or should they be mixed. Should individual tests and workflow scenarios be tested separately. All the tests cannot be written before the actual testing starts. You may overlook

needed tests. The results of the tests will provide clues as to what other tests should be

performed. System crash, error or warning messages, incorrect results may alert you to

include some additional tests.


Environment plays a role in the results of the tests. Particularly in the areas of performance testing.

Some of the areas you cannot control.◦ Other traffic on the network◦ Other processes running on the server◦ Other process running on the DBMS

The areas you can control in the test environment:◦ Connection to the DBMS - opening a connection involves overhead;

it is efficient to keep a session open.◦ File opens - opening a file involves overhead. It is more efficient to

keep a file open.◦ DBMS space management - file fragmentation, data and index

page splits occurs due to the large number of inserts or updates. This impacts performance. Deletes may results unused spaces.

◦ Space utilization should be monitored. Database utilities should be run regularly to control this.


Buffer pools may hold previously retrieved data or indexes and can give different performance results compared to data that must be retrieved from permanent storage. It might be desirable to flush the buffers between database requests.

Logging can slow the response time. Transaction logging is necessary for recovery. However, event logging for other types information capture may be undesirable while performance testing is in progress.


Performance testing tools determine the load a web server. A successful

performance testing tool must have the following features:

◦ Easy to install and maintain

◦ Keep track of test cases and selectively run the test cases.

◦ Capture the mouse clicks and hyperlink jumps between web pages as objects

and not as absolute locations on the window. Simulate many users from one machine by running the captured script. Mix several scripts and run them several times to simulate many users doing

different tasks. Collect performance data and have reporting tools to analyze the data. Able to measure the network load under different number of simulated users. Able to measure the CPU load by the server. Able to measure the throughput by the number of pages served by server


The Deliverables from the Test team would include the following:

◦ Test Plan.

◦ Test Case Documents.

◦ Defect Reports.

◦ Status Reports (Daily/weekly/Monthly).

◦ Test Scripts (if any).

◦ Metric Reports.

◦ Product Sign off Document.


Software CMM is a common sense application of process management and quality

improvement concepts to software development and maintenance.

A scale for assessing the degree of built-in documentation and discipline in a process, in

which the scale goes from Level 1, with no formal process, to Level 5, with a continuous,

rigorous and self-improving process.

The Capability Maturity Model for Software developed by the Software Engineering

Institute of Carnegie Melon has had a major influence on software process and quality

improvement around the world.

The SW-CMM defines a five level framework for how an organization matures its

software process. These levels are the result of evolution from ad hoc processes to more

matured and disciplined software process.

This model is now being extended to a broader range of applications in management.


Mercury TestDirector:◦ Mercury TestDirector™ allows you to deploy high-quality applications quickly

and effectively by providing a consistent, repeatable process for gathering

requirements, planning and scheduling tests, analyzing results, and managing

defects and issues. TestDirector is a single, Web-based application for all

essential aspects of test management — Requirements Management, Test

Plan, Test Lab, and Defects Management. You can leverage these core modules

either as a standalone solution or integrated within a global Quality Center of

Excellence environment.

◦ TestDirector supports high levels of communication and collaboration among IT

teams. Whether you are coordinating the work of many disparate QA teams, or

working with a large, distributed Center of Excellence, this test management

tool helps facilitate information access across geographical and organization

boundaries.
