www.cognity.

org

CALIDAD EN DESARROLLO DE SOFTWARE

FOUNDATION

ING. JOEL VÁSQUEZ VILLALOBOS.

MARZO 2018
CÓDIGO TI-QA
 https://www.linkedin.com/in/jvasquezv/
jvasquezv@gescom.com.pe
vasquezader@gmail.com
989914462

Arquitecto Web y Móvil con experiencia en DevOps, mejora y optimización de soluciones

web de alto tráfico; gestión de proyectos con Scrum en equipo multidisciplinario.
2’5 millones 1 millón
SUMINISTROS PROCESADOS FOTOS MENSUALES
20 millones 10 Servidores
TRANSACCIONES MENSUALES EN LA NIBE

SIGOF
ACSION
 CALIDAD Y EL TESTING
- Característica que nos permite comparar distintas cosas del mismo tipo. Se define, o se calcula, o se le asigna un
valor, en base a un conjunto de propiedades (seguridad, performance, usabilidad, etc.).

- La calidad es valor para una persona a la que le interesa.

Falacia del Nirvana

- El objetivo del testing es aportar calidad.

¿Se trata de encontrar la mayor cantidad de fallos posible?

¡NO! La idea es encontrar la mayor cantidad de fallos que más calidad le aporten al producto. O sea, los que al
cliente más le van a molestar.

CÓDIGO TI-QA
 TÉCNICAS DE DISEÑO DE CASOS DE PRUEBA

CÓDIGO TI-QA
 EJEMPLO: PRUEBAS DE CAJA NEGRA
Envió de correo electrónico al registrarse una transacción.

Descripción del caso: El sistema enviará un correo electrónico cuando se registre alguna de las
siguientes transacciones: pedido de venta de cliente, despacho de mercancía al cliente.

Caso 1.1: Datos de entrada: Registrar pedido de venta. Resultado esperado (Salida): El sistema envía
un correo electrónico al cliente como constancia que su pedido se ha recibido.

Caso 1.2: Datos de entrada: Registrar despacho de mercancía al cliente. Resultado esperado (Salida):
El sistema envía un correo electrónico al cliente como constancia que se ha realizado el despacho.

CÓDIGO TI-QA
 EJEMPLO: PRUEBAS DE CAJA NEGRA
Campo de texto que solo acepta caracteres alfabéticos.

Descripción del caso: Se tiene un campo de texto que solo acepta caracteres alfabéticos. La longitud del
valor ingresado debe estar entre 6 y 10 caracteres.

Caso 3.1: Datos de entrada: cadena de 5 caracteres. Resultado esperado (Salida): La aplicación no permite
el ingreso del dato y muestra un mensaje de error.

Caso 3.2: Datos de entrada: cadena de 7 caracteres, solo de caracteres alfabéticos. Resultado esperado
(Salida): La aplicación permite el ingreso del dato.

Caso 3.3: Datos de entrada: cadena de 11 caracteres. Resultado esperado (Salida): La aplicación no permite
el ingreso del dato y muestra un mensaje de error.

CÓDIGO TI-QA
 EJEMPLO: PRUEBAS DE CAJA BLANCA
Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o
pruebas estructurales) se centran en los detalles procedimentales del software, por lo
que su diseño está fuertemente ligado al código fuente.

CÓDIGO TI-QA
 AMBIENTES DE PRUEBA

CÓDIGO TI-QA
 Agile Testing
Agile Testing es una práctica de pruebas de software que sigue los principios del desarrollo ágil de software.

Agile Testing, incorpora una serie prácticas:

- Integración continua.

- Testing guiado por pruebas (Test Driven Development – TDD)

- Desarrollo guiado por comportamiento (Behaviour Driven

Development – BDD)

- Automatización de pruebas unitarias.

CÓDIGO TI-QA
 DESARROLLO CONDUCIDO POR PRUEBAS - TDD

TDD es una técnica que cambia el orden establecido en

cuanto a primero desarrollar (programar) y luego probar,
de manera que primero se define las pruebas (casos de
prueba) y a partir de estos se va desarrollando la
funcionalidad, repitiendo el ciclo.

CÓDIGO TI-QA
 DESARROLLO CONDUCIDO POR PRUEBAS - TDD
Pruebas Unitarias y de Integración.

Junit DBUnit HttpUnit y HTMLUnit Mockito

Pruebas Funcionales Web Services y APIs

Selenium Web Driver SoapUI Postman Wizdler

Pruebas de Rendimiento

JMeter

CÓDIGO TI-QA
 DESARROLLO CONDUCIDO POR COMPORTAMIENTO - BDD

- Un equipo que utilice BDD debería ser capaz de proporcionar una parte importante de la
"documentación funcional" en forma de Historias de usuarios aumentadas con escenarios
ejecutables.

- BDD busca un lenguaje común para unir la parte técnica y la de negocio, y que sea
desde ese lenguaje común desde donde arranque el Testing y, desde ahí, el desarrollo.

Gherkin es un lenguaje entendible por el negocio o lenguaje natural.

Dado [contexto inicial], cuando [se produce el evento], entonces [resultados]

Given [initial context], when [event occurs], then [ensure some outcomes].

CÓDIGO TI-QA
 DESARROLLO CONDUCIDO POR COMPORTAMIENTO - BDD

CÓDIGO TI-QA
 DevOps – OPERACIONES DE DESARROLLO
- Práctica de ingeniería de software que tiene como objetivo unificar el desarrollo de software (Dev)
y la operación del software (Ops).

Objetivos
Los objetivos de DevOps abarcan todo el proceso de entrega. Incluyen:

•Frecuencia de despliegue mejorada.

•Llegada al mercado más rápida.

•Baja tasa de errores de nuevas versiones

•Tiempo de entrega más corto entre parches.

•Tiempo de recuperación más rápido (en caso de que una nueva versión
falle).

CÓDIGO TI-QA
 DevOps – PRÁCTICAS DE OPERACIONES DE DESARROLLO

Administración de la configuración.

CÓDIGO TI-QA
 DevOps – OPERACIONES DE DESARROLLO

http://blog.getpostman.com/2014/05/09/writing-automated-tests-with-postman-part-3/

CÓDIGO TI-QA
 DevOps Tools
Analizadores estáticos de código
https://sonarwhal.com/scanner/
https://www.sonarqube.org/
Monitorización
https://www.site24x7.com/es/index.html
https://www.pingdom.com/
https://grafana.com/
https://www.nagios.org/
https://www.zabbix.com/
https://sensuapp.org/
https://newrelic.com/
https://www.loggly.com/
https://www.sumologic.com/
https://www.splunk.com
https://www.elastic.co/products/logstash
Servidor de automatización
https://jenkins.io/
https://es.atlassian.com/software/bamboo
https://travis-ci.org/
https://www.jetbrains.com/teamcity/
https://circleci.com/
CÓDIGO TI-QA
Testing
https://phpunit.de/
https://docs.pytest.org/en/latest/index.html
https://www.getpostman.com/
https://github.com/postmanlabs/newman
http://gettaurus.org/
https://gatling.io/
https://www.blazemeter.com
http://jmeter.apache.org/
https://chrome.google.com/webstore/detail/blazemeter-
the-load-
testi/mbopgmdnpcbohhpnfglgohlbhfongabi/related
http://www.seleniumhq.org/
BDD Frameworks
https://cucumber.io/
http://behat.org/en/latest/index.html
http://codeception.com/quickstart
Configuration management tools
https://www.ansible.com
https://galaxy.ansible.com/
https://puppet.com
https://www.chef.io
https://saltstack.com/
https://cfengine.com/
Contenedores y virtualización
https://www.docker.com
https://www.vagrantup.com
 FALACIA DE MÁS FIERRO
Cuántas veces habremos oído que las pruebas de performance no son necesarias, pues si se detectan problemas de
rendimiento en producción lo podemos resolver simplemente agregando “más fierros”, o sea, incrementando el
hardware, ya sea agregando servidores, agregando memoria, etc. Piensen en el caso de un memory leak, si se
agrega más memoria, tal vez logramos que el servidor esté activo durante 5 horas en lugar de 3, pero el problema no
lo resolvemos así. Tampoco tiene sentido aumentar los costos en infraestructura si se puede ser más eficiente con
lo que tenemos y así reducir costos fijos y costos a largo plazo, incluyendo la energía eléctrica que se necesita para
tener más servidores y consumiendo más ciclos de CPU.

CÓDIGO TI-QA
 FALACIAS DE ENTORNO DE PRUEBAS
Relacionado también a “los fierros” tenemos esta otra falacia, en la que se afirma que podemos realizar
las pruebas en el entorno de testing, sin importar qué tanto se parece este al entorno de producción. O
quizá, para un cliente hicimos las pruebas en Windows, y creemos que la aplicación funcionará
perfectamente en otro cliente que instalará el sistema bajo Linux. Al hacer las pruebas tenemos que ser
cuidadosos de hacerlo sobre un entorno que sea lo más parecido al de producción. Hay muchos
elementos del entorno que influyen en la performance de un sistema, desde los componentes de
hardware, las configuraciones del sistema operativo o cualquiera de los componentes con los que
interactúe, e incluso el resto de las aplicaciones que estén ejecutando al mismo tiempo. De igual forma
podemos pensar sobre la base de datos. Hay quienes creen que se puede realizar una prueba de
performance con una base de datos de pruebas. Si tenemos problemas con las consultas SQL quizá
pasen desapercibidos, pero si luego en producción tenemos una base de datos con miles de registros,
seguramente los tiempos de respuesta de SQLs que no están optimizadas nos den grandes problemas.

CÓDIGO TI-QA
 GRACIAS.

CÓDIGO TI-QA