How to be a good tester?

It’s a every testers question. How to be a good tester? Apart from the technical knowledge, testing skills, tester should have some personal level skills which will help them to build a good rapport in the testing team.
What are these abilities , skills which make a tester as a good tester? Well, I was reading Dave Whalen’s article “Ugly Baby Syndrome!” and found it very interesting. Dave compared software developers with the parents who deliver a baby (software) with countless efforts. Naturally the product managers, architectures, developers spent their countless time on developing application for the customer. Then they show it to us (testers) and asks: “ How is the baby (Application)? “ And testers tell them often that they have and ugly baby. (Application with Bugs!)
Testers don’t want to tell them that they have ugly baby, but unfortunately its our job. So effectively tester can convey the message to the developers without hurting them. How can be this done? Ya that is the skill of a good tester!
Here are the tips sated by Dave to handle such a delicate situation:
Be honest and Responsive:
Tell developers what are your plans to attack their application.
Be open and available:
If any dev ask you to have a look at the application developed by him before the release, then politely give feedback on it and report any extra efforts needed. Don’t log the bug’s for these notes.
Let them review your tests:
If you have designed or wrote some test cases from the requirement specifications then just show them those test cases. Let them know your stuff as you are going to critic on developers work!
Use of Bug tracker:
Some testers have habit to report each and everything publicly. This attitude hurts the developers. So if you have logged any bug then let the bug tracking system report it to respective developers and managers. Also don’t each time rely on bug tracker, talk personally to developers what you logged and why you logged?
Finally some good personal points:
Don’t take it personally:
Do the job of messenger. You could be a close target always. So build a thick skin!

Be prepared:
A good message in the end, Be prepared for everything! If worst things might not happened till now but they can happen at any moment in your career. So be ready to face them.
[Thougt of the Day: When a virtually flawless application is delivered to a customer, no one says how well tested it was. Development teams will always get the credit. However, if it is delivered with bugs, everyone will wonder who tested it! - - Dave Whalen]


http://www.softwaretestinghelp.com/how-to-be-a-good-tester/

COTS

Commercial Off The Shelf ( COTS )

En los últimos años se ha visto un aumento en el uso de componentes comerciales en prácticas de reutilización de software. Concretamente, estos componentes comerciales comúnmente conocidos con el nombre de COTS ( Commercial Off The Shelf ) están siendo considerados con  mayor frecuencia para la construcción de sistemas complejos, distribuidos y abiertos.

Para la elaboración de estos sistemas los ingenieros utilizan metodologías, procesos y técnicas de desarrollo basados en componentes (DSBC).

Los componentes de COTS se construyen mediante la integración a una gran escala de componentes adquiridos a terceras partes. Estas actividades de desarrollo afectan tanto a la organización encargada de hacer la adquisición como a la organización encargada de los componentes COTS.  

http://xherrera334.blogspot.es/1193625420/

Desarrollo de Software Basado en Componentes

El desarrollo de software basado en componentes es (DSBC), es un modelo que:

• Describe
• Construye
• Utiliza

Técnicas de software para  la elaboración de sistemas abiertos y distribuidos mediante el ensamblaje de de partes de software reutilizables.

El DSBC es utilizado para reducir los costos, tiempos y esfuerzos en el desarrollo de software, a la vez que ayuda a mejorar: 

• La fiabilidad
• La  flexibilidad
• La reutilización

Ingeniería de Software Basada en componentes

Una práctica generalizada en un proyecto de software es utilizar partes de software ya desarrolladas en proyectos previos o adquiridos a terceras personas. La mayoría de desarrolladores de software utilizan métodos mal organizados que conducen en la mayoría de los casos a aplicaciones mal construidas, retrasos en los plazos de finalización del proyecto y un aumento en el costo final de del desarrollo.

Esto se debe a la falta de procesos y técnicas bien definidas que guíen a los desarrolladores de software durante la construcción de una aplicación basada en la reutilización.

El desarrollo de software ideal se debería concebir con la idea de reutilización de componentes y debería ser visto como fases en la resolución de un problema planteado.

Etapas del DSBC y Tecnología de Componentes

 Básicamente se describe mediante las siguientes etapas: 

1. Análisis. 
2. Diseño. 
3. Implementación. 
4. Mantenimiento.

Fuente: http://xherrera334.blogspot.es/1193625420/

Modelo de prototipos

El modelo de prototipos o de prototipaje previo a su desarrollo debe considerar las siguientes partes fundamentales:

• La definición de los objetivos globales para el software.
• Identificar los requisitos conocidos.
• Identificar las áreas del esquema del software en donde sea necesaria una mayor definición.
  

El siguiente esquema represente el proceso que sigue este modelo:

 

Su diseño es rápido y se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida).

Ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos y ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

La clave de su éxito esta en definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:

• Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos
• Que el prototipo se descarte, o al menos en parte.
• Que después se desarrolle el software real con un enfoque hacia la calidad

Cabe resaltar que este modelo solamente es útil cuando tanto el cliente como el desarrollador conocen los objetivos y las necesidades generales para el software.

Modelo Espiral

 Modelo en Espiral

Desarrollado por B. Boehm, básicamente, la idea es Desarrollo Evolutivo, usando el Modelo de Cascada para cada etapa. Está orientado a evitar riesgos de trabajo. 

No define en detalle el sistema completo a la primera. Los desarrollares deberían solamente definir las mas altas prioridades.

El Modelo Espiral mejora el Modelo de Cascada enfatizando la naturaleza iterativa del proceso de diseño. Eso introduce un ciclo de prototipo iterativo. En cada iteración, las nuevas expresiones que son obtenidas transformando otras dadas son examinadas para ver si representan progresos hacia el objetivo.

El proceso se representa como una espiral más que como una secuencia de actividades con vuelta hacia atrás  Es decir: cada iteración integra el resultado anterior. Cada vuelta en la espiral representa una fase del proceso. Cada fase supone un avance en el proceso de desarrollo

No hay “etapas” fijas tradicionales, ligadas a actividades como la especificación o diseño. Cada vuelta en la espiral determina las actividades a realizar.

 Presentación sobre el modelo en espiral Permalink

http://xherrera334.blogspot.es/1193195700/modelos-de-desarrollo-de-software/

Modelo en Cascada

Modelo en Cascada

            El más conocido, esta basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades:

 

Ingeniería y Análisis del Sistema: debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.

Análisis de los requisitos del software: el proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (Analistas) debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas.

Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación.

Codificación: el diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente.

Prueba: una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.

Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.

Desventajas: 

• Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicación del paradigma. 

• Normalmente, es difícil para el cliente establecer explícitamente al principio  todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos. 

• El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará disponible una versión operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.

Ventaja:

La ventaja de este método radica en su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.

http://xherrera334.blogspot.es/1192588380/resumen/ 

Modelo Iterativo Incremental

El modelo iterativo incremental combina elementos del modelo cascada (aplicado repetidamente) así como la filosofia iterativa del prototipado.

La parte inicial es el nucleo del producto (es la parte más importante).

Una nueva version del producto surge cuando nuevas características han sido implementadas a medida que han sido sugeridas por el usuario.

Este modelo es aplicable cuando es dificil establecer los requisitos iniciales de un proyecto y es más apropiado para proyectos pequeños.

Las nuevas versiones pueden ser planeadas de modo que los requisitostecnicos puedan ser administrados.

El objetivo es trabajar junto al usuario para descubrir sus requisitos de manera incremental antes de que el producto final sea obtenido.

El modelo iterativo de desarrollo de software se basa en que antes de entregar el sistema de una vez, tanto el desarrollo como las entregas se dividen en incrementos.

Los requisitos del usuario se priorizan y los requisitos de prioridad más alta se incluyen en los incrementos más tempranos.

Cuando el desarrollo de un incremento comienza, sus requisitos son inamovibles, aunque los requisitos de incrementos posteriores pueden continuar desarrollándose.

Los clientes no tienen que esperar hasta tener el sistema completo. El primer incremento satisface los requisitos más críticos. Los primeros incrementos sirven como prototipo y ayudan en la tarea de detectar los posteriores requisitos.

Un gráfico que muestra cual es el desarrollo de este proceso es el siguiente:

Modelo W

El modelo en W es una evolución del Modelo V.

Más que aportar algo nuevo lo que pretende es aclarar ciertos aspectos que el modelo en V no termina de dejar claros (si bien bastantes de las características del modelo en W ya eran de aplicación en el modelo en V).

Existen diferentes implementaciones del modelo en W, es este artículo me voy a centrar en la propuesta por Paul Herzlich.

En el modelo en V tenemos dos secuencias de pasos, una se consideraba que era de carácter constructivo, la primera recta de la V y la segunda de carácter destructivo (en el mejor de los casos, si ha pasado el test se continua hacia adelante), lo cual seguía marginando en cierto modo las actividades de testing, algo que precisamente intentaba evitar el modelo en V, al situar las mismas a la misma altura y a la vez que las de desarrollo.

En este caso tenemos dos V, una correspondiente al proceso de desarrollo y otra correspondiente al proceso de testing. Hay quienes piensan y tal vez no les falte razón que añadir una V específica para el testing lo único que ha hecho es trasladar el mismo defecto a otra dimensión, ya que vamos a seguir teniendo un caso donde se construye y otro donde se “fiscaliza”, si bien, el hecho de que este modelo integre explícitamente las vueltas a atrás acerca más ambos tipos de tareas.

Y es lógico que sea así porque todos sabemos que es muy complicado (por no decir casi imposible) acertar a la primera, por lo que el proceso de verificación, feedback y ajuste debe entenderse como un proceso integrado en el desarrollo y no como tareas independientes y enfrentadas.

Entonces, si tenemos ahora dos V, qué representa el lado creciente de cada una de ellas. Pues realmente lo que hace el modelo en W es diferenciar cláramente cuáles son los hitos de un proyecto software (algo que podía resultar confuso en el modelo en V) de manera que en la primera recta están los hitos previos a la construcción del software (con las pruebas y verificaciones correspondientes a los hitos documentales) y en la segunda los posteriores a la construcción del software (verificación sobre el producto software).

Modelo V

El Modelo en V, o Modelo de Cuatro Niveles, del ciclo de vida de un proyecto de desarrollo de software. El modelo representa, en forma de V, las relaciones temporales entre las distintas fases del ciclo de desarrollo de un proyecto. 

En los niveles lógicos del 1 al 4, para cada fase del desarrollo, existe una fase correspondiente o paralela de verificación o validación. Esta estructura obedece al principio de que para cada fase del desarrollo debe existir un resultado verificable.

En la misma estructura se advierte también que la proximidad entre una fase del desarrollo y su fase de verificación correspondiente va decreciendo a medida que aumenta el nivel dentro de la V. La longitud de esta separación intenta ser proporcional a la distancia en el tiempo entre una fase y su homóloga de verificación.

• El nivel 1 está orientado al “cliente”. El inicio del proyecto y el fin del proyecto constituyen los dos extremos del ciclo. Se compone del análisis de requisitos y especificaciones, se traduce en un documento de requisitos y especificaciones.
• El nivel 2 se dedica a las características funcionales del sistema propuesto. Puede considerarse el sistema como una caja negra, y caracterizarla únicamente con aquellas funciones que son directa o indirectamente visibles por el usuario final, se traduce en un documento de análisis funcional.
• El nivel 3 define los componentes hardware y software del sistema final, a cuyo conjunto se denomina arquitectura del sistema.
• El nivel 4 es la fase de implementación, en la que se desarrollan los elementos unitarios o módulos del programa.

¿Tengo que hacer documentación de todo?
Por supuesto. Cada fase tiene que estar respaldada por su documento correspondiente y test.

¿Por qué utilizar una metodología?
Porque es lo más rápido y barato. Volviendo al ejemplo de la casa, imaginad la cantidad de veces que debería volver atrás y tirar paredes ya hechas porque de pronto descubro que el suelo es inestable, la bañera no cabe, la instalación eléctrica no la había tenido en cuenta…
Pues, con el código pasa exactamente lo mismo.

El Modelo V tiende a estar muy relacionado con el Modelo de Cascada puesto que es una evolución del mismo.

 

Puede notarse que su primera mitad es similar al Modelo en Cascada, y la otra mitad tiene como finalidad hacer pruebas e integración asociado a cada una de las etapas de la mitad anterior.

            Se puede identificar una ventaja principal con respecto al Modelo Cascada más simple, y se refiere a que este modelo involucra chequeos de cada una de las etapas del modelo de cascada.

Desventajas:

• El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de aceptación al final de cada etapa, las pruebas comienzan a efectuarse luego de haber terminado la implementación, lo que puede traer como consecuencia un “roll-back” de todo un proceso que costó tiempo y dinero.
• El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir.
• Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de desarrollo, lo que disminuye el riesgo.

            A pesar de todo lo antes mencionado, definitivamente se trata de un modelo más robusto y completo que el Modelo de Cascada, y puede producir software de mayor calidad que con el modelo de cascada.

Modelos de proceso software

Modelos de proceso software

 

Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software. Entre los principales tenemos los siguientes:

·       Codificar y corregir

·       Modelo en cascada

·       Desarrollo evolutivo

·       Desarrollo formal de sistemas

·       Desarrollo basado en reutilización

·       Desarrollo incremental

·       Desarrollo en espiral

El objetivo de la ingeniería de software es lograr productos de software de calidad (tanto en su forma final como durante su elaboración), mediante un proceso apoyado por métodos y herramientas.


Modelos de Ciclo de Vida de Desarrollo de Software (SDLC):
 

• Modelo Secuencial
• Modelo en Cascada
• Modelo V
  
• Modelo W
• Modelo Incremental  Iterativo
• Modelo de Prototipos
• Modelo  Basado en Componentes
• Modelo en Espiral
•  Modelo Ágil

 

Fuente: http://xherrera334.blogspot.es/1192588380/resumen/

Noticia - 200.000 Certificaciones Tester

Las certificaciones de pruebas de Software de ISTQB® exceden las 200.000 certificaciones

Desde Marzo de 2009 hasta Diciembre de 2011, el número de certificaciones se

duplicó, haciendo de ISTQB ® el esquema de certificación de pruebas de

software más ampliamente adoptado y de más rápido crecimiento en el mundo.

Creemos firmemente que es un resultado excepcional, que se ha logrado

gracias al esfuerzo de todos los Comités a nivel internacional y de los

proveedores de exámenes.

El anuncio se encuentra en la página web de ISTQB ®,podrán encontrarlo en el

siguiente link: http://www.istqb.org/documents/ISTQB_Announcement_200000.pdf

Proceso de desarrollo de software

Proceso de desarrollo de software

Un sistema informático está compuesto por hardware y software. En cuanto al hardware, su producción se realiza sistemáticamente y la base de conocimiento para el desarrollo de dicha actividad está claramente definida. La fiabilidad del hardware es, en principio, equiparable a la de cualquier otra máquina construida por el hombre. Sin embargo, respecto del software, su construcción y resultados han sido históricamente cuestionados debido a los problemas asociados, entre ellos podemos destacar los siguientes:

·       Los sistemas no responden a las expectativas de los usuarios.

·       Los programas “fallan” con cierta frecuencia.

·       Los costes del software son difíciles de prever y normalmente superan las estimaciones.

·       La modificación del software es una tarea difícil y costosa.

·       El software se suele presentar fuera del plazo establecido y con menos prestaciones de las consideradas inicialmente.

·       Normalmente, es difícil cambiar de entorno hardware usando el mismo software.

·       El aprovechamiento óptimo de los recursos (personas, tiempo, dinero, herramientas, etc.) no suele cumplirse.

Algunas deficiencias comunes en el desarrollo de software son:

·       Escasa o tardía validación con el cliente.

·       Inadecuada gestión de los requisitos.

·       No existe medición del proceso ni registro de datos históricos.

·       Estimaciones imprevistas de plazos y costos.

·       Excesiva e irracional presión en los plazos.

·       Escaso o deficiente control en el progreso del proceso de desarrollo.

·       No se hace gestión de riesgos formalmente.

·       No se realiza un proceso formal de pruebas.

·       No se realizan revisiones técnicas formales e inspecciones de código.

Pressman caracteriza la Ingeniería de Software como “una tecnología multicapa”, ilustrada en la Figura 1.

·       Cualquier disciplina de ingeniería debe ser de calidad. La calidad y las filosofías similares fomentan una cultura continua de mejoras de procesos que conducen al desarrollo de enfoques cada vez más robustos para la ingeniería del software.

·       El proceso define un marco de trabajo para  un conjunto de áreas clave, las cuales forman  la base del control de gestión  de proyectos de software y establecen el contexto en el cual: se aplican los métodos técnicos, se producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.

·       Los métodos de la ingeniería de software indican cómo construir técnicamente el software.  Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Estos métodos dependen de un conjunto de principios básicos que gobiernan cada  área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas.

·       Las herramientas de la ingeniería del software proporcionan un soporte automático o semi-automático para el proceso y los métodos, a estas herramientas se les llama herramientas CASE (Computer-Aided Software Engineering).

Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Dicho proceso, en términos globales se muestra en la Figura 2

El proceso de desarrollo de software no es único. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. 

Debido a esta diversidad, es difícil automatizar todo un proceso de desarrollo de software.

A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos:

1.    Especificación de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software.

2.    Diseño e Implementación: Se diseña y construye el software de acuerdo a la especificación.

3.    Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente.

4.    Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente.

Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software es establecer las relaciones entre elementos que permitan responder Quién debe hacer Qué, Cuándo y Cómo debe hacerlo.

 

http://xherrera334.blogspot.es/1192588380/resumen/

Noticia - Certificados a nivel Mundial

La tasa de crecimiento en certificaciones es de más de 10.000 certificados por trimestre.

 

-Las certificaciones en el nivel Avanzado están creciendo rápidamente, entre los módulos del Advanced Level, el Test Manager es el que tiene un crecimiento mayor.
 

-TOTAL DE COMITÉS EN EL MUNDO: 47

-HASTQB ocupó el puesto #26 en el total de certificaciones por Comité con un total de 742 certificaciones, con una contribución al ISTQB® de 0.3%.

Fuente: http://www.hastqb.org/eventos/details/101-total-de-certificados-en-el-mundo.html

Need of Skilled Testers

Some years ago many companies preferred not to have separate test engineers in the project team. But this I have not seen in past 2-3 years in my career. As now all the companies have a clear idea of the need of the QA and test engineers. Also the QA and testers rolls are now concrete and there is no confusion.
Unfortunately, still I find the perception of testing as a inferior role in some developers mind. This “anyone can do” attitude should be removed from those people’s mind. Lots of companies hiring “any” skilled personals to do this job and eventually suffering from the lost of money and time. Instead of hiring the junk of testers they should hire some gifted testers who can do there job beyond the developer’s limitations.
If Managers and management remove this inferiority thinking from their mind then they can hire these gifted testers in their organization. Such testers can do complex job well, can find complex bugs and further more can add some procedures to the way of doing the routine jobs in order to make it more structured.

http://www.softwaretestinghelp.com/need-of-skilled-testers/

Pruebas del Software

Las pruebas funcionales - (Functional Software Testing) y las pruebas unitarias (Unit Software Testing) deben ser consideradas como temas cien por ciento técnicos, en mi experiencia como analista de pruebas o también llamado tester, he llegado a probar una buena cantidad de sistemas en varias empresas, enfocadas principalmente al sector financiero.

Para el analista de pruebas es muy importante y conveniente tener una definición funcional y técnica decente antes de iniciar el proceso de prueba, en realidad en un proceso de aseguramiento de la calidad el analista QA revisor debe validar que estos documentos son lo suficientemente claros y consistentes, una vez aprobados estos documentos podrán servir de base para que el analista de pruebas pueda preparar el plan de pruebas, el cronograma de pruebas y los casos de prueba.

Cada vez que tengo un sistema en mis manos siento que mi labor debe ser darle un valor agregado, cada error que yo pudiera encontrar significa un éxito para la calidad del sistema. Evidentemente el analista de pruebas o tester debe ser un profesional en Ing. De Sistemas o Ing. de Software, los conocimientos técnicos son valiosos en esta labor, pero no son suficientes, necesitamos también tener conocimientos del negocio, en la actualidad los sistemas más importantes son realizados para dar solución a los problemas de negocios. 

El nivel de conocimiento del tester sobre un negocio debe ser similar al del usuario que utilizará el sistema. Un tester experimentado puede llegar a tener un amplio conocimiento  de diversos negocios y le resultará sencillo adaptarse a cualquier tipo de aplicación y a cualquier tipo de plataforma: Web, C/S o Host, siendo esta última a mí parecer la más complicada.

Para conocer como funcionara el sistema y tener una visión general de lo que este hace para el negocio es necesario asimilar la documentación funcional y técnica previamente definida. Luego de asimilar estos conocimientos será más sencillo el desarrollo de los casos de prueba.

En las pruebas funcionales los casos de prueba tienen el objetivo de detectar errores, los casos de prueba deben definir los datos de entrada a utilizar, el proceso que debemos seguir en el sistema y el resultado esperado.

Una vez concluidos los casos de prueba es mas sencillo poder estimar cuanto tiempo nos tomara una primera barrida de pruebas y con esto también podremos realizar nuestro cronograma y plan de pruebas.

Los casos de prueba nos permitirán probar todas las funcionalidades del sistema, sin embargo es importante tener buen criterio a la hora de desarrollarlos.  Las combinaciones de casos de prueba podrían ser prácticamente infinitas, propongo el siguiente ejemplo:

Si pensamos hacer casos funcionales para un sistema bancario nos encontraremos con una gran combinación de variables:

Para este ejemplo solo nos centraremos en un simple retiro bancario, en donde nos encontraríamos con las siguientes variables:

¿En que tipo de cuenta haremos el cargo? Ahorros, Corriente, A Plazos
Esto nos daría al menos 3 variables o casos de prueba.

¿La cuanta tendrá saldo? Saldo = 0,  Saldo > 0, Saldo < 0
3 variables

¿Es una cuenta en Moneda Nacional MN o Moneda extranjera?
2 variables

¿Pertenece a una Persona natural PN o Persona Jurídica PJ?
2 variables

¿La cuenta es mancomunada? Si o No
2 variables

¿En que estado se encuentra la cuenta? Activa, Inactiva, Cerrada (Suponiendo que solo se manejen 3 estados).
3 variables

¿La cuenta tendrá alguna facilidad crediticia? Es decir ¿Permite sobregiros?
Si o No
2 variables

¿De que tipo será el cargo a la cuenta?

1. Transferencia entre cuenta propia
2. Transferencia a un tercero
3. Transferencia interbancaria
4. Retiro en efectivo
5. Pago de un cheque

5 variables

¿En que canal de atención se realizará esta operación?

1. En ventanilla
2. Cajero Automático – ATM
3. POS – Pago de servicio o consumo
4. Home Bankin

4 variables

Para este ejemplo tan sencillo podríamos obtener fácilmente más de 3000 casos de prueba y ni siquiera estamos enfocados a los casos que presentarán en cada pantalla. Como menús, listas, grillas, botones etc. Por este motivo debemos delimitar claramente cual es la funcionalidad que queremos probar diseñando cada caso de manera que abarque la mayor cantidad de esfuerzo posible al sistema.

Una vez que empezamos a probar nuestros casos siempre deberíamos ir un poco más allá. Muchos de los errores que he podido encontrar no estaban escritos en mis casos de prueba. 

Si en mi caso defino hacer un cargo de 1000 dólares, luego de eso podría hacer una prueba con un cargo de 1000.01 y otro de 9999.99 siempre tratando de encontrar los valores limites que provoquen un mal funcionamiento. Es interesante notar que la gran mayoría de los errores se encuentran en los valores límite. Si una pantalla se define para que no soporte un número mayor de 99999999.99 pues entonces probemos con 100000000.00 pues el sistema debería mostrarnos un mensaje indicando que el monto ingresado esta fuera del rango permitido o algo por el estilo. 

Es increíble como algunos programadores creen que no se deben probar casos para los cuales el sistema no esta preparado, bueno yo pienso totalmente lo contrario un buen sistema debe funcionar perfectamente con datos ingresados bien o mal esto diferencia a un sistema de alta calidad, se debe probar que el sistema haga lo que debe de hacer y por supuesto que no haga lo que no debe de hacer, la labor del analista de pruebas es totalmente destructiva para con el sistema, un analista tester jamás debería estar bajo las ordenes de un programador y tampoco es recomendable dejar que el programador pruebe sus propios programas, es gracioso cuando me pongo a pensar en la gran cantidad de programadores que me han pagado apuestas por su seguridad en la robustez de sus sistemas, simplemente en el fondo no quieren maltratarlos, los aman…

Otro nicho en el que se ocultan errores podrían ser los campos de ingreso de datos, aún no entiendo porque tantos programadores no colocan valores límite máximos permitidos en los campos de texto, sobre todo en los campos de párrafos o multilíneas, disfruto de esas pruebas haciendo un solo Copy de un texto mediano para luego hacer 100 veces Paste, casi me parece escuchar como se truenan los huesos de la base de datos cuando no soportan el contenido. Si realizo esa prueba la primera vez en un sistema y lo logra pasar limpio pues ese programador se ha ganado mi respeto, a pesar de ser una definición tan simple muchos la olvidan.

Las pruebas que requieran cálculos de diversos valores deberían tener pocos casos pero muy extensos y complejos, alguna vez hice pruebas para un sistema de bolsa de valores en donde se deberían calcular diversos campos calculados, cada uno de ellos mostrado en un campo o grilla, el caso debe especificar que valor se espera en cada campo y una vez ejecutado el caso constataremos que los datos que se presenten sean correctos, tanto en las pantallas como en los reportes, jamás he tenido la experiencia de encontrar un sistema nuevo sin errores en sus cálculos complejos “El sistema nunca funciona bien la primera vez”. ¡Ese es mi lema!

Por último una muy buena recomendación de pruebas es el manejo del valor cero 0 muchas veces por la complejidad de los procesos el programador olvida que este valor puede llegar a ser un divisor de otro valor y entonces: “Error Exception Faillure #afg99d7 - no valido” o algún otro mensaje horrible.

Pruebas Software

Las pruebas de software consisten en la dinámica de la verificación del comportamiento de un programa en un conjunto finito de casos de prueba, debidamente seleccionados de por lo general infinitas ejecuciones de dominio, contra la del comportamiento esperado. Son una serie de actividades que se realizan con el propósito de encontrar los posibles fallos de implementación, calidad o usabilidad de un programa u ordenador; probando el comportamiento del mismo.

La prueba de software es un elemento crítico para la garantía del correcto funcionamiento del software. Entre sus objetivos están:

1. Detectar defectos en el software.
2. Verificar la integración adecuada de los componentes.
3. Verificar que todos los requisitos se han implementado correctamente.
4. Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente.
5. Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.

Para lograr los objetivos propuestos, un ingeniero de software deberá conocer los principios básicos que guían las pruebas del software.

Las pruebas se rigen por una serie de principios, una buena comprensión de estos facilitará el posterior uso de los métodos en un efectivo diseño de casos de prueba. A continuación se citan:

• La prueba puede ser usada para mostrar la presencia de errores, pero nunca su ausencia.
• La principal dificultad del proceso de prueba es decidir cuándo parar.
• Evitar casos de pruebas no planificados, no reusables y triviales a menos que el programa sea verdaderamente sencillo.
• Una parte necesaria de un caso de prueba es la definición del resultado esperado.
• Los casos de pruebas tienen que ser escritos no solo para condiciones de entrada válidas y esperadas sino también para condiciones no válidas e inesperadas.
• El número de errores sin descubrir es directamente proporcional al número de errores descubiertos.

Estas leyes que definen básicamente la aplicación de las pruebas de software ayudan a refinar el producto de software a través de las etapas involucradas.

1. Seleccionar qué es lo que debe medir la prueba, es decir, cuál es su objetivo, para qué exactamente se hace la prueba.
2. Decidir cómo se va a realizar la prueba, es decir, qué clase de prueba se va a utilizar para medir la calidad y qué clase de elementos de prueba se deben usar.
3. Desarrollar los casos de prueba. Un caso de prueba es un conjunto de datos o situaciones de prueba que se utilizarán para ejecutar la unidad que se prueba o para revelar algo sobre el atributo de calidad que se está midiendo.
4. Determinar cuáles deberían ser los resultados esperados de los casos de prueba y crear el documento que los contenga.
5. Ejecutar los casos de prueba.