The Fundamentals of

Testing
STLC (Software Testing Life Cycle)

What is Software Testing Life Cycle (STLC)?

Software Testing Life Cycle (STLC) is a sequence

of specific activities conducted during the testing
process to ensure software quality goals are met.
STLC involves both verification and validation
activities. Contrary to popular belief, Software
Testing is not just a single/isolate activity, i.e.
testing. It consists of a series of activities carried
out methodologically to help certify your software
product. STLC stands for Software Testing Life
Cycle.
STLC - What is Entry and Exit Criteria in STLC?

Entry Criteria: Entry Criteria gives the prerequisite items that must be completed before
testing can begin.

Exit Criteria: Exit Criteria defines the items that must be completed before testing can be
concluded

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.
STLC - Entry and Exit Criteria example

Entry Criteria

1. In the Test Cases Development phase, the following conditions should be met:
Requirements and specifications for the software should be clear and available.
Test plan document should be prepared and finalized.
Test environment should be set up.
2. In the Test Planning phase, the following conditions should be met:
Requirement specification and User acceptance criteria documents should be available.
Requirement Traceability Matrix (RTM), Testing and Automation feasibility (if applicable) reports should be prepared and finalized.
3. In the Test Execution phase, the following conditions should be met:
Test plan document, test cases, test scripts, and test environment setup should be completed.

Exit Criteria

1. In the Test Cases Development phase, the following expectations should be met:
Reviewed test cases should be available.
Test scripts along with test data (if test environment available) should be prepared.
2. In the Test Planning phase, the following expectations should be met:
The test plan document, test strategy document, and efforts estimation document should be prepared and finalized.
3. In the Test Execution phase, the following expectations should be met:
Executed test cases result and defect reports should be available.
STLC - Requirement Phase Testing

Requirement Phase Testing also known as Requirement Analysis in which test team studies the
requirements from a testing point of view to identify testable requirements and the QA team may
interact with various stakeholders to understand requirements in detail. Requirements could be either
functional or non-functional. Automation feasibility for the testing project is also done in this stage.

Activities in Requirement Phase Testing

● Identify types of tests to be performed.

● Gather details about testing priorities and focus.
● Prepare Requirement Traceability Matrix (RTM).
● Identify test environment details where testing is supposed to be carried out.
● Automation feasibility analysis (if required).

Deliverables of Requirement Phase Testing

● RTM
● Automation feasibility report. (if applicable)
STLC - Test Planning in STLC

Test Planning in STLC is a phase in which a Senior QA manager determines the test plan strategy along with efforts and
cost estimates for the project. Moreover, the resources, test environment, test limitations and the testing schedule are also
determined. The Test Plan gets prepared and finalized in the same phase.

Test Planning Activities

● Preparation of test plan/strategy document for various types of testing

● Test tool selection
● Test effort estimation
● Resource planning and determining roles and responsibilities.
● Training requirement

Deliverables of Test Planning

● Test plan /strategy document.

● Effort estimation document.
STLC - Test Case Development Phase

During the Test Case Development phase of the Software Testing Life Cycle (STLC), test cases are designed and documented to ensure
comprehensive coverage of the system under test. Here's a brief overview:

1. Review Requirements.
2. Identify Test Scenarios.
3. Define Test Cases with clear steps, inputs, and expected outputs.
4. Review and refine test cases.
5. Document test cases in a test management tool or spreadsheet.
6. Prepare test data and test environment.
7. Plan test case execution.
8. Execute test cases and compare actual results with expected results.(Depends on SDLC model)
9. Report defects if any discrepancies are found.
10. Maintain and update test cases as needed.

Test Case Development Activities

● Create test cases

● Review and baseline test cases and scripts
● Create test data (If Test Environment is available)

Deliverables of Test Case Development

● Test cases
● Test data
STLC - Test Environment Setup

Test Environment Setup decides the software and hardware conditions under which a work product is tested. It
is one of the critical aspects of the testing process and can be done in parallel with the Test Case Development
Phase. Test team may not be involved in this activity if the development team provides the test environment.
The test team is required to do a readiness check (smoke testing) of the given environment.

Test Environment Setup Activities

● Understand the required architecture, environment set-up and prepare hardware and software
requirement list for the Test Environment.
● Setup test Environment and test data
● Perform smoke test on the build

Deliverables of Test Environment Setup

● Environment ready with test data set up

● Smoke Test Results.
STLC - Test Execution Phase

Test Execution Phase is carried out by the testers in which testing of the software build is done based on test plans and
test cases prepared. The process consists of test script execution, test script maintenance and bug reporting. If bugs are
reported then it is reverted back to development team for correction and retesting will be performed.

Test Execution Activities

● Execute tests as per plan

● Document test results, and log defects for failed cases
● Map defects to test cases in RTM
● Retest the Defect fixes
● Track the defects to closure

Deliverables of Test Execution

● Completed RTM with the execution status

● Test cases updated with results
● Defect reports
STLC - Test Cycle Closure

Test Cycle Closure is the phase where the testing team wraps up the execution of tests. It includes activities like creating a test completion report,
gathering test completion data and results. The team members come together to discuss and analyze the testing artifacts to learn from the current
cycle and improve future test cycles. The goal is to identify and resolve any issues or obstacles in the testing process for smoother future cycles.

Test Cycle Closure Activities

● Evaluate cycle completion criteria based on Time, Test coverage, Cost,Software, Critical Business Objectives, Quality
● Prepare test metrics based on the above parameters.
● Document the learning out of the project
● Prepare Test closure report
● Qualitative and quantitative reporting of quality of the work product to the customer.
● Test result analysis to find out the defect distribution by type and severity.

Deliverables of Test Cycle Closure

● Test Closure report

● Test metrics
Test Documentation

What is Test Documentation?

Test documentation is a collection of documents and artifacts created during software testing. It provides valuable information about
testing activities, test cases, scenarios, results, and more. The key types of test documentation include:

1. Test Plan: Outlines the testing approach, objectives, scope, resources, and schedules.

2. Test Cases: Step-by-step instructions for performing specific tests, including inputs, expected outcomes, and additional details.

3. Test Scenarios: High-level descriptions of functionality or features to be tested, helping identify test cases.

4. Test Scripts: Detailed instructions or scripts for automated testing, including commands and expected outputs.

5. Test Data: Input values or datasets used for testing, covering different scenarios and edge cases.

6. Test Execution Logs: Capture details of each test execution, including test case IDs, results, and identified issues.

7. Defect Reports: Document issues or defects found during testing, including descriptions, reproduction steps, severity, and status.

8. Test Summary Report: Provides an overview of testing activities, metrics, and overall software quality.
Test Documentation
Why Test Formality?

For a newbie, it’s easy to assume that Testing is executing the various section of code on an
ad-hoc basis and verifying the results. But in the real world, Testing is a very formal activity
and is documented in detail. Test Documentation makes planning, review, and execution of
testing easy as well as verifiable.

The degree of test formality depends on

● The type of application under test

● Standards followed by your organization
● The maturity of the development process.

Testing activities generally consume 30% to 50% of software development project effort.
Documentations help to identify Test process improvement that can be applied to future
projects.
Test Documentation
Test Policy document

Test policy is a document described at the organization level and gives the organizational insight for the test activities.

It is determined by the senior management of the organization and defines the test principles that the organization has
adopt. The test policy is very high-level document and at the top of the test documentation structure.

Organizations may prefer to publish their test policy in a sentence, as well as a separate document. Also they may use
this policy in both development and maintenance projects.

The test policy shall describe the followings:

● Clear answer to the question of “What does testing means for the organization”
● Test objectives that the organization have
● The definition of the testing process used by the organization to increase the quality of the software developed
● How the organization will measure the effectiveness and efficiency of the test while achieving goals
Test Documentation
Test Strategy document
Test strategy document is prepared at the program level and includes general test strategy, management principles, processes and approaches for the
tests to be performed for a software in detail.

The test strategy document is also a high level document and is usually written by the test manager and the project manager in the top level
organization. It is generally prepared in large scale projects and does not need much updating. In small scale projects, test strategies and test approach
may be included in the test plan, and also the test strategy document may not be written separately.

Test approach and test activities included in the test strategy document must be consistent with the test policies of the organization.

The test strategy document may applicable for a program / system that contains multiple projects and describes;

● Objective / scope of testing

● In-scope / out of scope items for testing
● Test levels (Unit, System, Integration, System Integration)
● Test types ( Functional / Non-Functional)
● Entry / Exit / Stop / Resumption Criteria for testing (for different levels / phases)
● Risks to be addressed
● Test environment
● Test case design methodology
● Test methodology (Top-down / bottom-up / risk based)
● Test control and reporting
● Test automation approach
● Test tools to be used
● Defect management approach
● Defect classification
● Retesting & regression approach
Test Documentation
Test Plan document

Test plan is a document prepared at the project level. In general it defines work products to be tested, how they will be
tested (test cases) and test type distribution among testers. Test plan also includes test environment and test tools to be
used during the project, the persons responsible for the tests and their responsibilities, test levels and test types, test
schedule planned for test runs, and the principles of management and reporting of errors / bugs.

Test plan is usually prepared by the test manager or test leader in the test organization and shared with the entire team in
the project. It is a living document throughout the project and should be kept under revision control as it’s updated.

The information in the test plan document must be consistent with the organization’s test policy and test strategy.

The test plan may describe the followings:

● All test strategies specific to the project

● Test estimations & test schedule
● Test organization / roles / responsibilities
● Test deliverables
● Test reporting principles
Test Documentation
Test Plan document
IEEE Std 829 (IEEE Standard for Software Test Documentation) gives a “Test Plan Template” that would be useful for those who will prepare a test plan. According to this
standard, test plans shall cover,

● Test Plan Identifier (name, number, revision number of the document)

● References
● Introduction
● Test Items
● Software Risk Issues
● Features to be Tested
● Features not to Tested
● Approach
● Item Pass / Fail Criteria
● Suspension Criteria and Resumption Requirements
● Test Deliverables
● Remaining Test Task
● Environmental Needs
● Staffing and training needs
● Responsibilities
● Schedule
● Planning Risks and Contingencies
● Approvals
● Glossary

The companies working in the field of software development and testing should also be handled the above mentioned test documentation in their quality management
system. Thus, the company guarantees that the software developed will provide and maintain the quality in the best possible level. All employees involved in the software
testing process know that a software will not be 100% error-free. However, the presence of these documents and setting testing criteria within them, e.g. exit / resumption
criteria or requirements, are mandatory for a company to protect itself formally.
Test Documentation
Test Scenario document

What is a Test Scenario?

A Test Scenario is defined as any functionality that can be tested. It is also called Test
Condition or Test Possibility. As a tester, you should put yourself in the end user’s shoes and
figure out the real-world scenarios and use cases of the Application Under Test.

Scenario Testing

Scenario Testing in software testing is a method in which actual scenarios are used for testing
the software application instead of test cases. The purpose of scenario testing is to test end to
end scenarios for a specific complex problem of the software. Scenarios help in an easier way
to test and evaluate end to end complicated problems.
Test Documentation
Test Scenario document
Creating test scenarios is important in the software testing process for several reasons:

Test Coverage: Test scenarios help ensure comprehensive test coverage by identifying various combinations of inputs, actions, and
conditions to be tested. They help in verifying that the software functions as expected and handles different scenarios correctly.

Requirement Validation: Test scenarios are derived from the requirements, specifications, or user stories. By creating test scenarios, testers
can validate if the software meets the intended functionality and behavior specified in the requirements.

Clarity and Consistency: Test scenarios provide clear and structured instructions for testers to follow during testing. They help in
standardizing the testing process and ensure that all testers have a common understanding of the expected behavior.

Reproducibility: Test scenarios define a set of steps to execute a specific test. Having well-defined test scenarios makes it easier to
reproduce and rerun tests, facilitating the identification and resolution of any issues.

Communication and Collaboration: Test scenarios serve as a communication tool between testers, developers, and stakeholders. They help
in conveying the testing objectives, identifying test conditions, and fostering collaboration among team members.
Test Documentation
Test Scenario document
Despite the benefits of creating test scenarios, there might be situations where creating them is not practical or necessary. Here are some
reasons why test scenarios may not be created:

Time Constraints: In situations with tight deadlines or limited resources, creating detailed test scenarios for every possible test case may not
be feasible. In such cases, prioritizing critical or high-risk scenarios can help optimize testing efforts.

Exploratory Testing: Exploratory testing is a testing approach where testers rely more on their domain knowledge, intuition, and real-time
exploration rather than following predefined scenarios. In this context, test scenarios may not be explicitly created but can be derived based
on testers' experience.

Agile Development: In agile methodologies, the focus is on continuous delivery and iterative development. Test scenarios may be created on
a just-in-time basis, allowing flexibility and adaptability to changing requirements and user stories.

Ad-hoc Testing: Ad-hoc testing refers to testing activities performed without predefined test cases or scenarios. It may be useful for quick
checks, usability testing, or uncovering unforeseen issues. In such cases, creating formal test scenarios may not be necessary.
Test Documentation
Test Scenario document

Test Scenario for eCommerce Application

Test Scenario: Login Functionality
Test Cases:
1 Verify the system behavior when a valid email ID and password are entered.
2 Verify the system behavior when an invalid email ID and a valid password are entered.
3 Verify the system behavior when a valid email ID and an invalid password are entered.
4 Verify the system behavior when an invalid email ID and an invalid password are entered.
5 Verify the system behavior when the email ID and password fields are left blank and the "Sign In" button is
clicked.
6 Verify that the "Forgot your password" feature is working as expected.
7 Verify the system behavior when a valid or invalid phone number and password are entered.
8 Verify the system behavior when the "Keep me signed" option is checked.
Test Documentation
Test Case document

What is a Test Case?

A Test Case is a set of actions executed to verify a particular feature or functionality of your
software application. A Test Case contains test steps, test data, precondition, postcondition
developed for specific test scenario to verify any requirement. The test case includes specific
variables or conditions, using which a testing engineer can compare expected and actual
results to determine whether a software product is functioning as per the requirements of the
customer.
Test Documentation
Test Data

What is Test Data in Software Testing?

Test Data in Software Testing is the input given to a software program during test execution. It
represents data that affects or affected by software execution while testing. Test data is used
for both positive testing to verify that functions produce expected results for given inputs and
for negative testing to test software ability to handle unusual, exceptional or unexpected
inputs.

Poorly designed testing data may not test all possible test scenarios which will hamper the
quality of the software.
Test Documentation
Test Data

What is Test Data Generation? Why test data should be created before test execution?

Everybody knows that testing is a process that produces and consumes large amounts of
data. Data used in testing describes the initial conditions for a test and represents the medium
through which the tester influences the software. It is a crucial part of most Functional Tests.

Depending on your testing environment you may need to CREATE Test Data (Most of the
times) or at least identify a suitable test data for your test cases (is the test data is already
created).
Test Documentation
Bug/Defect report

Defect in Software Testing

A Defect in Software Testing is a variation or deviation of the software application from end
user’s requirements or original business requirements. A software defect is an error in coding
which causes incorrect or unexpected results from a software program which does not meet
actual requirements. Testers might come across such defects while executing the test cases.
Test Documentation
Bug/Defect report

Bug Report in Software Testing

A Bug Report in Software Testing is a detailed document about bugs found in the software application. Bug report contains each detail about bugs like
description, date when bug was found, name of tester who found it, name of developer who fixed it, etc. Bug report helps to identify similar bugs in future
so it can be avoided.

While reporting the bug to developer, your Bug Report should contain the following information

● Defect_ID – Unique identification number for the defect.

● Defect Description – Detailed description of the Defect including information about the module in which Defect was found.
● Version – Version of the application in which defect was found.
● Steps – Detailed steps along with screenshots with which the developer can reproduce the defects.
● Date Raised – Date when the defect is raised
● Reference– where in you Provide reference to the documents like . requirements, design, architecture or maybe even screenshots of the error
to help understand the defect
● Detected By – Name/ID of the tester who raised the defect
● Status – Status of the defect , more on this later
● Fixed by – Name/ID of the developer who fixed it
● Date Closed – Date when the defect is closed
● Severity which describes the impact of the defect on the application
● Priority which is related to defect fixing urgency. Severity Priority could be High/Medium/Low based on the impact urgency at which the defect
should be fixed respectively
Test Documentation
Test summary report

Test Report is a document which contains a summary of all test activities and final test results
of a testing project. Test report is an assessment of how well the Testing is performed. Based
on the test report, stakeholders can evaluate the quality of the tested product and make a
decision on the software release.

For example, if the test report informs that there are many defects remaining in the product,
stakeholders can delay the release until all the defects are fixed.
Test Documentation
Test summary report

Why Test Summary Report?

Do you know the root cause of this

problem? Why does the website still has
defects even when your Team has already
tested it?

The problem is you ignored the reporting &

evaluation phase in Test Management. The
boss has no information to evaluate the
quality of this website. They just trusted
what you said and released the website
without knowing its testing performance.
Test Documentation
Test summary report

What does a test report contain?

Test Documentation
Test summary report

Project Information

All information of the project such as the project name, product name, and version should be described in the test report.

Test Objective

As mentioned in Test Planning tutorial, Test Report should include the objective of each round of testing, such as Unit Test, Performance Test, System Test …Etc.

Test Summary

This section includes the summary of testing activity in general. Information detailed here includes

● The number of test cases executed

● The numbers of test cases pass
● The numbers of test cases fail
● Pass percentage
● Fail percentage
● Comments
● This information should be displayed visually by using color indicator, graph, and highlighted table.
Test Documentation
Test summary report

Defect

One of the most important information in Test Report is defect. The report should contain
following information

● Total number of bugs

● Status of bugs (open, closed, responding)
● Number of bugs open, resolved, closed
● Breakdown by severity and priority
● Like test summary, you can include some simple metrics like Defect density, % of fixed
defects.
Test Documentation
Best practice to Achieve Test Documentation

● QA team needs to be involved in the initial phase of the project so that Test
Documentation is created in parallel
● Don’t just create and leave the document, but update whenever required
● Use version control to manage and track your documents
● Try to document what is needed for you to understand your work and what you will
need to produce to your stakeholders
● You should use a standard template for documentation like excel sheet or doc file
● Store all your project related documents at a single location. It should be accessible to
every team member for reference as well as to update when needed
● Not providing enough detail is also a common mistake while creating a test document
Test Documentation
Advantages of Test Documentation

● The main reason behind creating test documentation is to either reduce or remove any
uncertainties about the testing activities. Helps you to remove ambiguity which often arises
when it comes to the allocation of tasks
● Documentation not only offers a systematic approach to software testing, but it also acts as
training material to freshers in the software testing process
● It is also a good marketing & sales strategy to showcase Test Documentation to exhibit a
mature testing process
● Test documentation helps you to offer a quality product to the client within specific time limits
● In Software Engineering, Test Documentation also helps to configure or set-up the program
through the configuration document and operator manuals
● Test documentation helps you to improve transparency with the client
Test Documentation
Disadvantages of Test Documentation

● The cost of the documentation may surpass its value as it is very time-consuming
● Many times, it is written by people who can’t write well or who don’t know the material
● Keeping track of changes requested by the client and updating corresponding
documents is tiring.
● Poor documentation directly reflects the quality of the product as a misunderstanding
between the client and the organization can occur
Test Documentation
Summary

● Test documentation is documentation of artifacts created before or during the testing of

software.
● The degree of test formality depends on 1) the type of application under test 2)
standards followed by your organization 3) the maturity of the development process.
● Important types of Test Documents are Test policy, Test strategy, Test plan, Test case
etc.
● QA team needs to be involved in the initial phase of the project so that Test
Documentation is created in parallel
● The main reason behind creating test documentation is to either reduce or remove any
uncertainties about the testing activities.
● The cost of the documentation may surpass its value as it is very time-consuming
The Psychology of Testing
Psychological Testing in Software Testing

Software development, including software testing, involves human beings. Therefore, human
psychology has important effect on software testing.

In software testing, psychology plays an extremely important role. It is one of those factors
that stay behind the scene, but has a great impact on the end result. Categorized into three
sections, the psychology of testing enables smooth testing as well as makes the process
hassle-free. It is mainly dependent on the mindset of the developers and testers, as well as
the quality of communication between them. Moreover, the psychology of testing improves
mutual understanding among team members and helps them work towards a common goal.

The three sections of the psychology of testing are:

● The mindset of Developers and Testers.

● Communication in a Constructive Manner.
● Test Independence.
The Psychology of Testing
The mindset of Developers and Testers

The software development life cycle is a combination of various activities, which are
performed by different individuals using their expertise and knowledge. It is not an unknown
fact that to accomplish the success, development of software, people with different skills and
mindset are required.

Developers synthesize code. They build up things, putting pieces together and figuring out fun
and unique ways of combining those distinct little bits to do wonderful and amazing things.

But Testers are all about analysis. Once it has all been put together, the tester likes to take it
apart again, piece by piece, this time looking for those little corners, edges, and absurdities
that hide in those weird and strange interactions that come from those new and amazing ways
of putting pieces together.

Testing and Reviewing the applications are different from analyzing and developing it. While
testing or reviewing a product, testers mainly look for defects or failures in the product. If we
are building or developing applications, we have to work positively to solve the problems
during the development process and to make the product according to the user specification.
The Psychology of Testing
The mindset of Developers and Testers

Identifying defects during static testing such as requirements review or user story refinement
session or identifying failures during dynamic test execution, may be perceived as Criticism
of the product and of its author.

So the developer or the analyst may have problems with you as a tester because he thinks
that you are criticizing them.

There’s an element of human psychology called Confirmation bias, which means that most of
people find it difficult to accept information that disagrees with currently held believes.

For example, since developers expect their code to be correct, they have a confirmation bias
that makes it difficult to accept that the code is incorrect.

In addition to confirmation bias, other cognitive biases may make it difficult for people to
understand or accept information produced by testing.
The Psychology of Testing
Communication in a Constructive Manner

Testers and test managers need to have good interpersonal skills to be able to communicate effectively about
the defects, failures, test results, test progress and risks and to build positive relationships among colleagues.

Similarly during the process of testing also, the requirement of communication in a constructive manner is
extremely high. As testers are responsible for finding bugs and reporting them, it becomes vitally important for
them to communicate it in a respectful, polite, and suitable way to avoid hurting and disappointing someone.

Finding and reporting defects can be an achievement for the tester but is merely an inconvenience for
programmers, designers, developers, and other stakeholders of the project. As testing can be a destructive
activity, it is important for software testers to report defects and failures as objectively and politely as possible
to avoid hurting and upsetting other members related to the project.

So as testers, there are many ways to communicate collaboratively with developers.

● Start with collaboration rather than battels.

● Remind everyone about their common goal of having better quality systems.
● Emphasize the benefits of testing.
The Psychology of Testing
Communication in a Constructive Manner

For example, for the authors, defect information can help them to improve the work products and their
skills.

● For the organization, defects found and fixed during testing will save money, time and reduce
overall risk to product quality.
● Communicate test results and other findings in a neutral, fact focused way without criticizing
the person who created the defected item.
● Write objectives, defect reports and review findings.
● Try to understand how the other person feels and the reasons they may react negatively to the
information.
● Confirm that the other person has understood what has been said.
● Clearly define the right set of test objectives has important psychological implications.
● Most people tend to align their plans and behaviors with the objectives set by the team,
management, and stakeholders. So it’s also important that testers adhere to these objectives
with minimum personnel bias.
The Psychology of Testing
Self-testing and Independent testing

Comparison of the mindsets of a tester and a programmer does not mean that a tester cannot
be a programmer, or that a programmer cannot be the tester, although they often are separate
roles. In fact, programmers are the testers. They always test the component which they built.

While testing their own code they find many problems so the programmers, architect, and
developers always test their own code before giving it to anyone. However, we all know that it
is difficult to find our own mistakes. It might be due to some reasons such as,

● “Parental feelings” towards their code

● Focus on the “Positive Paths”
● Work-based on the principle of simplifying of complex scenarios
● Inability to catch small things in big pictures
● Lack of end-to-end & real-user perspective
● bLess experience with common bugs & application pitfalls
Thanks!