CALIDAD Y ASEGURAMIENTO

DEL SOFTWARE (SQA)

Jefry Amador H.
1-11-5490
 Contenido
Que es la prueba del software?
Que es calidad del software?
Importancias de las pruebas del software.
Diferencia entre error, defecto y falla.
Costo del defecto.
Ciclo del defecto.
Casos de pruebas.
Ejemplo de casos de pruebas.
Principios de pruebas.
Ciclo de vida de la prueba del software
(STLC).
Tipos de pruebas.
Que es la calidad y aseguramiento de
software (SQA).
Diferencia entre QA y QC (testing).
Estructura del departamento de SQA
 Introduccin
Hablaremos sobre los
fundamentos de pruebas y
Conceptos bsicos de calidad
y aseguramiento de software
apoyndonos sobre los
fundamentos de International
Software Testing
Qualifications Board (ISTQB).
 Qu es prueba del software?
Es el proceso de ejecutar un
programa o aplicacin con el fin
de encontrar defectos.
Tambin puede definirse como el
proceso de verificar y validar que
el programa o aplicacin cumple
con los requerimientos de
negocios y documentos Tcnicos
(Anlisis y Diseo).
 Calidad del Software
El grado con el que un
sistema, componente o
proceso cumple con los
requisitos especificados y
las necesidades o
expectativas del cliente o
usuario. (IEEE.Std.610-
1990.
Importancia de las pruebas de software
Las pruebas de software son necesarias porque los humanos
cometemos errores, algunos de estos errores no son crticos
pero algunos son muy costosos o dainos.
Ayuda a reducir el riesgo de que pase una falla en produccin.
Estas fallas producidas pueden provocar perdida econmica,
Mala reputacin de un negocio e incluso daos o muerte a una
persona.
Ayuda a ganar confianza y proporciona informacin sobre el
nivel de calidad.
Ayuda a validar que el resultado final cumple con los requerido
por el usuario.
Brinda informacin para la toma decisin en cuanto al proceso
y la salida a produccin.
 Diferencia entre Error, Defectos y fallas
Error: Es la accin incorrecta que
comete una persona (Programador)
y puede provenir por un mal uso del
lenguaje, mal uso dela lgica,
implementacin incorrecta de un
requerimiento o no implementacin
de un requerimiento.

Defecto: Imperfeccin del software.

Cuando el resultado esperado no
coincide con el resultado actual.

Falla: Es el mal funcionamiento del

software que impide su
operatividad. Esto ocurre en
ambiente de produccin.
 Costo del defecto
Cuando el defecto es encontrado en la fase del requerimiento
sale menos costoso repararlo ya que solo es corregir el texto y
publicarlo, por igual si es en la fase del anlisis y diseo solo
habr que corregir el anlisis y diseo y quizs en el
requerimiento si el defecto encontrado en la fase de diseo
proviene del alcance del requerimiento, si es en la fase de
codificacin sale un poco mas costosa ya que si el defecto
proviene de la fase del requerimiento habr que corregirlo en
la fase del requerimiento, modificar el anlisis y diseo y
corregirlo en la fase de codificacin.

Si el defecto es encontrado en la fase de prueba sale mas

costoso ya que si el defecto proviene del requerimiento habr
que corregir el requerimiento, el anlisis y diseo, la
codificacin y luego habr que realizar re-prueba (para verificar
que el cdigo fue corregido), prueba de regresin (para validar
que la correccin del defecto no afecto las funcionalidades) si
el defecto es encontrado en produccin saldr mas costoso ya
que este puede provocar una falla que cree una mala
reputacin a la empresa, perdida econmica a la empresa o
puede provocar daos o muertes y aparate de esto para poder
corregir esta falla se tendra que volver a empezar el ciclo de
vida del software, Ejemplo: levantamiento de requerimiento,
analysis y diseo, codificacin y pruebas y pase a produccin.
 Ciclo de vida del defecto
El probador crea un nuevo reporte de
defecto, este es asignado a un programador
el cual evala si el defecto es genuino en
caso de ser genuino este lo corrige y coloca
el reporte de defecto como corregido, luego
el reporte queda en estado pendiente de re-
prueba para que el probador verifique si fue
corregido el defecto, si fue corregido se
cierra el reporte de defecto, en caso
contrario este lo re-abre para que sea
corregido y pasa el ciclo nuevamente.
Un reporte de defecto puede ser corregido,
rechazado si no es genuino, aplazado para
otra versin o no es un defecto si lo
reportado no aplica o es una solicitud de
usuario que no se especifico en el
requerimiento.
 Casos de Pruebas
Es un conjunto de escenario, pasos y datos que sirven para
validar el correcto funcionamiento de una especificacin de
un requerimiento de usuarios.
Es una series de pasos, datos de entradas y salidas en el
cual se espera un resultado, cuando el resultado actual no
coincide con el resultado esperado, el caso de prueba fue
fallido.
Un caso de prueba contiene una identificacin, escenarios,
pasos para ejecutar el escenario, data de prueba, resultado
esperado y resultado actual, estatus del caso de pruebas y
nivel de riesgo que contiene.
Ejemplo de caso de prueba
 Principios de
1.
o
pruebas
Las pruebas muestran la presencia de defectos.
Este muestra la presencia de errores no que no existan.
2. Las pruebas exhaustivas son imposibles.
o No es posible cubrir todas las pruebas realizando todas las combinaciones posibles.
3. Pruebas Tempranas.
o Ayudan a encontrar defecto a tiempo y reduce el costo de correccin.
4. Agrupamiento de defectos.
o El 80% de los defectos se encuentran en el 20% de los mdulos. Los defectos se
agrupan solo en el 20% de los mdulos.
5. Paradoja del pesticida.
o Los casos de pruebas tienen que ser revisados y re-escritos para fortalecerse.
6. La prueba depende del contexto.
o Realizar prueba a un portal es menos riesgoso que realizar prueba a un sistema
financiero.
7. La falacia de ausencia de errores.
o Si el sistema no cumple con lo solicitado por el cliente, encontrar defectos y corregirlo
no contribuye con la calidad del software.
 Ciclo de vida de la prueba del software
(STLC)
1 Anlisis del requerimiento.
1.1 Anlisis de las especificaciones de requisitos del sistema para
entender los diferentes mdulos de negocio y sus funcionalidades

1.2 Para identificar el perfil de usuario, la interfaz de usuario y la

autenticacin de usuario.

1.3 Los tipos de pruebas que deben realizarse en la aplicacin o el

producto deben identificarse.

1.4 Debe reunir los detalles sobre las prioridades de las pruebas.

1.5 Preparacin de RTM que es matriz de trazabilidad de

requisitos.

1.6 Los detalles del entorno de prueba deben ser identificados

para realizar pruebas.

1.7 Anlisis de la posibilidad de automatizacin si es necesario.

conocer los mdulos.
 Ciclo de vida de la prueba del software (STLC) Cont.

2. Planeacin de las pruebas.

2.1 Preparacin del documento del plan de prueba.

2.2 Preparacin del documento de estrategia de prueba.

2.3 Analizar el mtodo de prueba ms adecuado para la

aplicacin o el producto.

2.4 Analizar las tcnicas de prueba y los tipos de pruebas a

realizar para mantener la calidad.

2.5 Seleccin de la herramienta de prueba.

2.6 Estimacin de los esfuerzos de prueba.

2.7 Planificacin de recursos segn la habilidad requerida

para la prueba y tambin asignacin de roles y
responsabilidad a ellos.
 Ciclo de vida de la prueba del software (STLC) Cont.
3. Desarrollo de los casos
de pruebas.
3.1 Creacin de casos de prueba para
todos los mdulos o caractersticas de
la aplicacin o producto.

3.2 Creacin de scripts de

automatizacin si es necesario.

3.3 Revisin de casos de prueba y

scripts de automatizacin de pruebas.

3.4 Obtener la data de prueba.

 Ciclo de vida de la prueba del software (STLC) Cont.

4. Preparacin de ambientes.
4.1 Comprender el diseo y la arquitectura de la
aplicacin.

4.2 Configuracin del entorno de prueba.

4.3 Instalacin del hardware y software

necesarios para comenzar a probar la aplicacin.

4.4 Integracin de cualquier aplicacin de

terceros (si es necesario).

4.5 Instalacin de los objetos modificados o

creados.

4.6 Creacin de datos de prueba.

 Ciclo de vida de la prueba del software (STLC)
Cont.
5. Ejecucin de las pruebas
5.1 Ejecucin de los casos de prueba.

5.2 Preparacin del documento de resultado de la prueba.

5.3 Defectos de registro para los casos de prueba fallidos.

5.4 Cartografa de defectos con los casos de prueba.

5.5 Actualizar los casos de prueba y la estrategia de prueba si

es necesario.

5.6 Los defectos fijos deben ser nuevamente probados.

5.7 Cierre de los defectos si funcionan como se esperaba.

5.8 Ejecucin de pruebas de regresin de la aplicacin o

producto para asegurar su estabilidad post cierre de defectos.
 Ciclo de vida de la prueba del software (STLC) Cont.

6. Cierre de las actividades

de las pruebas.
6.1 Evaluacin de la finalizacin de la
prueba sobre la base de la Cobertura de
la Prueba y la Calidad del Software.

6.2 Preparacin del informe de cierre de

la prueba.

6.3 Analizar los resultados de las pruebas

para determinar la distribucin de los
defectos graves.
 Tipos de pruebas
Pruebas
Pruebas Pruebas no Prueba
relacionadas con
Funcionales Funcionales Estructural
el cambio
Prueba de caja Prueba de Prueba de caja Re-Prueba (Re-
negra. usabilidad. blanca. testing).
Prueba de Prueba de Prueba de Prueba de
equivalencia. mantenibilidad cobertura. regresin.
. Verificacin
Prueba de de estndar
carga. del cdigo.
Prueba de
estrs.
Prueba de
seguridad.
 Que es la Calidad y
Aseguramiento del Software
(SQA)?
La calidad y Aseguramiento del software

consiste en monitorear el proceso de la

ingeniera del software y mtodos usados
para asegurar la calidad.
 Diferencias entre QA y QC (Testing)
QA (Quality Assurance): Se enfoca
en mejorar el proceso del ciclo de vida
del software.
Ayuda a prevenir la aparicin de
defectos.

QC (Quality Control) Prueba: Se

enfoca en encontrar bug (Defectos).
Se enfoca en la calidad del product
no en la calidad del ciclo de vida del
software aunque los informes final
de las pruebas contribuyen a la
toma de decision para la mejora del
proceso del ciclo de vida del
software.
 Conclusion
Pudimos ver algunos fundamentos sobre las
pruebas y la calidad y aseguramiento de
software, las importancias de las pruebas, los
tipos de pruebas, los costos del defectos entre
otros.

Las Pruebas siempre deben realizarse tomando

en cuenta el nivel de riesgo que se quera tomar,
ya no siempre tienes suficiente tiempo para
realizer todas las pruebas.