Introduction- fundamental design concepts

The design concepts provide the software designer with a foundation from which more
sophisticated methods can be applied. A set of fundamental design concepts has evolved. They
are as follows:

1. Abstraction - Abstraction is the process or result of generalization by reducing

the information content of a concept or an observable phenomenon, typically in order to
retain only information which is relevant for a particular purpose.
2. Refinement - It is the process of elaboration. A hierarchy is developed by
decomposing a macroscopic statement of function in a step-wise fashion until
programming language statements are reached. In each step, one or several instructions
of a given program are decomposed into more detailed instructions. Abstraction and
Refinement are complementary concepts.
3. Modularity - Software architecture is divided into components called modules.
4. Software Architecture - It refers to the overall structure of the software and the
ways in which that structure provides conceptual integrity for a system. Good software
architecture will yield a good return on investment with respect to the desired outcome of
the project, e.g. in terms of performance, quality, schedule and cost.
5. Control Hierarchy - A program structure that represents the organization of a
program component and implies a hierarchy of control.
6. Structural Partitioning - The program structure can be divided both horizontally
and vertically. Horizontal partitions define separate branches of modular hierarchy for
each major program function. Vertical partitioning suggests that control and work should
be distributed top down in the program structure.
7. Data Structure - It is a representation of the logical relationship among
individual elements of data.
8. Software Procedure - It focuses on the processing of each module individually.
9. Information Hiding - Modules should be specified and designed so that
information contained within a module is inaccessible to other modules that have no
need for such information.
In his object model, Grady Booch mentions Abstraction, Encapsulation, Modularisation, and
Hierarchy as fundamental software design principles. The acronym PHAME (Principles of
Hierarchy, Abstraction, Modularisation, and Encapsulation) is sometimes used to refer to these
four fundamental principles.
 Modules and modularization criteria

Modular design, or "modularity in design", is a design approach that subdivides a

system into smaller parts called modules or skids, that can be independently
created and then used in different systems. A modular system can be
characterized by functional partitioning into discrete scalable, reusable modules;
rigorous use of well-defined modular interfaces; and making use of industry
standards for interfaces.

Besides reduction in cost (due to less customization, and shorter learning time), and
flexibility in design, modularity offers other benefits such as augmentation (adding new
solution by merely plugging in a new module), and exclusion. Examples of modular
systems are cars, computers, process systems, solar panels andwind
turbines, elevators and modular buildings. Earlier examples include looms, railroad
signaling systems, telephone exchanges, pipe organs and electric power
distribution systems. Computers use modularity to overcome changing customer
demands and to make the manufacturing process more adaptive to change
(seemodular programming). Modular design is an attempt to combine the advantages
of standardization (high volume normally equals low manufacturing costs) with those
of customization. A downside to modularity (and this depends on the extent of
modularity) is that low quality modular systems are not optimized for performance. This
is usually due to the cost of putting up interfaces between modules.
Modularization is a technique to divide a software system into multiple
discrete and independent modules, which are expected to be capable of
carrying out task(s) independently. These modules may work as basic
constructs for the entire software. Designers tend to design modules such
that they can be executed and/or compiled separately and independently.

Modular design unintentionally follows the rules of ‘divide and conquer’

problem-solving strategy this is because there are many other benefits
attached with the modular design of a software.

Advantage of modularization:

 Smaller components are easier to maintain

 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect

Design notation : Procedure template, Pseudo code -

Structured flow chart decision

Design notation
Design notations are used when planning and should be able to communicate the purpose of a
program without the need for formal code. Commonly used design notations are:

 Pseudocode
 Flow charts
 Structure chart
Pseudocode
When designing a program, it is useful to lay out how the program might work, before writing it
in a programming language,.

Pseudocode is a design notation that is closely related to the logic of how a program will work. It
lets you detail what your program will do without having to worry about the particular syntax of
your chosen programming language.

There is no specific standard for pseudocode and programmers often have their own version.
Pseudocode can look a lot like code but it does not need to be implemented as strictly.

Programming languages like python, reference language (used by the SQA) and visual basic will
have specific rules around syntax and structure, whereas pseudocode gives more freedom.

There is no strict set of rules for pseudocode, but some of the most widely recognised are:

 INPUT – indicates a user will be inputting something

 OUTPUT – indicates that an output will appear on the screen
 WHILE – a loop (iteration that has a condition at the beginning)
 FOR – a counting loop (iteration)
 REPEAT – UNTIL – a loop (iteration) that has a condition at the end
 IF – THEN – ELSE – a decision (selection) in which a choice is made
Pseudocode can be used to plan out programs. It is similar to actual code. Planning a program
that asks people what their favourite subject is could look like this in pseudocode:

REPEAT
OUTPUT 'What is the best subject you take?'
INPUT user inputs the best subject they take
STORE the user's input in the answer variable
IF answer = 'Computer Science' THEN
OUTPUT 'Of course it is!'
ELSE
OUTPUT 'Try again!'
UNTIL answer = 'Computer Science'
A programmer who uses pseudocode as part of their planning is able to take time to think about
how their program will work, what variables they might need and what inputs and outputs there
are.

Flow charts
Flow charts show what is going on in a program and how data flows around it. Flow charts can
represent everyday processes, show decisions taken and the result of these decisions.
The diamond shape explains when there is a choice to make. The flow chart shows what happens
depending on the decision made at this point. Flow charts visualise the results of decisions,
showing what will happen in a program, and also when, for example an if statement, is required
to make a decision.

Flow charts can be used to show iteration (repeating something).

In the above flow chart, the user is asked what their favourite subject is. If they answer
'Computing Science' they are told they are 'clearly very intelligent' and the program stops.

Any other answer results in the user being asked again. If the user does not enter 'Computing
Science', the program will keep going round and round, asking them forever until they enter
Computing Science.

Structure diagrams
Another way of representing a program design is to use a structure diagram. Structure diagrams
break down a problem into smaller sections. These smaller sections can then be worked on one at
a time.

This can be good for big projects where a large problem can be split into smaller tasks for
separate groups, or individuals, to work on.

Below is an example of how a structure diagram might be used to break a large problem down.
This shows how you can take a complex problem and start breaking it down into more
manageable chunks.

In reality, a complex project like building a house would have many more stages, but this
example shows that structure diagrams can help to break down problems when designing a
program.

You would most likely use a structure diagram if you were designing a game and wanted to
break down the overall design problem into individual elements.
Algorithms
An algorithm is a step-by-step procedure for solving a problem in a finite number of steps. It is
essentially some code that accomplishes a certain task.

For example, algorithms might:

 check data has been entered correctly

 test if a number is even
 calculate a person's salary
 convert a piece of text from lower case to upper case
Any bit of written code that carries out a specific task could be said to be an algorithm.

Input Validation algorithm

Input Validation means making sure a piece of data is correct. You might want someone to enter
their age into your program and check that the value they enter is sensible.

You might therefore check that the value they enter is between 0 and 130. Anything outside that
range will be flagged up to them as not sensible and they would then be asked to enter an
appropriate value. This type of validation is often used when people fill out forms online.

Validation is such a common occurrence in programming that a standard algorithm exists.

Tables
A decision table is a good way to deal with combinations of things (e.g. inputs). This technique is
sometimes also referred to as a ’cause-effect’ table. The reason for this is that there is an associated
logic diagramming technique called ’cause-effect graphing’ which was sometimes used to help derive
the decision table (Myers describes this as a combinatorial logic network [Myers, 1979]). However, most
people find it more useful just to use the table described in [Copeland, 2003].

 Decision tables provide a systematic way of stating complex business rules, which is
useful for developers as well as for testers.

 Decision tables can be used in test design whether or not they are used in specifications,
as they help testers explore the effects of combinations of different inputs and other software
states that must correctly implement business rules.

 It helps the developers to do a better job can also lead to better relationships with
them. Testing combinations can be a challenge, as the number of combinations can often be
huge. Testing all combinations may be impractical if not impossible. We have to be satisfied with
 testing just a small subset of combinations but making the choice of which combinations to test
and which to leave out is also important. If you do not have a systematic way of selecting
combinations, an arbitrary subset will be used and this may well result in an ineffective test
effort.

Why Decision table is important?

Decision tables are very much helpful in test design technique – it helps testers to search
the effects of combinations of different inputs and other software states that must correctly
implement business rules. Also, provides a regular way of stating complex business rules,
that’s helpful for developers as well as for testers. Testing combinations can be a challenge,
as the number of combinations can often be huge. It assists in development process with
developer to do a better job. Testing with all combination might be unrealistic or unfeasible.
We have to be happy with testing just a small subset of combinations but making the option
of which combinations to test and which to leave out is also significant. If you do not have a
efficient way of selecting combinations, an arbitrary subset will be used and this may well
result in an ineffective test effort.

A decision table is basically an outstanding technique used in both testing and requirements
management. It is a structured exercise to prepare requirements when dealing with
complex business rules. Also, used in model complicated logic.

Way to use decision tables in test designing

Firstly; get to know a suitable function or subsystem that acts according to a combination of
inputs or events. Taken system should be with fewer inputs or else combinations will
become impossible. Always better to take maximum numbers of conditions, split them into
subsets and use these subsets one at a time. After getting features that need to be
combined, add them to a table showing all combinations of “Yes” and “No” for each of the
feature.

Let’s take an example of a finance application, where users pay money – monthly
Repayment or year wise (the term of loan). If user chooses both options, the system will
create a negotiation between two. So, there are two conditions of the loan amount, mention
in the given below table,

TABLE 1: Blank decision table

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has

been mentioned

Terms of loan has been

mentioned

Next, recognize all of the combinations in “Yes” and “No” (In Table 2). In each column of
two conditions mention “Yes” or “No”, user will get here four combinations (two to the
power of the number of things to be combined). Note, if user has three things to combine,
they will have eight combinations, with four things, there are 16, etc. Because of this, it’s
always good to take small sets of combinations at once. To keep track on combinations,
give alternate “Yes” and “No” on the bottom row, put two “Yes” and then two “No” on the
row above the bottom row, etc., so the top row will have all “Yes” and then all “No” (Apply
the same principle to all such tables).

TABLE 2: Decision table – Input combination

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N

been mentioned

Terms of loan has been Y N Y N

mentioned

In the next step, recognize the exact outcome for each combination (In Table 3). In this
example, user can enter one or both of the two fields. Each combination is sometimes
referred to as a step.

TABLE 3: Decision table – Combinations and outcomes

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N

been mentioned

Terms of loan has been Y N Y N

mentioned

Actions/Outcomes
Process loan money Y Y

Process term Y Y

At this time you didn’t think that what will happen when customer don’t enter anything in
either of the two fields. The table has shown a combination that was not given in the
specification for this example. This combination can result as an error message, so it is
necessary to add another action (In Table 4). This will flash the strength this method to find
out omissions and ambiguities in specifications.

TABLE 4: Decision table – Additional outcomes

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N

been mentioned

Terms of loan has been Y N Y N

mentioned

Actions/Outcomes

Process loan money Y Y

Process term Y Y

Error message Y

We will provide you some other example that allows the customer to enter both repayment
and term. This will change the outcome of our table, this will generate an error message if
both are entered (Shown in Table 5).

TABLE 5: Decision table – Changed outcomes

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N

been mentioned
Terms of loan has been Y N Y N
mentioned

Actions/Outcomes

Process loan money Y

Process term Y

Error message Y Y

Design techniques
Software testing is a process carried out to check and confirm the delivery potential of the
software. In this procedure, a set of pre-decided inputs are fed into the software and the output
produced is measured against the expected results. This process helps to ensure that the
software is working as desired and can be released into the market. Software released without
sufficient testing can damage the company’s standing in two ways. First, it will generate poor
customer reviews, and second, it will lead to more serious problems such as the leakage of
the customer’s private data. This can severely impair the organization’s business prospects.

Software test design refers to the process of designing different tests that validate the eligibility
of a software before its release in the market. The process of test designing assumes high
priority, as a poorly designed test will lead to improper testing of an application. This, in turn,
leads to failure in identifying defects and consequently, an application containing errors may be
released.

While a developer has to ensure that the software meets the specifications, a business owner
has to ensure that it meets the business’ operational needs. To satisfy these individual goals
and the main aim of the software development process, that is a high-quality output, one will
have to plan, design, and conduct tests in different environments. To ensure that the testing
strategy chalked out is an effective one, following the below-mentioned steps is essential:

1. Gathering and understanding the requirements of the users

2. Deriving all important business scenarios
3. Designing test scenarios for all the important business scenarios
4. Assigning all the designed test scenarios to different test cases
Once done with all the above-mentioned steps, one will have to choose a test design technique
as per the requirements of their business. Some of the most common design techniques are
listed below.
2 Types of Software Test Design Techniques

There are various types of designing techniques, each of which is suitable for identifying a
particular type of error. Hence, the challenge lies in selecting the right set of relevant test design
techniques for the particular application. Software test design techniques can be broadly
classified into two major categories: static and dynamic techniques.

1. Static Test Design Techniques:

Static testing refers to the testing of software manually or with the help of tools. Static
testing is usually carried out during the early phase of software development life cycle.
Static testing is useful for testing multiple aspects of a software, including source code,
functional and requirement specifications, and design documents and models.

Static testing can be further divided into two categories based upon whether it is
performed manually or with the help of tools.

Classes of Static Test Design Techniques:

Manual With Help of Tools

Walk through Analysis of coding standard using compiler

Informal review Analysis of code metrics

Technical review Analysis of code structure

Audit

Inspection

Management review
Manual Static Test Design Techniques
These are of the following kinds and differ in the formality of the process.

 Walk through:
Walk through is not a formal process of review and is carried out by authors. The authors
guide the participants through the document and try and understand their thought
processes, in order to gain feedback and arrive at a common understanding.

 Informal Review:
An informal review aims to improve the quality of the tested product through discussions and
is usually not documented. The preliminary stage of the review may involve assessment by a
two-member team whereas during later stages, the reviewing team size may increase and
may require more meetings.

 Technical Review:
A technical review is carried out by a trained moderator or technical expert. It is less formal
as compared to an inspection. It is usually carried out as a peer review without any
participation from management.

 Audit:

An audit is an independent examination of all the documents related to the software, carried
out by an external agent. Audits provide increased assurance to the various stakeholders of
the project that the document is up to standards and devoid of any defects.

 Inspection:
An inspection is the most formal type of review and is conducted by trained moderators.
During an inspection, the documents and products are examined through a process of
reviews and defects are identified. The defects identified are documented in a logging list or
issue log and a formal follow-up is carried out.

 Management Review:
The management review is a cross-functional review undertaken by an organization’s top
management. It includes analyses of customer satisfaction, determination of the cost of poor
quality, performance trends and achievement of objectives defined in the business plan.

 2.Dynamic Test Design Techniques:

o Dynamic testing involves execution of the test object (application) on a computer.
The input data is fed into the test object (application) and the program is executed. In
 dynamic testing, various variable quantities such as memory usage, response time, CPU
usage and overall performance of the software are analyzed against the expected output.
Dynamic testing is carried out during the validation process. Dynamic test design
techniques can be further classified into:
 Specification-based (black-box, also known as behavioral techniques)
 Structure-based (white-box or structural techniques
 Experience- based
Dynamic Testing Techniques:

Specification-based Structure-based Experience-based

Boundary Value Analysis Exploratory

Statement Coverage or Line Coverage
(BVA) Testing

Condition Coverage or Predicate

Equivalence Partitioning (EP) Fault Attack
Coverage

Decision Table Testing Decision Coverage or Branch Coverage

State Transition Diagrams Multiple Condition Coverage

Use Case Testing

Specification-Based / Black Box Test Design Technique|:

Also known as specification-based test design technique, the black box test design
technique uses the software’s external descriptions such as the technical specifications,
design, customer requirements, etc. This implies that a tester who does not have any
knowledge about the code or internal structure can also perform the test. Some of the well-
known methods in this technique are:

o Boundary Value Analysis:

The best method of the black box design technique, boundary value analysis comprises
testing the input values at the boundaries. Generally, the input values are put to test at the
initial stages to reduce the chances of causing errors

o Decision Table Testing:

 Identifying the test conditions as per the decision tables which are associated with
different conditions is known as decision table testing. Each and every decision keeps up a
correspondence to predicates, relations, or variables. Decision tables which have a
‘hyphen’ symbol are known to have little influence on the actions that are being
performed.

o State Transition Testing:

Identifying the test conditions from a state table is state transition testing. This test case
design method is best used for applications with implanted workflow within them.

o Equivalence Class Partitioning:

The purpose of this type of test design method is to reduce the number of tests by dividing
the different types of test. Once the tests have been divided, the system will behave in a
similar way for the different tests with equivalence partition.

o Use Case Testing:

The method of deriving the test condition from use case is known as use case testing. The
test cases designed as per this type of method execute the different business scenarios and
user functionalities.

Structure-based / White Box Test Design Technique

The exact opposite of the black box test design technique, white box test design technique
necessitates knowledge of the internal structure of a program. Some of the methods
implemented in this type of technique are:

o Condition Coverage:
Most of the outcomes of test cases designed as per the white box test design technique are
derived by following the condition coverage method. By following this method, the test
cases are designed in a manner that the condition outcomes (the evaluation of a condition
as ‘true’ or ‘false’) are executed automatically.

o Decision Coverage:
In the decision coverage method, the test cases are designed in a manner that the decision
outcomes are executed automatically. It ensures that each possible branch from a decision
point is implemented at least once.

o Statement Coverage:
This method involves calculation of the percentage of executable statements which are
being exercised by the test suite.
 o Multiple Condition Coverage:
Every combination of ‘true’ or ‘false’ for the conditions related to a decision have to be
tested in this technique.

Experience-Based Test Design Technique:

As the name suggests, the experience-based technique neither involves internal, nor the
external structure, but is based on experience. Some of the methods followed are:

o Exploratory Testing:
This method, generally conducted by business analysts and experts, is followed to test the
applications without any documentation.

o Fault Attack:
One of the widely used method of the experience based test design technique, fault attack
involves testers anticipating the errors, defect data availability, etc., as per their
experience

The final process of this method is to write test cases to use each of the four steps in our
table.

Stepwise refinement - Levels of abstraction

The next process is what is called stepwise refinement or decomposition. Rather than leaving step 1 as
“walk to paper”, we need to be more clear than this. So, to break this step down with stepwise
refinement, we could say…

1. Walk to paper.
1a. Walk to wall
1b. turn right
1c. move
1d. turn left

As this program is relatively simple, I think it can be left at just the one breakdown. However, more
complicated programs will require that steps 1a, 1b, 1c, 1d and 1e are decomposed several times.

For step 2 “pick it up”, the assignment says we can assume there will always be a paper there. To be on
the safe side, we might want to have a bit more detail here and put checks in place such as using an if
statement to check if a paper is present. Also, we could look here at pre-conditions and post-conditions.
We need to know where Karel will be after step 1 and where he needs to be to start step 3. In the
breakdown of “walk to paper” I decided to leave Karel at the inside of the door facing out… so a pre-
condition is that Karel needs to make 1 move to the paper. A post-condition I will set is for Karel is that
he has returned to inside the house facing west which means we need to remember that as a pre-
condition for step 3… returning to the start.

Breaking down part 2:

2. Pick it up
2a. Move to paper
2b. Check if paper available
2c. pick up paper
2d. turn around
2e. move (leave facing west)

Now we know that Karel is in the house, facing west we can break down step 3 as follows:

3. Return back to the start

3a. move to wall
3b. turn right
3c. move to wall

I decided to tackle point 3 a different way. Instead of sending Karel back to the couch the same way he
came in… along the top and right wall. I decided to make him simply continue west till he hits the wall,
then turn right and then move to the top wall.

Levels of Abstraction: Levels of abstraction was originally described by Dijkstra as a bottom-

up design technique. In Dijkstra’s system each level of abstraction is composed of a group of
related functions, some of which are externally visible and some of which are internal to the
level. Internal functions are hidden from other levels; they can only be invoked by functions on
the same level. The internal functions are used to perform tasks common to the work being
performed on that level of abstraction. Each level of abstraction performs a set of services for the
functions on the next higher level of abstraction.
Example
Problem: Print the count and average of a sequence of positive integers

 Initial Solution:
1. Initialize data
2. Get data
3. Calculate results
4. Output results

 Refinement:
1. Initialize data
2. get data
 2.1 loop
 2.2 get integer x
 2.3 exit when x < 1
 2.4 process x
3. Calculate results
 3.1 avg = sum / count
4. Output results
 Further refinement (of step 2.4):
o 2.4.1 increase count by 1
o 2.4.2 increase sum by x

 Process of refinement is complete when all steps can be easily programmed

The top-down approach to software development involves breaking down a large,

complex problem or system into smaller, more manageable pieces and then working on
each piece individually. This approach is often used to develop software systems
because it allows developers to focus on one part of the system at a time, which can
make the development process more organized and efficient.

There are several steps involved in the top-down approach to software development:

 Define the overall system requirements:

The first step is to define the overall goals and objectives of the system, as well as any
specific requirements or constraints.
  Break down the system into smaller components:

Next, the system is broken down into smaller, more manageable components or
modules.

 Develop each component individually:

Once the system has been divided into smaller components, each component can be
developed individually.

 Test and debug each component:

As each component is developed, it is important to test and debug it to ensure that it is

working properly.

 Integrate the components:

After each component has been developed and tested individually, they can be
integrated into the larger system.

 Test the entire system:

Once all of the components have been integrated, the entire system can be tested to
ensure that it is functioning as intended.

 Maintain and update the system:

After the system has been implemented, it will need to be maintained and updated on
an ongoing basis to fix any bugs or to add new features.

Benefits of Top-Down Design

 It helps to identify systems and subsystems.
 Bring in more clarity on communication between two systems or subsystems.
 Comprehensive list of features and sub-features along with all business rules.
 No room for mistakes in implementing user requirements. High quality can be achieved.
 Ensure to arrive at a correct estimate.
  Easy to code as we have clearly defined expectations at all levels.
 Nonfunctional will help to make sure it performs, secured.

Disadvantages of Topdown Approach

In a top-down approach, the design process begins with the big picture and breaks it
down into smaller, more manageable pieces. This approach has some disadvantages:

 It can be inflexible:

Since the design process starts with the big picture, it can be difficult to make changes
later on in the process.

 It can be time-consuming:

Breaking down the big picture into smaller pieces can take a lot of time, especially if the
design is complex.

 It can be costly:

The top-down approach may require more resources upfront, as all of the planning and
design work needs to be done before the project can be implemented.

 It can be difficult to manage:

With so many pieces and components, it can be challenging to keep track of everything
and ensure that everything is working together as intended.

 It can be less effective for creative projects:

The top-down approach may not be as effective for projects that require a lot of
creativity and innovation, as it can be inflexible and leave little room for experimentation.
Test plans-Design guidelines
What is a Test Plan?
A test plan is a detailed document that outlines the test strategy, Testing objectives, resources
(manpower, software, hardware) required for testing, test schedule, test estimation and test deliverables.
The test plan serves as a blueprint to conduct software testing activities as a defined process which is
minutely monitored and controlled by the test manager.
Let’s start with following scenario
In a meeting, you want to discuss the Test Plan with the team members, but they are not interested - .

Importance of Test Plan

Making Test Plan has multiple benefits

 Test Plan helps us determine the effort needed to validate the quality of the application under
test
 Help people outside the test team such as developers, business managers,
customers understand the details of testing.
 Test Plan guides our thinking. It is like a rule book, which needs to be followed.
 Important aspects like test estimation, test scope, test strategy are documented in Test Plan, so
it can be reviewed by Management Team and re-used for other projects.
How to write a Test Plan
You already know that making a Test Plan is the most important task of Test Management Process.
Follow the seven steps below to create a test plan as per IEEE 829

1. Analyze the product

2. Design the Test Strategy
3. Define Test Criteria
4. Define the Test Objectives
5. Resource Planning
6. Plan Test Environment
7. Schedule & Estimation
8. Determine Test Deliverables
Step 1) Analyze the product
How can you test a product without any information about it? The answer is Impossible. You must learn
a product thoroughly before testing it.
The product under test is Guru99 banking website. You should research clients and the end users to
know their needs and expectations from the application

 Who will use the website?

 What is it used for?
 How will it work?
 What are software/ hardware the product uses?

Step 2) Develop Test Strategy

Test Strategy is a critical step in making a Test Plan. A Test Strategy document, is a high-level
document, which is usually developed by Test Manager. This document defines:

 The project’s testing objectives and the means to achieve them

 Determines testing effort and costs
Step 3) Define Test Objective
Test Objective is the overall goal and achievement of the test execution. The objective of the testing is
finding as many software defects as possible; ensure that the software under test is bug freebefore
release.
To define the test objectives, you should do 2 following steps

1. List all the software features (functionality, performance, GUI…) which may need to test.
2. Define the target or the goal of the test based on above features
Step 4) Define Test Criteria
Test Criteria is a standard or rule on which a test procedure or test judgment can be based. There’re 2
types of test criteria as following

Suspension Criteria
Specify the critical suspension criteria for a test. If the suspension criteria are met during testing, the
active test cycle will be suspended until the criteria are resolved.

Step 5) Resource Planning

Resource plan is a detailed summary of all types of resources required to complete project task.
Resource could be human, equipment and materials needed to complete a project
The resource planning is important factor of the test planning because helps
in determining the number of resources (employee, equipment…) to be used for the project. Therefore,
the Test Manager can make the correct schedule & estimation for the project.

Step 6) Plan Test Environment

What is the Test Environment
A testing environment is a setup of software and hardware on which the testing team is going to execute
test cases. The test environment consists of real business and user environment, as well as physical
environments, such as server, front end running environment.

Step 7) Schedule & Estimation

In the article Test estimation, you already used some techniques to estimate the effort to complete the
project. Now you should include that estimation as well as the schedule to the Test Planning
In the Test Estimation phase, suppose you break out the whole project into small tasks and add the
estimation for each task as below

Task Members Estimate effort

Create the test specification Test Designer 170 man-hour

Perform Test Execution Tester, Test Administrator 80 man-hour

Test Report Tester 10 man-hour

Test Delivery 20 man-hour

280 man-hour
Total

Step 8) Test Deliverables

Test Deliverables is a list of all the documents, tools and other components that has to be developed and
maintained in support of the testing effort.
There are different test deliverables at every phase of the software development lifecycle.

Test deliverables are provided before testing phase.

 Test plans document.

 Test cases documents
 Test Design specifications.
Test deliverables are provided during the testing
 Test Scripts
 Simulators.
 Test Data
 Test Traceability Matrix
 Error logs and execution logs.
Test deliverables are provided after the testing cycles is over.
 Test Results/reports
 Defect Report
 Installation/ Test procedures guidelines