Testing types

Testing types, levels, techniques

● Test type: A group of test activities aimed at testing a component or

system focused on a specific test objective, i.e. functional test, usability
test, regression test etc.

● Test level: A group of test activities that are organized and managed
together. A test level is linked to the responsibilities in a project. Examples
of test levels are component test, integration test, system test and
acceptance test.

● Test design technique: Procedure used to derive and/or select test cases.
Criterias

Test types are segregated based on various criterias:

● Objective (functional vs non-functional)

● Access to source code (black-box, white-box, grey-box)
● Executor (manual vs. automated)
● Run time (static vs dynamic)
● Location (alpha vs beta)
Testing types

Depending on objective:

● Functional Testing

● Non-functional Testing
Functional testing

● A set of actions/activities that are verifying

a specific functionality of the system
● They may answer questions such as 'Is the
user able to do this?' or 'Is this feature
working?'
Functional testing flow

● Understand the Requirements

● Identify test data
● Generate test cases based on: test data, actions to
do, expected result
● Execute test cases
● Comparison of actual vs. expected result
Functional testing types

● Smoke testing

● Sanity testing

● Interface Testing

● Regression Testing

● GUI Testing
Smoke testing

● ensure that the most important functions are working

● if smoke passes, then testing can move on, if no, ask for a
new build
● explore problems early during development cycle
● can be done both manually or automated
Sanity testing

● Sanity testing is done to check that new functionality/bugs

have been fixed at a high level (only some tests are
executed)
● It is also a subset of regression testing, checking also that
no new issues were introduced.
Interface testing

● A connection between two different components or

systems is called an interface
● An integration test type that is concerned with testing the
interfaces is called interface testing
Regression testing

● Confirm that latest code changes didn't affect

existing features
● It is based on re-testing already executed test cases
● With larger test suites, the execution time increases
accordingly
GUI testing

● GUI is what user sees

● Testing performed by interacting with the software
under test via the graphical user interface.
● GUI testing involves checking the screens with the
controls like menus, buttons, icons, and all types of
bars - toolbar, menu bar, dialog boxes and windows
Non-Functional testing

Verifies software characteristics that are not related to

a function or user action, but to aspects such as
security, performance or scalability
Non-Functional testing types

● Compatibility testing ● Performance testing

● Usability testing ● Load testing
● Security testing ● Stress testing
● Maintainability testing ● Localization testing
● Reliability testing ● Compliance testing
Non-Functional testing

● more effective by using tools

● testability level:
○ the software should be fast
○ the app should be easy to work with
Functional vs. Non-Functional

●what the product does VS how well the

product behaves
●requirements VS expectations
Compatibility testing

● non-functional testing type

● assure the compatibility of the application
with other systems, such as browser,
hardware, OSes, networks
Usability testing

● how easy is the software to use?

● is the software user friendly?
● is the application easy to learn?
Security testing

● is user confidentiality guaranteed?

● is data integrity assured?
● are the authorization levels properly set?
● is the authentication method secure?
Reliability testing

● how long is the software able to perform

without any failures under some given
conditions?
● is the software trustworthy?
Performance testing

● check how fast a system works under an expected

workload
● used to determine application speed, scalability and
stability
● two main subtypes:
○ Load testing
○ Stress testing
Performance - Load testing

● check software behavior under a defined

load
● find the maximum operating capacity
● e.g. verify how application behaves when
many users access it the same time
Performance - Stress testing

● test beyond the normal operational

capacity of a system and observe the results
● determine how stable a system is
● e.g. low memory, low disk space, no
internet connection, copy 5GB of text into a
text app, etc.
Testing types

Depending on access to source code:

● White Box
● Black Box
● Grey Box
White-Box testing

● tester knows about the internal structure of the item

being tested
● goal is to identify poor structured paths in the code
and security holes, as well as checking flow of
specific inputs through the code
● how? unit testing
● starts early in SDLC -> bug prevention
Black-Box testing

● functionality of the software under test (SUT) is

tested without looking at the internal code structure
● based entirely on the software requirements and
specifications
● we just focus on input and output of the software
Black-Box testing process SDLC

● examine the customer requirements

● choose valid inputs (positive tests) and verify that the system
processes them correctly, choose invalid inputs (negative
tests) and verify that the system can detect them
● determine expected outputs for inputs
● write test cases based on inputs, then execute them
● compare actual results with expected results
● log defects and retest them
Black-Box advantages

● execute tests considering user point of view, help

find out specification deviation
● no programming knowledge needed
● no need for developers to do this due to their
subjective perspective
● test cases are designed as specifications are in place
Black-Box disadvantages

● small number of inputs can be tested, leaving some

paths untested
● difficulty in test design, since in many projects there
are no clear specs
Gray-Box testing

● It's black box? It's white box? No, it's both!

● Partial knowledge of the internal code is needed
● e.g. if link is not working, tester can change a simple
HTML file
● e.g. design test cases based on code analysis
(white-box), then execute them on UI (black-box)
Why Gray-Box?

● double benefits of black/white box

● input from both developers and testers is combined
● helps developers to fix the issues faster
Testing types

Depending on executor:

● Manual Testing

● Automated Testing
Manual vs. Automated

Which one is the best?

.
.
.
If so, why do we need the other one? :)
Testing types

Depending on run-time:

● Static Testing

● Dynamic Testing
Static testing

Testing of a software development artifact,

e.g., requirements, design or code, without
execution of these artifacts

Main approaches:
● Reviews (meetings)
● static analysis using tools (FindBugs, Sonar)
Static testing

What can we test?

● Specifications, requirements, user stories

● Architecture and design specifications
● Code
● Testware, including test plans, test cases, test procedures, and
automated test scripts
Static testing

Advantages:

● Detecting and correcting defects prior to dynamic test execution

● Identifying defects which are not easily found by dynamic testing
● Preventing defects in design or coding
● Reducing development/test cost and time
● Reducing total cost of quality over the software’s lifetime, due to
fewer failures later in the lifecycle or after delivery into operation
Testing types

Depending on location:

● Alpha Testing

● Beta Testing
Alpha testing

takes place at the developer's site, before

installing the application at the customer site
Beta testing

● takes place at customer's site

● users install and use the application under
real working conditions
References

● Read chapters 2 and 4 of the ISTQB

Foundation Level Syllabus
Questions?