tester

QA : Maneja los procesos que se llevan a cabo (se enfoca en procesos)
Pruebas: Verifican que si se cumplan dichos requerimientos. (se enfoca en productos – resultados)
Referencias: http://www.istqb.org/
Durante el proceso de desarrollo se debe tener en cuenta tanto la
calidad como la productividad y la seguridad.


ATRIBUTOS DE CALIDAD:
Correcto:
Mantenible :
Testeable:Usabilidad:
Confiable:
Portable:
Calidad externa : Es la detectable por el usuario
Calidad interna:
TESTING
Encontrar defectos, enfocarse a que se cumplan las necesidades del usuario, generar información de riesgo, aprender de los defectos (retroalimentación).

PRINCIPIOS DEL TESTING
1. El testing muestra la presencia de defectos, no su ausencia.

Puede probar la presencia de defectos.
Se reduceprobabilidad de presencia de defectos que permanecen sin ser detectados.
No hallar defectos, no prueba que no existan.
El proceso de pruebas puede tener errores.
Condición de pruebas no propias para detectar defectos.

2. El testing exhaustivo no es posible.

Pruebas exhaustivas: Combinación de todos los valores posibles
Explosión de casos: Costo y esfuerzo por pruebas exhaustivas.Utilizar análisis de riesgos y priorización para definir las pruebas y controlar el esfuerzo.
Definir subconjunto de todos los valores (de forma sistémica o aleatoria)
Las pruebas exhaustivas solo es posible en casos triviales.


3. Pruebas tempranas.

Entre más temprano se encuentre un defecto se evita la perdida de tiempo y el aumento de costos
Las pruebas deben iniciar cuando comienza elproyecto
Menos costo en corrección de errores detectados en etapas tempranas
Los conceptos y especificaciones pueden ser probados
Preparación temprana de pruebas.
Consumo de tiempo
Pruebas es más que ejecución
Se puede iniciar actividades de pruebas antes del desarrollo.


4. Agrupamiento de defectos.

Si un defecto es encontrado en un módulo, es muy probable que haya más defectosalrededor de este último.
Las fallas a menudo se originan en unos pocos modulos.
Cuando se detecta un defecto es conveniente investigar el modulo donde se encontró.

5. Paradoja del pesticida

Repetir pruebas en las mismas condiciones no es efectivo.
Es necesario repetir una prueba tras una modificación de código (corrección de defecto, funcionalidad indirecta).
Elaborar nuevos casos yactualizar los existentes.
Cada caso de prueba debe contar con conbinación única de entrada para obtener información adicional.
La automatización es conveniente para la repetición de pruebas que son requeridas.

6. Las pruebas dependen del contexto.

Las pruebas deben adaptarse a los riesgos inherentes al uso y el entorno de la aplicación.
Dos sistemas no deberían ser testeados de la misma forma.Objetos de pruebas diferentes son probados de forma diferente.
Definir objetivos de las pruebas según el contexto.
El entorno de pruebas debe ser similar a producción.

7. La falancia de ausencia de errores.
Encontrar fallas y reparar defectos significa que el sistema cumple las expectativas y necesidades del usuario. La temprana participación del usuario en el proceso de desarrollo y el usode prototipos para evitar problemas.
Un proceso de pruebas adecuado detectara los fallos más importantes.
La calidad debe ser construida desde el principio del proyecto.
No se puede introducir calidad solo a través de pruebas.
CONCEPTOS:

Error: Acción humana que produce un resultado incorrecto. Ejemplo: error de digitación, error de programación.
Defecto: Desperfecto de un componente quepuede ser la causa para que no realice su función específica. Ejemplo: Definición de datos incorrecta.
Falla: Manifestación de un defecto. Desviación de un componente respecto al resultado esperado. Ejemplo: overflow
Requisito: Descripción de un atributo funcional o no funcional deseado u obligatorio.
Requerimiento: petición o solicitud que se realiza.
Versión: cambio de gran impacto o...