¿Qué es el QA / software testing?

 El software testing permite ahorrar tiempo, costos de reparación de errores a futuro, previsión de errores, aseguramiento de correcta funcionalidad desde las primeras versiones Alfa, hasta la versión última del contenido "BETA > RC". Como todo, siempre habrán errores experimentales en la aplicación que salga al mercado, algunos usuarios encontrarán errores que no se encontraron hasta el momento porque también es normal, un equipo de testers frente a millones de usuarios, cuando el producto salga al mercado se verán nuevos errores y quizá, algunos incluso más complejos.

Siempre habrán errores que corregir y actualizaciones que hacer.
El software testing pervive mientras el producto perviva y se siga actualizando.
Pero el QA Testing, requiere de una metodología, conocimiento y experiencia previas, cuanta más experiencia y conocimiento, mejor comprensión tendrá el Tester de las posibilidades y formas de abordar las posibles casuísticas y errores. Existen tantos tipos de QA testing, como tipos de Software y productos haya.

En este blog, documentaremos toda la información interesante y reelevante con respecto a las pruebas de software y en qué consisten.

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