MANUAL TESTING NOTES BY JOBHUNTER TEAM

SDLC Models

As Software Tester you must have exposure on Software Development Life Cycle / Software Development Process. Actually it is developers /Programmers concern, but Testing also part of SDLC, so you need to concentrate on SDLC process.

In the IT industry there are several SDLC models available, but we can segregate them in two categories.

a) Sequential Development Models

b) Incremental / Iterative Models

You must familiar with at least two Sequential Development Models and two Incremental / Iterative Models in order to get better opportunities.

Sequential Development Models:

In this Approach Software Project development is divided into phases like Requirements gathering, Analysis & Planning, Design, Coding, Testing and Release & Maintenance, every stage output is input for next stage.

Easy way of development, takes less time, but success not guaranty, recommendable for small scale, low budget and short term projects.

Ex: Waterfall Model, V model etc…

Incremental / Iterative Models:

In this approach, the first increment is often a core product. The core product is used by the customer or undergoes a detailed review. As a result of use and/or evaluation a plan is developed for the next increment. The plan addresses the modification to the core product to better meet the needs of the customer and delivery of additional features and functionality.

Software is constructed in a step-by-step manner. While a software product is being developed, each step adds to what has already been completed.

Advantages of Incremental Model

o System is developed and delivered in increments after establishing an overall architecture.

o Requirements and specifications for each increment may be developed.

o Users may experiment with delivered increments while others are being developed.

o Intended to combine some of the advantages of prototyping but with a more manageable process and better system structure.

o Incremental development is especially useful when staffing us unavailable for a complete implementation by the business deadline.

o Early increments can be implemented with fewer people.

Examples: Spiral Model, Agile Models etc…

II) Test Levels

This is Tester’s first and direct concept, we have 4 levels of testing for every software project, some may have 5 levels of testing.

Generally 4 levels of testing is common for every software, but 5 levels of testing for distributed (Business Integration) software.

Test Levels for Independent Applications (No business dependency with other Applications)

a) Unit / Component / Program / Module Testing

b) Integration Testing

c) System Testing

d) Acceptance Testing

Test Levels for Integrated Applications (Business dependency with other Applications)

a) Unit / Component / Program / Module Testing

b) Component Integration Testing

c) System Testing

d) System Integration Testing

e) Acceptance Testing

Unit / Component Testing:

The testing of individual software units or components.

In this level usually developers conduct Testing using White box test techniques like Statement testing, condition testing, Decision testing etc... techniques.

Integration Testing

Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems.

System Testing

The process of testing an integrated system to verify that it meets specified requirements.

In this level usually Independent Testers conduct Testing (Functional and Non-Functional) using Black box test design techniques like Equivalent classes, Boundary Value Analysis, Decision Tables, State Transition Testing etc... Techniques.

Acceptance Testing

Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.

3 type of Acceptance Testing

a) User Acceptance Testing

End users / Customer representatives perform this type of testing based on Business Requirements

b) Operational Acceptance Testing

Network administrators/ Technical support people conduct this type of testing

c) Certification Acceptance Testing

Certified Testers conduct this type of testing

Test Design Techniques

I) Specification-based/Black-box techniques

o Equivalence partitioning

o Boundary value analysis

o Decision table testing

o State transition testing

o Use case testing

Equivalence partitioning

o Inputs to the software or system are divided in to groups that are expected to exhibit similar behavior

o Equivalence partitions or classes can be found for both valid data and invalid data

o Partitions can also be identified for outputs, internal values, time related values and for interface values.

o Equivalence partitioning is applicable all levels of testing

Boundary value analysis

o Behavior at the edge of each equivalence partition is more likely to be incorrect. The maximum and minimum values of a partition are its boundary values.

o A boundary value for a valid partition is a valid boundary value; the boundary of an invalid partition is an invalid boundary value.

o Boundary value analysis can be applied at all test levels

o It is relatively easy to apply and its defect-finding capability is high

o This technique is often considered as an extension of equivalence partitioning.

Decision table testing

o In Decision table testing test cases are designed to execute the combination of inputs

o Decision tables are good way to capture system requirements that contain logical conditions.

o The decision table contains triggering conditions, often combinations of true and false for all input conditions

o It maybe applied to all situations when the action of the software depends on several logical decisions

State transition testing

o In state transition testing test cases are designed to execute valid and invalid state transitions

o A system may exhibit a deferent response on current conditions or previous history. In this case, that aspect of the system can be shown as a state transition diagram.

o State transition testing is much used in embedded software and technical automation.

Use case testing

o In use case testing test cases are designed to execute user scenarios

o A use case describes interactions between actors, including users and the system

o Each use case has preconditions, which need to be met for a use case to work successfully.

o A use case usually has a mainstream scenario and some times alternative branches.

o Use cases, often referred to as scenarios, are very useful for designing acceptance tests with customer/user participation

II) Structure-based/White-box techniques

o Statement testing and coverage

o Decision testing and coverage

o Other structure-based techniques

o condition coverage

o multi condition coverage

Statement testing and coverage:

Statement

An entity in a programming language, which is typically the smallest indivisible unit of execution

Statement coverage

The percentage of executable statements that have been exercised by a test suite

Statement testing

A white box test design technique in which test cases are designed to execute statements

Decision testing and coverage

Decision

A program point at which the control flow has two or more alternative routes

A node with two or more links to separate branches

Decision Coverage

The percentage of decision outcomes that have been exercised by a test suite

100% decision coverage implies both 100% branches coverage and 100% statement coverage

Decision testing

A white box test design technique in which test cases are designed to execute decision outcomes.

Other structure-based techniques

Condition

A logical expression that can be evaluated as true or false

Condition coverage

The percentage of condition outcomes that have been exercised by a test suite

Condition testing

A white box test design technique in which test cases are designed to execute condition outcomes

Multiple condition testing

A white box test design technique in which test cases are designed to execute combinations of single condition outcomes

III) Experience-based techniques

o Error guessing

o Exploratory testing

Error guessing

o Error guessing is a commonly used experience-based technique

o Generally testers anticipate defects based on experience, these defects list can be built based on experience, available defect data, and from common knowledge about why software fails.

Exploratory testing

o Exploratory testing is concurrent test design, test execution, test logging and learning , based on test charter containing test objectives and carried out within time boxes

o It is approach that is most useful where there are few or inadequate specifications and serve time pressure.

Quality Standards Organizations:

ISO (International Organization for Standards),

ISO has provided so many terms and guidelines for Software Testing

IEEE (Institute of Electrical and Electronics Engineers),

IEEE has provided so many terms (Terminology) and Test documentation standards like Test Plan, Test Specification, Transmittal Report, Test Case Specification, Incident Report and Test Summary Report etc...

CMM/CMMI (Capability Maturity Model Integration),

CMMI has Provided Test process guidelines.

and some other Non-Government Organizations have provided the

the Standards for the IT Industry.

--------------------------------------------------------------

4 Stages of Software Test Process

I) Test Planning

(Primary Role: Test Lead/Team Lead)

Input:/Reference:

-----------------

a) Requirements specification

b) Test Strategy

c) Project plan

----

d) Use cases/design docs/Prototype screen

e) Process Guidelines docs

Templates:

----------

Review Report

Test Plan

Roles:

------

Test Lead/team Lead: Test Planning

Test Engineers: Contribution to Test plan

---------

BA: Clarifications on Requirements

Tasks:

-------

a) Understanding & Analyzing the Requirements

b) Test Strategy Implementation

c) Test Estimations (Time, Resources-Environmental, Human, Budget)

d) Risk Analysis

f) Team formation

g) Configuration management plan

h) Test Plan Documentation

i) Test Environment set-up defining

Output:

-------

Test Plan Document

----------------------------------------------------

II) Test design:

----------------

Input:/Reference:

-----------------

a) Requirements specification

b) Test Plan

----

d) Use cases/design docs/Prototype screen

e) Process Guidelines docs

Templates:

----------

Test Scenarios

Test case

Test data

Roles:

------

Test Engineers: Test case documentation

Test Lead/team Lead: Guidance, monitoring & Control

---------

BA: Clarifications on Requirements

Tasks:

------

a) Creating Test scenarios

b) Test case documentation

c) Test data collection

Output:

-------

Test case Documents

Test Data

--------------------------------

3) Test Execution:

-------------------

Input:/Reference:

-----------------

a) Requirements specification

b) Test Plan

c) Test Case docs

d) Test data

----

e) Test Environment

Templates:

----------

Defect Report

Test Report

Roles:

------

Test engineers: Test execution

Test Lead: Guidance, monitoring & Control

----------

BA: Clarifications on Requirements

System Administrator/Network Administration: Test Environment set-up

Tasks:

-------

a) Forming Test Batches

b) Verifying Test Environment set-up

c) Test Execution

d) Test reporting

e) Defect Reporting

f) Regression Testing

Output:

-------

Test Reports

Opened/Closed Defect Reports

4) Test Closure

Input:/Reference:

-----------------

Requirements

Test Plan

Test Reports

Opened/Closed Defect Reports

Templates:

----------

Test Summary Report

Roles:

Test Lead: decide when to stop testing & Creating Test summary Report

Testers: Contribution

Tasks:

-------

a) Evaluating Exit criteria

b) Collecting all facts from Testing activities

c) Sending Test deliverables to the Customer

d) Improvement suggestions for future projects

Output:

-------

Test Summary Report

Test Deliverables (Test Plan, Test scenarios, Test cases, Test Data, Test Reports, Opened/Closed defect Reports, Test Summary Report)

***********************************************************

Documents to be created and used for Software Testing:

a) Test Policy (Company Level)

A high level document describing the principles, approach and major objectives

of the organization regarding testing.

b) Test Strategy (Company Level)

A high-level description of the test levels to be performed and the testing within those levels for an organization or programme (one or more projects).

c) Test Plan (Project Level)

A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process.

d) Traceability Matrix

A traceability matrix is a document, usually in the form of a table, that correlates any two baselined documents that require a many to many relationship to determine the completeness of the relationship.

e) Test Case

A set of input values, execution preconditions, expected results and execution

Post-conditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.

f) Test Data

Data that exists (for example, in a database) before a test is executed, and that affects or is affected by the component or system under test.

g) Defect Report

A document reporting on any flaw in a component or system that can cause the

component or system to fail to perform its required function.

h) Review Report

i) Test Summary Report

A document summarizing testing activities and results. It also contains

an evaluation of the corresponding test items against exit criteria.

Software Development Life Cycle (SDLC):

I) Requirements Gathering (BA/BT)

in case of customer specific application:

-----------------------------------------

Business Analyst category people gathers requirements from the customer, and prepares

BRS (Business Requirement specification) and submits to Project Manager.

PM sends BRS for review, after getting review report and clarifications, PM approve the document.

Document stages:

a)document creation/preparation

b)document review

c)document approval

Base lined document (finalized)

------------------

we can execute this base lined document

in case of Software Product:

----------------------------

Business Team gathers requirements from model customers and explores competitor products, and prepares

PRD (Product Requirement Document) and submits to Project Manager.

PM sends PRD for review, after getting review report and clarifications, PM approve the document.

------------------------

Output of this stage:

---------------------

Baselined BRS/PRD

Document names may vary from one company to another

Ex: BRS/CRS/BRD/URS/PRD etc..

----------------------------

II) Analysis & Planning (Tech Manager and Project Manager)

------------------------------------------------------

Technical Manager analyzes BRS document in terms of below factors

a) are they complete requirements?

b) are they correct requirements?

c) are they achievable requirements?

d) are they Testable requirements?

------------------------

after analyzing the above factors Technical Manager creates SRS (Software Requirements specification) Document

SRS consists of two sub documents

a) FRS (functional requirement specification)

FRS describes functionalities to be developed

b) SRS (System Requirements specification)

SRS describes Software & Hardware to be used

---------------------------

During SRS creation TM concentrates on Technology selection

He considers below factors for selecting Technology:

Technical factors:

------------------

a) Nature of the Application

b) Organization's experience

---------

Business factors:

----------------

a) Cost/Budjet

b) Customer interests

--------------------------

Planning:

---------

Project manager analyzes risks, creates project plan, team formation etc...

-------------------------------

Output:

-------

SRS

Project Plan

III) Design (System Arch)

--------------------

Input: SRS

------

System Architect / senior developer creates Software Design document(SDD)

It consists of two types of design docs

a) HLD (High Level Design) or Global Design

Overall architecture of the system

b) LLDs (Low Level design) or Detailed Design

Internal architecture of each and every Unit/component/module

Note: System Architect uses either word document or UML like tools for Software

-----------------------------------------------

Output:

-------

SDD

IV) Implementation / Coding (Developers/programmers)

----------------------------------------------

Input:

SDD

Developer/Programmers develop the code based on Design documents and they follow

coding standards

Output:

-------

Code documents

software(.exe file)

Testing (Testers)

-----------------

Input:

------

software(.exe file)

SRS

Testers test software based on SRS, if they find any mismatch, send defect reports

, after fixing defects, confirm fixes and close defects

Output:

-------

Tested software

Test documents

V) Release & Maintenance (Release Team/Maintenance Team)

-----------------------------------------------------

Release:

--------

PM forms Release Team, Release team consists of a few developers, testers,project management executive, and system administrator

Release Team goes to customer place and deploys software.

Release Team provides some training to the customer site people (if required)

------------

Maintenance:

------------

PM forms Maintenance Team, Maintenance team consists of a few developers, testers, and project management executive

Release Team receives customer change requests and perform required changes

Maintenance(3 types)

---------------------

a) Modifications

i) Corrective changes

ii) Enhancements

b) Migration

Migrating from old technology to new technology

(ex: windows 98 to Vista/windows 7)

Ms Access to SQL Server/Oracle)

c) Retirement

Retiring the Old system and developing New system

Waterfall Development Model

Overview:

Waterfall development model was launched in 1970’s. It is a framework for software development in which development proceeds sequentially through a series of phases, starting with Business requirements, Software Requirements analysis and planning to develop software product, release and maintenance.

In this model each phase has specific deliverables, after completion of a phase/stage next stage will begin. One stage output is input for next stage.

A number of variants of this model exist, with each one quoting slightly different labels for the various stages. In general, however, the model may be considered as having six distinct phases, described below:

a) Requirements Gathering:

This first step is also the most important, because it involves gathering information about what the customer needs and defining, in the clearest possible terms, the problem that the product is expected to solve.

b) System Requirements:

In this phase Business Requirements are converted as Software Requirements.

) Design:

In this phase Global and Detailed design can be produced based on Software Requirements.

d) Coding:

This step consists of actually constructing the product as per the design specification(s) developed in the previous step. Typically, this step is performed by a development team consisting of programmers, interface designers and other specialists, using tools such as compilers, debuggers, interpreters and media editors. The output of this step is one or more product components, built according to a pre-defined coding standard and debugged, tested and integrated to satisfy the system architecture requirements.

e) Testing:

In this stage, System will be tested by testers, if the find any mismatch they report defects. Developers /Programmers fix the defects and then testers close defects by performing confirmation testing (Regression Testing).

f) Release & Maintenance:

Release team (consists of a few developers, testers, and tech-support people etc…) install software in Customer environment and they consider below factors;

Correct & Complete installation

User Management

Services Management

Coexistence with other software

Handling of Input & Output devices

Handling of secondary storage devices

Etc…

Maintenance team process Customer issues based on service agreements.

3 Types of Software maintenance:

a) Modifications

b) Migration

c) Retirement

Advantages of Waterfall Model :

i) Simple and easy to use

ii) Easy to manage due to the rigidity of the model- each phase has specific deliverables and a review process.

iii) Phases are processed and completed one at a time.

iv) Works well for smaller projects where requirements are very well understood.

Disadvantages of Waterfall Model :

i) No working software is produced until late during the life cycle

ii) High amount of risk and uncertainty

iii) Poor model for complex and object oriented projects.

iv) Poor model for Long and ongoing projects

v) Poor Model where requirements are at a moderate to high risk of changing.

V Model

Overview:

A framework to describe the software development life cycle activities from requirements specification to maintenance.

The V-model illustrates how testing activities can be integrated into each phase of the software development life cycle.

V Model was inaugurated in order to avoid drawbacks in Waterfall model and its main focus on multiple stages of testing.

Multiple stages of Testing avoids defects multiplication.

Software Quality:

Quality: Meeting Customer Requirements and expectations.

Software Quality:

Meet Customer Requirements (Functionality)

Meet Customer Expectations (Performance, Usability, portability etc...)

Cost to purchase license

Time to release

Note: First two factors are Technical, last two factors are Non-Technical.

Quality Assurance (QA):

Defining, Monitoring and Optimizing the process is called Quality Assurance, it is part of Quality Management and It is Prevention oriented.

Quality Control (QC)

Checking the System (Final Outcome) with respect to Requirements is called Quality Control and it is Detection oriented.

Verification:

Testing Quality work products (Documentation such as Test Plan, Test Cases Etc...) by performing Reviews and conducting meeting etc... and it is Static

Validation

Testing the Working Software based on its Requirements and it is Dynamic.

Verification Validation

Description of V Model:

It is Verification & Validation model, known as V Model, in this model all development phases can be integrated with Testing phases.

It is considered to be an extension of the Waterfall model. This is because just like the waterfall model, it's a well structured method in which the different phases progress in a sequential or linear way. That means each phase begins only after the completion of the previous phase.

Development Phases Integration with Testing Phases

a) User Requirements Vs Acceptance Testing

Business Analyst category people gather requirements and the document the requirements, after documentation Reviews, Meetings like verifications will take place in order get correct & Complete Requirements.

End Uses derive Acceptance Test cases from User Requirements.

b) Software Requirements Vs System Testing

Development Manager/Tech Manager converts User Requirements as Software Requirements and Reviews, Meetings like verification methods will be performed on Software Requirements, after Verification Project manager provides Approval.

Independent testers generate test cases from Software Requirements in order to perform System Testing

c) Global Design Vs Integration Testing

System Architect / senior developer creates Global design, Informal Review/ Walk through / Technical Review / Inspection like Verification methods will be applied on Design documents.

Developers perform Integration Testing based on Software Global Design.

d) Detailed Design Vs Unit / Component Testing

Developers perform Unit /Component Testing based on Software Detailed Design.

Advantages of V Model:

o Tester role will take place in the requirement phase it self

o Multiple stages of Testing available so that Defects multiplication can be reduced.

o Can be used for any type of requirements

o Due to Multiple stages of Testing and Multiple teams involvement Quality can be improved.

o The V Model Supports wide range of development methodologies such as Structured and Object oriented systems development.

o The V Model supports tailoring.

Disadvantages of V Model:

o It an expensive model than Waterfall model, needs lot of resources, budget and time.

o Co-ordination and Maintenance are difficult.

o Adoption of changes in Requirements and Adding New Requirements at middle of the process are difficult.

o It needs an established process for proper implementation.

Overview on Prototype Model:

It begins with requirements gathering. Developers and Customers meet and define the overall objectives of the software.

Developers prepare design documents using all available requirements then build the prototypes, prototypes are sent to Customer, and Customer evaluates Prototypes and gives feedback. Developers redefine Requirements, modify software design and produce modified Prototypes. Process will be continued like this, after getting Customer’s confirmation Developers Start Regular process; Software Design, Coding (Implementation), Testing and Release & Maintenance.

The Objective of this approach is getting clear (Complete and Correct)

Requirements from Customers in order to avoid Defects multiplication.

Prototype Model Diagram

Advantages of Prototype Model:

o The customer doesn’t need to wait long as in the Linear Model or Waterfall Model.

o Feedback from customer is received periodically and the changes don’t come as a last minute surprise.

o Customer’s interaction improves the Quality as well success rate.

Disadvantages of Prototype Model:

o It is an expensive approach and time taking process when its compare to sequential models like Waterfall model.

o Customer could believe the prototype as the working version.

o Developer also could make the implementation compromises.

o Once Requirements finalized then adopting changes in Requirements and adding New Requirements are difficult.

Agile Development Model

The term Agile means 'moving quickly.' Agile process itself is a software development process by small teams, in a short time frame, and involving system users as well as developers. This agile process is an iterative approach in which customer satisfaction is at highest priority as the customer has direct involvement in evaluating the software. An Agile approach focuses on adaptability and response time to changing requirements.

Overview

The definition for agile software development evolved in the mid 1990s. It helps in adaptive planning, iterative development and time boxing. It is a theoretical framework that promotes foreseen interactions throughout the development cycle.

Agile Model Phases

The agile process follows the software development life cycle which includes requirements gathering, analysis, design, coding, testing and delivers partially implemented software and waits for the customer feedback. In the whole process, customer satisfaction is at highest priority with faster development time. The following diagram depicts the software development life cycle of Agile Process.

The Agile process requires less planning and it divides the tasks into small increments. This process is meant for short term projects with an effort of team work that follows the software development life cycle. Software development life cycle includes the following phases

1.Requirements gathering,

2.Analysis,

3.Design,

4.Coding,

5.Testing,

6.Maintenance.

The involvement of software team management with customers reduces the risks associated with the software. This agile process is an iterative process in which changes can be made according to the customer satisfaction.

The Agile system development life cycle model begins with initial elicitation of requirements in order to conceptualize the system. Once the system concept is formed, requirements are estimated and prioritized in order to plan the development iterations. Within each iteration, requirements continue to evolve and are used in brief model storming sessions in order to design the functionality required to meet requirements allocated to the iteration. When the system model is developed/modified, the coding is initiated/continued using a test-driven approach. Once the functionality for the iteration is tested successfully, refactoring takes place. Refactoring is a disciplined technique for altering the structure of an existing code base without altering functionality. When refactoring is completed and functionality is confirmed, the code is deployed internally, completing the iteration.

If plans include deploying the code beyond the development iteration, the code is then deployed externally. Eventually, all iterations are completed, resulting in a system with full functionality that is accepted by stakeholders because it meets allocated requirements.

There are several methodologies through which we can implement Agile Projects. The agile methods are focused on different aspects of the software development life cycle. Some focus on the practices (extreme programming, pair programming), while others focus on managing the software projects (the scrum approach).

The three methodologies which are most widely used in Industry are

1. Extreme Programming (XP).

2. Scrum.

3. Feature Driven Development (FDD).

1. Extreme Programming (XP): XP is the most successful method of developing agile software because of its focus on customer satisfaction. XP requires maximum customer interaction to develop the software.

It divides the entire software development life cycle into several number of short development cycles. It welcomes and incorporates changes or requirements from the customers at any phase of the development life cycle.

2. Scrum: Scrum is another popular method of agile development through which productivity becomes very high. It is basically based on incremental software development process. In scrum method the entire development cycle is divided into a series of iteration where each iteration is called as a sprint. Maximum duration of a sprint is 30 days.

3. Feature Driven Development (FDD): FDD is one of the agile development methods. The key advantage of this method is to design the domain of the software to be produced before development.

Advantages of Agile Model

• Adaptive to the changing environment.

• Agile helps to speed up the SDLC phases and bypasses process steps that add little value to the project.

• Engages the stakeholders continuously so that the new requirements are gathered faster and there is no scope for guess work by the teams.

• Saves cost, time and efforts by following iterative incremental work delivery and thereby identifying deviations early.

• Least documentation.

• Provides the end result of higher quality of the software delivered and a highly satisfied customer.

Disadvantage of Agile Model

• Time consuming and wastage of resources because of constant change of requirements.

• More helpful for management than developer.

• Only senior developers are in a better position to take the decisions necessary for the agile type of development.

• Once teams become bigger, agile methodologies begin to fail, as they don’t scale to large teams, or teams spread across geographies.

• If the projects are large then it becomes difficult to judge the efforts and the time required for the project in the software development life cycle.

--------------------------------

Agile Development Model

The term Agile means 'moving quickly.' Agile process itself is a software development process by small teams, in a short time frame, and involving system users as well as developers. This agile process is an iterative approach in which customer satisfaction is at highest priority as the customer has direct involvement in evaluating the software. An Agile approach focuses on adaptability and response time to changing requirements.

Overview

The definition for agile software development evolved in the mid 1990s. It helps in adaptive planning, iterative development and time boxing. It is a theoretical framework that promotes foreseen interactions throughout the development cycle.

Agile Model Phases

The agile process follows the software development life cycle which includes requirements gathering, analysis, design, coding, testing and delivers partially implemented software and waits for the customer feedback. In the whole process, customer satisfaction is at highest priority with faster development time. The following diagram depicts the software development life cycle of Agile Process.

The Agile process requires less planning and it divides the tasks into small increments. This process is meant for short term projects with an effort of team work that follows the software development life cycle. Software development life cycle includes the following phases

1.Requirements gathering,

2.Analysis,

3.Design,

4.Coding,

5.Testing,

6.Maintenance.

The involvement of software team management with customers reduces the risks associated with the software. This agile process is an iterative process in which changes can be made according to the customer satisfaction.

The Agile system development life cycle model begins with initial elicitation of requirements in order to conceptualize the system. Once the system concept is formed, requirements are estimated and prioritized in order to plan the development iterations. Within each iteration, requirements continue to evolve and are used in brief model storming sessions in order to design the functionality required to meet requirements allocated to the iteration. When the system model is developed/modified, the coding is initiated/continued using a test-driven approach. Once the functionality for the iteration is tested successfully, refactoring takes place. Refactoring is a disciplined technique for altering the structure of an existing code base without altering functionality. When refactoring is completed and functionality is confirmed, the code is deployed internally, completing the iteration.

If plans include deploying the code beyond the development iteration, the code is then deployed externally. Eventually, all iterations are completed, resulting in a system with full functionality that is accepted by stakeholders because it meets allocated requirements.

There are several methodologies through which we can implement Agile Projects. The agile methods are focused on different aspects of the software development life cycle. Some focus on the practices (extreme programming, pair programming), while others focus on managing the software projects (the scrum approach).

The three methodologies which are most widely used in Industry are

1. Extreme Programming (XP).

2. Scrum.

3. Feature Driven Development (FDD).

1. Extreme Programming (XP): XP is the most successful method of developing agile software because of its focus on customer satisfaction. XP requires maximum customer interaction to develop the software. It divides the entire software development life cycle into several number of short development cycles. It welcomes and incorporates changes or requirements from the customers at any phase of the development life cycle.

2. Scrum: Scrum is another popular method of agile development through which productivity becomes very high. It is basically based on incremental software development process. In scrum method the entire development cycle is divided into a series of iteration where each iteration is called as a sprint. Maximum duration of a sprint is 30 days.

3. Feature Driven Development (FDD): FDD is one of the agile development methods. The key advantage of this method is to design the domain of the software to be produced before development.

Advantages of Agile Model

• Adaptive to the changing environment.

• Agile helps to speed up the SDLC phases and bypasses process steps that add little value to the project.

• Engages the stakeholders continuously so that the new requirements are gathered faster and there is no scope for guess work by the teams.

• Saves cost, time and efforts by following iterative incremental work delivery and thereby identifying deviations early.

• Least documentation.

• Provides the end result of higher quality of the software delivered and a highly satisfied customer.

Disadvantage of Agile Model

• Time consuming and wastage of resources because of constant change of requirements.

• More helpful for management than developer.

• Only senior developers are in a better position to take the decisions necessary for the agile type of development.

• Once teams become bigger, agile methodologies begin to fail, as they don’t scale to large teams, or teams spread across geographies.

• If the projects are large then it becomes difficult to judge the efforts and the time required for the project in the software development life cycle.

--------------------------------

Software Test Design Techniques

1) Introduction to Software Test Design Techniques

2) Static and Dynamic Test Design Techniques

3) Black box Test Design Techniques

a) Equivalence Partitioning (EP)

b) Boundary Value Analysis (BVA)

c) Decision Table Testing

d) State Transition Testing

e) Use Case Testing

--------------------------------------------------

1) Introduction to Software Test Design Techniques

> What is Technique?

An Efficient way of doing or achieving something.

> What is Test Design Technique?

A test design technique is used to select a good set of tests from the all possible tests for a given system.

> Why we need to use Test Design Techniques?

Exhaustive Testing is not possible, so we need to use Test Design Techniques in order to reduce the size of the input.

Exhaustive Testing is a Test approach in which the test suite comprises all combination of input values and preconditions.

Exhaustive Testing is not recommendable due to Time and Budget considerations.

> Categories of Test Design Techniques?

There are two main categories of Test Design Techniques, They are:

a) Static Techniques

b) Dynamic Techniques

--------------------------------------------------

2) Static and Dynamic Test Design Techniques

A) Static Techniques

> Testing of the software documents manually or with a set of tools but without executing the Software.

Two types of static testing techniques

i) Reviews (Manual Examination)

ii) Static Analysis (Automated Analysis)

-------------------------------

i) Reviews

Types of Reviews

a) Informal Review

b) Walkthrough

c) Technical Review

d) Inspection

ii) Static Analysis

Static analysis tools are typically used by developers, Compilers offer some support for Static analysis,

------------------------------------

B) Dynamic Test Design Techniques

> The software is tested by executing it on computer.

Categories of Dynamic Test Design Techniques

i) Specification based or Black box Techniques a) Equivalence Partitioning (EP)

b) Boundary Value Analysis (BVA)

c) Decision Table Testing

d) State Transition Testing

e) Use Case Testing Etc...

ii) Structure based or White box Techniques a) Statement Testing and coverage

b) Decision Testing and Coverage

c) Condition Testing, Multi Condition Testing etc...

iii) Experience based Techniques a) Error Guessing

b) Exploratory Testing

--------------------------------------------------

3) Black box Test Design Techniques

a) Equivalence Partitioning (EP)

b) Boundary Value Analysis (BVA)

c) Decision Table Testing

d) State Transition Testing

e) Use Case Testing

--------------------------------------------------

a) Equivalence Partitioning (EP)

• It can be applied at any level of testing (Unit, Integration, System and Acceptance Testing)

• In Equivalence Partitioning, inputs to the Software are divided into groups that are expected to exhibit similar behavior.

• Equivalence Partitions/Classes can be found for both valid data and invalid data.

Example 1 (Data Range):

Tickets field in a Reservation system accepts 1 to 10 Tickets only.

Partition 1 Partition 2 Partition 3

0 1 to 10 11 to 99 or above

(Invalid) (Valid) (Invalid)

Example 2 (Data Type):

Customer Identification Number field in a CRM system accepts only numbers.

Partition 1 Partition 2 Partition 3 Partition 4

Alpha bytes Numbers Special Characters Alpha-numeric

(Invalid) (Valid) (Invalid) (Invalid)

Example 3 (Data Size)

Phone Number filed accepts 10 digits number only

Partition 1 Partition 2 Partition 3

Below 10 10 Above 10

(Invalid) (Valid) (Invalid)

Example 4 (Others)

A Payment management system accepts credit card payments only

Partition 1 Partisan 2 Partisan 3

Credit card Net Banking Cash on Delivery

(Valid) (Invalid) (Invalid)

--------------------------------------------------

b) Boundary Value Analysis (BVA)

• The maximum and minimum values of a partition are its boundary values.

• Behavior at edge of each equivalence partition is more likely to be incorrect than behavior within the partition.

• Boundary value analysis can be applied at all Test levels(Unit, Integration, System and Acceptance Testing).

Example 1:

Partition 1 Partition 2 Partition 3

0 1 to 10 11 to 99 or above

(Invalid) (Valid) (Invalid)

Minimum/maximum 0

Minimum 1

Maximum 10

Minimum 11

Maximum 99

-------------------------------------

Example 3 (Data Size)

Phone Number filed accepts 10 digits number only

Partition 1 Partition 2 Partition 3

Below 10 10 Above 10

(Invalid) (Valid) (Invalid)

Minimum -9

Minimum and Maximum - 10

Maximum -11

----------------------------------------

Example: User Id field accepts 10 to 20 characters

Partition 1 Partition 2 Partition 3

Below 10 10 to 20 11 to 99

Minimum -1

Maximum - 9

Minimum - 10

Maximum - 20

Minimum - 21

Maximum -99

--------------------------------------------------

c) Decision Table Testing

• The decision tables are good way to capture system requirements that contain logical conditions.

• It may be applied for all situations when the action of the software depends on logical decisions.

BSRB (Govt) System Job eligibility criteria,

Age should be in between 21 and 35

Conditions:

i) For SC or ST Candidates 5 Years age relaxation

ii) For BC Candidates 5 Years age relaxation

iii) PHC Candidates 5 Years age relaxation

Category Age Valid/Invalid

----------------------------------------------

OC 20 Invalid

OC 21 Valid

OC 35 Valid

OC 36 Valid

BC 36 Valid

BC 39 Invalid

SC 39 Valid

PHC 39 Valid

ST 40 Valid

-----------------------------------------------------

Banking System interest rates For fixed deposits.

1 to 2 years 7%

2 to 3 Years 8%

3 to 5 Years 10%

Condition:

For Senior citizens 0.5% extra for all ranges

Age Period Interest Rate

-----------------------------------

25 1 year 7%

35 2.5 8%

56 4 10%

66 4 10.5%

--------------------------------------------------

d) State Transition Testing

• In State transition Testing Test cases are designed to execute valid and invalid state transitions.

• A System (Application Under Test) may exhibit a different response on current conditions or previous history.

Example: Internet Banking System Fund Transfer operation

Initial Balance: 45000

Transaction 1 Transaction Amount Transaction

1 20000 Successful (Pass)

2 20000 Successful (Pass)

3 20000 Unsuccessful (Pass)

--------------------------------------------------

e) Use Case Testing

• In Use Case Testing Test Cases are designed to execute User Scenarios or Business Scenarios.

• A Use Case describes interactions between actors, including users and the system.

• A Use case usually has a mainstream scenario and sometimes alternative scenarios.

Example:

Business Scenario: ATM Cash Withdrawal operation

Mainstream Scenario:

1)

User: Inserts ATM Card

System: Asks for PIN

2)

User: Enters PIN

System: Validates PIN and asks to select language

3)

User: Selects Language

System: Asks to select Account Type

4)

User: Selects Account Type

System: Asks to enter Amount

5)

User: Enters Amount

System: Releases Money

--------------------------------------------------

Alternatives

2a) Suppose if user enters invalid Pin

System: Shows error message and asks to enter correct PIN

User: Enters Correct PIN

-----------------------

4a) Suppose if user selects incorrect Account Type

System: Shows error and asks to select correct Account Type

User: Select correct account type

5a) If User enters incorrect amount (More than the balance amount or more than the day limit)

System: Shows Error message and asks to enter correct amount

User: Enters correct amount

Test Process may vary from one company to another and one project to another, but as per industry standards there is a 4 levels of Test Process available.

-----------------------------------------------------------------

Quality Standards Organizations:

ISO (International Organization for Standards),

ISO has provided so many terms and guidelines for Software Testing

IEEE (Institute of Electrical and Electronics Engineers),

IEEE has provided so many terms (Terminology) and Test documentation standards like Test Plan, Test Specification, Transmittal Report, Test Case Specification, Incident Report and Test Summary Report etc...

CMM/CMMI (Capability Maturity Model Integration),

CMMI has Provided Test process guidelines.

and some other Non-Government Organizations have provided the

the Standards for the IT Industry.

--------------------------------------------------------------

4 Stages of Software Test Process

I) Test Planning

(Primary Role: Test Lead/Team Lead)

Input:/Reference:

-----------------

a) Requirements specification

b) Test Strategy

c) Project plan

----

d) Use cases/design docs/Prototype screen

e) Process Guidelines docs

Templates:

----------

Review Report

Test Plan

Roles:

------

Test Lead/team Lead: Test Planning

Test Engineers: Contribution to Test plan

---------

BA: Clarifications on Requirements

Tasks:

-------

a) Understanding & Analyzing the Requirements

b) Test Strategy Implementation

c) Test Estimations (Time, Resources-Environmental, Human, Budget)

d) Risk Analysis

f) Team formation

g) Configuration management plan

h) Test Plan Documentation

i) Test Environment set-up defining

Output:

-------

Test Plan Document

----------------------------------------------------

II) Test design:

----------------

Input:/Reference:

-----------------

a) Requirements specification

b) Test Plan

----

d) Use cases/design docs/Prototype screen

e) Process Guidelines docs

Templates:

----------

Test Scenarios

Test case

Test data

Roles:

------

Test Engineers: Test case documentation

Test Lead/team Lead: Guidance, monitoring & Control

---------

BA: Clarifications on Requirements

Tasks:

------

a) Creating Test scenarios

b) Test case documentation

c) Test data collection

Output:

-------

Test case Documents

Test Data

--------------------------------

3) Test Execution:

-------------------

Input:/Reference:

-----------------

a) Requirements specification

b) Test Plan

c) Test Case docs

d) Test data

----

e) Test Environment

Templates:

----------

Defect Report

Test Report

Roles:

------

Test engineers: Test execution

Test Lead: Guidance, monitoring & Control

----------

BA: Clarifications on Requirements

System Administrator/Network Administration: Test Environment set-up

Tasks:

-------

a) Forming Test Batches

b) Verifying Test Environment set-up

c) Test Execution

d) Test reporting

e) Defect Reporting

f) Regression Testing

Output:

-------

Test Reports

Opened/Closed Defect Reports

4) Test Closure

Input:/Reference:

-----------------

Requirements

Test Plan

Test Reports

Opened/Closed Defect Reports

Templates:

----------

Test Summary Report

Roles:

Test Lead: decide when to stop testing & Creating Test summary Report

Testers: Contribution

Tasks:

-------

a) Evaluating Exit criteria

b) Collecting all facts from Testing activities

c) Sending Test deliverables to the Customer

d) Improvement suggestions for future projects

Output:

-------

Test Summary Report

Test Deliverables (Test Plan, Test scenarios, Test cases, Test Data, Test Reports, Opened/Closed defect Reports, Test Summary Report)

***********************************************************

Documents to be created and used for Software Testing:

a) Test Policy (Company Level)

A high level document describing the principles, approach and major objectives

of the organization regarding testing.

b) Test Strategy (Company Level)

A high-level description of the test levels to be performed and the testing within those levels for an organization or programme (one or more projects).

c) Test Plan (Project Level)

A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process.

d) Traceability Matrix

A traceability matrix is a document, usually in the form of a table, that correlates any two baselined documents that require a many to many relationship to determine the completeness of the relationship.

e) Test Case

A set of input values, execution preconditions, expected results and execution

Post-conditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.

f) Test Data

Data that exists (for example, in a database) before a test is executed, and that affects or is affected by the component or system under test.

g) Defect Report

A document reporting on any flaw in a component or system that can cause the

component or system to fail to perform its required function.

h) Review Report

i) Test Summary Report

A document summarizing testing activities and results. It also contains

an evaluation of the corresponding test items against exit criteria.

Software Business Domains

a) Banking Domain

b) Insurance

c) ERP

d) Telecom

e) Healthcare

f) E-commerece

g) Retail Market

h) System Software

Banking Domain:

A bank is a business; banks sell financial services such as Vehicle loans, home mortgage loans, business loans, checking accounts, credit card services, certificates of deposit, and individual retirement accounts etc...

Some people go to banks in search of a safe place to keep their money. Others are seeking to borrow money to buy a house or a car, start a business, expand a farm, pay for college, or do other things that require borrowing money.

Where do banks get the money to lend?

They get it from people who open accounts. Banks act as go-betweens for people who save and people who want to borrow. If savers didn’t put their money in banks, the banks would have little or no money to lend.

Types of Banks:

a) Saving Banks

Saving banks are established to create saving habit among the people. These banks are helpful for salaried people and low income groups. The deposits collected from customers are invested in bonds, securities, etc. At present most of the commercial banks carry the functions of savings banks. Postal department also performs the functions of saving bank.

b) Commercial Banks

Commercial banks are established with an objective to help businessmen. These banks collect money from general public and give short-term loans to businessmen by way of cash credits, overdrafts, etc. Commercial banks provide various services like collecting cheques, bill of exchange, remittance money from one place to another place.

c) Industrial Banks

Industrial or Development banks collect cash by issuing shares & debentures and providing long-term loans to industries. The main objective of these banks is to provide long-term loans for expansion and modernization of industries.

d) Land Mortgage Banks

Land Mortgage or Land Development banks are also known as Agricultural Banks because these are formed to finance agricultural sector. They also help in land development.

e) Central / Federal / National Bank

Every country of the world has a central bank. In India, Reserve Bank of India, in U.S.A, Federal Reserve and in U.K, Bank of England. These central banks are the bankers of the other banks. They provide specialized functions i.e. issue of paper currency, working as bankers of government, supervising and controlling foreign exchange. A central bank is a non-profit making institution. It does not deal with the public but it deals with other banks. The principal responsibility of Central Bank is thorough control on currency of a country.

f) Co-operative Banks

Co-operative banks generally give credit facilities to small farmers, salaried employees, small-scale industries, etc. Co-operative Banks are available in rural as well as in urban areas. The functions of these banks are just similar to commercial banks.

g) Exchange Banks

These banks are mainly concerned with financing foreign trade.

Following are the various functions of Exchange Banks:-

1. Remitting money from one country to another country,

2. Discounting of foreign bills,

3. Buying and Selling Gold and Silver, and

4. Helping Import and Export Trade.

h) Consumers Banks

Consumers bank is a new addition to the existing type of banks. Such banks are usually found only in advanced countries like U.S.A. and Germany. The main objective of this bank is to give loans to

consumers for purchase of the durables like Motor car, television set, washing machine, furniture, etc. The consumers have to repay the loans in easy installments.

Types of Bank Accounts

Savings accounts:

They are for people who want to keep their money in a safe place and earn interest at the same time. We don’t need a lot of money to open a savings account.

Certificates of deposit:

They are savings deposits that require you to keep a certain amount of money in the bank for a fixed period of time. Usually banks charge a penalty if we withdraw our money early.

Individual retirement accounts: They are savings deposits that offer an excellent way to save for our later years.

Checking accounts or Current accounts:

They offer safety and convenience. We keep our money in the account and write a check when we want to pay a bill or transfer some of our money to someone else. Banks sometimes charge a fee for checking accounts, many banks also offer no-fee checking and checking accounts that earn interest if you agree to keep a certain amount of money—a minimum balance—in the account.

Money market deposit accounts:

They are similar to checking accounts that earn interest, except that they usually pay a higher rate of interest and require a higher minimum balance.

Types of Loans

Personal Loans

Personal Bank Loans are the credits which a bank offers to its customer to meet his instant personal requirements ranging from home renovation to purchasing of new laptop, a getaway with family or for reimbursing the credit card liabilities, for buying a new car or for child's education, etc. Personal loan simplifies the cash flow of the customer besides handling its immediate needs.

Home Loans

Almost everyone will require a home loan if they are looking to buy a house of their own. In fact providing that we can afford it, getting a home loan is one of the best investment decisions that we can make.

Tax Benefits on Home Loans:

Any person who opts for home loan is entitled for tax benefits under Income Tax Act, 1961 on principal and the interest amount in the form of deductions from the chargeable earnings.

Bank Loans against Property:

Property Loan or Loan against property is a kind of loan which is allowed by the bank on the condition of keeping the customer's current assets as a security with them. These loans are very useful when other resources of financing get exhausted.

Business Loans:

Before starting a business, the entrepreneur should be mentally and financially prepared to encounter the fiscal setbacks during the process. To bail the companies out from the fiscal crunch, several banks in India offers business Loans both for meeting urgent official growth and expenses. Other details of Business Loans offered by Banks in India are:

Car Loans:

Every individual want to own a car. Hence, the need for car loans emerges at some point or the other. While selecting a car loan it is always wise to scrutinize the various options accessible in the market besides analyzing its fiscal suitability.

Education Loans

Education Loans offered by various banks in India provide much required assistance to fund your child's education when all other resources of finance get exhausted. Education Loans are offered by almost every Indian bank thus providing ample opportunity to students to undergo higher education both in India and abroad.

Types of Deposits

a) Savings account -

These are the simplest of deposits. We deposit money into our account and we can withdraw it anytime. There would be a small limitation on the number of times we can withdraw money from our account.

b) Current account -

These are similar to Savings accounts with two small differences. One is, the money in a current account does not earn interest and two is, you can withdraw any number of times. This account is for business people who would have high number of transactions in one single day.

c) Fixed Deposit -

This is a deposit product where we deposit a certain sum of money with the bank for a specific duration of time. As per the deposit agreement we are expected to let the money be with the bank based on the deposit tenure. Hence the interest offered on such deposits is higher than normal deposits. Also we will attract a penalty charge for pre-closing such deposits

d) Recurring Deposits -

These are similar to fixed deposits with a difference being, you deposit a small amount of money every month into this account for a specified duration of time and the bank would compound the interest every month and pay you in lump at the end of the tenure.

Banking Terms:

Account Holder:

Any person designated and authorized to transact business on behalf of an account. Each account holder's signature needs to be on file with the bank. The signature authorizes that person to conduct business on behalf of the account.

Affidavit:

A sworn statement in writing before a proper official, such as a notary public.

Annual Percentage Rate (APR):

The cost of credit on a yearly basis, expressed as a percentage.

Application:

An oral or written request for an extension of credit that is made in accordance with the procedures established by a creditor for the type of credit requested.

Appraisal:

The act of evaluating and setting the value of a specific piece of personal or real property.

Automated Teller Machine (ATM):

A machine, activated by a magnetically encoded card or other medium, that can process a variety of banking transactions. These include accepting deposits and loan payments, providing withdrawals, and transferring funds between accounts.

Automatic Bill Payment:

A checkless system for paying recurring bills with one authorization statement to a financial institution. For example, the customer would only have to provide one authorization form/letter/document to pay the cable bill each month. The necessary debits and credits are made through an Automated Clearing House (ACH).

Available Balance:

The balance of an account less any hold, uncollected funds, and restrictions against the account.

Balance Transfer:

The process of moving an outstanding balance from one credit card to another. This is usually done to obtain a lower interest rate on the outstanding balance. Transfers are sometimes subjected to a Balance Transfer Fee.

Bank Statement:

Periodically the bank provides a statement of a customer's deposit account. It shows all deposits made, all checks paid, and other debits posted during the period (usually one month), as well as the current balance.

Business Day:

Any day on which offices of a bank are open to the public for carrying on substantially all of the bank's business.

Cashier's Check:

A check drawn on the funds of the bank, not against the funds in a depositor's account. However, the depositor paid for the cashier's check with funds from their account. The primary benefit of a cashier's check is that the recipient of the check is assured that the funds are available.

Certificate of Deposit:

A negotiable instrument issued by a bank in exchange for funds, usually bearing interest, deposited with the bank.

Check:

A written order instructing a financial institution to pay immediately on demand a specified amount of money from the check writer's account to the person named on the check or, if a specific person is not named, to whoever bears the check to the institution for payment.

Check Truncation:

The conversion of data on a check into an electronic image after a check enters the processing system. Check truncation eliminates the need to return canceled checks to customers.

Checking Account:

A demand deposit account subject to withdrawal of funds by check.

Co-Maker:

A person who signs a note to guarantee a loan made to another person and is jointly liable with the maker for repayment of the loan. (Also known as a Co-signer.)

Credit Life Insurance:

A type of life insurance that helps repay a loan if you should die before the loan is fully repaid. This is optional coverage.

Credit Limit:

The maximum amount of credit that is available on a credit card or other line of credit account.

Debit:

A debit may be an account entry representing money you owe a lender or money that has been taken from your deposit account.

Debit Card:

A debit card allows the account owner to access their funds electronically. Debit cards may be used to obtain cash from automated teller machines or purchase goods or services using point-of-sale systems. The use of a debit card involves immediate debiting and crediting of consumers' accounts.

Demand Deposit:

A deposit of funds that can be withdrawn without any advance notice.

Draft:

A signed, written order by which one party (the drawer) instructs another party (the drawee) to pay a specified sum to a third party (the payee), at sight or at a specific date. Typical bank drafts are negotiable instruments and are similar in many ways to checks.

Drawee:

The person (or bank) who is expected to pay a check or draft when it is presented for payment.

Drawee bank:

The bank upon which a check is drawn.

Drawer:

The person who writes a check or draft instructing the drawee to pay someone else.

Electronic Banking:

A service that allows an account holder to obtain account information and manage certain banking transactions through a personal computer via the financial institution's Web site on the Internet. (This is also known as Internet or online banking.)

Electronic Funds Transfer (EFT):

The transfer of money between accounts by consumer electronic systems-such as automated teller machines (ATMs) and electronic payment of bills-rather than by check or cash. (Wire transfers, checks, drafts, and paper instruments do not fall into this category.)

First Mortgage:

A real estate loan which is in a first lien position, taking priority over all other liens. In case of a foreclosure, the first mortgage will be repaid before any other mortgages.

Fixed Rate Loan:

The interest rate and the payment remain the same over the life of the loan. The consumer makes equal monthly payments of principal and interest until the debt is paid in full.

Fixed Rate Mortgage:

A mortgage with payments that remain the same throughout the life of the loan because the interest rate and other terms are fixed and do not change.

Float:

The amount of uncollected funds represented by checks in the possession of one bank but drawn on other banks

Foreign Transaction Fees:

A fee assessed by your bank for making a transaction at another bank's ATM.

Forged Check:

A check on which the drawer's signature has been forged.

Forgery:

The fraudulent signing or alteration of another's name to an instrument such as a deed, mortgage, or check. The intent of the forgery is to deceive or defraud.

Guarantor:

A party who agrees to be responsible for the payment of another party's debts should that party default.

Home Equity Loan:

A home equity loan allows you to tap into your home's built-up equity, which is the difference between the amount that your home could be sold for and the amount that you still owe.

Inactive Account:

An account that has little or no activity; neither deposits nor withdrawals having been posted to the account for a significant period of time.

Individual Account:

An account in the name of one individual.

Insufficient Funds:

When a depositor's checking account balance is inadequate to pay a check presented for payment.

Interest:

The term interest is used to describe the cost of using money, a right, share, or title in property.

Joint Account:

An account owned by two or more persons. Either party can conduct transactions separately or together as set forth in the deposit account contract.

Lender:

An individual or financial institution that lends money with the expectation that the money will be returned with interest.

Line of Credit:

A pre-approved loan authorization with a specific borrowing limit based on creditworthiness. A line of credit allows borrowers to obtain a number of loans without re-applying each time as long as the total of borrowed funds does not exceed the credit limit.

Loan Fee:

A fee charged by a lender to make a loan (in addition to the interest charged to the borrower).

Local Check:

A check payable by, at, or through a bank in the same check processing region as the location of the branch of the depository bank. The depository bank is the bank into which the check was deposited.:

Maturity:

The date on which the principal balance of a loan, bond, or other financial instrument becomes due and payable.

Minimum Balance:

The amount of money required to be on deposit in an account to qualify the depositor for special services or to waive a service charge.

Minimum Payment:

The minimum dollar amount that must be paid each month on a loan, line of credit, or other debt.

Missing Payment:

A payment that has been made but not credited to the appropriate account.

Mortgage:

A debt instrument used in a real estate transaction where the property is the collateral for the loan. A mortgage gives the lender a right to take possession of the property if the borrower fails to pay off the loan.

Mortgage Loan:

A loan made by a lender to a borrower for the financing of real property.

Mortgagee:

The lender in a mortgage loan relationship.

Mortgagor:

The borrower in a mortgage loan relationship. (Property is used as collateral to make payment.)

Mutual Fund:

A fund operated by an investment company that raises money from shareholders and invests it in stocks, bonds, options, commodities, or money market securities. These funds offer investors the advantages of diversification and professional management.

Official Check:

A check drawn on a bank and signed by an authorized bank official. (Also known as a cashier's check.)

Online Banking:

A service that allows an account holder to obtain account information and manage certain banking transactions through a personal computer via the financial institution's web site on the Internet. (This is also known as Internet or electronic banking.)

Outstanding Check:

A check written by a depositor that has not yet been presented for payment to or paid by the depositor's bank.

Overdraft:

When the amount of money withdrawn from a bank account is greater than the amount actually available in the account, the excess is known as an overdraft, and the account is said to be overdrawn.

Overdraw:

To write a check for an amount that exceeds the amount on deposit in the account.

Overlimit:

An open-end credit account in which the assigned dollar limit has been exceeded.

Passbook:

A book in ledger form in which are recorded all deposits, withdrawals, and earnings of a customer's savings account.

Payee:

The person or organization to whom a check, draft, or note is made payable.

Paying (Payor) Bank :

A bank upon which a check is drawn and that pays a check or other draft.

Payment Due Date:

The date on which a loan or installment payment is due. It is set by a financial institution. Any payment received after this date is considered late; fees and penalties can be assessed.

Payoff:

The complete repayment of a loan, including principal, interest, and any other amounts due. Payoff occurs either over the full term of the loan or through prepayments.

Personal Identification Number (PIN):

Generally a four-character number or word, the PIN is the secret code given to credit or debit cardholders enabling them to access their accounts. The code is either randomly assigned by the bank or selected by the customer. It is intended to prevent unauthorized use of the card while accessing a financial service terminal.

Prepayment:

The payment of a debt before it actually becomes due.

Refund:

An amount paid back because of an overpayment or because of the return of an item previously sold.

Renewal:

A form of extending an unpaid loan in which the borrower's remaining unpaid loan balance is carried over (renewed) into a new loan at the beginning of the next financing period.

Statement:

A summary of all transactions that occurred over the preceding month and could be associated with a deposit account or a credit card account.

Stop Payment:

An order not to pay a check that has been issued but not yet cashed. If requested soon enough, the check will not be debited from the payer's account. Most banks charge a fee for this service.

Terms:

The period of time and the interest rate arranged between creditor and debtor to repay a loan.

Time Certificate of Deposit:

A time deposit evidenced by a negotiable or nonnegotiable instrument specifying an amount and maturity.

Uncollected Funds:

A portion of a deposit balance that has not yet been collected by the depository bank.

Wire Transfer:

A transfer of funds from one point to another by wire or network such the Federal Reserve Wire Network (also known as FedWire).

******************************************************

INTERVIEW QUESTION

********************************************

1. What is Acceptance Testing?

Testing conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria.

2. What is Accessibility Testing?

Verifying a product is accessible to the people having disabilities (deaf, blind, mentally disabled etc.).

3. What is Ad-Hoc Testing?

A testing phase where the tester tries to 'break' the system by randomly trying the system's functionality. Can include negative testing as well. See also Monkey Testing.

4. What is Agile Testing?

Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm. See also Test Driven Development.

5. What is Application Binary Interface (ABI)?

A specification defining requirements for portability of applications in binary forms across different system platforms and environments.

6. What is Application Programming Interface (API)?

A formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services.

7. What is Automated Software Quality (ASQ)?

The use of software tools, such as automated testing tools, to improve software quality.

8. What is Automated Testing?

Testing employing software tools which execute tests without manual intervention. Can be applied in GUI, performance, API, etc. testing. The use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.

9. What is Backus-Naur Form?

A metalanguage used to formally describe the syntax of a language.

10. What is Basic Block?

A sequence of one or more consecutive, executable statements containing no

branches.

11. What is Basis Path Testing?

A white box test case design technique that uses the algorithmic flow of the program to design tests.

12. What is Basis Set?

The set of tests derived using basis path testing.

13. What is Baseline?

The point at which some deliverable produced during the software engineering process is put under formal change control.

14. What you will do during the first day of job?

What would you like to do five years from now?

15. What is Beta Testing?

Testing of a rerelease of a software product conducted by customers.

16. What is Binary Portability Testing?

Testing an executable application for portability across system platforms and environments, usually for conformation to an ABI specification.

17. What is Black Box Testing?

Testing based on an analysis of the specification of a piece of software without reference to its internal workings. The goal is to test how well the component conforms to the published requirements for the component.

18. What is Bottom Up Testing?

An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested.

19. What is Boundary Testing?

Test which focus on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests).

20. What is Boundary Value Analysis?

BVA is similar to Equivalence Partitioning but focuses on "corner cases" or values that are usually out of range as defined by the specification. his means that if a function expects all values in range of negative 100 to positive 1000, test inputs would include negative 101 and positive 1001.

21. What is Branch Testing?

Testing in which all branches in the program source code are tested at least once.

22. What is Breadth Testing?

A test suite that exercises the full functionality of a product but does not test features in detail.

23. What is CAST?

Computer Aided Software Testing.

24. What is Capture/Replay Tool?

A test tool that records test input as it is sent to the software under test. The input cases stored can then be used to reproduce the test at a later time. Most commonly applied to GUI test tools.

25. What is CMM?

The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes.

27. What is Cause Effect Graph?

A graphical representation of inputs and the associated outputs effects which can be used to design test cases.

28. What is Code Complete?

Phase of development where functionality is implemented in entirety; bug fixes are all that are left. All functions found in the Functional Specifications have been implemented.

29. What is Code Coverage?

An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention.

30. What is Code Inspection?

A formal testing technique where the programmer reviews source code with a

group who ask questions analyzing the program logic, analyzing the code with respect to a checklist of historically common programming errors, and analyzing its compliance with coding standards.

31. What is Code Walkthrough?

A formal testing technique where source code is traced by a group with a small set of test cases, while the state of program variables is manually monitored, to analyze the programmer's logic and assumptions.

32. What is Coding?

The generation of source code.

33. What is Compatibility Testing?

Testing whether software is compatible with other elements of a system with which it should operate, e.g. browsers, Operating Systems, or hardware.

34. What is Component?

A minimal software item for which a separate specification is available.

35. What is Component Testing?

Testing of individual software components (Unit Testing).

36. What is Concurrency Testing?

Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single-threaded code and locking semaphores.

37. What is Conformance Testing?

The process of testing that an implementation conforms to the specification on which it is based. Usually applied to testing conformance to a formal standard.

38. What is Context Driven Testing?

The context-driven school of software testing is flavor of Agile Testing that advocates continuous and creative evaluation of testing opportunities in light of the potential information revealed and the value of that information to the organization right now.

39. What is Conversion Testing?

Testing of programs or procedures used to convert data from existing systems for use in replacement systems.

40. What is Cyclomatic Complexity?

A measure of the logical complexity of an algorithm, used in white-box testing.

41. What is Data Dictionary?

A database that contains definitions of all data items defined during analysis.

42. What is Data Flow Diagram?

A modeling notation that represents a functional decomposition of a system.

43. What is Data Driven Testing?

Testing in which the action of a test case is parameterized by externally defined data values, maintained as a file or spreadsheet. A common technique in Automated Testing.

44. What is Debugging?

The process of finding and removing the causes of software failures.

45. What is Defect?

Non-conformance to requirements or functional / program specification

46. What is Dependency Testing?

Examines an application's requirements for pre-existing software, initial states and configuration in order to maintain proper functionality.

47. What is Depth Testing?

A test that exercises a feature of a product in full detail.

48. What is Dynamic Testing?

Testing software through executing it. See also Static Testing.

49. What is Emulator?

A device, computer program, or system that accepts the same inputs and produces the same outputs as a given system.

50. What is Endurance Testing?

Checks for memory leaks or other problems that may occur with prolonged

execution

51. What is End-to-End testing?

Testing a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

52. What is Equivalence Class?

A portion of a component's input or output domains for which the component's behaviour is assumed to be the same from the component's specification.

53. What is Equivalence Partitioning?

A test case design technique for a component in which test cases are designed to execute representatives from equivalence classes.

54. What is Exhaustive Testing?

Testing which covers all combinations of input values and preconditions for an element of the software under test.

55. What is Functional Decomposition?

A technique used during planning, analysis and design; creates a functional hierarchy for the software.

55. What is Functional Testing?

Testing the features and operational behavior of a product to ensure they correspond to its specifications. Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions. or Black Box Testing.

56. What is Glass Box Testing?

A synonym for White Box Testing.

57. What is Gorilla Testing?

Testing one particular module, functionality heavily.

58. What is Gray Box Testing?

A combination of Black Box and White Box testing methodologies? testing a piece of software against its specification but using some knowledge of its internal workings.

59. What is High Order Tests?

Black-box tests conducted once the software has been integrated.

60. What is Independent Test Group (ITG)?

A group of people whose primary responsibility is software testing,

61. What is Inspection?

A group review quality improvement process for written material. It consists of two aspects; product (document itself) improvement and process improvement (of both document production and inspection).

62. What is Integration Testing?

Testing of combined parts of an application to determine if they function together correctly. Usually performed after unit and functional testing. This type of testing is especially relevant to client/server and distributed systems.

63. What is Installation Testing?

Confirms that the application under test recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.

64. What is Load Testing?

See Performance Testing.

65. What is Localization Testing?

This term refers to making software specifically designed for a specific locality.

66. What is Loop Testing?

A white box testing technique that exercises program loops.

67. What is Metric?

A standard of measurement. Software metrics are the statistics describing the structure or content of a program. A metric should be a real objective measurement of something such as number of bugs per lines of code.

68. What is Monkey Testing?

Testing a system or an Application on the fly, i.e just few tests here and there to ensure the system or an application does not crash out.

69. What is Negative Testing?

Testing aimed at showing software does not work. Also known as "test to fail". See also Positive Testing.

70. What is Path Testing?

Testing in which all paths in the program source code are tested at least once.

71. What is Performance Testing?

Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users. Also know as "Load Testing".

72. What is Positive Testing?

Testing aimed at showing software works. Also known as "test to pass". See also Negative Testing.

73. What is Quality Assurance?

All those planned or systematic actions necessary to provide adequate confidence that a product or service is of the type and quality needed and expected by the customer.

74. What is Quality Audit?

A systematic and independent examination to determine whether quality activities and related results comply with planned arrangements and whether these arrangements are implemented effectively and are suitable to achieve objectives.

75. What is Quality Circle?

A group of individuals with related interests that meet at regular intervals to consider problems or other matters related to the quality of outputs of a process and to the correction of problems or to the improvement of quality.

76. What is Quality Control?

The operational techniques and the activities used to fulfill and verify requirements of quality.

77. What is Quality Management?

That aspect of the overall management function that determines and implements the quality policy.

78. What is Quality Policy?

The overall intentions and direction of an organization as regards quality as formally expressed by top management.

79. What is Quality System?

The organizational structure, responsibilities, procedures, processes, and resources for implementing quality management.

80. What is Race Condition?

A cause of concurrency problems. Multiple accesses to a shared resource, at least one of which is a write, with no mechanism used by either to moderate simultaneous access.

81. What is Ramp Testing?

Continuously raising an input signal until the system breaks down.

82. What is Recovery Testing?

Confirms that the program recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions

83. What is Regression Testing?

Retesting a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of the changes made.

84. What is Release Candidate?

A pre-release version, which contains the desired functionality of the final version, but which needs to be tested for bugs (which ideally should be removed before the final version is released).

85. What is Sanity Testing?

Brief test of major functional elements of a piece of software to determine if its basically operational.

86. What is Scalability Testing?

Performance testing focused on ensuring the application under test gracefully handles increases in work load.

87. What is Security Testing?

Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level.

88. What is Smoke Testing?

A quick-and-dirty test that the major functions of a piece of software work. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.

89. What is Soak Testing?

Running a system at high load for a prolonged period of time. For example, running several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed.

90. What is Software Requirements Specification?

A deliverable that describes all data, functional and behavioral requirements, all constraints, and all validation requirements for software/

91. What is Software Testing?

A set of activities conducted with the intent of finding errors in software.

92. What is Static Analysis?

Analysis of a program carried out without executing the program.

93. What is Static Analyzer?

A tool that carries out static analysis.

94. What is Static Testing?

Analysis of a program carried out without executing the program.

95. What is Storage Testing?

Testing that verifies the program under test stores data files in the correct directories and that it reserves sufficient space to prevent unexpected termination resulting from lack of space. This is external storage as opposed to internal storage.

96. What is Stress Testing?

Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Often this is performance testing using a very high level of simulated load.

97. What is Structural Testing?

Testing based on an analysis of internal workings and structure of a piece of software. See also White Box Testing.

98. What is System Testing?

Testing that attempts to discover defects that are properties of the entire system rather than of its individual components.

99. What is Testability?

The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met.

100. What is Testing?

The process of exercising software to verify that it satisfies specified requirements and to detect errors. The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs), and to evaluate the features of the software item (Ref. IEEE Std 829). The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component. What is Test Automation? It is the same as Automated Testing.

101. What is Test Bed?

An execution environment configured for testing. May consist of specific hardware, OS, network topology, configuration of the product under test, other application or system software, etc. The Test Plan for a project should enumerated the test beds(s) to be used.

102. What is Test Case?

Test Case is a commonly used term for a specific test. This is usually the smallest unit of testing. A Test Case will consist of information such as requirements testing, test steps, verification steps, prerequisites, outputs, test environment, etc. A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. Test Driven Development? Testing methodology associated with Agile Programming in which every chunk of code is covered by unit tests, which must all pass all the

time, in an effort to eliminate unit-level and regression bugs during development. Practitioners of TDD write a lot of tests, i.e. an equal number of lines of test code to the size of the production code.

103. What is Test Driver?

A program or test tool used to execute tests. Also known as a Test Harness.

104. What is Test Environment?

The hardware and software environment in which tests will be run, and any other software with which the software under test interacts when under test including stubs and test drivers.

105. What is Test First Design?

Test-first design is one of the mandatory practices of Extreme Programming (XP).It requires that programmers do not write any production code until they have first written a unit test.

106. What is Test Harness?

A program or test tool used to execute a tests. Also known as a Test Driver.

107. What is Test Plan?

A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning.

108. What is Test Procedure?

A document providing detailed instructions for the execution of one or more test cases.

109. What is Test Script?

Commonly used to refer to the instructions for a particular test that will be carried out by an automated test tool.

110. What is Test Specification?

A document specifying the test approach for a software feature or combination or features and the inputs, predicted results and execution conditions for the associated tests.

111. What is Test Suite?

A collection of tests used to validate the behavior of a product. The scope of a Test Suite varies from organization to organization. There may be several Test Suites for a particular product for example. In most cases however a Test Suite is a high level concept, grouping together hundreds or thousands of tests related by what they are intended to test.

112. What is Test Tools?

Computer programs used in the testing of a system, a component of the system, or its documentation.

113. What is Thread Testing?

A variation of top-down testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by successively lower levels.

114. What is Top Down Testing?

An approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested.

115. What is Total Quality Management?

A company commitment to develop a process that achieves high quality product and customer satisfaction.

116. What is Traceability Matrix?

A document showing the relationship between Test Requirements and Test Cases.

117. What is Usability Testing?

Testing the ease with which users can learn and use a product.

-------------------------------------------------------------------

Q: How do you introduce a new software QA process?

A: It depends on the size of the organization and the risks involved. For large organizations with high-risk projects, a serious management buy-in is required and a formalized QA process is necessary. For medium size organizations with lower risk projects, management and organizational buy-in and a slower, step-by-step process is required. Generally speaking, QA processes should be balanced with productivity, in order to keep any bureaucracy from getting out of hand. For smaller groups or projects, an ad-hoc process is more appropriate. A lot depends on team leads and managers, feedback to developers and good communication is essential among customers, managers, developers, test engineers and testers. Regardless the size of the company, the greatest value for effort is in managing requirement processes, where the goal is requirements that are clear, complete and

testable.

Q: What is the role of documentation in QA?

A: Documentation plays a critical role in QA. QA practices should be documented, so that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals should all be documented. Ideally, there should be a system for easily finding and obtaining of documents and determining what document will have a particular piece of information. Use documentation change management, if possible.

Q: What makes a good test engineer?

A: Good test engineers have a "test to break" attitude. We, good test engineers, take the point of view of the customer; have a strong desire for quality and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers and an ability to communicate with both technical and non-technical people. Previous software development experience is also helpful as it provides a deeper understanding of the software development process, gives the test engineer an appreciation for the developers' point of view and reduces the learning curve in automated test tool programming.

G C Reddy is a good test engineer because he has a "test to break" attitude, takes the point of view of the customer, has a strong desire for quality, has an attention to detail, He's also tactful and diplomatic and has good a communication skill, both oral and written. And he has previous software development experience, too.

Q: What is a test plan?

A: 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 none outside the test group will be able to read it.

Q: What is a test case?

A: A test case is a document that describes an input, action, or event and its expected result, in order to determine if a feature of an application is working correctly. A test case should contain particulars such as a...

• Test case identifier;

• Test case name;

• Objective;

• Test conditions/setup;

• Input data requirements/steps, and

• Expected results.

Please note, the process of developing test cases can help find problems in the requirements or design of an application, since it requires you to completely think through the operation of the application. For this reason, it is useful to prepare test cases early in the development cycle, if possible.

Q: What should be done after a bug is found?

A: When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate

these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.

Q: What is configuration management?

A: Configuration management (CM) covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, changes made to them and who makes the changes. Rob Davis has had experience with a full range of CM tools and concepts, and can easily adapt to your software tool and process needs.

Q: What if the software is so buggy it can't be tested at all?

A: In this situation the best bet is to have test engineers go through the process of reporting whatever bugs or problems initially show up, with the focus being on critical bugs.

Since this type of problem can severely affect schedules and indicates deeper problems in the software development process, such as insufficient unit testing, insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem.

Q: What if there isn't enough time for thorough testing?

A: Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects.

Use risk analysis to determine where testing should be focused. This requires judgment skills, common sense and experience. The checklist should include answers to the following questions:

• Which functionality is most important to the project's intended purpose?

• Which functionality is most visible to the user?

• Which functionality has the largest safety impact?

• Which functionality has the largest financial impact on users?

• Which aspects of the application are most important to the customer?

• Which aspects of the application can be tested early in the development cycle?

• Which parts of the code are most complex and thus most subject to errors?

• Which parts of the application were developed in rush or panic mode?

• Which aspects of similar/related previous projects caused problems?

• Which aspects of similar/related previous projects had large maintenance expenses?

• Which parts of the requirements and design are unclear or poorly thought out?

• What do the developers think are the highest-risk aspects of the application?

• What kinds of problems would cause the worst publicity?

• What kinds of problems would cause the most customer service complaints?

• What kinds of tests could easily cover multiple functionalities?

• Which tests will have the best high-risk-coverage to time-required ratio?

Q: What if the project isn't big enough to justify extensive testing?

A: Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the considerations listed under "What if there isn't enough time for thorough testing?" do apply. The test engineer then should do "ad hoc" testing, or write up a limited test plan based on the risk analysis.

Q: What can be done if requirements are changing continuously?

A: Work with management early on to understand how requirements might change, so that alternate test plans and strategies can be worked out in advance. It is helpful if the application's initial design

allows for some adaptability, so that later changes do not require redoing the application from scratch. Additionally, try to...

• Ensure the code is well commented and well documented; this makes changes easier for the developers.

• Use rapid prototyping whenever possible; this will help customers feel sure of their requirements and minimize changes.

• In the project's initial schedule, allow for some extra time to commensurate with probable changes.

Move new requirements to a 'Phase 2' version of an application and use the original requirements for the 'Phase 1' version.

Negotiate to allow only easily implemented new requirements into the project.

• Ensure customers and management understand scheduling impacts, inherent risks and costs of significant requirements changes. Then let management or the customers decide if the changes are warranted; after all, that's their job.

• Balance the effort put into setting up automated testing with the expected effort required to redo them to deal with changes.

• Design some flexibility into automated test scripts;

• Focus initial automated testing on application aspects that are most likely to remain unchanged;

• Devote appropriate effort to risk analysis of changes, in order to minimize regression-testing needs;

• Design some flexibility into test cases; this is not easily done; the best bet is to minimize the detail in the test cases, or set up only higher-level generic-type test plans;

Focus less on detailed test plans and test cases and more on ad-hoc testing with an understanding of the added risk this entails.

Q: How do you know when to stop testing?

A: This can be difficult to determine. Many modern software applications are so complex and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are...

• Deadlines, e.g. release deadlines, testing deadlines;

• Test cases completed with certain percentage passed;

• Test budget has been depleted;

• Coverage of code, functionality, or requirements reaches a specified point;

• Bug rate falls below a certain level; or

• Beta or alpha testing period ends.

Q: What if the application has functionality that wasn't in the requirements?

A: It may take serious effort to determine if an application has significant unexpected or hidden functionality, which it would indicate deeper problems in the software development process. If the functionality isn't necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer.

If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only affects areas, such as minor improvements in the user interface, it may not be a significant risk.