What is a Test Case?

A test case is standard format adhered to in testing to check if the software is working as per the
requirements. It comprises a collection of conditions that are required to be verified to validate if the
actual outcomes on the software are matching with the expected ones.

The various sections of a test case are listed below −

 Functionality Name − It points to the functionality which is verified.

 Test Case Identifier − It points to a unique id assigned to each test case.

 Name of Tester − The name of the tester who will carry out the testing.

 Test Scenario Name − The name of the scenario which will be converted into a test case.

 Test Case Description − The requirement or the criteria which is going to be verified in the test
case.

 Test Steps − The actions to be performed on the software to verify the test conditions.

 Preconditions − The prerequisites that need to be satisfied before starting with the test steps.

 Test Priority − The test priority is assigned to the test case to decide the order in which it needs
to be executed.

 Test Data − The inputs and data which are needed to complete the test.

 Expected Outcome − The expected results as per the requirements.

 Test Settings − The settings and parameters that are needed to be set before running the test.

 Actual Outcome − The actual result produced on the software.

 Environment − The configuration of the environment on which the test is to be performed

including the operating system, configurations, security etc.

 Test Status − The status of the test should reflect as pass, fail, not executed and blocked.

 Comments − The comments added against each test case.

Why are the Test Cases Written?

The test cases are written for the reasons listed below −
  To check if the software is working as per the requirements.

 To check if the software is working under specified conditions.

 It helps to restrict the software updates and other needs.

 It ensures that all the requirements with every possible scenario and use cases are covered and
documented, thereby improving the test coverage.

 It helps to achieve evenness in test execution. A well designed test case lets any tester begin
verifying the software.

 A good test case requires minimal maintenance efforts.

What is the Basic Format of a Test Case?

Components Purpose

Test Case Id It points to a unique id assigned to each test case.

Test Case
A short description to describe why the test case is designed.
Description

Preconditions The prerequisites that needed to be satisfied before starting with the test steps.

Test Steps Describe the test steps in detail.

Test Data The inputs and data which are needed to complete the test.

Expected Outcome The expected results as per the requirements.

The conditions that are required to be fulfilled after the test case is run
Post Conditions
successfully.

Actual Outcome The actual result produced on the software.

Test Status The status of the test after comparing with the actual and expected results.

Project Name Name of the project.

Module Name Name of the module.

References The location where the references are available.

Created By The tester name who has designed the test case.
 Created Date The data on which the test case has been created.

Reviewed Date The data on which the test case has been reviewed.

Executed By The tester name who has executed the test case.

Executed Date The data on which the test case has been executed.

Comments The comments added against the test case.

Best Practices to Design a Test Case

The best practices to design a test case are listed below −

 It should not be complex, clear and easy to understand.

 Each of the test cases should be distinct.

 It should be designed only after a clear understanding of requirements, inputs, data, and without
any assumptions.

 Each of the test cases should be mapped to at least one requirement for traceability.

 Every test case should be verified with all possible inputs, conditions, and data.

 The test case descriptions, names etc should be self explanatory but explained in a few sentences.

 Each test case should cover customer requirements.

 The test cases should not be designed such that they generate the same outcomes.

 It should be designed keeping in mind the end user’s requirements and perspectives.

 Every test case should have a unique id.

 It should have the clearly defined preconditions and postconditions.

 It should be written such that it can be reused in other places.

 The precise expected outcomes of the test cases should be incorporated.

Test Management Tools

The different test management tools are listed below −

 TestRail − It is a test management tool.

 Jira − It is a project management tool.

 ALM/HP QC − It is a project management tool.

Different Types of Test Cases
The different types of test cases are listed below −

 Functional Test Cases − They are written to verify if the functionalities of the software are working
as expected.

 Unit Test Cases − They are written by developers to verify if the unit of the software they have
developed is working.

 GUI Test Cases − They are written to verify the graphical user interface of the software.

 Integration Test Cases − They are written to verify if the different components of the software
are working fine after being integrated with other components.

 Performance Test Cases − They are written to verify the response time and overall performance
of the software.

 Database Test Cases − They are written to verify the backend and if all the data are reflecting in
the correct tables in the database.

 Security Test Cases − They are written to verify the security features of the software.

 Usability Test Cases − They are written to verify if the software is usable and user friendly.

 User Acceptance Testing − They are written to verify if the software is working correctly in real
life scenarios and environments.

What is a Test Suite?

Test suite is a container that has a set of tests which helps testers in executing and reporting the test
execution status. It can take any of the three states namely Active, Inprogress and completed.

A Test case can be added to multiple test suites and test plans. After creating a test plan, test suites are
created which in turn can have any number of tests.

Test suites are created based on the cycle or based on the scope. It can contain any type of tests, viz -
functional or Non-Functional.

Test Suite - Diagram:

Main Types of software testing

Software testing is an extremely robust field where each key category branches out into different sub-
fields that are just as important. Below, we gave our best shot to visualize this whole ecosystem of
software tests in one, single graph just like an upside-down tree.
Manual vs. Automated vs. Continuous Testing

Let’s start our journey from the roots of your tree by comparing the three main primary approaches to
software testing that dominate the landscape: manual testing, automated testing, and continuous testing.

You may also notice that this level of our diagram is somewhat intertwined with the categories on the
level below it. What does this mean?

It’s hard to categorize which software tests can be automated and which can’t. In some circumstances, it
is both, while in others the manual approach is the only possible choice. So, for simplicity’s sake, we’ve
put this categorization at the bottom, so that our graph doesn’t look like a complex Penrose diagram. Just
keep in mind that

So, with that clarification out of the way, let’s move on to the first categorization based on how the testing
process is performed.

Manual testing

Manual testing involves human testers meticulously executing test cases, simulating user interactions,
and observing software behavior. It requires human intuition, expertise, and attention to detail. Manual
testing excels in situations where subjective evaluation, exploratory testing, and ad hoc testing are
required. It is especially useful when:

 Testing user interfaces, usability, and user experience,

 Assessing software behavior in unpredictable scenarios,

 Evaluating the aesthetics and overall feel of the application.

Automated testing

Automation testing uses specialized software tools to execute predefined test cases and compare actual
results with expected results. It accelerates the testing process, increases efficiency, and enables test
iteration. Automated testing is ideal for scenarios such as:

 Regression testing to ensure that modifications don’t introduce new defects.

 Performance testing to evaluate system response times and resource utilization.

 Load testing to measure software stability under high user volumes.

Automation testing requires an initial investment to set up the test environment, create test scripts, and
select appropriate tools. It requires technical expertise to develop and maintain automated test suites.
While automated testing reduces the effort required for repetitive tasks, it may lack the human element
to detect certain nuances that manual testing excels at.

Continuous testing

Continuous testing integrates testing activities throughout the entire software development process,
ensuring quick feedback and rapid defect resolution. It combines manual and automated testing
approaches and leverages test automation frameworks and tools. Continuous testing is particularly
valuable in scenarios like:

 Agile and DevOps environments where continuous integration and deployment are key.

 Projects that require frequent software updates and iterative development.

 Complex systems that demand constant quality assurance.

Continuous testing requires a robust test automation infrastructure, comprehensive test suites, and a
well-defined feedback loop. It requires collaboration between development and testing teams to enable
a streamlined process for identifying and fixing defects early in the development cycle.
Functional vs. non-functional testing

Now let’s move to the next level of our diagram and look at functional and non-functional testing.

These are the categories that really divide software testing into two distinct groups, each performed with
different goals in mind.

Functional testing revolves around evaluating whether the application works as intended, performs the
desired actions, and produces accurate results. Functional testing evaluates the behavior of the software
in various scenarios to ensure that it works properly and delivers the expected results. Testers simulate
user interactions, input various data sets, and examine the software’s responses.

If we compare software testing to a construction supervisor making a final check of the building before
the project is completed, functional testing would be equivalent to verifying that all the basic
requirements from the architect’s blueprint are met. It checks that the rooms have the right dimensions,
and that all the doors and windows are in the right places.

Non-functional testing, on the other hand, shifts the focus beyond functional requirements to examine
other critical aspects of software quality.

Non-functional testing evaluates how the software performs in terms of attributes such as scalability,
reliability, usability, performance, and security. It evaluates the software’s response time, its ability to
handle concurrent users or heavy loads, its resilience under stress, and its adherence to security protocols.
Non-functional testing ensures that the software is not only functionally sound, but also provides a
superior user experience and meets performance expectations.
Going back to our construction manager example, non-functional testing would go a bit deeper. It would
include things like verifying that the ceiling can support the load we want, that the walls are keeping the
heat in, and that the site is prepared for future expansion of our building.

Now that we’ve covered the basics, we can move to the next level of our diagram and cover all the
different types of functional and non-functional testing.

Examples of functional software testing

Unit testing

Let’s start with the most basic type of software testing – unit testing. Sometimes called component
testing, unit testing focuses on verifying the individual units or components of a given software system.

It involves testing small, independent units of code to ensure that they work as intended. Unit testing is
typically performed manually by developers, using white-box testing techniques that delve into the
internal logic and structure of the code itself. By testing individual units in isolation, developers can
identify defects early in the development cycle and promote code reusability and maintainability. Unit
testing can be seen as the foundation for building robust and reliable software systems.
Common unit tests may include:

 Data flow testing,

 Branch coverage testing,

 Control flow testing,

 Statement Coverage Testing,

Example of a unit test:

A developer has created a password input text field with a validation value that must contain at least 8
characters and special characters. He then sets up a unit test to verify this one specific text field by
entering a password that has fewer characters, no special characters, an empty field, etc.

Integration testing

Next on the list is integration testing, which is a key software testing type that evaluates how well the
system communicates between different components or modules.

It validates that these components integrate and work together smoothly. Bottom up integration testing
verifies that data flows correctly between modules, dependencies are accurately managed, and overall
system functionality is not compromised.

It identifies problems such as incorrect data transfer, inconsistent interfaces, or faulty interactions that
may occur during the integration process. Integration testing plays a critical role in ensuring that each part
of the software system works in tandem to achieve the desired functionality. There are two main subtypes
of integration testing:

Incremental Testing

This approach works best when there’s a clear relationship between software modules. Developers take
two modules and verify the flow of data between them. If the integration between them works well, they
can add another module and test again. In other words, we can say that developers incrementally add
modules and test the data flow in the integration between them.

There are also two types of incremental testing, called top-down and bottom-up approaches, which are
based on the parent-child relationship within the system. The incremental method allows early detection
and resolution of integration problems and reduces the complexity of testing.

Non-incremental testing

If the data flow is complex and there are difficulties in classifying parent-child relationships, developers
can choose the non-incremental integration testing approach, also known as the big bang method. This
method may be appropriate for smaller software projects or when all components are readily available
and stable.

Example of integration testing process:

A team of developers is working on a software application that consists of a web-based front-end, a

middleware data processing layer, and a back-end database. They are setting up integration tests to verify
that data submitted to the front-end is properly processed by the middleware and then stored in the
underlying database.

System testing

Now we move on to system testing, which evaluates the entire software system as a whole, focusing on
its behavior and functionality from end to end.

System testing verifies that the integrated components and subsystems of the software work together
seamlessly and meet the specified functional requirements. It validates that the system performs its
intended tasks, handles data correctly, and provides the expected outputs. System testing is essential for
identifying problems that may arise due to component interactions or data dependencies throughout the
system.
End-to-end testing

This type of system testing is the most comprehensive, as it basically verifies the entire sequence of
actions within a software application, from the initial user input to the final output. It involves testing the
application’s functionality across multiple systems, servers, and interfaces, ensuring the smooth
integration of all components.

Sanity testing

Sanity testing is a software testing technique typically performed after receiving a software build that
contains minor code or feature changes. Its purpose is to verify that recent updates to the code base have
resolved previous problems. Basically, it checks whether each update makes sense from a practical point
of view.

Smoke testing

This form of software testing evaluates the functionality of the essential or core features of a software
application, verifies their expected behavior, and determines the stability of the application for
subsequent testing phases. Performing this type of testing helps to avoid spending time and resources on
an unstable or broken state, ensuring a more efficient use of resources.

Black box testing

This approach does not require knowledge of an application’s internal functions or processes. Testers
execute pre-defined test cases to identify functionality issues rather than internal implementation issues.
The focus is purely on inputs and outputs.

Monkey box testing

This rather funnily named software testing technique aims to interrupt application processes in order to
uncover potential errors or bugs. Also known as ad hoc testing or gorilla testing, this approach is done at
random and is typically an unplanned activity that does not use software documentation or test design
methodologies to construct test cases.

User Acceptance testing

Once your product begins to take its final form, it’s time to see what the general public thinks of it. That’s
where User Acceptance Testing (UAT) comes in, with the goal of assessing the software’s suitability for
real-world use by end users.

It focuses on validating whether the software meets user expectations and performs the intended tasks
effectively. UAT typically involves end-users or stakeholders executing predefined test cases and
evaluating the software’s behavior in a realistic environment. It ensures that the software meets user
requirements, functions intuitively, and provides a satisfactory user experience. UAT acts as a final
validation step before software deployment, allowing stakeholders to provide feedback and confirm that
the software is ready for production use.

Alpha and beta testing

If you are a gamer, you will be familiar with both of these terms. Alpha testing is the initial phase in which
a software application is tested internally by the development team or a select group of users. The goal is
to identify bugs, evaluate the functionality of the software, and gather feedback to improve its
performance. Once alpha testing is complete, the software moves into beta testing. Beta testing involves
a larger pool of external users who test the software in a real-world environment. The focus shifts to user
feedback, usability, and overall user experience.

Examples of non-functional testing

Now let’s move on to the part of software testing that is not so apparent to the end users – non-functional
testing. When the previous group of tests aimed at checking features of the application that end-users
will be interacting with, non-functional tests will dig a little bit deeper into the technical inner workings of
a software application.

So without a further a do let’s get down to the key types of non-functional software testing.
Performance testing

Performance testing is an incredibly complex topic. So complex that we’ve dedicated an entire blog
post to the importance of performance testing in modern custom development projects. That said, let’s
take a quick look at the main types of performance testing and the factors that make this aspect of non-
functional testing so incredibly important.

In a nutshell, performance testing aims to assess the responsiveness, speed, scalability, and stability of a
software system under various workload conditions. It ensures that the application performs optimally
and meets performance expectations.

Why is software performance testing important?

Simply put, it ensures that the software application meets the performance expectations of users and
stakeholders. It enables organizations to identify and resolve issues related to response times, low
latency, throughput, resource usage, and stability. By proactively addressing performance issues,
organizations can increase user satisfaction, reduce downtime, improve customer retention and protect
brand reputation. Whether it is a robust enterprise software accounting system, a metasearch travel
engine, or a social media platform, software performance is critical to all of these projects.
Load Testing

Load testing is a type of software testing that evaluates the performance and behavior of a system under
specific user loads and concurrent user activity. It helps identify the system’s capacity limits, potential
bottlenecks, and performance degradation to ensure that it can handle the expected workload without
compromising functionality or responsiveness.

Stress Testing

Stress testing is a type of software testing that evaluates the robustness and stability of a system under
extreme or abnormal conditions. By subjecting the system to exceptionally high user loads, excessive data
volumes, or limited system resources, stress testing aims to identify the system’s breaking points,
potential failures, or performance degradation.

Spike Testing

In spike testing, the application is subjected to a significant increase or decrease in load to evaluate its
ability to handle abrupt changes and determine the impact on the user experience. The primary objective
is to assess how effectively the software handles sudden load changes and whether it affects the overall
user experience.

Endurance Testing

Endurance testing is another form of performance testing that aims to determine whether an application
can withstand a significant load, this time over an extended period of time. The focus of endurance testing
is primarily on assessing the application’s performance in terms of memory usage and its ability to endure
prolonged use without degradation.

Scalability testing

Scalability tests are specifically designed to evaluate the system’s capacity to handle increasing amounts
of data as more hardware resources are allocated to it. These tests aim to assess the system’s ability to
efficiently process larger workloads, ensuring that the performance scales in proportion to the additional
hardware resources dedicated to it.

Security testing

Security testing focuses on evaluating a software system’s ability to protect data, maintain confidentiality,
and defend against potential threats and vulnerabilities.

This type of testing is typically performed by a team of experienced cybersecurity professionals. For
smaller SaaS applications, there’s an alternative – applications like Scanrepeat that perform continuous
security audits.

Security testing itself involves identifying security weaknesses and vulnerabilities in the application’s
design, implementation, and infrastructure. By evaluating the system’s defenses, security testing helps
ensure that sensitive data remains protected and the system remains resilient to security breaches. There
are three main types of security testing:

Penetration Testing

Penetration testing, commonly known as “ethical hacking,” involves simulating real-world attacks on the
software system to identify potential security vulnerabilities. The goal is to uncover vulnerabilities that
could be exploited by attackers, provide insight into the security robustness of the system, and
recommend mitigation measures.

Vulnerability Testing

This type of testing is designed to identify vulnerabilities and weaknesses in the software application,
network, or infrastructure. It involves performing continuous testing and auditing to verify that the code
base is being developed according to the latest security best practices.

Security Configuration Testing

Security configuration testing evaluates the security configurations of the software application, servers,
and network infrastructure. The goal is to ensure that the system is securely configured with proper access
controls, encryption settings, and other security measures.
Usability testing

Usability testing is another type of non-functional testing that evaluates the usability, intuitiveness, and
overall user experience of software products.

Usability testing, a critical element of user-centered interaction design, focuses on evaluating the ease of
use and usability of a software product. Conducting usability testing requires a thorough understanding
of the application because it involves extensive testing. In essence, usability testing serves as a distinct
technique to identify flaws in the end-user interaction of a software product, earning it the alternative
term of user experience (UX) testing. There are two types of usability testing that are worth mentioning
here:

Cross-browser Testing

Cross-browser testing, as the name suggests, tests an application on different browsers, operating
systems, and mobile devices to see how it looks, feels, and performs.

Why do we need cross-browser testing?

The answer is quite simple. Different users use different operating systems, browsers, and mobile devices.
The goal of any company developing digital products is to ensure a great user experience regardless of
the device.

Exploratory testing

Exploratory testing in software development is a dynamic and unscripted approach to testing that focuses
on simultaneous learning, test design, and test execution. Unlike traditional scripted testing where test
cases are predefined, exploratory testing encourages testers to actively explore the software application
while designing and executing test cases on the fly.

Exploratory testing is particularly valuable for uncovering unexpected behavior, validating assumptions,
and providing real-time feedback on software functionality, usability, and overall quality.
Compatibility testing

Compatibility testing is a type of testing that verifies the behavior and performance of software in
different environments, such as different Web servers, hardware setups, and network configurations. Its
primary goal is to ensure that the software will function correctly across different configurations,
databases, browsers, and their respective versions.

Integration Testing Approaches & Methodologies

Software Engineering offers a number of strategies for doing integration testing, including −

 Big Bang Approach

 Incremental Approach

 Sandwich Approach - Combination of Top-Down and Bottom-Up

The various tactics, how they are implemented, as well as their limits and benefits, are listed below.

Big Bang Experimentation

Big Bang Testing is a technique for integration testing in which all of the components or modules are
brought together at the same time and then tested as a single entity. During testing, this integrated
collection of components is treated as a single object. The integration procedure will not run unless all of
the components in the unit have been finished.

Advantages

 It's ideal for tiny systems.

Disadvantages

 It's tough to pinpoint the exact location of a fault.

 Given the large number of interfaces that must be examined in this method, certain interfaces
that must be evaluated may be overlooked.

 Because integration testing can only begin after "all" of the modules have been defined, the
testing team will have less time throughout the testing phase to execute.

 Due to the fact that all modules are evaluated at the same time, high-risk critical modules are not
segregated and examined first. Peripheral modules that deal with user interfaces aren't
segregated or prioritized for testing.

Incremental Testing

The Incremental Evaluating technique involves merging two or more modules that are logically connected
to one another and then testing the application for correct functionality. The additional connected
modules are then progressively integrated, and the procedure is repeated until all logically linked modules
have been successfully integrated and tested.
The Incremental Approach is implemented using two alternative methods −

 Bottom-Up

 Top Down

Drivers and Stubs

Stubs and Drivers are fake programs used in Integration testing to make the software testing process
easier. These programs act as stand-ins for the testing's missing models. They do not implement all of the
software module's programming logic, but they do mimic data transfer with the caller module during
testing.

 Stub − This method is invoked by the Module under Test.

 Driver − This is the program that calls the module that will be tested.

Bottom-up Integrity Checking

Bottom-up The strategy of integration testing is to test the lowest level components first. The tested
modules are then utilized to help with the testing of higher-level modules. The process is repeated until
all top-level modules have been tested. The next level of modules is generated when the lower level
modules have been tested and merged.

Advantages

 It is simpler to locate a fault.

 Unlike the Big-bang strategy, no time is wasted waiting for all modules to be constructed.

Disadvantages

 Critical modules (at the top level of software architecture) that affect the flow of the program are
tested last and are more likely to have bugs.

 It is not feasible to create an early prototype.

Integration Testing from the Top Down

Top-Down Integration Testing is a way of doing integration testing from the top to the bottom of a
software system's control flow. To ensure software functioning, higher-level modules are tested first,
followed by lower-level modules that are tested and integrated. If certain modules aren't ready, stubs are
used to test them.

Advantages

 It is simpler to locate a fault.

 Possibility of getting a prototype early on.

 Critical Modules are tested first; severe design faults may be discovered and corrected first.

Disadvantages
  Many Stubs are required.

 Lower-level modules are not thoroughly tested.

Sandwich Testing

Sandwich testing is an approach in which top-level modules are tested with lower-level modules while
lower-level components are combined with top-level modules and evaluated as a system. Hybrid
Integration Testing is a hybrid technique that combines top-down and bottom-up approaches. Both stubs
and drivers are used in this project.

Integration Test Approach

Regardless of the Software testing methodologies (described above), the Integration test approach is as
follows −

 Make a plan for the integration tests.

 Create the scenarios, cases, and scripts for the tests.

 Following the execution of the test cases, the flaws are reported.

 Defect tracking and re-testing

 Steps 3 and 4 are performed until the Integration is completed successfully.

Integration Test Plans: A Quick Overview

It has the following characteristics −

 Testing Methodologies/Approaches (as discussed above).

 Scopes and Exclusions Integration Testing Items

 Responsibilities and Roles

 Integration testing has several prerequisites.

 Environment for testing.

 Plans for Risk and Mitigation.

Integration Testing Entry and Exit Criteria

In any software development methodology, there are entry and exit criteria for the integration testing
phase.

Criteria for Entry

 Components/Modules that have been unit tested

 All high-priority bugs have been resolved and closed.

 All modules must be coded and correctly integrated.

  Tests of integration Plan, test case, and scenarios must all be approved and recorded.

 Integration testing requires the creation of a test environment.

Criteria for Exit

 The Integrated Application was successfully tested.

 Test Cases that have been completed are documented.

 All high-priority defects must be repaired and closed before technical documentation and release
notes are submitted.

Integration Testing Best Practices/Guidelines

 Determine the Integration Test Strategy that may be used first, and then create the test cases and
data to go with it.

 Examine the application's architecture and determine the critical modules. These must be tested
as soon as possible.

 Obtain the architectural team's interface designs and write test cases to thoroughly check all of
the interfaces. The database interface, as well as any external hardware or software applications,
must be thoroughly tested.

 Following the test cases, the test data is the most important factor.

 Prior to execution, always have the mock data ready. During the execution of the test cases, do
not choose test data.

Integration Testing Challenges

We've covered a lot of ground in terms of how integration testing works and the benefits it provides.
Benefits, as is customary, come with some drawbacks. Integration testing might be more difficult than
you think due to a number of issues. Here are a few instances of scenarios like this −

 It's difficult to comprehend the logic of units when there are too many individuals involved in the
code development process, each with their own style.

 Testing can be complicated by a variety of elements (databases, platform, environment, and so

on).

 Integrating two legacy systems, as well as integrating a new system into an existing one, is seldom
painless.

 If multiple teams build distinct systems for integration, they may be incompatible.

 Choosing the most efficient model might be challenging due to many methodologies and testing
combinations.