Software Testing Fundamentals

Course Level

Beginner

Duration

01h

Total Chapters

6

Free

About Course

Software testing is a critical component of software development that helps to ensure that software applications work correctly, meet user requirements and expectations with the least defects and issues. It is complex, challenging, and requires a deep understanding of testing techniques, processes, and tools.

To have a successful career in software testing, you must have a solid foundation. And we understand that starting in this field can be daunting since there are tons of inconsistent materials out there to learn. That’s why we designed this course to equip you with the essentials of software testing in a simple yet practical manner, backed up with real-life examples.

In six chapters, you will learn about:

  • The concept and common misconceptions of software testing
  • The objectives and importance of software testing with real-life examples
  • The seven universally-accepted testing principles
  • Different popular models of software testing development lifecycle
  • The typical stages of software testing lifecycle
  • The concepts and relationship between testing levels and testing types
  • The mindset of testers and how to work with developers effectively

By the end of this course, you will understand your role as a QA or QC in software development and have a solid foundation to continue your self-learning journey in software testing.

Chapter Overview

Understanding the concept of software testing correctly

00:00-02:36

Hi, welcome to Katalon Academy and the first chapter where you will learn and understand the concept of software testing correctly.

Here's a common misconception about software testing: It's only about executing tests. It would mean if you are a manual tester and you're testing a web application, you would only perform some actions on the app according to the pre-written test steps and then verify the results. In the case of automated testing, you would only run the automated tests and check the results.

Software testing is more than just executing tests. In fact, it's a stage in the software development lifecycle used to assess the quality of the software and reduce the risk of software failure in operation.

It's a process that includes a set of activities, rather than just execution, to verify whether a system under test meets the specified requirements. It also validates whether the system meets the needs of users and other stakeholders in the operational environments in terms of both functional and non-functional aspects such as performance and security. This can be done by checking whether the actual results on the system match the expected results.

While there is no fixed test process for all teams, here are the main groups of activities that are necessary to meet the testing objectives. They include:

- Test planning

- Test designing (including creating test environments, test cases, and test data)

- Test executing

- Test reporting and analytics

- And finally test monitoring and control

We will discuss the objectives and details of these activities in the later chapters.

It's also worth mentioning that testing is not limited to the execution of a system under test, which is called dynamic testing. It also involves static testing, which is reviewing work products such as requirements, user stories, and source code.

For example, when you test a web application, dynamic testing is when you perform actions on the application. It requires the website to open and run to verify whether a function meets the requirements, or a whether non-functional aspect can meet the user's expectations. For example, make sure that the website won't crash even with a high volume of traffic or users.

Static testing, on the other hand, is when you review the requirements of a function before it's implemented or coded. It does not require the website to operate.

Understanding the basic terms in software testing

00:00-02:58

Before moving to the next chapters, it would be helpful for us to learn several basic terms and truly understand what they mean.

The most common terms you will see and hear a lot are Error, Defect, and Failure. They are not the same but closely related.

Their relationship can be described like this: a person makes an error (or mistake) that can introduce a defect (often called bugs, or sometimes called fault) in the software code, which can then lead to a failure of the software during operation. One thing to remember here is that failures of a system are not solely due to defects. They can also result from other environmental factors.

For instance, when writing requirements, a business analyst makes a mistake by misunderstanding a requirement from clients, which leads to a requirement defect. This defect then results in another programming error from an engineer, which leads to a defect in the system code. When the code is later executed, a system failure may trigger during the operation, depending on specific data input.

The next terms we will discuss are Quality management, Quality assurance, and Quality control.

Quality management is the highest level. It includes all activities that direct and control an organization regarding quality, including both quality assurance and quality control.

Quality assurance is more process-oriented. It creates proper processes and makes sure that all team members follow them. When processes are carried out properly, the created work products generally have higher quality. It's reasonable to say that quality assurance focuses more on defect prevention.

Quality control, on the other hand, is more product-oriented. It includes all testing activities to identify defects and achieve different levels of quality. While quality assurance supports proper testing, quality control ensures the proper execution of the entire test process.

In reality, most people and many companies use these two terms interchangeably in work and hiring. When looking for a job, you should pay more attention to the job description, what they require you to do, to know what you're applying for.

Lastly, we will look into the two terms Verification and Validation. Each activity has a completely different purpose.

Verification answers the question ''Do we build the system or product right?'' It ensures a module, system, or product is designed and developed correctly according to the written specifications or requirements.

Validation, on the other hand, answers the question ''Do we build the right system or product?'' It is checking how well the system or product addresses and meets the user's needs and expectations in a real-world context.

Explaining the objectives and importance of software testing

00:00-04:44

Now you understand the concept and the scope of testing and some common basic terms. Let's move on to see the importance of software testing.

One thing you should always remember is that there's no perfect software application. Most people have had an experience with software that did not work as expected. Software that does not work correctly can lead to many problems, including loss of money, time, business reputation, and even injury or death.

NASA's Mars Climate Orbiter is a popular example of one of the most costly software defects, around 200 million dollars for the spacecraft development alone. It was reported that the ground control software used the imperial measurements while the onboard software produced by NASA used the international system of units. This mismatch in development caused the probe to travel much lower to the surface of Mars and eventually got burned up.

Software defects that create security vulnerabilities in the system can also be very costly. A system hack or a data leak can severely damage the business's reputation and profit.

A software defect in any car's safety systems, such as anti-lock brakes, stability control, and airbags can potentially lead to accidents and injuries, or even death. These examples and many similar ones are the reasons why testing exists, to assess the quality of the software and to reduce the risk of software failure in operation.

The most typical objectives of testing can be categorized into 4 groups:

1. Preventing defects: This can be done by having testers involved in reviewing the requirements reviews or refining the user stories before the development phase begins. The identification and removal of defects in requirements can reduce the risk of incorrect or untestable features being developed.

2. Finding defects: This usually happens after the development phase, when a tester comes in and performs the test steps on an application or system to verify whether a function works correctly according to the specified requirements.

3. Gaining confidence about the level of quality: Without testing, you cannot tell the quality level of the software in question. The more you test, the better the software becomes. When bugs or defects are found early, you can quickly fix them to ensure software quality when it is released to end users.

4. Providing significant information for decision-making: The test lead or test manager normally look into the higher-level metrics, such as test coverage and defect management, and communicate with the product manager or release manager to evaluate whether the software is ready to release or not. If there are too many unsolved defects, it would make sense to delay the release. However, that would result in some possible negative consequences. For example, the competitors would release their products first and win more users. Regardless of the decisions, the information or reports from testing activities is crucial to evaluate the situation and make the right decision.

That said, the objectives of testing can vary depending on the context of the business, the system under test, the development model, the testing types and levels, and so on. For example, when testing a function after it's developed, the main objective might be to identify as many defects as possible so that they can be fixed as early as possible.

But in the later stage when the software is about to be released, it would make more sense to just focus on confirming that the system can work according to the requirements and provide the information to the stakeholders to evaluate the current state of software quality for release.

One more thing we would like you to remember is that the cost of defects will rise higher when the bugs escape and are found in the later stages.

Take mass-producing a new car model as an example. Let's say there's a defect in the airbag software. If we can detect this early when the function is being developed, it would be easy and inexpensive to fix.

But if we miss it, and only detect this problem after thousands of cars have been released to the market, it would cost a huge amount of money to recall and fix all the vehicles and significantly damage the business image in case of injuries. These stories have happened several times before in the car industry.

Now you understand why testing is an important process in software development. It helps us identify, prevent, and fix defects to ensure the highest possible level of quality when software is developed and delivered to end users.

Explaining the seven testing principles

00:00-05:16

Over the years, many testing principles have been developed. Here are the 7 ones that are widely applied and you can use them as general guidelines.

1. Early testing (sometimes called shift-left testing) saves time and money.

As we discussed in the previous lesson, defects become more costly when found in the later stages. So, it's important to carry out testing activities as early as possible in the software development lifecycle, which helps reduce or eliminate costly changes.

This is one of the primary reasons why many teams turn to Scrum or Agile development process instead of following the traditional Waterfall model. We will discuss this more in a later chapter about the software development lifecycle.

2. Testing cannot prove there are no defects.

Testing can only show the presence of defects and reduces the probability of undiscovered defects remaining in the software. We don't know what we don't know. Even when there are no defects found through testing, you cannot conclude the software is defect-free.

3. Exhaustive testing is not possible.

It is impossible to test everything in a software application. Just a simple function like uploading files can have endless test scenarios. It would be impossible to test all possible file types and sizes that could be uploaded within a timeframe. And one web application has many other features and functions.

Instead of trying to test everything, use different risk analysis methods, test techniques, product knowledge, and personal experience to set priorities and focus on the areas that matter the most in a release.

4. Defects cluster together.

A small number of modules in any software system is highly likely to contain most of the defects.

Defect clustering occurs because of various reasons. It can be because certain modules or functionalities are more complex than others, or they are used more frequently, or they were not tested thoroughly during development. The underlying cause is not always clear, but it is essential to identify and focus test efforts on the areas of the software that are prone to defects.

For example, with a banking software system, we would likely prioritize testing the modules that deal with financial transactions, since these are frequently functioning, high-risk, and highly-complex areas.

5. Avoid the pesticide paradox.

In the context of farming, when you use the same pesticide over and over again, at a certain point, it will stop working because the pests might build up the immune system or new kinds of incest are introduced.

The same applies to testing. When the same tests are repeated and the software system remains the same, the same defects will be found.

In reality, new requirements and functions are frequently added, resulting in the possibility of new defects in the system. Since the existing tests were designed to look for specific defects, they may not be effective at identifying new types of bugs.

To overcome the pesticide paradox, your testing team needs to continually update and modify the test cases and test data to ensure that they will be able to identify new defects in the software system.

6. Testing depends on context.

The effectiveness of a testing approach depends on the context in which it is applied. Context includes factors such as the type of system under test, the end users, the technology used, the development methodology, and the business environment.

For example, the way you test a game application may be different from accounting software, as the requirements of the user interface, functionalities, and performance are different for each. Similarly, testing a web application following Agile methodologies is certainly different from testing a desktop application using the Waterfall methodologies.

To apply testing effectively in a specific context, your testing team must understand the unique features of the software system you are testing, the needs of the end-users, the business goals, and other internal conditions.

7. The mistaken belief of absence of errors.

This principle implies that the absence of errors, including identifying and fixing all found defects, does not guarantee that the software is functioning correctly or meeting user needs in reality.

Testers should not narrow their scope to just finding and fixing defects. They should always consider the broader context of the software they are testing and its intended use in real-life scenarios. Ultimately, good software is one that can meet user needs and function correctly in all relevant contexts.

There are certainly a lot more testing principles out there. But these seven principles will give you a good mindset and foundation when stepping into the world of software testing. And that's the end of this chapter. You have learned the concept of software testing, the objectives, and its importance in software development. See you in the next chapter.

SD
SM
BM
JJ

This course is useful for our students

JR
MP
NK
PP
VK

55

NE

nice but it was a some difficult to understand it

SM
KI
MS
SB
MA
DA
CP
NB
PP
VV
KN
AA
ML
DN
RO
SF
BM
VR

NICE

PV

good

JR
NA
RG

excellent

SK
MT
SY
AL
PG
TA
AK
PG
GV
RT
KS
மM
AT
VK
NN
NP
D
PP
DA
PS
ES
RP
JL
PR
A
VV

VERY IMPORTANT AND SUPER

PD

4

SP
SU
SM
MB
RN
SK
BV
AS
JM
AD
SL
AC
AD
BL
LM
SS
JA
KB
JM
KG
EV
AP

Good Information on QA Basics

MR
GG
NJ

Very Nice!!

MK
KJ
NS
EE
DB
RR
RM
HT

Kool

MT
NG
RR
PA
DI
MI
SB
OR
VP
SK
AJ
AS
SB
N
J

good

IS

great

TI
X
SA
SG
SN
TN
SH

good

5K
K
RC
J
JH

Good.

VD
MB
RR
RG
AD
MN
P

Great

VD
RB
AK
OP
MK
CL
YV

Excellent. Easy to understand

AF
TV

It\'s good

AS
GR
DR
SB
PH
MG
CK
NV
AD
VK
MN
BP
NK
RB
Free

Materials include

  • On-demand course

  • Lifetime access

Share