QA to Any App

 ¿Te en-cajan estos métodos de prueba en caja? ¡No son para partirse la-caja!  Bien, tras este stupid-word joke. Vamos a desglosar el significado de tipos de prueba basados en cajas. Pruebas de caja negra: Llámese así a las pruebas que realiza el usuario con todo lo "visible" del proyecto, por ejemplo, la UI de cualquier página web. (Apartado visual). Pruebas de caja blanca: Sencillo y relativo al código y a la lógica de la plataforma. (Apartado backend o de código). Pruebas de caja gris: Híbrido entre pruebas de caja negra y caja blanca.

 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 ...

 A lo largo de todo el proceso de creación del software, tenemos una serie de atributos a tener en cuenta. ISO 9126 Costos de calidad reales: En fase inicial del proyecto: 130€ estimados de costo. En fase de post-producción (comercial/prod): Alrededor de 7k €. ¿Cómo se logra la calidad del Software? Métodos de ingeniería del software: Análisis de requisitos del producto, diseño adecuado y con dimensiones adecuadas, atributos y factores de calidad que determinan la calidad del mismo proyecto bien estudiados. Técnicas de administración de proyectos: Estimaciones para cumplir las fechas. Dependencias de las actividades programadas. Planificación del riesgo: ¿Qué puede salir mal? ¿Qué planes hay para combatir incendios? ¿Planes de contingencia? En 1986 falleció un paciente al que se le quemó la cabeza mediante un software médico de radiación, las causas que se detectaron a posteriori databan de un error 54, detectado por un físico y una médico. Las causas del error constaban de: - Códi...

- 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 ...

 Ser eterno estudiante: Estar siempre al tanto de todos los ámbitos del testing de software. Investigar nuevas ideas: Presenta al equipo de testing nuevas ideas e investiga. Sin miedo a exponer problemas: Propón nuevos problemas para dar mayor al proyecto y al cliente. Siempre tener evidencia de los tests: Guarda como archivos locales o como fuere, mantén constancia de todos tus tests. Mantener buena relación con los departamentos: Sobretodo con los de desarrollo, dado su conocimiento pueden ayudarnos a detectar las áreas de mayor riesgo de fallo en el software. No tomar las decisiones de la gerencia o del equipo de desarrollo de forma personal: Es mejor no influir de forma directa en decisiones de negocio o mercado, sobre las versiones que se vayan sacando. Pero sí es necesario alertar al equipo de la luz verde o roja que se pudiera dar. No tomemos a lo personal si la gerencia decide lanzar una versión al mercado con errores de los que hemos alertado, pues si hemos alertado, hem...

 Un plan de pruebas, puede realizarse de forma robusta, o bien de una forma más light. Pero generalmente se basa en un documento que registra todas las pruebas a realizar. De ello nos emerge la siguiente duda: ¿Es lo mismo un plan de pruebas que una batería de pruebas? Una base de pruebas consta de los documentos o productos de trabajo a partir de los cuales se pueden generar los requisitos del sistema. Por ejemplo, un documento de requisitos, historias de usuario, diagramas de diseño, modelos de datos, productos de trabajo similares que especifiquen como debería de ser el comportamiento adecuado del sistema que se prueba. Un tester debe estar familiarizado, al menos con la idea de las siguientes fases de prueba: Ejecutar pruebas (de forma manual o automatizada). Comparación de resultados reales con resultados esperados. (¿Plan de pruebas en base a GDD?) Diseñar y priorizar casos de pruebas. Identificar los datos de las pruebas. (Pruebas de regresión). Diseñar el entorno de prueba...