CHAPTER 4

SOFTWARE TESTING
ARTIFACTS
BỘ MÔN CNPM- KHOA CNTT
TRƯỜNG ĐH NGOẠI NGỮ TIN HOC TPHCM
OBJECTIVES

• Help students understanding and some software testing artifacts

• Understanding & Catching test design
• Manipulating to design test checklist, test scenario, test cases, test reviews
• Catching the bugs, errors, life cycles of them
• Set up environment for testing, execute test and bug reports
CONTENTS

• Test deliveries
• Test plan/Test Strategy
• Entry and exit Criteria
• Test checklist
• Test cases/ Test Scenario
• Bug- defect-failure –error
• Bug Severity And Priority
• Bug management - Bug life Cycle
• Test environment – Test execute – Test report
TEST DELIVERABLES

• Test Deliverables are the test artifacts

which are given to the stakeholders of a
software project during the SDLC (Software
Development Life Cycle). A software project
which follows SDLC undergoes the different
phases before delivering to the customer. In
this process, there will be some deliverables
in every phase. Some of the deliverables are
provided before the testing phase
commences and some are provided during
the testing phase and rest after the testing
phase is complete
TEST STRATEGY

• Test Strategy is a high level document (static document) and usually developed by project
manager. It is a document which captures the approach on how we go about testing the
product and achieve the goals. It is normally derived from the Business Requirement
Specification (BRS). Documents like Test Plan are prepared by keeping this document as base.
• Usually test team starts writing the detailed Test Plan and continue further phases of testing
once the test strategy is ready.
• This is one of the important documents in test deliverables. Like other test deliverables, test
team shares this with the stakeholders for better understanding about the scope of the
project, test approaches and other important aspects.
TEST STRATEGY (CONT)
Test Strategy Document
1. Scope and overview
2. Test Approach
3. Testing tools
4. Industry standards to follow
5. Test deliverables
6. Testing metrics
7. Requirement Traceability Matrix
8. Risk and mitigation
9. Reporting tool
10. Test summary
TEST STRATEGY (CONT)
Scope and overview:
• In this section, we will mention the scope of testing activities (what to test and why to test)
and mention an overview of the AUT.
• Example: Creating a new Application (Say Google Mail) which offers email services. Test the
functionality of emails and make sure it gives value to the customer.
Test Approach:
• Test levels
• Test types
• Roles and responsibilities
• Environment requirements
TEST STRATEGY (CONT)
Test Levels:
This section lists out the levels of testing that will be performed during QA Testing. Levels of
testing such as unit testing, integration testing, system testing and user acceptance testing.
Testers are responsible for integration testing, system testing and user acceptance testing.
Test Types:
This section lists out the testing types that will be performed during QA Testing.
Roles and responsibilities:
This section describes the roles and responsibilities of Project Manager, Project Lead, individual
testers.
TEST STRATEGY (CONT)
Environment requirements:
• This section lists out the hardware and software for the test environment in order to
commence the testing activities.
Testing tools:
• This section will describe the testing tools necessary to conduct the tests
• Example: Name of Test Management Tool, Name of Bug Tracking Tool, Name of Automation
Tool
• Test Summary:
• This section lists out what kind of test summary reports will be produced along with the
frequency. Test summary reports will be generated on a daily, weekly or monthly basis
depends on how critical the project is.
TEST PLAN
What is test plan?
Test plan is one of the documents in test deliverables. Like other test deliverables, the test
plan document is also shared with the stakeholders. The stakeholders get to know the
scope, approach, objectives, and schedule of software testing to be done.
Who Prepare Test Plan Template?
Usually, Test Lead prepares Test Plan and Testers involve in the process of preparing test
plan document. Once the test plan is well prepared, then the testers write test scenarios
and test cases based on test plan document.
TEST PLAN
Sections of Test Plan Template:
1. Test Plan Identifier
2. References
3. Introduction
4. Test Items
5. Features To Be Tested
6. Features Not To Be Tested
7. Approach
8. Pass/Fail Criteria
9. Suspension Criteria
10. Test Deliverables
11. Testing Tasks
12. Environmental Needs
13. Responsibilities
14. Staffing and Training Needs
15. Schedule
16. Risks and Contingencies
17. Approvals
TEST PLAN
Sections of Test Plan Template:
1. Test Plan Identifier
2. References
3. Introduction
4. Test Items
5. Features To Be Tested
6. Features Not To Be Tested
7. Approach
8. Pass/Fail Criteria
9. Suspension Criteria
Test Plan Document as per IEEE 829 Standards.
10. Test Deliverables
11. Testing Tasks
12. Environmental Needs
13. Responsibilities
14. Staffing and Training Needs
15. Schedule
16. Risks and Contingencies
17. Approvals
TEST PLAN
Test Plan Identifier:
• Test Plan Identifier is a unique number to identify the test plan.
• Example: ProjectName_0001
References:
• This section is to specify all the list of documents that support the test plan which you are
currently creating.
• Example: SRS (System Requirement Specification), Use Case Documents, Test Strategy, Project
Plan, Project Guidelines etc.,
Introduction:
• Introduction or summary includes the purpose and scope of the project
• Example: The objective of this document is to test the functionality of the ‘ProjectName’
TEST PLAN
Test Items:
• A list of test items which will be tested
• Example: Testing should be done on both front end and back end of the application on the
Windows/Linux environments.
Features To Be Tested:
• In this section, we list out all the features that will be tested within the project.
• Example: The features which are to be tested are Login Page, Dashboard, Reports.
Features Not To Be Tested:
• In this section, we list out the features which are not included in the project.
• Example: Payment using PayPal features is above to remove from the application. There is no
need to test this feature.
TEST PLAN
Approach:
• The overall strategy of how testing will be performed. It contains details such as
Methodology, Test types, Test techniques etc.,
• Example: We follow Agile Methodology in this project
Pass/Fail Criteria:
• In this section, we specify the criteria that will be used to determine pass or fail
percentage of test items.
• Example: All the major functionality of the application should work as intended and the
pass percentage of test cases should be more than 95% and there should not be any
critical bugs.
TEST PLAN
Suspension Criteria:
• In this section, we specify when to stop the testing.
• Example: If any of the major functionalities are not functional or system experiences login
issues then testing should suspend.
Test Deliverables:
• List of documents need to be delivered at each phase of testing life cycle. The list of all
test artifacts.
• Examples: Test Cases, Bug Report
• Read more on “Test Deliverables”..
TEST PLAN
Testing Tasks:
• In this section, we specify the list of testing tasks we need to complete in the current project.
• Example: Test environment should be ready prior to test execution phase. Test summary
report needs to be prepared.
Environmental Needs:
• List of hardware, software and any other tools that are needed for a test environment.
Responsibilities:
• We specify the list of roles and responsibilities of each test tasks.
• Example: Test plan should be prepared by Test Lead. Preparation and execution of tests should
be carried out by testers.
 TEST PLAN
Staffing and Training Needs:
• Plan training course to improve the skills of resources in the project to achieve the desired goals.
Schedule:
• Complete details on when to start, finish and how much time each task should take place.
• Example: Perform test execution – 120 man-hours, Test Reporting – 30 man-hours
Risks and Contingencies:
• In this section, we specify the probability of risks and contingencies to overcome those risks.
• Example: Risk – In case of a wrong budget estimation, the cost may overrun. Contingency Plan – Establish the scope
before beginning the testing tasks and pay attention in the project planning and also track the budget estimates
constantly.
Approvals:
• Who should sign off and approve the testing project
• Example: Project manager should agree on completion of the project and determine the steps to proceed further
 ENTRY AND EXIT CRITERIA

Both Entry and Exit criteria in software testing for each

different level is decided and defined by the combined
efforts of test team controller and business team .
ENTRY AND EXIT CRITERIA
What is Entry and Exit Criteria?
• Entry Criteria: Entry Criteria gives the prerequisite items that must be completed
before testing can begin.
• For Instance, to start the Test Cases development phase, the following conditions should
be met
▪ The requirement document should be available.
▪ Complete understanding of the application flow is required.
▪ The Test Plan Document should be ready.
ENTRY AND EXIT CRITERIA
What is Entry and Exit Criteria?
• Exit Criteria: Exit Criteria defines the items that must be completed before testing can be
concluded
• Exit criteria is a set of expectations; this should be met before concluding the STLC phase.
• For Instance, to conclude the Test Cases development phase, following expectations should be met
−
▪ Test Cases should be written and reviewed.
▪ Test Data should be identified and ready.
▪ Test automation script should be ready if applicable
• You have Entry and Exit Criteria for all levels in the Software Testing Life Cycle (STLC)
• In an Ideal world, you will not enter the next stage until the exit criteria for the previous stage is
met. But practically this is not always possible. So for this tutorial, we will focus on activities and
deliverables for the different stages in STLC life cycle. Let's look into them in detail.
TEST CHECKLIST

• Checklist - is a list of tests which should be run in a definite procedure. It helps to

understand if testing is fully run and how many failed. It also helps
formalize testing separetely taken functionality, putting tests in a list. Test order in
the checklist may be strict as well as random
• A Checklist is a catalog of items/tasks that are recorded for tracking. This list could be
either ordered in a sequence or could be haphazard.
• Ex: (open some file checklists)
TEST CHECKLIST
Why to use checklist
• To ensure coverage the customer’s requirements
• To ensure the software will be tested enough coverage need
• To reduce the lack of errors from tester
• To fill test report quickly
• To guarantee level of reliability after testing
• To help tester coverage the domain of testing
• Strengthen coordination among other related groups of participants in the software testing
process
→ For tracking and assessing completion (or non-completion). To make a note of tasks, so that
nothing is overlooked.
TEST CHECKLIST
How to make the checklist?
• Depending on the criteria of software project
• Detecting of object/module/unit/system need to get what is to be tested?
• Making the basic items for checklist from personal awareness and understanding
• Adding the more missing contents through expert exchange and online lookup
• Getting consensus from other group members
Tham khảo:
• https://tester.itmscoaching.com/checklist/

• http://www.mobileqazone.com/profiles/blogs/what-is-checklist-based-testing

• https://www.quora.com/What-is-checklist-based-testing
http://qualitypointtech.net/forum/viewtopic.php?f=12&t=8546)

• https://www.stickyminds.com/sites/default/files/article/file/2014/Graphical%20UI%20Testing%20Checklist.pdf
http://sqa.fyicenter.com/FAQ/Software-Testing-Check-List/
http://www.seleniumtests.com/2014/05/manual-testing-checklist.html
TEST CHECKLIST
Use the checklist when and where?
When
• When there was not enough time to write test cases
• Used for trainning
• Used to confirm the review before embarking on test case development

Where
• For applications with basic functions, simple, not complicated, and easy to understand
• For functional or to-do lists that must be repeated many times
• For applications, complex functions, requiring detailed conditions, data, and specific
operations, it should be written in test case.
TEST CHECKLIST
Use the checklist when and where?
When
• When there was not enough time to write test cases
• Used for trainning
• Used to confirm the review before embarking on test case development

Where
• For applications with basic functions, simple, not complicated, and easy to understand
• For functional or to-do lists that must be repeated many times
• For applications, complex functions, requiring detailed conditions, data, and specific operations, it should be written in
test case.

Who
• Testers
• Developers
• Trainers and trainees
• Team members have to checked the items to be developed and tested
TEST CHECKLIST
Advantages, disadvantages
Advantages
• Short, ensuring the correctness and accuracy for testing software
• Help tester see clearly and cover the testing process
• Takes less time to match projects with highly variable specs, with large workloads
• Analysis results (work schedule, completion status) is very easy
• Very flexible (You can add or remove unnecessary items)
Disadvantages
• Case selection will be difficult if you do not know the system requirements.
• Testers need the ability to see in order to perform many test cases based on the items in the
checklist
• It will be difficult for you new testers because there is no clear action in the checklist
TEST CHECKLIST
Some test checklists
● Graph User Interface
● Element & Datatype
● Function Search
● Function Sort
● Function Paging
● Function Master Data
● Function Login
● Function Upload & Download CSV
● Function Send mail
● Mobile
TEST SCENARIO

• Test Scenario gives the idea of what we have to test.Test Scenario is like a high-level test case.
• A test scenrio is defined as any functionality that can be tested. It is also called Test
Condition or Test Possibility.
• Scenario Testing is a variant of Software Testing where Scenarios are Used for Testing.
Scenarios help in an Easier Way of Testing of the more complicated Systems
• Test Scenario answers “What to be tested”
• Assume that we need to test the functionality of a login page of Gmail application.Test
scenario for the Gmail login page functionality as follows:
• Test Scenario Example: Verify the login functionality
TEST SCENARIO
Why create Test Scenarios?
• Creating Test Scenarios ensures complete Test Coverage
• Test Scenarios can be approved by various stakeholders like Business Analyst, Developers, Customers to
ensure the Application Under Test is thoroughly tested. It ensures that the software is working for the
most common use cases.
• They serve as a quick tool to determine the testing work effort and accordingly create a proposal for
the client or organize the workforce.
• They help determine the most important end-to-end transactions or the real use of the software
applications.
• For studying the end-to-end functioning of the program, Test Scenario is critical.
TEST SCENARIO
• When not create Test Scenario?
• The Application Under Test is complicated, unstable and there is a time crunch in the
project.
• Projects that follow Agile Methodology like Scrum, Kanban may not create Test Scenarios.
• Test Scenario may not be created for a new bug fix or Regression Testing. In such cases,
Test Scenarios must be already heavily documented in the previous test cycles. This is
especially true for Maintenance projects.
TEST SCENARIO
How to Write Test Scenarios?
• Step 1: Read the Requirement Documents like BRS, SRS, FRS, of the System Under Test (SUT). You
could also refer uses cases, books, manuals, etc. of the application to be tested.
• Step 2: For each requirement, figure out possible users actions and objectives. Determine the technical
aspects of the requirement. Ascertain possible scenarios of system abuse and evaluate users with
hacker's mindset.
• Step 3: After reading the Requirements Document and doing your due Analysis, list out different test
scenarios that verify each feature of the software.
• Step 4: Once you have listed all possible Test Scenarios, a Traceability Matrix is created to verify that
each & every requirement has a corresponding Test Scenario
• Step 5: The scenarios created are reviewed by your supervisor. Later, they are also reviewed by other
Stakeholders in the project.
TEST SCENARIO
Tips to Create Test Scenarios
• Each Test Scenario should be tied to a minimum of one Requirement or User Story as
per the Project Methodology.
• Before creating a Test Scenario that verifies multiple Requirements at once, ensure you
have a Test Scenario that checks that requirement in isolation.
• Avoid creating overly complicated Test Scenarios spanning multiple Requirements.
• The number of scenarios may be large, and it is expensive to run them all. Based on
customer priorities only run selected Test Scenarios
TEST CASES

• Test cases are the set of positive and negative executable steps of a test scenario which
has a set of pre-conditions, test data, expected result, post-conditions and actual results.
• Test Case answers “How to be tested”
• Assume that we need to test the functionality of a login page of Gmail application.Test
cases for the above login page functionality as follows:
• Test Case Examples:
• Test Case 1: Enter valid User Name and valid Password
Test Case 2: Enter valid User Name and invalid Password
Test Case 3: Enter invalid User Name and valid Password
Test Case 4: Enter invalid User Name and invalid Password
TEST CASES
Test case’s structure
Test Case ID
Each test case should be represented by a unique ID. It’s good practice to follow some naming
convention for better understanding and discrimination purposes.

Test Description / test item:

Summary the content of test case, usual Pick test cases properly from the test scenarios

Ex:
Test scenario:Verify the login of Gmail
Test case: Enter a valid username and valid password
TEST CASES
Test case’s structure
•Pre-condition
Conditions that need to meet before executing the test case. Mention if any preconditions are
available.
Example: Need a valid Gmail account to do login
Test Steps:
To execute test cases, you need to perform some actions. So write proper test steps. Mention all the
test steps in detail and in the order how it could be executed from the end-user’s perspective
Ex:
• Enter Username
• Enter Password
• Click Login button
TEST CASES
Test case’s structure
Test Data
You need proper test data to execute the test steps. So gather appropriate test data. The data
which could be used an input for the test cases.
Ex:
• Username: rajkumar@softwaretestingmaterial.com
• Password: STM
Expected Result:
The result which we expect once the test cases were executed. It might be anything such as
Home Page, Relevant screen, Error message, etc.,
Ex: Successful login
TEST CASES
Test case’s structure
Test Data
You need proper test data to execute the test steps. So gather appropriate test data. The data
which could be used an input for the test cases.
Ex:
• Username: rajkumar@softwaretestingmaterial.com
• Password: STM
Expected Result:
The result which we expect once the test cases were executed. It might be anything such as
Home Page, Relevant screen, Error message, etc.,
Ex: Successful login
TEST CASES
Test case’s structure
Post Condition:
• Conditions that need to achieve when the test case was successfully executed.
• Ex: Gmail inbox is shown
Usually: post condition be merged into expected result

Actual Result:
• The result which system shows once the test case was executed. Capture the result after
the execution. Based on this result and the expected result, we set the status of the test
case.
Ex: Pass/Fail Redirected to Gmail inbox
TEST CASES
Create test case
B1: Define the purpose of the test: need to understand the specification of customer
requirements.
B2: Define the testing function: need to know how the software is used including different
functional activities and organization.
B3: Identification of non-functional requirements: hardware requirements, operating system,
security aspects

B4: Define forms for TCs: include UI interface, functionality, compatibility, and performance ...

B5: Determination of interoperability between modular principles: TCs should be designed to

cover the maximum degree of module influence.
TEST CASES
Test case type
• Normal case: Common test cases
• Abnormal case: Abnormal case of the test
• Boundary case: The boundary check boundary.
Test case must be
• Accurate and complete professional system
• Independent (can be performed without depending on other test cases, easily divided among
many testers)
• The content is simple, has a clear purpose and is understood by everyone in a unique way.
(clear input, output, implementation steps) A coherent presentation of the entire document.
• Reusable (can be easily updated and modified).
TEST CASES & TEST SCENARIO
BUG – DEFECT- ERROR-FAILURE
BUG – DEFECT- ERROR-FAILURE
• Testing is the process of identifying defects, where a defect is any variance between actual and
expected result . “A mistake in code is called Error .”
• Error found by tester is called defect , Defect accepted by development team is called Bug.
And build does not meet the requirements then it is Failure.
BUG – DEFECT- ERROR-FAILURE

What is Error ?
• An error is a mistake, misconception, or misunderstanding on the part of a software
developer. In the category of developer we include software engineers, programmers,
analysts, and testers.
• For example, a developer may misunderstand a de-sign notation, or a programmer
might type a variable name incorrectly — leads to an Error. It is the one which is
generated because of wrong login, loop or due to syntax. Error normally arises in
software; it leads to change the functionality of the program.
BUG – DEFECT- ERROR-FAILURE

What is Error ?
• An error is a mistake, misconception, or misunderstanding on the part of a software
developer. In the category of developer we include software engineers, programmers,
analysts, and testers.
• For example, a developer may misunderstand a de-sign notation, or a programmer
might type a variable name incorrectly — leads to an Error. It is the one which is
generated because of wrong login, loop or due to syntax. Error normally arises in
software; it leads to change the functionality of the program.
BUG – DEFECT- ERROR-FAILURE

What is Failure ?
As we , discuss above when build does not meet the requirement then it is called Failure or fault.
• It is a condition that causes the software to fail to perform its required function. It is the
inability of a system or component to perform required function according to its
specification.
• For example, as per the software requirement specification there is no need to develop
the login page but all requirements are not clear at the end of developer side and they
created login page
BUG – DEFECT- ERROR-FAILURE

What is Bug ?
• As we , discuss above When defect accepted by development team it is called Bug
• In Software testing, when the expected and actual behavior is not matching, an incident needs
to be raised. It is a programmer’s fault where a programmer intended to implement a certain
behavior, but the code fails to correctly conform to this behavior because of incorrect
implementation in coding. It is also known as Defect.
• For example, login module is tested by the tester ; he enter valid email address and
password but it still show warning “ invalid email address”. Now tester reported that defect
to developer and he accepted that defect/ issue is called bug.
BUG – DEFECT- ERROR-FAILURE

What is Defect in software testing?

As we discuss above firstly that Defect is a variance between expected results and actual
results of execution of test case on the system.
A programmer while designing and building the software can make mistakes or error. These
mistakes or errors mean that there are flaws in the software. These are called defects.
WHAT IS DEFECT LIFE CYCLE?

• Defect life cycle, also known as

Bug Life cycle is the journey of
a defect cycle, which
a defect goes through during its
lifetime. It varies from organization
to organization and also from
project to project as it is governed
by the software testing process
and also depends upon the tools
used.
WHAT IS DEFECT LIFE CYCLE?

• Defect life cycle, also known as

Bug Life cycle is the journey of
a defect cycle, which
a defect goes through during its
lifetime. It varies from organization
to organization and also from
project to project as it is governed
by the software testing process
and also depends upon the tools
used.
WHAT IS DEFECT LIFE CYCLE?

• New: When a defect is logged and posted for the first time. Its state is given as new.
• Assigned: Once the bug is posted by the tester, the lead of the tester approves the bug and
assigns the bug to developer team.
• Open: Its state when the developer starts analyzing and working on the defect fix.
• Fixed:When developer makes necessary code changes and verifies the changes then he/she can
make bug status as ‘Fixed’.
• Retest: At this stage the tester do the retesting of the changed code which developer has given to
him to check whether the defect got fixed or not.
• Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes
the status to “reopened”.The bug goes through the life cycle once again.
WHAT IS DEFECT LIFE CYCLE?

• 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 a priority the bug
may be low, lack of time for the release or the bug may not have a major effect on the software.
• Rejected: If the developer feels that the bug is not genuine, the developer rejects the bug. Then the
state of the bug is changed to “rejected”.
• Duplicate : If the bug is repeated twice or the two bugs mention the same concept of the bug, then
the recent/latest bug status is changed to “duplicate“.
• Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in
the software, tester changes the status of the bug to “closed”. This state means that the bug is fixed,
tested and approved.
WHAT IS DEFECT LIFE CYCLE?

• Not a bug/Enhancement: The state given as “Not a bug/Enhancement” if there is no change in

the functionality of the application. For an example: If customer asks for some change in the look
and field of the application like change of color of some text then it is not a bug but just some
change in the looks of the application.
Conclusion:
• A Bug is the result of a coding Error and A Defect is a deviation from the Requirements. A
defect does not necessarily mean there is a bug in the code, it could be a function that was
not implemented but defined in the requirements of the software.
• Refference: https://medium.com/swlh/what-is-difference-between-defect-bug-error-
b477e76b5502
BUG SEVERITY AND PRIORITY

• Bug/Defect severity can be defined as the impact of the bug on the application. It can be
Critical, Major or Minor. In simple words, how much effect will be there on the system
because of a particular defect
• What are the types of Severity?
• Severity can be categorized into three types:
• As mentioned above the type of severity are categorized as Critical, Major, and Minor
• Let’s see how can we segregate a bug into these types:
 BUG SEVERITY AND PRIORITY
• Critical:
• A critical severity issue is an issue where a large piece of functionality or major system component is completely
broken and there is no workaround to move further.
For example, Due to a bug in one module, we cannot test the other modules because that blocker bug has blocked
the other modules. Bugs which affects the customers business are considered as critical
• Major:
• A major severity issue is an issue where a large piece of functionality or major system component is completely
broken and there is a workaround to move further.
• Minor:
• A minor severity issue is an issue that imposes some loss of functionality, but for which there is an acceptable &
easily reproducible workaround.
• For example, font family or font size or color or spelling issue
• Trivial:
• A trivial severity defect is a defect which is related to the enhancement of the system
 BUG SEVERITY AND PRIORITY
• What is Priority?
• Defect priority can be defined as an impact of the bug on the customers business. Main focus on how soon the
defect should be fixed. It gives the order in which a defect should be resolved. Developers decide which defect they
should take up next based on the priority. It can be High, Medium or Low.
• Most of the times the priority status is set based on the customer requirement.
• High:
• A high priority issue is an issue which has a high impact on the customers business or an issue which affects the
system severely and the system cannot be used until the issue was fixed. These kinds of issues must be fixed
immediately. Most of the cases as per the user perspective, the priority of the issue is set to high priority even
though the severity of the issue is minor.
• Medium:
• Issues which can be released in the next build comes under medium priority. Such issues can be resolved along with
other development activities.
• Low:
• An issue which has no impact on the customer business comes under low priority.
BUG SEVERITY AND PRIORITY

• https://www.softwaretestingmaterial.com/what-is-the-difference-between-severity-and-priority-in-software-testing/
DEFECT/BUG MANAGEMENT & TEST REPORT
• What is Defect Management Process

• Defect Management is a systematic process to identify

and fix bugs. A defect management cycle contains the
following stages
• 1) Discovery of Defect,
• 2) Defect Categorization
• 3) Fixing of Defect by developers
• 4) Verification by Testers,
• 5) Defect Closure
• 6) Defect Reports at the end of project
DEFECT/BUG MANAGEMENT & TEST REPORT
• Discovery
DEFECT/BUG MANAGEMENT & TEST REPORT
• Categorization

• Defects are
usually
categorized by
the Test Manager
–
DEFECT/BUG MANAGEMENT & TEST REPORT
Resolution
• Assignment: Assigned to a developer or
other technician to fix, and changed the
status to Responding.
• Schedule fixing: The developer side take
charge in this phase. They will create a
schedule to fix these defects, depend on
the defect priority.
• Fix the defect: While the development
team is fixing the defects, the Test
Manager tracks the process of fixing
defect compare to the above schedule.
• Report the resolution: Get a report of
the resolution from developers when
defects are fixed.
DEFECT/BUG MANAGEMENT & TEST REPORT
Verification
• After the development team fixed and reported the defect, the testing team verifies that the
defects are actually resolved.
• For example, in the above scenario, when the development team reported that they already fixed 61
defects, your team would test again to verify these defects were actually fixed or not.
Closure
• Once a defect has been resolved and verified, the defect is changed status as closed. If not, you
have send a notice to the development to check the defect again.
Reporting
• The management board has right to know the defect status. They must understand the defect
management process to support you in this project. Therefore, you must report them the current
defect situation to get feedback from them.
TEST ENVIRONMENT
What is Test Environment?
• Test Environment consists of elements that support test execution with software, hardware and
network configured. Test environment configuration must mimic the production environment in
order to uncover any environment/configuration related issues.

Factors for designing Test Environment:

• Determine if test environment needs archiving in order to take back ups.
• Verify the network configuration.
• Identify the required server operating system, databases and other components.
• Identify the number of license required by the test team.
TEST ENVIRONMENT
Environmental Configuration:
It is the combination of hardware and software environment on which the tests will be executed. It
includes hardware configuration, operating system settings, software configuration, test terminals and
other support to perform the test.

Example:
A typical Environmental Configuration for a web-based application is given below:

Web Server - IIS/Apache

Database - MS SQL OS - Windows/
Linux Browser - IE/FireFox Java
version : version 6
TEST EXECUTE
What is Test Execution?
Test execution is the process of executing the code and comparing the expected and actual
results. Following factors are to be considered for a test execution process:
• Based on a risk, select a subset of test suite to be executed for this cycle.
• Assign the test cases in each test suite to testers for execution.
• Execute tests, report bugs, and capture test status continuously.
• Resolve blocking issues as they arise.
• Report status, adjust assignments, and reconsider plans and priorities daily.
• Report test cycle findings and status.
 TEST REPORT
What is the Test Report?

Test Report is a document which contains

• A summary of test activities and final test results
• An assessment of how well the Testing is performed

Based on the test report, the stakeholders can

• Evaluate the quality of the tested product
• Make a decision on the software release. For example, if the test report informs that there’re many
defects remaining in the product, the stakeholder can delay the release until all the defects are fixed.
 TEST REPORT
Test report template
 TEST METRICS
Software Testing Metrics is defined as a quantitative measure that helps to estimate the progress and
quality of a software testing process. A metric is defined as the degree to which a system or its
component possesses a specific attribute.
Importance of software testing metrics
• Software testing metrics is important due to several factors. Well, I have listed a few of them below:
● It helps you to take a decision for the next phase of activities
● It is evidence of the claim or prediction
● It helps you to understand the type of improvement required
● It eases the process of decision making or technology change
• Well, in these simple points you have got an overview of the importance of testing metrics, let us
move towards our next segment. There are different types of metrics. Here they are!
 TEST METRICS
Types of software testing metrics:
• Process Metrics: It is used to improve the efficiency of the process in the SDLC (Software
Development Life Cycle).
• Product Metrics: It is used to tackle the quality of the software product.
• Project Metrics: It measures the efficiency of the team working on the project along with
the testing tools used.