Scribd
Upload
16 views

Testing Basics

Uploaded by

Santiago Murcia Cadavid
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
16 views

Testing Basics

Uploaded by

Santiago Murcia Cadavid
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 18

1 - Testing Basics

Bootcamp - TAE
Agenda

● Theory
■ Testing.
■ Types of testing.
■ Testing Approaches
■ Functional Test.
■ Non-Functional Test.
● Practice
■ Git.
■ Maven.
■ Junit.
■ Exercise.
Theory

Theory
Testing

The art of destroying


something constructively

The process of executing The process of operating a


a program with the system or component to
intention of certifying its evaluate specific aspects
quality. under specific conditions,
observing and registering the
results.
Testing

¿Why is it necessary?

Because errors exist...and humans **** up things. Testing helps us to:

● Ensures product fits customer's requirements.


● Makes sure the code is reliable, helps improve developers knowledge/skills and
overall product quality.
● Reduce defects that can potentially reach Production environments.
● Redefine the way things are done and how they work.
● Set projects up to success.

As time passes, the cost of fixing a defect increases.


Testing types
Testing types

Unit tests
Exercises the smallest pieces of testable software (object or method) in the
application to determine whether they behave as expected.

■ Executes against static code.


■ The developer that wrote the code is involved (+ Code Review).
■ Defects are fixed as soon as they are detected, without needing to go
through the bug reporting formalities.
■ Coverage is measured in % of code covered.
Testing types

Component tests

Component is any well-encapsulated, coherent and independently replaceable


part of a larger system. In a microservice architecture, the components are the
services themselves

Limits the scope of the exercised software to a portion of the system under test,
manipulating the system through internal code interfaces and using test doubles to
isolate the code under test from other components.

● Ability to thoroughly acceptance test the behavior encapsulated by that


component.
● Tests execute more quickly than broad stack equivalents.
● Isolates component from its peers using test doubles. Avoids any
complex behavior they may have.
● Controlled testing environment for the component. Able to trigger any
applicable error cases in a repeatable manner.
Testing types

Integration tests

Collect modules together and test them as a subsystem in order to verify that they
collaborate as intended to achieve some larger piece of behavior. They check for
any incorrect assumptions each module has about how to interact with its peers.

● In micro service architectures they are typically used to verify interactions


between layers of integration code and the external components to which they
are integrating (other micro services, data stores and caches).
● The goal is to verify that the module can communicate sufficiently rather than
to acceptance test the external component.
● Should aim to cover basic success and error paths through the integration
module.
Testing types

End to End tests

Verifies that the system as a whole meets business goals irrespective of the
component architecture in use. Since end-to-end tests are more business facing,
they often utilise business readable Domain Syntax Language (DSL, such as
Gherkin) to express test cases.

● Written by Test Automation Engineers.


● Following guidelines usually applies to End to End tests:
○ Write as few as possible (specially UI tests, as they are the slowest type
of automated test).
○ Make tests data-independent.
● Two different entry points for End to End tests:
○ Web UI.
○ Public APIs (“headless End to End”, without the UI).
Testing types
Testing approaches

Approach Purpose Pros Cons

Black Tests what the software should do Unbiased Testing each/every input is
Box Based on the module’s definitions and User based unrealistic. Insufficient time. Many
specifications testing paths go untested
Does not care about the program’s Requirement Hard to evaluate how much has
internals validation been tested
Functional test, produced by data, inputs approach Suites grow fast. High maintenance
and outputs of automated tests
Test redundancy

White Tests what the software does Harder to validate requirements


Box Test cases are designed considering the Development skills needed
software’s internal structure Cannot detect absence of
functionality or misinterpretations

Positive Verifies the ability of the system to implement a solution to the business needs under normal
conditions

Negative Verifies the ability of the system to detect, document and resolve user errors or any other condition
not considered normal
Functional Testing Types

● Generally described within the functional requirements specification.


● Refers mostly to “what the system does”.
● These tests belong to the “Black Box” category.

Smoke testing: Refers to the first tests that are executed to provide quick
feedback to determine if system under test is stable and won’t fail drastically.

Sanity testing: Refers to the suite of tests that is executed to verify the main
functions of a system are working without errors to determine if it is
reasonable to continue with further (more detailed) tests.

Regression testing: Consist in testing a system after a modification has


taken place to verify that no new defects have been introduced or affected the
previous correct functionality
Non Functional Testing Types

● Tests system attributes that are not related to functionalities.


● May include:
○ Performance.
○ Stress.
○ Usability.
○ Disaster/Error Recovery.
○ Portability.
Practice

Practice
Practice

● Git
● Maven
● Junit
Exercise

Design the tests of Math Java library where the trainee tests the main functionality of the
library.

● Create a branch of each trainee. (


https://github.com/mauriparra/bootcamp-tae-bogota-2017)
● Use Maven as a builder.
● Use junit as a test framework.
● Commit the results in git branch.

You might also like