ISTQB – Cap 1 – Fundamentos del Testing – II

Siguiendo con la secuencia de entradas (Cap1-Parte I) sobre la certificación ISTQB, les dejo la parte II del capitulo 1.

Principios del Testing

Principio 1 – El Testing demuestra la presencia de errores .

Mediante el testing podemos demostrar la presencia de errores, pero no la ausencia de los mismos.  Incluso si no se detectan deficiencias, no es una prueba de la corrección.

Este principio se deriva de la teoría del proceso de la experimentación científica [Popper] y ha sido adoptado por los testers. La analogía utilizada en la ciencia es útil para explicar este principio, no importa la cantidad de cisnes blancos que vemos, no podemos decir ’todos los cisnes son blancos” . Sin embargo, tan pronto como vemos un cisne negro, podemos decir ’No todos los cisnes son blancos”. De la misma manera, sin embargo, que muchas pruebas se hayan ejecutado sin encontrar un error, no demuestra que “No hay errores”. Tan pronto como nos encontramos con un error, se ha mostrado ’Este código no está libre de errores”.

ISTQB – Cap 1 – Fundamentos del Testing – I

En esta nueva entrada vamos a arrancar con una serie de posts acerca de la certificación ISTQB. En esta entrada vamos a ver los dos primeros puntos del fundamento del testing (¿Porque es necesario el testing?; ¿Que es testing?), por una cuestión de limitación de contenido de los posts .

¿Porque es necesario el Testing?

Vamos a ir desglosando el porque es necesario desde distintos puntos de vista:

Si miramos el contexto de los sistemas hoy

• Por la importancia económica del software

• El funcionamiento de maquinaria y equipamiento depende en gran medida del software
• No es posible imaginar grandes sistemas, en el ámbito de las finanzas ni el control del trafico automotor, entre otros, funcionando sin software.

Por la calidad del Software

• Cada vez más, la calidad software se ha convertido en un factor determinante del éxito de sistemas y productos técnicos o comerciales

• Por las pruebas para la mejora de la calidad

• Las pruebas y revisiones aseguran la mejora de la calidad de productos de software así como de la calidad del proceso de desarrollo en sí.

• Por los riesgos

• No todos el software tiene el mismo nivel de riesgo y no todos los problemas tienen el mismo impacto cuando ocurren.

Si miramos porque fallan los sistemas

Todos sabemos que las personas cometemos errores, ahora ¿Como inciden estos errores en los sistemas?.

Vamos a definir un  Error (IEEE 610) como: Acción humana que produce un resultado incorrecto. Ej. Un error de programación.

Este ‘Error’ va a producir un Defecto (defect, bug) en el software: Desperfecto en un componente o sistema que puede causar que el componente o sistema falle en desempeñar las funciones requeridas, por ejemplo una sentencia o una definición de datos incorrecta.

Si se localiza un defecto durante una ejecución puede causar un fallo en el componente o sistema. Fallo (Failure) es la manifestación física o funcional de un defecto. Si un defecto es encontrado durante la ejecución de una aplicación puede producir un fallo. Es la desviación de un componente o sistema respecto de la prestación, servicios o resultado esperado.

Un error introduce un defecto, un defecto causa un fallo.

¿Como es el proceso de testing en Google?

Me parece muy interesante la seguidilla de posts que realizo James Whittaker sobre como Google lleva adelante el proceso de testing sobre sus productos y me pareció que estaría bueno compartirlo con ustedes:

• Parte 1
• Parte 2
• Parte 3
• Parte 4
• Parte 5

Entre las distintas entregas tome distintos fragmentos que me parecieron más que interesantes ya que son temáticas que siempre están en discusión en toda charla sobre Software Testing y tener una referencia de como Google resuelve esos temas:

En cuanto a procesos:

Yes, that’s right: at Google it’s the product teams that own quality, not testers.

Developers can’t test! Well, who am I to deny that? No amount of corporate kool-aid could get me to deny it.

The important thing is that Google testers share a common language to talk about what is getting tested and how those tests are scoped.

These engineers often identify themselves as testers but their actual mission is one of productivity. They exist to make developers more productive and quality is a large part of that productivity.

Quality is not equal to test; it is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other.

This means that quality is more an act of prevention than it is detection. Quality is a development issue, not a testing issue.

En cuanto al Testing automatizado:

If it can be automated and the problem doesn’t require human cleverness and intuition, then it should be automated.

The ongoing effort to automate to within the “last inch of the human mind” is currently the design spec for the next generation of test engineering tools Google is building.

Espero que la información compartida por James les sea tan interesante a uds. como fue para mi.

Material Webinar Selenium 2

Para aquellos que vieron el post sobre el webinar tarde y no pudieron concurrir, para aquellos que no les interesaba el webinar pero quieren saber un poco más de que se trata Selenium 2 y para todos, les dejo los links del material sobre el webinar para que puedan ver el webinar, ver la presentación, bajarse el código de ejemplo y leer la documentación sobre Selenium 2

Espero que les sea útil!

Webinar de Selenium 2

La gente de SuceLabs esta brindando un Webinar sobre Selenium 2 el próximo 16 de Febrero a las 15 hs.  Esta bueno aprovechar la oportunidad ya que es gratis y será dictado por Jason Huggins (Creador de Selenium y Co-Fundador de SauceLabs)

¿Sobre que se trata?

Para Desarrolladores o Testers que sienten curiosidad sobre Selenium 2 y quieran aprender como Selenium 2 puede acelerar sus tareas de desarrollo.

Los temas que se van a tratar:

• Testing sobre Iphone y Android
• API simplificada para usuarios IDE
• Escalabilidad y arquitectura  mejorada

¿Como me registro?

Para registrarse deben ingresar sus datos en esta web.

 

 

 

¿Porque realizar Testing?

Este tema surgió de una pregunta realizada en el foro QALatinoamérica donde se solicita información estadística sobre la justificación de la implementación de las pruebas de software en el proceso de desarrollo de software.

Desde mi punto de vista la justificación del proceso de pruebas se basa en dos partes:

Justificación social y propagandística

Existen altas exigencias por parte de los clientes para poder implementar en producción el software que adquieren. Hoy en día el software acapara gran parte de las actividades diarias de las personas y pueden llegar a manejar desde grandes sumas de dinero hasta vidas de personas. Desde que nos levantamos hasta que nos acostamos estamos en continua relación con aplicaciones software ya sea mientras miramos televisión, compramos en el supermercado, hablamos por teléfono, etc…