proceso de pruebas

Niveles de las pruebas o modelo en V

Test levels or V-model

Component tests: the components are tested separately (unit)
Integra on tests: integra ons are tested (front and back)
System tes ng: func onal tes ng (manual/automated)
Acceptance Tes ng: Customer Tes ng
ti
ti
ti
ti
ti
ti
ti
 Tes ng process:
Test planning.
Test design.
Implementa on or execu on of tests.
Evalua on of exit criteria.
Closing of the process.

Page Factory
The PageFactory pa ern is used, along with the Page Object
pa ern when implemen ng func onal tests to make the code
more maintainable and avoid wri ng code like:

De este modo, para hacer referencia a un elemento web, bastaría con importar:
•​
•​
•​
•​
•​
tt
ti
ti
ti
tt
ti
ti
ti
ti
 U lizar FindBy para tomar los elementos, así;

Inicializar esos elementos de la clase (u objeto de Page Object) con el PageFactory: (hay
que pasar el driver y la propia clase)

Y realizar operaciones sobre estos elementos en el método per nente de la siguiente

forma:

Tomado de: h ps://emerrefe.github.io/qa-blog/pagefactory-pa ern/

ti
tt
tt
ti
 Page Object Model (POM)

POM is a commonly used design pa ern in Selenium for test case

automa on, seeking to improve test maintainability and reduce
code duplica on. where web pages are represented by a
corresponding class and web elements are represented by class
variables and all interac ons are possible via the class's methods or
func ons.

The bene t is that if the UI changes for the page, the tests
themselves don't need to be changed, only the code inside the page
object needs to change, subsequently all the changes to support
that new UI are there. In one single place.

Advantages of the POM model:

According to POM we should keep our tests and element locators

separate, this will keep the code clean and easy to understand and
maintain.

The Page Object approach makes the test automa on framework

programmer friendly, more durable and comprehensive.

Another important advantage is that our page object repository is

independent of automa on tests. Keeping a separate repository for
page objects helps us to use this repository for di erent purposes
with di erent frameworks like, we can integrate this repository with
other tools like JUnit / NUnit / PhpUnit as well as TestNG /
Cucumber / etc.
ti
ff
ti
fi
ti
ti
ti
tt
ff
ti
 Test cases become short and streamlined.

Any changes to the user interface can be easily implemented,

updated, and maintained in the page's objects and classes.Tomado
de : h ps://www.geeksforgeeks.org/page-object-model-pom/

Tomado de: h ps://www.geeksforgeeks.org/page-object-model-pom/

tt
tt
 BDD

This refers to development directed by behaviors, BDD is not a

technique or a tes ng tool, but rather a development strategy that
ts very well in agile methodologies, since in these generally the
requirements are delivered such as HU's (User Stories) and also
focuses on preven ng defects instead of nding them in a
controlled environment.

What is proposed through behavior-driven development is the

de ni on of a common language for the business and the solving
team.

Taken from: h ps://www.pragma.com.co/academia/lecciones/

bdd-para-la-automa zacion-de-pruebas

TDD

TDD or Test-Driven Development (test-driven development) is a

programming prac ce that consists of rst wri ng the tests (usually
unitary), then wri ng the source code

that it passes the test sa sfactorily and, nally, con nuously

refactoring the built code.

This prac ce achieves, among other things: a more robust, safer,

more maintainable code and faster development.Tomado de:
h ps://www.paradigmadigital.com/dev/tdd-como-metodologia-de-
diseno-de-so ware/
fi
tt
fi
ti
ti
ft
tt
ti
ti
ti
ti
ti
ti
fi
fi
fi
ti
ti
 ATDD

It means that the whole team collabora vely discusses acceptance

criteria, with examples, and then divides them into a set of
acceptance tests.

The collabora ve discussions that occur to generate the acceptance

test are o en called the three friends, which represent the three
perspec ves of the client (what problem are we trying to solve?),
Development (how could we solve this problem?) And tests (what's
going on...).

These acceptance tests represent the user's point of view and act as
a form of requirements to describe how the system will work, in
addi on to serving as a way to verify that the system works as
intended. ATDD is closer to a process rather than an ac vity.

Taken from: h ps://www.agilealliance.org/glossary/atdd/

#q=~(in nite~false~ lters~(postType~(~'page~'post~'aa_book~'a_e
vent_session~'aa_experience_report~'aa_glossary~'aa_research_pa
per~'aa
ti
fi
ti
ft
ti
tt
fi
ti
ti
 Gherkin

It is a speci c domain language, readable by companies, created

especially for behavior descrip ons, currently Gherkin supports
more than 60 languages.

It gives you the ability to remove logical details from the tests.

Usually projects have two types of pro les:

Business pro les, who understand li le about technology, but know

a lot about return on investment, func onali es, requirements, etc.

Technological pro les, who know a lot about technology, but

usually know li le about the business.

There are environments where it is very important that there is a lot

of cohesion between those pro les, so it is vital to have a common
language that these two pro les understand, even that they
understand the machines.
fi
fi
tt
fi
fi
ti
fi
tt
fi
ti
ti
Elements that make up the structure

Tomado de: h ps://docs.behat.org/en/v2.5/guides/1.gherkin.html

tt
 Gherkin Impera ve

It refers to when we write each step to be performed in the user

interface

This type of scenario provides more details to the reader about the
steps to take to achieve a result, and is easier to automate because
the step does a single ac on, but creates very long scenarios, and is
sensi ve to changes in the interface, which is not desirable. This
type of scenario can be used where details are required to clearly
communicate how a feature works.

Example:

Scenario: Receive an email when you complete the registra on

form

Given that the user clicked on "Make new registra on"

When you complete the elds "Name", "Email", "Password"

And click on the "I accept the terms of the contract" eld
ti
ti
ti
fi
ti
fi
ti
 Then you receive an email con rming your new Declara ve mode of
registra on

Declara ve Gherkin

These steps are more complex to automate (each step is a set of

ac ons that must be automated), and we lose details of the data
used, but we get as a result short scenarios that talk about the
process and that are very robust if there are constant changes in
the interface.

Scenario: Receive an email when you complete the registra on

form

Given the user wants to make a new registra on

When you ll in the required elds

And accept the terms of the contract

Then you receive an email con rming your new account

ti
ti
ti
fi
fi
fi
fi
ti
ti
ti
 Recommenda on:

The recommenda on is to write in a more declara ve way for cases

that are well understood by all members of the team, and move to
a more impera ve mode in cases where there is some complex
func onality where understanding is li le or is concentrated in a
single person.

Cucumber

It is a tool to implement methodologies such as (BDD) or behavior-

based development, which allows you to execute func onal
descrip ons in plain text such as automated so ware tests.

These func onal descrip ons are wri en in Gherkin language which
is a domain-speci c language and readable by the business area.

Taken from: h ps://www.pragma.com.co/blog/junit-vs.-cucumber-

test-automa on-tools
ti
ti
ti
ti
tt
ti
ti
fi
ti
ti
tt
tt
ft
ti
ti
 FIRST Principle

FIRST is the acronym for the ve characteris cs that our unit tests
must have to be considered quality tests:

Fast (fast)

Run a large number of tests in a ma er of seconds.

Independent (independent)

No ma er how many unitary tests we have, they must all be

independent of the others.

Repeatable (repeatable)

The result of the tests must be the same regardless of the server on
which it runs. Tests should not have server dependencies, user
con gura on or execu on me.

Self-valida ng (self-evaluable)
fi
tt
ti
ti
ti
ti
fi
tt
ti
 One of the points in favor of automated tests is that we can execute
them simply by pressing a bu on or even make them run
automa cally a er another process.

Timely (opportune)

Tests must be developed before star ng to develop the applica on

code (TDD)

Taken from: h ps://www.paradigmadigital.com/dev/principio- rst-

aumentar-la-calidad-tests-unitarios/

INVEST Principle

Method to ensure the quality of HUs

Independent: the user's story must be self-explanatory, it must not

depend on other user stories.

Nego able (Nego able): avoid including too much detail, so that
user stories are exible and can be modi ed.
ti
ti
tt
ft
fl
ti
tt
ti
fi
fi
ti
 Valuable: user stories must provide some value to the end user.

Es mable: you must be able to es mate the resources necessary to

complete each user story.

Scalable: make user stories simple, so that they can be ordered and
priori zed.

Testable (Veri able): explains the veri ca on and approval criteria,

so that the team knows them and applies them when a story is
complete.

Smart Method

When we break down our user stories into tasks, we will use the
SMART method, a method that helps us evaluate whether our tasks
are correctly de ned.

SMART is the acronym for: S - Speci c, M - Measurable, A -

Achievable, R - Relevant, T - Time-boxed
ti
ti
fi
fi
ti
fi
fi
ti
 Speci c: A task must be speci c enough for everyone to understand
it.

Measurable (Measurable): Do you do what you want? It is the team

that must agree on what this means.

Achievable: Is the goal reasonable? Tip: It is good to set goals that

represent a challenge, but it may be counterproduc ve not to
achieve them.

Relevant (Relevant): Each task must be relevant, contribu ng to the

story in ques on.

Time-Boxed: A task must be limited to a speci c dura on. It should

not necessarily be a formal es mate in hours or days, but there
must be an expecta on so that people know when they should seek
help.

Taken from: h ps://www.beagilemyfriend.com/historias-de-

usuario-invest-smart/
fi
ti
tt
ti
fi
ti
fi
ti
ti
ti
 SOLID Principle

They are principles to develop quality so ware based on the

principles of object-oriented programming.

S: Single responsibility principle or Single responsibility principle

It establishes that a class, component or microservice must be

responsible for only one thing (the much-acclaimed term
"decoupled" in English). If, on the other hand, a class has several
responsibili es, this implies that the change in one responsibility
will cause the modi ca on in another responsibility.

O: Open/closed principle or Open/closed principle

It establishes that so ware en es (classes, libraries or

frameworks) should be open for extension, but closed for
modi ca on.

L: Liskov subs tu on principle or Liskov subs tu on principle

"Derived classes must be able to be replaced by their base classes."

fi
ti
ti
ti
ti
fi
ft
ti
ti
ti
ft
ti
ti
 This means that objects must be able to be replaced by instances of
their subtypes without altering the proper func oning of the
system or what is the same: if we use a certain class in a program,
we should be able to use any of its subclasses without interfering
with the func onality of the program.

I: Interface segrega on principle or Principle of segrega on of the

interface

"Make interfaces that are speci c to a type of customer," that is, for
a speci c purpose.

In this sense, according to the Interface Segrega on Principle (ISP),

it is preferable to have many interfaces that de ne few methods
than to have a forced interface to implement many methods that
will not be used.

D: Dependency investment principle or Dependency investment

principle

We come to the last principle: "It depends on abstrac ons, not on

speci c classes."
fi
fi
ti
ti
fi
fi
ti
ti
ti
ti
 So, Robert C. Mar n recommends:

High-level modules should not depend on low-level modules. Both

should depend on abstrac ons.

Abstrac ons should not depend on the details. The details should
depend on the abstrac ons.

The objec ve of the Dependency Inversion Principle (DIP) is to

reduce the dependencies between the modules of the code, that is,
to achieve a low coupling of the classes.

Taken from: h ps://enmilocalfunciona.io/principios-solid/ and

h ps://pro le.es/blog/principios-solid-desarrollo-so ware-calidad/
tt
ti
ti
fi
tt
ti
ti
ti
ft
 AAA pa ern

It is a way of wri ng unitary tests.

The AAA structure is generally followed because it is easy to read

and understand.

Arrange: It is the part of the Unitary Test where all the code is
con gured to run the unitary test, we declare the variables and
create the instance of the objects of the classes.

Act (Law): This is the phase of the Unit Test where the code to be
tested is executed, where the method we are tes ng (verifying) is
called. In this sec on, it is where the input parameters are passed
to the method and where the result returned by the method is
collected.

Assert (A rm): In this part compare the actual result of the call
with the expected result. The test is passed or not depends on this
part of the statement. Usually, the Assert class is used for this
opera on.
fi
ti
tt
ffi
ti
ti
ti
 Taken from: h p://joaquin.medina.name/web2008/documentos/
informa ca/documentacion/visualEstudio/PruebasUnitarias/
2017_04_19_PruebasUnitarias_EstructuraDeCodigo.html

Object-oriented programming - POO

In short, object-oriented programming is a programming paradigm

that uses the a ributes and interac ons of objects to create
applica ons and is based on the principles of the OOP.

Class

It is a template or mold to create objects.

Objects

It is an en ty provided with a set of proper es or a ributes (data)

and behaviors (methods)

It's an instance to a class

ti
ti
ti
tt
tt
ti
ti
tt
 Characteris cs of object-oriented programming

Abstrac on:

Process of capturing the fundamental details of an object such as its

characteris cs and behaviors.

Encapsula on:

It is the process of hiding all the details of an object that do not

contribute to its essen al characteris cs.

Polymorphism:

Di erent behaviors, associated with di erent objects, can share the

same name

Inheritance:

It is the process by which an object acquires the proper es and

behaviors of another object.
ff
ti
ti
ti
ti
ti
ti
ff
ti
 Access modi ers:

They help to restrict the scope of a class, constructor, variable,

method or data member.

Default - No keyword required

When no access modi er is speci ed for a class, method or data

member, it is said to have a default access modi er by default.

Members of data, class or methods that are not declared using any
access modi er, that is, that have a default access modi er, are only
accessible within the same package.
fi
fi
fi
fi
fi
fi
 Private

The private access modi er is speci ed with the private keyword.

The declared methods or data members…

h ps://www.federico-toledo.com/en-que-nivel-conviene-automa zar/
tt
fi
fi
ti
 Xpath
It is a syntax or language to nd any element on the web page using the XML path expression and
the HTML DOM structure.

o //: selecciona el nodo actual.

• Nombre de e queta: Nombre de e queta del nodo par cular.
• @: Seleccionar atributo.
• Atributo: nombre del atributo del nodo.
• Valor: valor del atributo.

Localizadores en el orden en que se recomienda su uso:

Localizador Descripción
ID Este es el primer localizador que debemos tratar de u lizar pues la mayoría de las
veces iden can de forma única al elemento.
Name Este localizador es el segundo que debemos tratar de u lizar en caso de que no
tengamos un id. Usualmente los nombres de los elementos son únicos y nos
permiten ubicar un elemento con facilidad.
Class Nombre de la clase de elemento.
TagName Este localizador busca por el nombre del tag del elemento dentro del
DOM(Document Object Model)
LinkText Este localizador busca links en la página donde el texto coincida con el parámetro
que le pasamos al método linkText ().
CssSelector Este localizador, es en sí una estrategia de localización que u liza el lenguaje CSS
(Cascade Style Sheet) para elementos que no enen ID, nombre o clase.
Xpath Se requiere XPath para encontrar el elemento dinámico y atravesar entre varios
elementos de la página web
ti
fi
ti
fi
ti
ti
ti
ti
ti
ti
 Tipos de Xpath

1. Xpath absoluto

Es la forma directa de encontrar el elemento, sin embargo, la desventaja del XPath

absoluto es que, si se realizan cambios en la ruta del elemento, entonces el XPath falla.
La caracterís ca clave de XPath es que comienza con una barra diagonal (/), lo que signi ca
que puede seleccionar el elemento desde el nodo raíz.

Ejemplo:

2. Xpath rela vo:

Para Xpath rela vo, la ruta comienza desde el medio de la estructura HTML
DOM. Comienza con la barra diagonal doble (//), lo que signi ca que puede buscar el
elemento en cualquier lugar de la página web.
Puede comenzar desde la mitad de la estructura HTML DOM y no es necesario escribir
xpath largo.

Ejemplo
ti
ti
ti
fi
fi
 Tomado de: h ps://www.guru99.com/xpath-selenium.html
tt