Norma ISO/IEC 14598
Marly Lorena Gallardo Rojas
Cod: 1083893151
Norma ISO/IEC 14598
En el campo de “Tecnología de la Información”, ISO (International Organization for Standardization)
e IEC (International Electrotechnical Commission) han establecido un comité técnico conjunto
ISO/IEC JTC, el cual preparó el estándar internacional ISO/IEC 14598-1.
La serie de estándares ISO/IEC 14598 brinda un conjunto de métodos para la medición y evaluación
de la calidad de un producto de software.
Esta norma está compuesta de las siguientes partes con el título “Tecnología de la Información –
Evaluación de Productos de Software”
- Parte 1: Descripción general
- Parte 2: Planificación y gerenciamiento
- Parte 3: Proceso para Desarrolladores
- Parte 4: Proceso para Adquirientes
- Parte 5: Proceso para Evaluadores
- Parte 6: Documentación de los módulos de evaluación
Norma ISO/IEC 14598
Parte 5. Proceso para Evaluadores.
Este proceso es utilizado por organizaciones encargadas de evaluar, provee los requisitos y guías
para la evaluación del producto software. Promueve las siguientes características de proceso
(repetible, Reproducible; Imparcial, Objetivo)
Repetible: Que el proceso bajo las mismas circunstancias, la misma configuración de las
herramientas utilizadas, el mismo producto y el mismo evaluador, la evaluación obtenga el mismo
resultado.
Reproducible: Es muy parecido a repetible pero no es lo mismo, ya que en este caso deben
mantenerse todas las condiciones iguales, salvo que el evaluador sea otro y en este caso también se
debe obtener el mismo resultado.
Imparcial: La evaluación debe resultar de los estudios realizados en esa instancia y no deben estar
influidos por resultados anteriores obtenidos para realizar la misma evaluación.
Objetivo: El evaluador no debe influenciarse por sentimientos propios o prejuicios sobre el producto
u similares.
Norma ISO/IEC 14598
Parte 5. Proceso para Evaluadores.
El proceso consta de 5 etapas:
1. Establecimiento de los Requerimientos
2. Especificación de la Evaluación
3. Diseño de la Evaluación
4. Ejecución de la Evaluación
5. Conclusión de la Evaluación
Norma ISO/IEC 14598
Parte 5. Proceso para Evaluadores.
Establecimiento de los Requerimientos.
El propósito de esta etapa es definir los objetivos de la evaluación. Esto se realiza a partir de los
requerimientos del solicitante, constituidos por una descripción a gran escala de lo que el cliente
quiere evaluar. Luego con el evaluador se realiza una definición del cubrimiento de la evaluación,
donde se especifica que es lo que se quiere evaluar y que no.
Como resultado de esta etapa se logran los “requerimientos de evaluación”. Esta constituido por una
descripción general del dominio de aplicación del producto en cuestión, un listado de requerimientos
de calidad a evaluar y una ponderación de dichos requerimientos en función del tipo de aplicación a
evaluar. Para la conformación del listado de los requerimientos se aconseja basarse en ISO/IEC 9126-
1, pero en caso de querer realizar evaluación sobre otros atributos de calidad, la última parte del
estándar indica un procedimiento para especificarlos.
Norma ISO/IEC 14598
Parte 5. Proceso para Evaluadores.
Especificación de la Evaluación.
Una vez que se tienen los Requerimientos de Evaluación, los cuales son obtenidos en la etapa
anterior, es que estamos en condiciones de pasar a la próxima etapa. Esta es la Especificación de la
Evaluación. Esta etapa tiene como propósito especificar las mediciones a ser tomadas sobre los
atributos de calidad que se definieron en la etapa anterior. Además, se desea brindar un nivel de
detalle suficiente como para asegurar que el proceso sea repetible y reproducible, objetivo que se
tiene que tener presente durante todas las etapas.
Norma ISO/IEC 14598
Parte 5. Proceso para Evaluadores.
Diseño de la Evaluación.
Una vez terminada la etapa de Especificación de la Evaluación, en la cascada sigue la etapa de
Diseño de la Evaluación. Esta etapa tiene como propósito documentar los procedimientos y
métodos a ser usados en la evaluación. A su vez es de interés especificar aquí los requerimientos a
ser utilizados en la Evaluación.
Norma ISO/IEC 14598
Parte 5. Proceso para Evaluadores.
Ejecución de la Evaluación.
Una vez que las actividades correspondientes con la etapa del “Diseño de la Evaluación” han sido
finalizadas, generándose así el Plan de la Evaluación, se comienza con la etapa de la Ejecución de la
Evaluación, la cual tiene como propósito el llevar a cabo lo establecido el plan anteriormente
definido, registrando los resultados obtenidos y las acciones tomadas.
Norma ISO/IEC 14598
Parte 5. Proceso para Evaluadores.
Conclusión de la Evaluación.
El propósito principal de esta etapa es el de generar el Informe Final de la Evaluación mediante una
revisión conjunta con el cliente.
Tipos de pruebas de Software
Manual vs Automated testing.
De manera general, lo primero que debemos tener en cuenta es que existen pruebas de software manuales y
pruebas de software automatizadas.
Las pruebas manuales son llevadas a cabo por personas, quienes navegan e interactúan con el software (usando
herramientas adecuadas para cada caso).
Estas pruebas resultan costosas, ya que se requiere contar con un profesional encargado de esta labor; para
configurar un entorno y así mismo ejecutar las pruebas.
Como es de esperarse, estas pruebas están expuestas a errores humanos: por ejemplo, se pueden cometer errores
tipográficos u omitir pasos durante la prueba.
Tipos de pruebas de Software
Manual vs Automated testing.
Las pruebas automatizadas, por el contrario, son realizadas por máquinas, que ejecutan un "test script" que ya ha
sido escrito previamente.
Estos tests (o pruebas) pueden variar mucho en cuanto a complejidad:
desde verificar que el método de una clase específica funcione correctamente,
hasta asegurar que una secuencia de acciones complejas en la UI se lleven acabo correctamente y devuelvan los
resultados esperados.
Estas pruebas son más rápidas y confiables que las que se llevan a cabo manualmente – pero la calidad de estas
pruebas automatizadas depende de qué tan bien escritos se encuentren los "tests scripts" (código que determina
qué es lo que se hará en la prueba).
Automated testing es un componente clave para continuous integration y continuous delivery, y es una excelente
manera de escalar tus procesos de QA (quality assurance, aseguramiento de calidad) a medida que agregas nuevas
características a tu aplicación.
Tipos de pruebas de Software
Unit tests
Las pruebas unitarias son a bajo nivel (cercanas al código fuente de nuestra aplicación).
Este tipo de testing consiste en probar de forma individual las funciones y/o métodos (de las clases, componentes
y/o módulos que son usados por nuestro software).
Debido a lo específicas que son, generalmente son las pruebas automatizadas de menor coste, y pueden ejecutarse
rápidamente por un servidor de continuous integration (integración continua).
Tipos de pruebas de Software
Unit tests
-Idealmente, cuando planeamos y escribimos pruebas unitarias, debemos aislar la funcionalidad hasta un punto en
que no se pueda desglosar más, y entonces escribir pruebas a partir de ello. Justamente, el nombre de este tipo de
testing hace referencia a una "unidad de código", que es independiente del resto.
-Estas pruebas verifican que el nombre de la función o método sea adecuado, que los nombres y tipos de los
parámetros sean correctos, y así mismo el tipo y valor de lo que se devuelve como resultado.
.Dado que las pruebas unitarias no deben tener ningún tipo de dependencia, se suele reemplazar los llamados a
APIs y servicios externos por funcionalidad que los imite (para que no exista interacción que vaya más allá de la
unidad que está siendo probanda).
-En muchos casos inclusive se suele reemplazar las consultas a bases de datos, de modo que la prueba se enfoque
en operar a partir de los valores de entrada, sin depender de ninguna fuente externa.
-Si no es factible aislar el uso de bases de datos de nuestras pruebas unitarias, será importante tener en cuenta el
rendimiento y buscar optimizar nuestras consultas.
Tipos de pruebas de Software
Integration tests
Las pruebas de integración verifican que los diferentes módulos y/o servicios usados por nuestra aplicación
funcionen en armonía cuando trabajan en conjunto.
Por ejemplo,
-pueden probar la interacción con una o múltples bases de datos,
-o asegurar que los microservicios operen como se espera.
Las pruebas de integración son típicamente el paso siguiente a las pruebas unitarias.
Y son generalmente más costosas de ejecutar, ya que requieren que más partes de nuestra aplicación se configuren
y se encuentren en funcionamiento.
Tipos de pruebas de Software
Functional tests
Las pruebas funcionales se centran en los requerimientos de negocio de una aplicación.
Estas pruebas verifican la salida (resultado) de una acción, sin prestar atención a los estados intermedios del sistema
mientras se lleva a cabo la ejecución.
A veces existe cierta confusión entre "integration tests" y "functional tests", ya que ambos requieren que múltiples
componentes interactúen entre sí.
La diferencia es que,
-una prueba de integración puede simplemente verificar que las consultas a una base de datos se ejecuten
correctamente,
-mientras que una prueba funcional esperaría mostrar un valor específico a un usuario, en concordancia a lo
definido por los requerimientos del producto.
Tipos de pruebas de Software
End-to-end tests
Las pruebas de punta a punta replican el comportamiento de los usuarios con el software, en un entorno de
aplicación completo.
Estas pruebas verifican que los flujos que sigue un usuario trabajen como se espera, y pueden ser tan simples como
-cargar una página web,
-iniciar sesión,
o mucho más complejas,
-verificando notificaciones vía email,
-pagos en línea, etcétera.
Las pruebas end-to-end son muy útiles, pero son costosas de realizar; y pueden ser difíciles de mantener cuando
son automatizadas.
Por tanto, es recomendable tener unas pocas pruebas end-to-end, que resulten claves para nuestra aplicación, y
confiar en mayor medida en las pruebas a bajo nivel (como pruebas unitarias y pruebas de integración) para
detectar rápidamente aquellos cambios que impactan negativamente sobre nuestra aplicación.
Tipos de pruebas de Software
Regression testing
Las pruebas de regresión verifican un conjunto de escenarios que funcionaron correctamente en el pasado, para
asegurar que continúen así.
-No debemos agregar nuevas características a nuestro regression test suite hasta que las pruebas de regresión
actuales pasen.
-Una falla en una prueba de regresión significa que una nueva funcionalidad ha afectado otra funcionalidad que era
correcta en el pasado, causando una "regresión".
-Una falla en un test de regresión podría indicar también que hemos vuelto a producir un bug que ya había sido
resuelto en el pasado.
Tipos de pruebas de Software
Smoke testing
Las pruebas de humo son pruebas que verifican la funcionalidad básica de una aplicación.
-Se pretende que sean pruebas rápidas de ejecutar,
- y su objetivo es asegurar que las características más importantes del sistema funcionan como se espera.
Los smoke tests pueden ser muy útiles:
-justo después de construir una nueva versión de nuestra aplicación, para decidir si estamos listos para ejecutar
pruebas más costosas,
-o justo después de un proceso de deployment, para asegurar que la aplicación está funcionando adecuadamente
en el nuevo entorno desplegado.
Tipos de pruebas de Software
Smoke testing
Más detalles sobre los smoke tests:
-Son un conjunto de pruebas automatizadas de alto nivel, y seleccionadas estrictamente.
-Tienen lugar entre las pruebas de integración y las pruebas de regresión. Y están ahí para verificar que la
funcionalidad principal del sitio opera como es debido.
-Se dice que el término "prueba de humo" tiene su origen en la plomería. Si se podía ver humo saliendo de una
tubería, significaba que tenía fugas y era necesario hacer reparaciones.
No son pruebas específicas. Son pruebas significativas que ocurren a un nivel más general. Idealmente deben
ejecutarse cada día, en cada uno de los entornos.
De modo que si un smoke test falla, significa que hay un grave problema con la funcionalidad de nuestro software.
Por tanto no deberíamos desplegar cambios nuevos hasta que los fallos sean atendidos. Y si fallan en producción, su
corrección tendrá la más alta prioridad.
Tipos de pruebas de Software
Acceptance testing
Las pruebas de aceptación son pruebas formales, ejecutadas para verificar si un sistema satisface sus
requerimientos de negocio.
Estas pruebas requieren que el software se encuentre en funcionamiento, y se centran en replicar el
comportamiento de los usuarios, a fin de rechazar cambios si no se cumplen los objetivos. Estos objetivos pueden ir
más allá de obtener una respuesta específica, y medir el rendimiento del sistema.
Las pruebas de aceptación:
-Son usualmente un conjunto de pruebas manuales que se realizan luego de que una fase de desarrollo ha finalizado
(de modo que se pueda volver rápidamente e iterar si algo no está correcto).
-Verifican que la características de nuestro software estén alineadas con todas las especificaciones iniciales y
criterios de aceptación.
-Suelen realizarse luego de las pruebas unitarias o de integración, para evitar que se avance mucho con el proceso
de prueba, y determinar a tiempo si se necesitan cambios significativos.
Para que este tipo de pruebas se lleve a cabo correctamente resulta importante que los responsables del proyecto
definan los criterios de aceptación justo antes de empezar a trabajar en el mismo. Así mismo, cualquier
requerimiento adicional que surja durante el proceso deberá verse reflejado en tales criterios de aceptación.
Tipos de pruebas de Software
Performance testing
Las pruebas de rendimiento verifican cómo responde el sistema cuando éste se encuentra bajo una alta carga.
Estos tests son no-funcionales, y pueden tener diversas formas para entender
-la fiabilidad,
-estabilidad
-y disponibilidad de la plataforma.
Por ejemplo, pueden observar los tiempos de respuesta cuando se ejecuta un alto número de requests (consultas al
servidor), o ver cómo se comporta el sistema ante una cantidad significativa de datos.
Las pruebas de rendimiento son, por su naturaleza, bastante costosas de implementar y ejecutar, pero pueden
ayudarnos a comprender si nuevos cambios van a degradar nuestro sistema (como hacerlo más lento o aumentar su
consumo de recursos).
Las pruebas de rendimiento no fallan del mismo modo en que lo hacen las demás pruebas. En vez de ello su
objetivo es recolectar métricas y definir objetivos por alcanzar.
Generalmente es buena idea realizar pruebas de este tipo ante nuevos lanzamientos y/o refactorizaciones
importantes en el código.
