Proceso de creación de pruebas.

Para ello necesitamos la generación de un plan de pruebas.

Que consiste en:

Diseño de pruebas específicas: Para ello tenemos que conocer el producto y su funcionalidad.

Ejecución de las pruebas: Probar el producto de todas las formas posibles e intentar "romperlo".

Evaluación de la salida esperada: QA como departamento, debe ser el encargado de decidir qué semáforo da.

Análisis de la estadística de errores: Como Qase, nos permite realizar un trackeo de todas las pruebas para cada actualización, que nos permite a su vez, validar la app según los resultados de un informe de pruebas.

Según el momento de realización y la forma.

Momento: pruebas de unidad, integración y validación.

Forma: caja blanca, negra y análisis de valores límites.

Hay que tener en cuenta que algunos valores límites o condiciones extremas que el software permite.

Comentarios

Publicar un comentario

Entradas populares de este blog

Ciclo de vida del defecto

 New > Assigned > Open > Fixed > Re-Test > Closed. Se abre el bug, se asigna a un lead, el lead lo asigna a un desarrollador, el desarrollador decide si lo soluciona, o bien, si lo deja pasar. Se manda para Re-testear desde dev a qa para verificarlo (estilo regresion), y si se ha solucionado, finalmente se pasa a closed/cerrado. Si se cierra entonces no se vuelve a reproducir más. A no ser que aparezca en nuevas actualizaciones. Hay que tener en cuenta que, al abrir el bug, el mismo puede aparecer duplicated /duplicado si se ha subido dos veces.  También puede rejected /rechazarse por alguna razón desde el departamento de desarrollo, pero si el QA considera que es un defecto, puede volver a reabrirlo y mandarlo de vuelta a desarrollo. Deferred , significa que el desarrollador lo rechaza, pero por alguna razón en concreto, por ejemplo, porque es un error que se conoce desde desarrollo y se va a solucionar para nuevas versiones (se usa muy poco, ya que el QA no ...
Leer más

¿Cómo integramos el software?

Para integrar pruebas en metodologías de software testing, podemos: Integrar componentes, para la creación de la batería de pruebas. Establecer una estrategia de integración de dichas pruebas para la batería de pruebas. Preparación del ambiente de prueba con un servidor y herramienta. Como por ejemplo, Qase. Establecer pruebas para cada actualización, por ejemplo los Test Run y basarnos en Test Plans. Además, existen otras 2 formas de integración del software. Pruebas Big-bang , llamadas así porque basa las pruebas en diferentes módulos o áreas dentro del proyecto. Por ejemplo, en LMDance, podría basarse en áreas de HUD/UI, o bien creación de perfiles, o bien Gameplay, o pruebas de conexiones.  Estas pruebas Big-bang, hacen hincapié en áreas independientes, como las ya mencionadas en el párrafo anterior. Por ello probamos el programa de manera completa e íntegra.  Pruebas Acendentes/descentes , más organizadas porque no van por áreas sueltas, sino que se prueba el software apa...
Leer más

Principios en pruebas de Software.

- Uno de los principios elementales del software testing, es que las pruebas muestran la cantidad de errores posibles, la cantidad de defectos. Pero no su ausencia.  Por ejemplo, para Samsung, el galaxy note 7 tuvo que ser retirado del mercado debido a que éste se incendiaba o explotaba tras cargarse durante varias horas. - Las pruebas exhaustivas son imposibles de realizar, o bien no existen. Un claro ejemplo, en cualquier proyecto de CHESS / ajedrez, habrían de realizarse infinitas pruebas respecto a los posibles movimientos.  Según IBM, corregir un defecto encontrado en post-producción, costará 30 veces más que en su etapa temprana. - Probar en la proporción adecuada, teniendo en cuenta la regla 80-20, el 80% de los fallos se podrían encontrar en un 20% de modos. - Cuidado con la paradoja del pesticida.  - Las pruebas dependen del contexto: No es lo mismo realizar pruebas que tiendan a perder vidas humanas, software médico, o económico, que probar una web que registre ...
Leer más