Chp-1: Software Testing Fundamentals

1.1 Definition & Objectives

1.2 Types of software bugs
1.3 Bug life cycle
1.4 Testing lifecycle
1.5 Test Plan
1.6 Test Cases – Definition, Test Case Designing
1.7 Case Studies on Test Plan & Test Case

1.1 Definition and Objectives Software Testing & Quality Assurance

Definitions:
Software testing is designed to establish that the software is working satisfactorily as per the
requirements. Software testing is a process designed to prove that the program is error free. From
objective point of view, testing can be done in two ways.

a) Positive Testing b) Negative Testing

a) Positive Testing: Operate application or software as it should be operated use proper
verify of test data including data values at boundaries to test if it fails.
Check actual test result with the expected and see : -

- Does it behave normally

- Are result correct
- Does software function correctly
b) Negative Testing: Test for abnormal operations. Test with illegal abnormal test data.
- Does system fail / crash
- Does the program do what it should not
- Does it fail to do what it should
Objectives: It is a statement of what the tester wants to accomplish when implementing a specific
testing activity.

- Each testing activity may have several activities and there are two levels of objectives
specification.
- A test plan contain both high level of general objectives in the overview section and
specific low level “provable” objectives for each particular type of testing being
implemented. The latter kind being operational goal for specific tasks.
- A good set of operational objectives can explain why we are executing a particular step
in the testing procedure.
General Objectives:

1) Finding errors / bugs.

2) A good test case will have a good chance of finding undiscovered errors.
3) To demonstrate that errors are not present in the process of software development.
4) To show that a program perform its intended for correctly.
5) To establish confidence that a program does what it is suppose to do.
6) To check whether the application is working as expected without any error or bug.
7) Whether the performance of the application is as expected and meets the need.

sunilkhilari@hotmail.com ,9850979655 1
 8) Reduce the risk of failure.
9) Reduce the cost of testing.
Inputs:

1) System Requirement documents.

2) System Design documents.
3) Risk Score Analysis.
(A) Identify test objectives: Three methods can be used to specify test objectives.
(i) Brain Storming: The test team uses “creative” intention to construct a list of test objectives
should be based on analysis. Products such as diagrams / text of the requirement
specifications.
(ii) Second approach is to identify “key” system functions. This procedure can also be
performed as a walkthrough of the function requirements section by section.
(iii) The third method is to identify business transactions base objectives on them. This can
also be thought of as scenario-based on business cycles could be used to drive the process.
Output: Statement of test objectives, the statement of the test objectives is really a statement of the
test requirements. It can be created using any word processing package or spreadsheet. It can
also be implement with automated testing tools.

(B) Define Completion Criteria:

A completion criteria is the standard by which a test objective is measured. Completion criteria
can be either quantitative or qualitative.
(C) Priority Test Objectives:
The Test objectives should be prioritized based on the risk analysis findings.
The priority should be assigned using this scale.
High – Most important test – must be executed.
Medium – Second level of objectives: should be executed only after high-priority tests.
Low – Least important – should be tested last and only if there is enough time.
(D) Operationalize Test Objectives:
- Test objective should be implemented manually in the form of quality check list – with
one more checklist items satisfying specific objectives.
- Automated – Test objectives should be translated into an appropriate form of the
automated test tools being used.

Quality: As per IEEE Glossary

Product which should meet its specification.

a) Customer Quality requirements

 Efficiency
 Reliability

b) Developer Quality requirements

 Maintainability, reusability
 Reliability, portability
Quality Assurance (QA):

sunilkhilari@hotmail.com ,9850979655 2
  Auditing & reporting functions of management
 It concentrate on the process of producing quality
 Defect prevention oriented
 This is usually staff function
 Review, audits, inspections
 Done after the product is built
QA = QC over QC
because of Quality Assurance evaluate whether Quality Control is working.

Software Quality Assurance (SQA):

 A set of systematic activities of software development to produce a software
product that is fit to use.
 Software quality assurance is an umbrella activity that applies throughout the
software process.

Quality Control (QC):

It is series of instruction, reviews and tests used throughout the development cycle to
ensure that each work product meets the requirement placed upon in.
 Concentrate on specific product
 Defect detection and correction oriented
 This is usually a line function e.g. software testing at various levels
 Done throughout the life cycle

1.2 Types of software bugs

It is assessment of the extents which a test object meets given requirements.
Error: Errors are a part of our daily life. Human makes errors in their thoughts, actions and in the
products that might result from their actions. Errors occur wherever humans are involved in taking
actions and making decisions.
Error is a state of the system, it could lead to failure.
Bug: Due to which program fail to perform its intended function correctly.

Defect: It is bug – roughly say Fault.

Fault: It is adjudged cause of error.

Failure: Failure is said to occur whenever the external behavior of a system does not confirm to that
prescribed in the system specification.

sunilkhilari@hotmail.com ,9850979655 3
1.3 Bug Life Cycle:

New

Open
Rejected
Assign
Deferred
Reopen Test

Verified

Closed

New: When the bug is posted for the 1st time, its state will be “New”. This means that the bug is not
yet approved.
Open: After a tester has posted a bug, the lead of the testers approves that bug is genuine and he
changes the state as “Open”.
Assign: Once the lead changes the state as “Open” he assigns the bug to corresponding
developer or developers’ team. The state of the bug now is opened to “Assign”.
Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of
testing. Before he releases the software with bug fixed, he changes the state of bug to “Test”. It
specifies that the bug has been fixed and is released to testing team.
Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next
releases. The reasons for changing the bug to this state have many factors. Some of them are priority
of the bug may be low, lack of time for the release or the bug may not have major effect on the
software.
Rejected: If the developer feels that bug is not genuine he rejects the bug. Then the state of the
bug is changed to “Rejected”.
Verified: Once the bug is fixed and the status is changed to “Test”, the tester tests the bug. If the
bug is not present in the software, he approves that the bug is fixed and changes the status to
“Verified”.
Reopen: If the bug still exists even after the bug is fixed by developer, the tester changes the
status to “Reopen”. The bug traverses the life cycle once again.
Closed: Once the bug is fixed, it is tested by the tester. If tester feels that the bug is no longer
exists in software, he changes the status of the bug to “Closed”. This state means that the bug is fixed,
tested and approved.

sunilkhilari@hotmail.com ,9850979655 4
1.4 Software Testing Life Cycle (STLC)
(i) Planning of Test
(ii) Analysis of Test
(iii) Design of Test
(iv) Creation and Verification of Test
(v) Execution of Testing Cycles
(vi) Performance Testing documents
(vii) Action after implementation
(i) Planning of Test:
In STLC multiple test levels which are going to be performed for the project. Activities at each
level must be planned well. Planned well in advance and it has to be formally documented
based on individual plan only? The individual test levels are carried out. It is the process of
defining a testing project such that it can be properly measured and controlled. Detailed
schedule of testing activity as well content of test plan are created.
Contents of test plan –
(a) Background: The item summarizes the function of the application system and test to be
performed.
(b) Introduction: What is to be tested, sequence of testing.
(c) Strategy: Main test activities, methodology
(d) Assumption: Indicates any anticipated assumptions which will be made while testing the
application.
(e) Test Items: List of each item (program) to be tested.
(f) Features not to be tested” Features won’t be tested and why not?
(g) Featured to be tested: List of features (functions or requirements) which will be tested or
demonstrated by the test.
(h) Approach: Describe data flow and test philosophy. All approaches which will be
followed at the various stages of the test execution.
(i) Item pass: Item list of expected output and tolerances.
(j) Suspension / completion criteria: Establish check point – when test start or complete.
(k) Test deliverables: What the besides software will be delivered – test reposts, test
software.
(l) Testing task: Functional tasks (e.g. equipment setup)
(m) Environmental needs: (Resources) – software and hardware requirements
(n) Responsibilities: Who does the task in section 5, what does the user do.
(o) Staffing and Training: recruitment of tester, developer and need for training
(p) Test Scheduling: Estimate, sequence ,plan
(q) Test Tools: Tools to be used for testing
(r) Risk:Any identified Ris
(s) Approvals: who will going to approve test plan and test records
Benefits of test plan:

i. Forms a contract between Quality Assurance lead and project team.

ii. Avoid random testing or missed features.
iii. Optimize resources.
Key points –

sunilkhilari@hotmail.com ,9850979655 5
 - Test objectives
- Test scope
- Test strategy
- Establish team or defining roles
- Estimate a test timeline
(iii) Test Design: Test Design is done based on the requirement of the project documented in SRS.
This phase decides which manual or automated testing is to be done.
Automation Testing: In Automation testing different paths for testing are to be identified 1st
and writing of script has to be done if required.
These originate a needed for an end-to-end checklist that covers al the features of the projects.
(iv) Analysis of Test: Once the test plan documentation is done the next stage is to analyze what
types of software testing should be carried out at the various stages of STLC.
(v) Creation and Verification of Test: In this phase test plans, the scripts test are completed.
Stress and performance testing plans are also completed at this stage when the development
team is done with unit of code, the testing team is required to help then in testing that unit and
reporting of the bug if found. Integration testing and bug reporting is done in this phase of the
software testing life cycle.
(vi) Execution of Test: Planning and execution of various test cases is done in this phase. Once the
unit test is completed. The functionality of the tests is done in this phase. At first top level of
testing is done to find out top level failures and bugs are reported immediately to the
development team to get required turnaround.Test report has to document properly and bug
have to be reported to the development team.
(vii) Performance Testing documents (Result Analysis): Once the bug is fixed by the
development team i.e. after the successful execution of the test case. The testing team has to be
result it to compare the expected values with actual values and declare the result as pass or fail.
(viii) Action after implementation: This is one of the important stages as the Defect Profile
Document (DPD) has to be updated for testing the developers know about the defects.
Defect profile document contains –
a) Defect ID: Unique identification of the defect
b) Test case ID: Test case identification for that defect
c) Description: Detailed description of the bug
d) Summary: This field contains some keyword information about the bug which can help in
minimizing the number of records to be searched.
e) Defect submitted by: Name of the tester who detected and reported the bug.
f) Date of submission: Date at which the bug was detected or reported.
g) Build No.: Number of runs required.
h) Version No.: Version information of the software application in which the bug was
detected or fixed.
i) Assigned to: Name of the developer who is suppose to fix the bug.
j) Severity: Degree of severity of the defect.
k) Priority: Priority of fixing the bug.
l) Status : Current status of the bug
Testing is an interactive process. The bug once reported and as the development team fixes the bug. It
has to undergo the testing process again to assure that the bug found is resolved. Regression testing
has to be done once the quality analysist assures that the product is ready, the software is released for

sunilkhilari@hotmail.com ,9850979655 6
production. Before release the software has to undergo one more round of top level testing. Thus
testing is an ongoing process.

1.5 Test cases Design

An activity in which system or component is executed under specified conditions, the results are
observed or recorded and an evaluation is made on some aspect of the software.A set of one or more
cases

2 Test case is document that describes an input action or event and expected response to
determine features of an application is working properly.
3 A set of test inputs, execution conditions and expected result.
Test case components:

1) Test case Id :
2) Test case name :
3) Purpose / objective :
4) Steps :
5) Expected results :
6) Actual results :
7) Pass / fail :
8) Pre-requisite :
9) Setup / initial condition :
10) Input data :

Steps for SQA Plan

1. Document the Plan
2. Obtain Management Support
3. Obtain Development Support
4. Plan for implementation of SQA plan
5. Execute the SQA plan
A) Document a Plan
Software Quality Assurance (SQA) Plan
Doc.No.
SNS001
Ver.No. 0001
Date :
24/05/2017
a) Objectives:-
b) Background:-
c) Scope :
d) Strategy :-
e) Item Test :-
f) Features need to test:- :
sunilkhilari@hotmail.com ,9850979655 7
 g) Features not to test:
h) Completion Criteria: -
i) Risk : -
j) Environment Needs: -
k) Staffing & Training: -
l) Testing Tools:-
m) Schedule :-
n) Approvals

Prepared By : Approved By:

sunilkhilari@hotmail.com ,9850979655 8