81 SDS Tic LN 004 Lineamiento Tecnico de Pruebas

2018
Lineamiento Técnico Pruebas

de Software
TABLA DE CONTENIDO
1. OBJETIVO............................................................................................................... 1
2. ALCANCE ............................................................................................................... 1
3. MARCO LEGAL ...................................................................................................... 2
4. GENERALIDADES .................................................................................................. 4
5. GLOSARIO.............................................................................................................. 7
6. BIBLIOGRAFIA ....................................................................................................... 8
DIRECCIÓN TIC Elaborado por: Eduardo
SISTEMA INTEGRADO DE GESTIÓN Olaya – Cesar Poveda
CONTROL DOCUMENTAL Revisado por: José Darío
LINEAMIENTO TÉCNICO DE PRUEBAS DE Medina Palacios
SOFTWARE Aprobado por: Arleth
Código: SDS-TIC-LN-004 V.1 Patricia Saurith Contreras
1. OBJETIVO
Prestación del proceso de ejecución de pruebas aplicando las mejores prácticas de pruebas
y aseguramiento de calidad de software, sobre los desarrollos de software de los sistemas
de Información que operan en la Secretaria Distrital de Salud de Bogotá.
2. ALCANCE
El servicio de ejecución de pruebas de software se prestará en las instalaciones de la

Secretaria Distrital de Salud de Bogotá, y será tanto para los grupos de desarrollos internos
de la entidad como para el software desarrollado en un modelo tercerizado o contratado.
La impresión de este documento se considera COPIA NO CONTROLADA y no se garantiza que esta corresponda a la versión
vigente, salvo en los procesos que usan sello. Esta información es de carácter confidencial y propiedad de la Secretaría
Distrital de Salud (SDS); está prohibida su reproducción y distribución sin previa autorización del proceso que lo genera,
excepto en los requisitos de ley.
1
3. MARCO LEGAL
Concepto de calidad y pruebas del software
En el contexto del proceso de desarrollo de software se entendía la calidad desde los

criterios básicos:
• Cumplimiento de los requisitos: “Conformance to requirements” (Crosby -1979).

• Listo para su uso: “Fitness for use” (Juran and Gryna -1970).
En la década de los 90’s, el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE, por sus
siglas en inglés) publicó un Diccionario de Computación como parte de su estándar IEEE
610 - 1990 [IEEE, 1990] y definía al software como “los programas de ordenador, los
procedimientos y, posiblemente la documentación asociada y los datos relativos a la
operación de un sistema informático”, adicionalmente definió como calidad “el grado con el
que un sistema componente o proceso cumple con los requisitos específicos y las
necesidades o expectativas del cliente o usuario”.
En 1991 la Organización Internacional de Estándares (ISO) y la Comisión Internacional

Electrotécnica (IEC) editaron de manera conjunta la norma internacional ISO/IEC 9126
[ISO/IEC-9126, 1991] que define calidad de software como “la totalidad de características de
un producto de software que le confiere la capacidad de satisfacer necesidades explícitas e
implícitas.
Como aporte adicional en 1993 Pressman [Pressman, 1993] definió la calidad de software
como “la concordancia del software con los requisitos explícitamente establecidos, con los
estándares de desarrollo expresamente fijados y con los requisitos implícitos, no
establecidos formalmente pero que desea el usuario”.
Las actividades desarrolladas en la fase de pruebas hacen parte del ciclo de vida del
desarrollo de software, estas actividades permiten tener cierta certeza sobre la funcionalidad
esperada del sistema desarrollado, incluso permite verificar los flujos de excepción a fallos
del sistema, estos pueden ser propios de la aplicación u ocasionados por causas externas al
sistema.
La realización de estas pruebas de software, basadas en una metodología ágil de ejecución

de pruebas, donde se definan y ejecuten tareas de verificación, garantizan la condición de
calidad esperada por él sistema; estas pruebas pueden cumplir con principios ISTQB®
(International Software Testing Qualifications Board)
2
El marco de referencia aquí definido se suscribe a los siguientes estándares:
ISO/ IEC/ IEEE29119 Software Testing: Es un conjunto de normas acordadas

internacionalmente para pruebas de software que se pueden utilizar dentro de cualquier
ciclo de vida u organización de desarrollo de software.
ISO / IEC 29119-1: Conceptos y definiciones (publicado en septiembre de 2013)

ISO / IEC 29119-2: Procesos de prueba (publicado en septiembre de 2013)
ISO / IEC 29119-3: Documentación de prueba (publicada en septiembre de 2013)
ISO / IEC 29119-4: Técnicas de prueba (en etapa DIS, anticipando la publicación a finales
de 2014)
ISO / IEC 29119-5: Prueba dirigida por palabras clave (en etapa de CD, anticipando la
publicación en 2015)
Los procesos definidos en ISO / IEC / IEEE 29119-2:
ISO / IEC 33063: Modelo de evaluación de procesos (en etapa DIS)
Los estándares ISO / IEC / IEEE 29119 reemplazan una serie de estándares de prueba de
software existentes:
Documentación de prueba IEEE 829

Prueba de unidad IEEE 1008
BS 7925-1 Vocabulario de términos en pruebas de software
BS 7925-2 Estándar de prueba de componentes de software
• Estándares “de facto” aceptados por la industria.
Es conveniente recordar que la intención de las actividades de pruebas es asegurar la

calidad de los productos de software desarrollados y con esto lograr niveles de satisfacción
del cliente y de usuario favorables para la organización.
3
4. GENERALIDADES
Metodología
En la metodología de pruebas se deben establecer todas las etapas con sus actividades
para ser realizadas durante el proceso de prueba de un producto entregado de software.
Esta metodología debe permitir obtener la descripción de cada actividad a realizar, y a su
vez debe establecer la documentación de entrada necesaria, así como la documentación de
salida que se obtendrá durante el proceso de pruebas.
Para los desarrollos entregados a la entidad por empresas o terceros, el contratista debe
definir el proceso de pruebas y la metodología que serán ejecutadas durante la realización
de los proyectos de desarrollo de software. Los proyectos de desarrollo y mantenimiento de
software siguen una metodología que incluye fases, actividades y entregables del producto
de software desarrollado. El proceso de pruebas definido por el proveedor deberá estar
completamente alineado con la o las metodologías definidas para el desarrollo del software
de la entidad, por tanto, el contratista deberá contemplar la ejecución de las actividades
definidas de forma paralela a las fases de desarrollo definidas en los proyectos de desarrollo
de software, y como complemento necesario a éstos. El control de la calidad asignado al
proyecto permitirá determinar los niveles y tipologías de pruebas que deben contemplarse y
aplicarse según la metodología usada
Planeación
Bajo el esquema de desarrollo de proyectos, el equipo de pruebas hace parte de la

planificación aportando información referente a la definición de los casos de prueba acorde a
los casos de usuario diseñados por el analista funcional. Estos casos de prueba deben
discriminar que tipos de prueba que se deben realizar y probar específicamente. Este
documento se realiza apoyado en los desarrolladores y el analista de pruebas.
Ejecución
Durante la ejecución de las actividades necesarias para el proceso de pruebas es necesario

contemplar la configuración de ambientes de trabajo, ejecución de casos de prueba,
elaboración de documentación e informes de seguimiento, registro en herramientas de
seguimiento aceptada por el equipo de pruebas y el equipo responsable del producto de
software. Durante la ejecución de pruebas se deben realizar actividades para cubrir
aspectos como elaboración y ejecución de pruebas acorde a las siguientes actividades:
• Pruebas de Caja Negra: se limitan a que el tester pruebe con “datos” de entrada y estudie
como salen, sin preocuparse de lo que ocurre en el interior. Principalmente, se centran en
módulos o charters de interfaz de usuario (pantalla, ficheros, canales de comunicación…)
pero suelen ser útiles en cualquier módulo ya que todos o la mayoría tienen datos de
4
entrada y salida que se pueden comprobar y verificar. Como cualquier otra prueba, las
de caja negra se apoyan y basan en la especificación de requisitos y documentación
funcional
• Pruebas Software de Regresión y las Re-pruebas: Una vez que un defecto ha sido
corregido, toca volver a probar el software para confirmar que el defecto ha sido eliminado.
Son pruebas repetidas o Re-Pruebas.
• Pruebas de Regresión: consisten en volver a probar un componente, tras haber

sido modificado, para descubrir cualquier defecto introducido, o no cubierto previamente,
como consecuencia de los cambios. Los defectos pueden encontrarse tanto en el software
que se ha cambiado como en algún otro componente. Se ejecutan cuando se cambia el
software o su entorno.
El criterio para decidir la extensión de estas Pruebas de Regresión está basado en el riesgo
de no encontrar defectos en el software que anteriormente estaba funcionando
correctamente. Estas realizan sobre un componente ya probado, para verificar que no
presenta nuevos defectos cuando se realiza una modificación después de dichas pruebas.
Este tipo de pruebas software deben ser repetibles si han de usarse suelen ser bastante
estables para actividades de automatización de pruebas software.
• Pruebas Funcionales: El alcance de las pruebas desde el punto de vista funcional, estará
acorde con los requerimientos entregados por la entidad y con el diseño de los módulos
correspondientes, considerando: la integración con otros aplicativos o plataformas,
validaciones de usabilidad y de excepción, y reglas del negocio.
Pruebas de Aceptación de Usuario (UAT): Definir con el usuario final o funcional los casos
prueba considerados en la ruta crítica, y acompañar al usuario en la realización de pruebas
para los casos previamente definidos y aprobados, con el fin de obtener su visto bueno con
respecto a la solución implementada para suplir sus necesidades.
Pruebas de Casos de Uso : Cuando los proyectos sean contratados y exigan los casos de
Uso las pruebas se realizaran para cada caso de uso generado en el sistemas y el sistema
en general.
Gestión de Incidencias
El proceso de gestión de incidencias está directamente relacionado con la ejecución de

pruebas y el seguimiento que de estas se realiza, así mismo, es utilizado para el reporte de
incidencias generadas por otros procesos como la verificación documental y las auditorías
referidas. El contratista deberá indicar como soporta y maneja la gestión de incidencias.
5
Reportar las observaciones y hacer el seguimiento. Las observaciones que resultan de

las pruebas registradas en el Sistema de Gestión de Versiones y se muestran inicialmente
como Estado Pendiente.
El programador atenderá las mismas para la verificación y conformidad del Área de Control
de Calidad, dándolas por Superadas si corresponde.
En caso de no proceder se definirán como Anuladas y si quedan pendientes de atención se

indican como Siguiente Versión.
CONFORMIDAD
1) Dar la Conformidad. El conjunto de pruebas realizadas y la corrección de las

observaciones encontradas permiten confirmar la salida de la versión a producción.
Para dar la conformidad se usan los siguientes criterios: - Todas las pruebas
planificadas han sido ejecutadas. - Todas las observaciones identificadas han sido
resueltas o definidas como Siguiente Versión.
2) Pase a producción En este proceso de emitirá concepto técnico desde el Área de

Control de Calidad- pruebas, al Área de TIC indicando que la revisión ha sido
culminada en el ambiente de pruebas y que está disponible a producción.
3) Informe Final de Pruebas Terminada cada versión el equipo asignado de pruebas

realiza el Informe Final de Pruebas.
6
5. GLOSARIO
Caso de prueba: Se refiere a la documentación en la que se describen las entradas,

condiciones y salidas.
Fallo: Es la incapacidad de un sistema o de alguno de sus componentes para realizar las

funciones requeridas dentro de los requisitos de rendimiento especificados.
Iteración: Una iteración es un ciclo de trabajo durante el cual el equipo de desarrollo estima,
planea, se compromete, desarrolla y entrega una versión de software que contiene un
conjunto de requerimientos solicitados por el ETT y el mismo equipo de desarrollo.
Pruebas: Es una actividad en la cual un sistema o uno de sus componentes se ejecuta en

dos o más circunstancias previamente especificadas, los resultados se observan se
registran y se realiza una evaluación de algún aspecto.
Pruebas de Integridad: Esta soportada por las pruebas básicas y validan que el sistema no
se vea afectado por ninguno de los cambios realizados durante la entrega de la versión por
el equipo de desarrollo.
Pruebas Unitarias: Son pruebas dirigidas a probar clases java aisladamente y están
relacionadas con el código y la responsabilidad de cada clase y sus fragmentos de código
más críticos
Pruebas obligatorias: Se probarán los desarrollos nuevos implementados en la versión,

estos desarrollos se probarán con los guiones de prueba que fueron recibidos por parte del
funcional. En estas pruebas obligatorias se realizarán unas pruebas libres, las cuales
realizarán pruebas importantes como pruebas de envíos y parametrización.
7
6. BIBLIOGRAFIA
• International Software Testing Qualifications Board [istqb], “Certified Tester

Foundation Level Syllabus. Released version 2011”, 2011 [en línea]. Disponible en:
http://www.istqb.org/downloads/send/2-foundation- level-documents/3-foundation-
level-syllabus-2011.html4o nombres de autores.
• ieee Computer Society, “Guide to the Software Engineering Body of Knowledge
Swebok”, ieee Computer Society, pp. 10-40, 2004 [en línea]. Disponible en:
https://www.computer.org/web/swebok/v3.
• Pruebas de software (ISO/IEC/IEEE 29119). En: Modelo para el gobierno de las TIC
basado en las normas ISO. C.M. Fernández Sánchez y M. Piattini Velthuis (c.). Cap.
10, pp. 297-318. Editorial AENOR, ISBN: 978-84-8143-790-4.
• Standarization effort: ISO/IEC 29119 Software Testing. AST Network Meeting,
Seville, 2011-10-19.
8

81 SDS Tic LN 004 Lineamiento Tecnico de Pruebas

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

81 SDS Tic LN 004 Lineamiento Tecnico de Pruebas

Transféré par

Droits d'auteur :

Formats disponibles

2018

Lineamiento Técnico Pruebas

El servicio de ejecución de pruebas de software se prestará en las instalaciones de la

Concepto de calidad y pruebas del software

En el contexto del proceso de desarrollo de software se entendía la calidad desde los

• Cumplimiento de los requisitos: “Conformance to requirements” (Crosby -1979).

En 1991 la Organización Internacional de Estándares (ISO) y la Comisión Internacional

La realización de estas pruebas de software, basadas en una metodología ágil de ejecución

El marco de referencia aquí definido se suscribe a los siguientes estándares:

ISO/ IEC/ IEEE29119 Software Testing: Es un conjunto de normas acordadas

ISO / IEC 29119-1: Conceptos y definiciones (publicado en septiembre de 2013)

Los procesos definidos en ISO / IEC / IEEE 29119-2:

ISO / IEC 33063: Modelo de evaluación de procesos (en etapa DIS)

Documentación de prueba IEEE 829

• Estándares “de facto” aceptados por la industria.

Es conveniente recordar que la intención de las actividades de pruebas es asegurar la

Bajo el esquema de desarrollo de proyectos, el equipo de pruebas hace parte de la

Durante la ejecución de las actividades necesarias para el proceso de pruebas es necesario

• Pruebas de Regresión: consisten en volver a probar un componente, tras haber

El proceso de gestión de incidencias está directamente relacionado con la ejecución de

Reportar las observaciones y hacer el seguimiento. Las observaciones que resultan de

En caso de no proceder se definirán como Anuladas y si quedan pendientes de atención se

1) Dar la Conformidad. El conjunto de pruebas realizadas y la corrección de las

2) Pase a producción En este proceso de emitirá concepto técnico desde el Área de

3) Informe Final de Pruebas Terminada cada versión el equipo asignado de pruebas

Caso de prueba: Se refiere a la documentación en la que se describen las entradas,

Fallo: Es la incapacidad de un sistema o de alguno de sus componentes para realizar las

Pruebas: Es una actividad en la cual un sistema o uno de sus componentes se ejecuta en

Pruebas obligatorias: Se probarán los desarrollos nuevos implementados en la versión,

• International Software Testing Qualifications Board [istqb], “Certified Tester

Vous aimerez peut-être aussi