Manual Testing Cheat Sheet

Anushree Chatterjee

September 5, 2023

 QA Process

 QA Resources

Software testing is a non-negotiable part of the software development

lifecycle (SDLC). Though automation testing is beneficial and the
primary focus of technological advancements, one can just not dismiss
the importance and effectiveness of manual testing. For example, in
situations where the product is in nascent stages, manual testing is
often a better choice. Only after the product stabilizes and matures
does it make sense to invest time and effort into setting up automation
testing.

With manual testing still being an integral part of software testing, it

makes sense to familiarize oneself with the commonly used terms and
procedures. Read on below to see a comprehensive compilation of the
key concepts required for anyone intending to manually test a product.

SDLC

Stages of the software development life

cycle (SDLC)
Types of SDLC models

Waterfall  Suitable for stable projects with clear  No flexibility for accommodating chan
Model requirements  The customer needs to wait till the fina
 Sequential approach
 Documentation at every stage, hence easy
tracking

Spiral  Suitable for clear and complete  Effective risk assessment and managem
Model requirements, but with room for future success
enhancements  Can be costly and resource intensive
 The iterative nature allows for continuous  Difficulty maintaining and tracking sta
improvement based on feedback.
 Focus on risk assessment and mitigation

RAD Model  Suitable for projects with clear but  Small cycles may not give substantial
presently incomplete requirements leading to significant delays in timelin
 Components developed can be reused  Experts are needed to build products in
easily

Prototype  Prototypes help in identifying missing  Involvement of customer early on mea

Model features or functionalities in the product satisfactory, the process goes on in a lo
in advance to be time-consuming, effort-intensive
 Since the customer is involved from the
initial stages, there is no ambiguity
 Agile  Product is broken down into smaller  Requires skilled resources to work in s
Model cycles leading to the development of a  If the customer is unsure of the require
working product quickly impacted
 Easy to add new features
 Customer feedback is utilized at every
stage

Testing methods
Black box testing  No knowledge of the internal structure or code
 The focus remains on input and output
 Examples include higher levels of testing like system or acceptance testing

White box testing  Testing based on the internal logic, structure, and code of the software
 Examples include lower levels of testing like unit testing

Grey box testing  Combination of black box and white box testing
 Partial knowledge of the product’s internal structure is available
 Examples include integration testing

Testing methods for integration testing

Top-down  Starts with testing the higher-level modules or components first and gradually int
approach  Stubs (simplified implementations of lower-level components) may be used for si
lower-level modules.

Bottom-up  Begins with testing the lower-level modules or components first and gradually in
approach  Drivers (programs that simulate higher-level components) may be used to provide
of higher-level modules.

Sandwich  Also known as mixed integration testing, this approach combines elements of bot
approach approaches.
 Allows for faster testing of critical modules by integrating lower-level modules a
simultaneously.
Levels of testing

Unit tests  Focus on individual units of code like functions and classes
 Major chunk of test cases
 Requires programming knowledge
 Lightweight tests that can run independently

Integration  Focus on integrations between different systems

tests  These tests may have some dependencies on other modules and systems and hence a
tests

End-to-end  Testing is done from the customer’s perspective rather than a developer’s
tests  UI-based testing hence takes longer to run
 Fewer in number compared to unit and integration tests

Types of testing
Functional  Testing functionalities for proper behavior
testing
Usability testing  Evaluating product’s ease of use and intuitiveness

Security testing  Checking the security of the application through the network, data, APIs and other
 Includes testing for issues like unauthorized access, data breaches, and injection at

Exploratory  This form of testing is unscripted and focuses on finding issues in the system
testing  Relies heavily of the tester’s understanding of the product

Smoke testing  A preliminary round of testing to quickly assess if the software is stable enough fo

Regression  Form of testing done to ensure that existing functionalities do not get impacted aft
testing or fixes

Alpha testing  This kind of acceptance testing is conducted by the internal QA team to identify d

Beta testing  Beta testing involves real users testing the software in a controlled environment be

Sanity testing  Validates at a high level if the functionalities are working as expected
 Further testing is done based on these results

Performance  Checks the performance of the application under different conditions like the prod
testing scalability, and stability under varying load conditions
 Includes targeted testing types like load testing and stress testing

Load testing  Evaluates the product under peak load to identify bottlenecks and scalability issue

Stress testing  Tests the product’s stability and performance under extreme conditions

Phases of software testing

lifecycle
Bug life cycle

Defect When product is not working as per requirement

Bug When the results are not as expected
Error Problems in code gives errors
Failure Can occur due to any of the above
Note: it’s vital to mention that sometimes the words “bug”, “defect” and
“error” are used interchangeably.

Testing metrics and artifacts

 Defect Density  The number of defects found in a specific component or area of
the size of that component
 Defect Density = Number of Defects / Size of Component (e.g.,

Defect Removal Efficiency (DRE)  Meant to measure the number of defects found internally
 DRE = (Total Defects Found – Total Defects Found in Productio

Test Coverage  Measures the extent to which the code or requirements are exerc

Defect Age  Measures how long a defect remains unresolved

QA  Refers to the process of assuring quality throughout SDLC

 Helps in creating preventive measures against issues

QC  Refers to verifying that the product meets expected standards

 Helps in detecting issues in the product

Priority  Importance of the issue to be resolved with respect to the custom

Severity  The seriousness of the issue in terms of functionality of the prod

Test Plan  Outlines the overall strategy, scope, objectives, and resources fo
 It also mentions testing approaches, deliverables, methodologies
responsibilities of team members

Test Strategy  Defines the high-level approach and guidelines for testing activi
 Covers aspects such as test levels, test techniques, environments

Requirement Traceability Matrix  Links requirements to corresponding test cases, ensuring compre
(RTM)  Helps track the progress of testing against specified requirement

Responsibilities of a tester
Leveraging manual testing
expertise through
automation
The myth that manual testers cannot automate test cases as effectively
as automation engineers is debunked by automation tools like testRigor.
This powerful test automation tool allows you to create scripts as easily
as writing test cases in plain English, eliminating the need to translate
those statements into a programming language. Its advanced AI engine
not only simplifies the scripting process but also ensures minimal test
maintenance overhead, rapid, and precise test execution. With its rich
set of commands, you can automate across platforms, such as the web,
mobile devices, and even native desktop applications, ensuring optimal
test coverage.

A test case in testRigor would look like this:

login

click on “Admin”

add a new contact

logout

Organizations using testRigor report a significant improvement in their

quality control endeavors due to increased test coverage, lower issues
releasing to production, and quicker release cycles. All this while
empowering in-house resources like manual testers to leverage their
testing experience without getting sidelined by the technicalities of
automation testing. This in turn benefits the company in terms of
overall costs and better collaboration between teams.