INSTITUTO TECNOLOGICO

Ensayo:
Testing para dummies

Ing. En Sistemas
1
 Introducción
Esta presentación nos habla principalmente de todo lo que un tester debe de
conocer, las características que debe de cumplir, cuáles son sus funciones, lo que
no debe de hacer. Las etapas, niveles de prueba y tipos de prueba que se deben
realizar, además de las metodologías, técnicas, estrategias en las que se puede
apoyar para realizar unas verdaderas pruebas para que así el producto final tenga
el mas mínimo numero de errores o lo que es casi imposible que no los tenga para
así asegurar la calidad y eficiencia del producto final que se entregara al cliente.

Contenido
Para la realización de un proyecto siempre es necesario tener bien organizado tu
equipo de trabajo, en el video nos muestra que un equipo para desarrollar un
software debe estar compuesto de:

 Un líder de proyecto
 Un arquitecto o líder técnico
 Un DBA (opcional)
 Tres desarrolladores
 Un tester
 Un documentador

Para la selección del tester del proyecto se deben tomar en cuenta bastantes puntos
como lo son:

 Disponibilidad.
Que tenga el tiempo necesario para hacer las pruebas del proyecto.
 Experiencia en el dominio
Dependiendo para lo que se requiera el proyecto, por ejemplo, algún hospital
o escuela.
 Costo
Pagar por lo que el tester sabe hacer, no siempre por lo que el pide.
 Perfil
Sus actitudes y técnicas con las que realiza las pruebas.
 Uso de técnicas y herramientas
Que sepa manejar muy bien sus técnicas y diferentes herramientas, además
que verifique el proyecto por completo.
 Uso de metodologías
Su manera de trabajar.
 Certificaciones
Que tenga un respaldo de que es verdaderamente bueno.

2
Testing no es lo mismo que asegurar la calidad ya que el testing se basa
principalmente a realizar las pruebas de un producto y asegurar la calidad va a lo
que es el proceso su relación si nos lleva a tener un buen proyecto.

Existen diferentes ciclos de vida de proyectos cada quien se basa en el que mejor
le conviene las metodologías más utilizadas para realizar las pruebas son el modelo
v y el modelo w. El modelo en v se debe de aplicarse desde el principio haciendo
una verificación y validación en cada etapa del ciclo de vida. Lo que es el modelo
en w es una variación del modelo en v donde el usuario interviene en algunas
etapas.

Para la realización de pruebas existe un proceso estándar con las etapas de:

Planificación Análisis y Ejecución Reporte

diseño de Cierre de
de pruebas de de
pruebas pruebas
pruebas pruebas

Las cuales se pueden realizar de forma iterativa o en cascada.

 La planificación de pruebas. Se basa en las estrategias con la que aremos

las pruebas, como que es lo que se va hacer, como se va a hacer, el tiempo
que se tardara, etc. Este plan se debe de ir actualizando.
 Análisis y Diseño de pruebas. Aquí entran los requerimientos funcionales y
no funcionales, además de diseñar como se probara el sistema.
 Ejecución de pruebas. Ya necesitamos el producto para hacerle las pruebas,
para generar lo que es el reporte de pruebas.
 Reporte de pruebas. Es la etapa donde se reportan los errores y que mejor
hacerlo con un análisis del impacto que produce cada uno de ellos. De aquí
se puede regresar al plan de pruebas e ir repitiendo el proceso hasta que ya
no sean mínimos los errores.
 Cierre de pruebas. Se analizan los errores para ya no volver a cometerlos y
reducir los riesgos en futuros proyectos.

Las pruebas se pueden realizar en distintos niveles de pruebas:

 Unitarias
Esta se basa en revisar las partes del código.
 Modulares
Como por ejemplo revisar el sistema pantalla por pantalla
independientemente.

3
  Integración
Se prueba la comunicación entre los módulos que van ligados. Como probar
que no tenga caracteres en blanco, que los datos tengan las longitudes
necesarias, que en el nombre no acepte números, etc.
 Integrales(De Sistema)
Probar ya funcionando el sistema con datos del negocio.
 UAT( Aceptación )
Que el usuario Pruebe y acepte que el sistema cumple con lo establecido.

Hay muchos tipos de pruebas que se requieren hacer como lo son las de Cobertura
de condiciones, Cobertura de condiciones múltiples, Componente, Funcionales,
Usabilidad, Mantenibilidad, Administración y Manejo de errores, Comportamiento,
Integrales, De convivencia, Migración, Instalación, Regresión, Humo, Persistencia
de datos, Disponibilidad, Respaldo y Recuperación, Stress, Carga, Seguridad y
algunas más.

Estas se podrían separar en lo que son pruebas funcionales y no funcionales. Las

pruebas no funcionales son la disponibilidad, mantenibilidad, usabilidad, eficiencia
y en las pruebas funcionales básicamente es lo que el sistema tiene que hacer. Las
cobertura de condiciones, cobertura de condiciones múltiples y prueba a
componente son técnicas de caja blanca. La documentación es muy importante para
dar mantenimiento. Documentar y manejar errores con algunos mensajes de alerta.
La convivencia como nuevos sistemas comunicándose con sistemas anteriores. La
migración cuando un sistema es diseñado para funcionar en alguna versión y en
nuevas versiones que sean compatibles. Las pruebas de humo sirven para dar un
diagnostico si en verdad vale la pena probar el sistema, ya que si el sistema no pasa
una prueba básica no tiene caso hacer pruebas mayores. La persistencia se basa
en que los datos estén bien guardados en lo que es la base de datos para que estos
persistan. La de stress que es la que mide el número de peticiones o usuarios que
estén utilizando el sistema simultáneamente. La de carga que es el volumen que
tenemos para almacenar en la base de datos.

Las pruebas de regresión son muy importantes en el proyecto ya que cuando

tenemos el proyecto terminado y queremos agregar un nuevo módulo esta prueba
nos ayuda a verificar que estos nuevas funcionalidades no afecten a lo que ya
teníamos funcionando correctamente. Además de las pruebas de respaldo y
recuperación que cuando exista algún desastre como se podrá recuperar el sistema.

4
Existen varias técnicas y estrategias para hacer las pruebas y estas también se
dividen en funcionales y no funcionales

Funcionales

 Todos los pares (Pairwise)

 Particiones equivalentes (Clases equivalentes)
No hacer todas las pruebas porque no terminarías solo hacer pruebas con
ciertos valores que cumplan con los atributos que se desean probar.
 Valores en la frontera (Valores al límite)
Meter datos mayores al límite para probar que estos valores marquen
errores.
 Tablas de decisiones
 Transición de estados

No Funcionales

 Pruebas de sentencias y Cobertura

 Pruebas de decisión y Cobertura
 Heurísticas
 Revisión por pares
Estas van orientadas a todo el proceso de pruebas
 Top-Down
Pruebas de arriba hacia abajo.
 Button up
Pruebas de abajo hacia arriba.
 Big bang
Estas no tienen un orden pueden ir de abajo hacia arriba como de arriba
hacia abajo o como nos dijo nuestra profesora se puede probar todo el
sistema junto.

La utilización de algunas herramientas para facilitar hacer las pruebas en las

diferentes etapas.

 Diseño y Ejecución de pruebas: Enterprise tester, Quality Center.

 Registro y Seguimiento de incidentes: Atlassian.
 Integración continua y Calidad del código: Jenkins, sonar.
 Profiling y Depuration: Jmelody, Jmeter, Webload, Fiddler.
 Automatización: Selenium
 Seguridad.
 Simulación o Análisis estático: Oracle Crystal ball, Minitab.

5
 Por ultimo para reportar los errores al líder del proyecto no solo se deben de
tomar en cuenta lo que son las métricas sino llegar un poco más a fondo
basándonos en:
 Eficiencia en la corrección de defectos
Se deben organizar los defectos dependiendo lo fuertes que sean.
 Volatilidad del producto
De qué manera van cambiando los requerimientos del producto y por lo
tanto ir cambiando las pruebas.
 Complejidad del producto KLOC y Complejidad ciclomatica MacCabe
Esta complejidad de puede probar de varias maneras, una por líneas de
código o por puntos de función.
 Cobertura de pruebas entre el tamaño total del sistema
Las coberturas de pruebas podrían ser por líneas de código probadas,
por puntos de función probados o por casos de usos probados.
 Suficiencia de pruebas
Hasta cuando es suficiente hacer pruebas.
 Densidad de defectos
El volumen en el que se dan los defectos.
 Índice de severidad de defectos
Medir el daño que causa cada defecto.

Conclusión
Como conclusión me queda que el trabajo de un tester no es fácil ya que este debe
probar todo lo que hicieron todos los demás encargados del proyecto para verificar
si estos hicieron bien su trabajo, este se relaciona con todas las etapas del ciclo de
vida del proyecto. Además que no se debe de tomar a cualquier persona como tester
este debe de tener experiencia en el ámbito del proyecto que se llevara a cabo y
por otro lado cumplir con una serie de características. El trabajo de un tester en el
proyecto es demasiado importante ya que este es el que encuentra los errores para
entregar un buen producto, debe de tener todo documentado y entregar su trabajo
de la mejor manera, tomando en cuenta todos los defectos encontrados y el daño
que causa cada uno de ellos en el proyecto, para así cuando se termine el sistema
se pueda tener la seguridad de que el cliente estará satisfecho con el trabajo
realizado.