<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>error on Una QA en Apuros</title><link>https://unaqaenapuros.com/tags/error/</link><description>Recent content in error on Una QA en Apuros</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Tue, 30 May 2017 08:29:04 +0000</lastBuildDate><atom:link href="https://unaqaenapuros.com/tags/error/index.xml" rel="self" type="application/rss+xml"/><item><title>007 - Cómo reportar un defecto.</title><link>https://unaqaenapuros.com/2017/05/30/007-como-reportar-un-defecto/</link><pubDate>Tue, 30 May 2017 08:29:04 +0000</pubDate><guid>https://unaqaenapuros.com/2017/05/30/007-como-reportar-un-defecto/</guid><description>¡Hola a todos!
En esta entrada vamos a dar una serie de consejos para reportar de forma correcta un defecto.
Una de las cosas que tenemos que tener claras antes de reportar un defecto es tener una forma de reproducirlo. Tenemos que tener un camino claro y definido de cómo reproducir lo que hemos encontrado para darle el máximo de detalles a los desarrolladores para que sean capaces de investigar y resolver el defecto que nos hemos encontrado. La mejor forma de mostrar evidencias que tenemos es tener unos pasos bien definidos, capturas de pantalla o incluso un video en el que se pueda ver el defecto que acabamos de reportar.</description></item><item><title>005 - Definiciones: Error, defecto, fallo, incidencia, test case...</title><link>https://unaqaenapuros.com/2017/05/28/005-definiciones-error-defecto-fallo-incidencia-test-case/</link><pubDate>Sun, 28 May 2017 10:48:25 +0000</pubDate><guid>https://unaqaenapuros.com/2017/05/28/005-definiciones-error-defecto-fallo-incidencia-test-case/</guid><description>Hola de nuevo, para seguir poniéndonos en contexto sobre todo lo que tenemos que saber de base de QA, en esta entrada daremos varias definiciones de términos que debemos conocer y tener claro su significado. La mayoría de estas definiciones están sacadas de la web de ISTQB (International Software Testing Qualifications Board), una de las mayores organizaciones de pruebas internacionales. ¡Comenzamos!
Error: acción humana que produce un resultado incorrecto, por ejemplo un error de programación. Defecto: Imperfección en un componente o sistema que puede causar que el componente o sistema falle en desempeñar las funciones requeridas. Por ejemplo, si se localiza un defecto durante una ejecución puede causar un fallo en el componente o sistema, por ejemplo una sentencia o una definición de datos incorrecta. Fallo: Manifestación física o funcional de un defecto, por ejemplo, desviación de un componente o sistema respecto de la presentación, servicio o resultado esperado. Enmascaramiento de error: Ocurrencia en la cual un defecto impide la detección de otro [ IEEE6] Incidencia: Cualquier ocurrencia de un suceso que requiere investigación [ Según IEEE 1008]. Escalabilidad: Capacidad de un producto software de ser actualizado para adaptarse a cargas crecientes. Test Case: es un documento que tienen un conjunto de datos a probar, condiciones previas, resultados esperados y condiciones posteriores. Se desarrolla para un escenario de prueba en particular con el fin de verificar el cumplimiento de un requisito específico. Test Suite: Una Test Suite es un contenedor con un conjunto de pruebas (test) que ayuda en la ejecución a los testers y a reportar el estado de las pruebas. Un test case se puede añadir a varias Test Suites. White Box Testing (pruebas de caja blanca): Las pruebas de caja blanca son una técnica que examina la estructura del programa y los datos de prueba derivados de la lógica del programa/código. Black Box Testing (pruebas de caja negra): es un método de pruebas de software que examina la funcionalidad de una aplicación basada en las especificaciones. El equipo de pruebas lleva a cabo este tipo de pruebas durante el ciclo de vida del software. Este tipo de prueba se puede aplicar a cada uno y todos los niveles de las pruebas de software tal como los unitarios, la integración y las pruebas de aceptación. Release Candidate: Una release candidate (RC) es la build a probar para comprobar si algún problema crítico ha sido detectado en el código durante el periodo de desarrollo anterior. La Release Candidate no tiene por qué ser la que se despliegue en producción, tan solo es para propósitos de prueba. Sin embargo, en la mayoría de los casos, no existen diferencias entre la release final y la release candidate. Espero que después de estas definiciones tengamos más claros estos conceptos. En la próxima entrada seguiremos con otra de las comparativas y definiciones más importantes, la diferencia entre validación y verificación. ¡Nos leemos en la siguiente entrada!</description></item></channel></rss>