Unit 3

• Software Testing for Databases

• Content created by Bing AI
• Content modified by SADT
Describe
• Software testing is required to ensure that the software solution meets the requirements and specifications of the
stakeholders.
• It helps identify defects and bugs in the software solution before it is released to production.

why •
• This helps reduce the cost of fixing defects and bugs in production and improves customer satisfaction.

Examples of what can happen if software testing is not performed, or not performed adequately:

software • In 2018, a software bug in the Facebook API exposed the personal data of millions of users to third-party
developers. This could have been prevented if Facebook had conducted proper testing.

testing is • In 2017, a software bug in the Equifax credit reporting agency’s website exposed the personal data of 143
million people to hackers. This could have been prevented if Equifax had conducted proper testing.

required • In 2016, a software bug in the Samsung Galaxy Note 7 caused the phone’s battery to overheat and catch
fire. This resulted in a recall of all Galaxy Note 7 phones and cost Samsung billions of dollars.
 • There are four levels of software testing:
• Unit or Component Testing
• Unit testing is performed on individual units or components of the software solution.
• In PL/SQL, a component might be:

Compare
• A stored program (procedure, function, trigger)
• In an anonymous block it would be a section of code. For example:
• Decision structure (e.g., IF)

software
• Iterative structure (e.g., loops)
• Exception handling
• Calculations

testing • Integration Testing

• Integration testing is performed on integrated modules of the software solution.
• This is where we take those smaller units or components and put them (integrate them) together.

levels •
• The units work individually, but do they still work in combination with other units.
System Testing
• System testing is performed on the entire system to ensure that it meets the requirements and
specifications.
• Acceptance Testing (also called User Acceptance Testing)
• Acceptance testing is performed by the stakeholders to ensure that the software solution meets
their requirements and specifications.
 • There are two types of software testing:
• Functional Testing
• Functional testing is performed to ensure that the software solution meets the functional

Compare
requirements and specifications.
• This is the type of testing we will be focused on in this course.
• Non-functional Testing

software • Non-functional testing is performed to ensure that the software solution meets the non-functional
requirements and specifications such as performance, security, usability, etc.
• Here are some examples of non-functional software testing:

testing •

•
Performance testing: This type of testing is used to evaluate the performance of the
software solution under different conditions such as high load or stress.
Usability testing: This type of testing is used to evaluate the ease of use and user-

types
friendliness of the software solution.
• Security testing: This type of testing is used to evaluate the security of the software
solution and identify potential vulnerabilities.
• Reliability testing: This type of testing is used to evaluate the reliability and stability of the
software solution under different conditions.
• Beyond this information, we will not be looking any closer at non-functional testing in this course.
 • Here are some testing terms that you should become familiar with:
• Dynamic testing:
• This is a type of testing that is performed when the system is running (executing).
• The main purpose of dynamic testing is to test software behavior with dynamic variables or variabl
es which are not constant and finding weak areas in software runtime environment
1
.
• An example of dynamic testing is load testing which is used to evaluate the performance of the
software solution under different conditions such as high load or stress.

Testing
• Static testing:
• This is a type of testing that is performed when the system is not running.
• Static testing includes reviews and static analysis by tools 2.

terms
• An example of static testing is code reviews which are used to evaluate the code quality and
identify potential issues before the software solution is deployed.
• Black box testing:
• Black box testing: This type of testing focuses on testing the functionality of a system without requi
ring knowledge of its internal workings
3
.
• We do not see the code with this type of testing.
• White box testing:
• White box testing: This type of testing involves testing the internal logic and structure of the syste
m’s code
3
.
• We see the code with this type of testing.
Specific • We combine the previous terms to identify two specific kinds of tests that we will be using:
• Dynamic black box testing:

tests we
• Dynamic black box testing: This is a type of testing that is performed when the system is running a
nd focuses on testing the visible business logic and simulating typical user behavior to find defects
1
.
• We focus on if we get the expected output/result based on input that we provide for testing.

will focus •
• When we create test plans, these are the types of tests we are listing and defining.
Static white box testing:

on in this
• This is a type of testing that evaluates software without executing the code and checks for flaws
and errors.
• It examines the code to find software flaws and weaknesses such as SQL injection and others 2.
• This would be a code review.

course • We look at the code without executing it and make sure that coding standards and
restrictions have been followed.
Describe
the
advantage • Combining static testing with white box testing and dynamic testing with black box testing provides us advantages
with the end product we produce:

s of
• Combining these software testing types helps ensure that the software solution meets both the functional
requirements (does what it is suppose to do) and the coding standards.
• Ensuring required functionality is present and works as expected helps improve customer satisfaction and

combining
reduces the cost of fixing defects and bugs in production.
• These fixes can be costly and have an impact on the customer’s uptime with the software.
• Making sure coding standards and restrictions have been followed ensures the code is maintainable over

software
time and allows for code evolution rather than complete re-writes when requirements change or grow.

testing
types
 • These would be specifically for dynamic black box testing.

Additional • We look at tests from two perspectives:

• Test-to-pass:

terms for
• This is an approach to testing software where you assure only that the software minimally works.
You don’t push its capabilities. You don’t see what you can do to break it 1.
• Only look at clean data (no erroneous data).

software
• Test-to-fail:
• Test-to-fail: This is an approach to testing software where you push the software’s capabilities and
see what you can do to break it
1
.

testing
• We look at both clean data and erroneous data.
• We mix the data together.
• We see what happens if we change the data, will the program remain stable and perform as
expected, or will it crash or perform its functionality incorrectly.
 • The guidelines used to select data to be used for dynamic black box testing include:

Describe
• Select data that represents typical usage scenarios.
• This guideline suggests selecting data that represents the most common usage scenarios for the
software.

the
• For example, if you are testing a web application that is used to book flights, you would want to
select data that represents typical flight booking scenarios such as selecting a destination,
selecting a date, and selecting a flight time.
• Select data that represents edge cases or boundary conditions.

guidelines • This guideline suggests selecting data that represents the limits of what the software can handle.
• For example, if you are testing a web application that is used to upload files, you would want to
select data that represents the largest file size that can be uploaded or the maximum number of

used to
files that can be uploaded at once.
• Select data that represents data types/values that cause known issues.
• These are data types/values that can cause issues regardless of language.

select
• These should always be included in testing if there is a possibility of their use.
• They are:
• Dates

data to be •
•
• Never use default formatting.
NULL values
Select data that represents invalid input or error conditions.

tested • This guideline suggests selecting data that represents invalid input or error conditions.
• For example, if you are testing a web application that is used to create user accounts, you would
want to select data that represents invalid input such as an email address with an incorrect format
or a password with too few characters.
 • Here is an example of the structure of informal test cases:

Demonstrat
e the 1
Component / Integration
Point Description
Calculate total number of
Component /
Integration
Component
Test Values (Input)

Start Time: NULL

Expected Output

Calculated Hours: Null

Successful /
Unsuccessful

documentati
Successful
hours End Time: NULL
2 Calculate total number of Component Start Time: July 1, 2018 Calculated Hours: 1
hours 13:00 Unsuccessful

on of
End Time: July 1, 2018 [3 returned]
14:00
3 Calculate total number of Component Start Time: NULL Calculated Hours: Null Unsuccessful
hours End Time: July 1, 2018 [Unhandled

software 4 Calculate total number of Component

14:00

Start Time: Fred Error message: The

exception
occurred]

test cases
hours End Time: July 1, 2018 start time was not a Successful
14:00 valid date

Audio describing the image above:

Describe • A template of the example provided on the previous slide is available as an MS Word document in the Course

how to •
Information content area on Brightspace.
All tests should be roughed in BEFORE any coding occurs.

prepare a
• Similar to flowcharts, we need to start with a plan.
• The plan can change, but we need to start somewhere.
• Think of all possible test cases and include them in the test plan.

test plan • You will probably be able to eliminate some when the testing begins if there is duplication, but for now
think big.
• At this point the “Successful/Unsuccessful” column would be left blank.

for a •
• We fill this in when we perform the test to see if it works as expected or needs correction.
The initial roughed in test plan should be based on the problem specifications, not on the code that was
created.

software • It is always possible that something was missed when the coding was being done.
• Compiling the test plan independent of the code, and before the code is written, means the test
plan also becomes a checklist and helps us identify if anything was missed during code creation.

solution
Food for
thought Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live.
- Martin Golding

Photo: Colourbox.com