----
Toda mi actividad la estoy haciendo en el siguiente blog
http://www.lecciones-aprendidas.info/
Estás cordialmente invitad@ a visitarme allí
----
domingo, octubre 29, 2017
miércoles, febrero 13, 2013
Por dónde comenzar a leer de SCRUM y de Agile, a quién seguir. VITAMINA CEREBRAL
Hola a todos
tengo un buen amigo Jorge Luis Valderrama (@jvalde en twitter), actualmente estudia una maestría en Oxford (Inglaterra) y lleva más de 7 años trabajando con metodologías ágiles y escuchando a los gurús del tema.
Hablo bastante con é y bueno filosofamos el tema y como cambiar a nuesta Colombia de forma que podamos producir software de calidad con entregas rápidas de forma que el software por fin se vuelva un habilitador de negocios y no un riesgo al momento de la transformaciones empresariales.
Una vez , le pregunte sobre a quien leer y a quien seguir en la industria y por donde empezar a volverme bueno en temas ágiles (aun estoy en pañales, lo reconozco, pero he dado mis pinitos - http://lecciones-aprendidas.blogspot.com/2012/09/mi-experiencia-con-scrum.html ).
He aquí la respuesta que me dió (y que hoy quiero compartir con ustedes):
----
SUBJECT DEL EMAIL: VITAMINA CEREBRAL
CONTENIDO DEL EMAIL:
Pillate este librito que esta sabroso que te adjunte, (Agile Survival Guide - Michael Sahota - 2012.pdf - no debo adjuntarlo pero si puedo mencionarlo)
Para leer, no tengo una lista de articulos, pero tengo una lista de gente que sigo y leo, son los respetados de la industria, los pioneros, los practicantes, los siempre involucrados con el aprendizaje:
Martin Fowler
Uncle Bob
Dan North
Paul Graham este man tiene un articulo que puede ser la biblia de las start ups http://www.paulgraham.com/growth.html
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
James Shore
Jurgen Apelo
Libros, hay unos que son obligatorios, esta la biblia continuous delivery: http://continuousdelivery.com/
The pragmatic programmer
Refactoring to Patterns
Refactoring: Improving the Design of Existing Code
Growing Object-Oriented Software
Clean Code: A Handbook of Agile Software Craftsmanship
Los ultimos son muy tecnicos, como yo te he dicho ando muy enfocado a ser buen desarrollador, los buenos programadores, generan, mejores resultados, mejores aplicaciones, por eso me gusta el cuento de software craftsmanship porque es un pacto con el aprendizaje, con la calidad, con el mejoramiento continuo
Sitios
ThoughtWorks es la empresa a seguir, ahi trabajan muchos de los gurus y son los que moldean para donde vamos en terminos de tecnologia y de metodologia!
-
Jorge Luis Valderrama A.
Java Developer.
Tribal London.
-------
Espero que Valde (como le decimos los amigos) se anime pronto a escribir y desde las letras y las iniciativas cambiemos el mundo y/o los metros cuadrados que nos fueron asignados.
Buena lectura y buena búsqueda.
domingo, octubre 07, 2012
Scrum vs PMBOK 4.0
Comparto esta vez un interesante trabajo elaborado por Enrique Arango Lyons, estudiante de mi curso de gerencia de proyectos informáticos, que dicto en el pregrado de la Universidad Eafit en la ciudad de Medellín,Colombia.
Para ver, hacer clic aquí
_
Para ver, hacer clic aquí
_
sábado, septiembre 29, 2012
Un Framework Unificado de Desarrollo de Software para los Pregrados Relacionados con Ingeniería de Sistemas
Descargar este artículo en PDF (clic aquí)
1
Estado actual de la industria
2
La academia vs la gestión basada por
procesos.
2.1
Un esquema
desarticulado de docentes frente al Proceso Software en las prácticas académicas
2.2
Forma de
trabajo de los estudiantes frente a las prácticas académicas que impliquen
construcción de software y componentes en escenarios desarticulados.
2.3
Consecuencias
de un enfoque no articulado en el Proceso Software de proyectos académicos.
3
Una propuesta
de un Framework Metodológico del Proceso Software en la Academia.
4
Beneficios
esperados del framework metodológico.
5
Referencias
Un Framework
Unificado de Desarrollo de Software para los Pregrados Relacionados con
Ingeniería de Sistemas
Jorge Hernán Abad
Londoño
Universidad
Eafit, Medellín, Colombia.
jabadlon@eafit.edu.co
jorge.abad@gmail.com
Septiembre 2012
Septiembre 2012
Resumen
La adopción de la
gestión basada en procesos por parte de la industria del software y el
establecimiento de repositorios de procesos en donde los ingenieros puedan
consultar y adaptar el Proceso Software según el tipo de proyecto a
desarrollar, marca una invitación a la academia relacionada con los programas
académicos de las carreras de Ingeniería de Sistemas, Ciencias de la Computación,
Ingeniería Informática y afines, a contar con métodos y procesos depositados y
administrados en un framework metodológico que le permita a los estudiantes
(orientados por los docentes) construir software para las diferentes prácticas
académicas, apoyándose en estándares, logrando de esta forma una comprensión y
aprehensión de los procesos metodológicos, reduciendo así los tiempos de
adaptación de los egresados de estos programas académicos en la industria y
mejorando la calidad de los desarrollos realizados por ellos.
Palabras clave
Ingeniería de Software,
academia, proyectos académicos, trabajos de pregrado, SPEM, biblioteca de
métodos, biblioteca de procesos, Eclipse Process Framework, Proceso Software,
CMMI, RUP.
1
Estado actual de la industria
La industria del
software desde hace más de 20 años ha venido trabajando en una orientación por
procesos, apoyada tanto por el estándar ISO 9000, como por modelos específicos
para esta industria, como ISO/IEC 15504, ISO/IEC 12207, PSP (Personal Software Process), TSP (Team Software Process), Métrica 3,
Moprosoft, CMM y posteriormente CMMi, entre muchos otros. Como consecuencia, para
las organizaciones que los han adoptado de forma disciplinada y consciente les
ha significado una madurez en la ejecución y gestión del Proceso Software, que
les permite realizar proyectos exitosos en términos de cumplimiento de tiempo, costo
y alcance, calidad y satisfacción de los clientes.
Como lo expresa CHRISSIS
y otros [3] (afirmación que se ha convertido en el
fundamento de CMM y posteriormente de CMMi), un buen producto o servicio
depende de tres pilares: Personas, Técnicas y herramientas, y Procesos (ver Figura 1); por lo tanto, el buen resultado en la consecución de
productos y servicios dependerá fuertemente de los procesos establecidos para
construirlos, pues estos son la única variable de la ecuación de calidad y
productividad que depende de la definición y forma de trabajo de la
organización en sí misma; es decir, organizaciones de software con similares
talentos humanos y herramientas, producirán bienes y servicios similares o
disimiles entre sí, en función de los procesos de software definidos al
interior de ellas, siendo por ende la forma de ejecución del Proceso Software
el factor diferenciador y que agrega valor.
Los procesos
dentro de las organizaciones de software son creados, publicados y mantenidos
por áreas como gerencias de calidad, gerencias de procesos, gerencias de
producción y/o PMO (Project Managment Office); y los Ingenieros de Software son
capacitados en el uso de estos procesos para la producción de software. Estas
capacitaciones en uso de estos Procesos Software, al igual que el tiempo en que
los ingenieros son completamente productivos (o sea, su dominio de los procesos
es tal que no requieren ayuda de otros compañeros, o de las áreas dueñas de los
procesos) dependerá en su gran mayoría en lo habituado que este el Ingeniero a
una orientación por procesos, siendo este hábito enseñado desde una compañía
anterior que provenga o desde la formación universitaria recibida para los
recién egresados.
2
La academia vs la gestión basada por
procesos.
Desde hace más de
10 años las universidades en Colombia trabajan en su acreditación institucional
(ver Figura 2), que consiste en la adopción de modelos de gestión para
los procesos académicos, buscando la calidad en la educación superior y el cumplimiento
de estándares internacionales.
Con la
acreditación, el que-hacer académico queda gobernado por el ciclo de mejora
PHVA, y toda la comunidad académica queda inmersa en una ejecución de
actividades y procesos que son gestionados y llevados a ciclos de mejora.
Por lo tanto,
profesores, alumnos, cuerpo académico y personal de soporte están guiados por
la ejecución de procesos, tareas, procedimientos, actividades, manuales, que
están gobernados por un sistema de calidad, administrado y mantenido por la
organización educativa.
Los estudiantes
de programas como, Ingeniería de Sistemas, Ciencias de la Computación, Ingeniería
Informática y afines, a pesar de encontrarse inmersos en un escenario gobernado
por procesos (dentro de instituciones acreditadas, o que trabajan en su
acreditación), y de ser instruidos en metodologías de desarrollo de software,
que se encargan de presentar el Proceso Software como un cuerpo coherente y
organizado de conocimiento, buenas prácticas, actividades, que conducen al
ingeniero y al equipo involucrado en la producción de buen software, no logran
percibir, ni adoptar este Proceso Software como fundamental para la realización
de las prácticas, laboratorios, proyectos de semestre, proyectos de grado, e
incluso tesis y proyectos de investigación, que impliquen algún tipo desarrollo
de software.
A continuación se
presentan algunas de las situaciones características que se evidencian en el
entorno académico relacionado con Ingeniería de Sistemas, cuando se requiere
construir software en escenarios académicos.
2.1
Un esquema
desarticulado de docentes frente al Proceso Software en las prácticas académicas
En entornos de
trabajo en donde los docentes se encuentran desarticulados en su forma de
solicitar prácticas y desarrollos de software a los estudiantes, es decir, no
existen formas estandarizadas de recibir los entregables del Proceso Software
construidos por los estudiantes en las materias durante el ciclo de formación,
se presentan las siguientes situaciones:
- No se trabaja de forma estandarizada,
- En los cursos donde se requiere realizar desarrollo de software o
componentes, los entregables esperados son diferentes.
- Aunque el resultado (que involucre desarrollo de software) es lo más
importante del proyecto a ser evaluado, el docente en muchos casos no
verifica el uso de las buenas prácticas, herramientas y el proceso utilizado
al momento de construirlo, ni de los distintos roles que juegan los
estudiantes en un proyecto de desarrollo
- Se presentan esfuerzos aislados de diferentes docentes para inculcar
buenas prácticas de desarrollo de software, pero no es un trabajo
coordinado por todo el Departamento/Carrera/Equipo.
- Existen casos de profesores que enseñan sólo su especialidad, sin tener
en cuenta el estado de la industria, del mercado local e internacional.
2.2
Forma de
trabajo de los estudiantes frente a las prácticas académicas que impliquen
construcción de software y componentes en escenarios desarticulados.
De igual forma,
los estudiantes al no contar con un referente organizado que les exija una
forma estructurada de producir software, presentan las siguientes características
en estos escenarios académicos:
- La construcción del software (componente, sistema) se enfoca sólo en
el resultado y no se emplean buenas prácticas de manera generalizada.
Estas solo son empleadas por los estudiantes más curiosos. Bajo este esquema,
sólo importa el resultado y carece de valor el proceso.
- Los estudiantes construyen software de la forma que creen o les dicen
sus compañeros; no son guiados por un MAESTRO (un experto en producción de
software).
- En la construcción de software se emplean los artefactos y prácticas
que les “obligan” algunos profesores en unas materias, que después de ser aprobadas,
son olvidados dichos artefactos.
- Los estudiantes aprenden a desarrollar software por “voz a voz” y no
saben cuál es la mejor forma de hacerlo.
- El Proceso Software no se adhiere a su “ADN académico”, quedando sólo
como un referente cognitivo para el estudiante y no como una herramienta
indispensable para su ciclo formativo y desempeño profesional.
2.3
Consecuencias
de un enfoque no articulado en el Proceso Software de proyectos académicos.
A continuación se
enumeran algunas consecuencias de un enfoque no articulado del Proceso Software,
tanto para los estudiantes, docentes e industria de IT en general:
- Los estudiantes no perciben el proceso software como un esquema formal
y coherente de trabajo, de forma que no se identifican ni se adhieren al
ADN cognitivo del estudiante las mejores prácticas para llevar a cabo un
proyecto de software exitoso.
- Ausencia de uniformidad en los entregables producidos tanto en la
documentación funcional como en la técnica a lo largo de todo el ciclo
formativo.
- Carencia de documentación de soporte al ciclo de vida en los proyectos
académicos de software y poca valoración de la misma durante el ciclo
formativo y el ejercicio profesional.
- Para las materias diferentes a Ingeniería de Software, no hay un
esquema de control en el cual se asegure que se están adoptando las mejores
prácticas de la industria en la producción de software.
- La evaluación de los trabajos académicos se concentra fundamentalmente
en los resultados (producto de software), sin considerar el proceso realizado
y los roles involucrados, dejando de lado la posibilidad de incorporar esquemas
de evaluación que consideren componentes del producto y del proceso: manejo
de versiones y repositorio, documentación, patrones, pruebas unitarias, pruebas
funcionales, entre otros.
- Falta de uniformidad de criterios para construir, gestionar, y evaluar
proyectos de software en las asignaturas que los incluyen.
- Los frameworks metodológicos son conocidos por los estudiantes como
una referencia etérea, mas no son concebidos como una herramienta clave para
el desempeño y éxito profesional.
- En consecuencia, es escasa la adopción de las mejores prácticas de la
industria de software por parte de los alumnos egresados debido a la baja
adherencia y uso de las mismas durante el ciclo formativo.
- En la industria de software se incurre en largos periodos de entrenamiento
de los nuevos profesionales debido a su desconocimiento de metodologías,
procesos, buenas prácticas de desarrollo y construcción de software, con
los reconocidos altos costos que esto conlleva y exagerados tiempos para
que sean productivos.
- En muchos casos, los desarrollos realizados por los recién egresados están
viciados por errores metodológicos que influencian negativamente la
iniciativa.
- Los ciclos de certificación en modelos de procesos y de referencia
tipo ISO 9000, CMMi, PSP, TSP, son más largos debido a la baja adherencia
del Proceso Software en el futuro profesional.
3
Una propuesta
de un Framework Metodológico del Proceso Software en la Academia.
Bajo este
escenario, en el cual existe una descontextualización y desarticulación general
del Proceso Software tanto de forma semestral como intersemestral (a excepción
de las materias y cursos de Ingeniería de Software, que su foco es el Proceso
mismo), se evidencia claramente que uno de los pilares de la Ingeniería de Sistemas
/ Ciencias de la Computación / Ingeniería Informática, el cual es la Ingeniería
de Software se encuentra en un panorama adverso de aprendizaje por parte del
futuro profesional.
Desde la
experiencia docente se observa, que si los conceptos aprendidos no son
empleados de manera continua a lo largo del ciclo formativo tienden a caer en
un olvido para el estudiante y a perder prioridad en su aplicabilidad para la
resolución de los distintos retos a los cuales se enfrenta. Por tanto, se
observa la necesidad de contar con una Biblioteca de Métodos o un Framework
Metodológico que se constituya en la base para construir software de manera
transversal y horizontal en el programa académico, convirtiéndose en parte del
ADN cognitivo del futuro profesional de TI, debido a su continua utilización.
Esta Biblioteca
de Métodos deberá contar, con:
·
Prácticas de desarrollo para construir componentes
simples.
·
Metodologías para construir sistemas de información
simples y complejos.
·
Procesos, actividades, tareas, roles y entregables que
sean reutilizables a lo ancho y largo de la biblioteca.
·
Ejemplos de aplicabilidad del framework, de forma que
tanto los profesores y estudiantes manejen la misma expectativa sobre lo que se
construirá y estos se constituyan en ejemplos, referentes y ayudas para
construir los diferentes componentes de software con sus distintos alcances a
considerar.
·
Repositorio de mejores prácticas, artículos, guías, plantillas,
formatos para guiar a los alumnos en los diferentes objetivos que se quieren
cumplir con los diferentes tipos de proyectos, tareas y prácticas asignadas a
lo largo de todo el ciclo profesional.
Figura 3: Terminología clave definida en la especificación del
SPEM 2.0, mapeado Contenido del Método versus Proceso. [7]
Esta biblioteca
se constituirá en el repositorio de conocimiento para construir software a lo
largo del pregrado y por ende, requerirá de estrategias de gestión que logren
una adecuada utilización. A continuación se enumeran estas estrategias:
·
Mantener el framework vigente, adicionando, modificando o
suprimiendo características innecesarias. Este mantenimiento es de revestida
importancia, debido a la velocidad y variabilidad de estándares y tendencias en
el ejercicio de la construcción de software.
·
Contar con Administradores del mismo, que se encarguen de
su adecuada divulgación, capacitación y uso. Los Administradores, que
corresponden a roles ejecutados por los docentes, deberán velar por la gobernabilidad
y continuidad, y estar acompañados por estudiantes que se encarguen de realizar
tareas de mantenimiento sobre el mismo, basados en cambios de tendencias, y
observaciones de la comunidad de usuarios y administradores.
·
Usuarios (estudiantes) que se encarguen de emplear el
framework y de realizar observaciones y sugerir ajustes al mismo.
Figura 4: Uso conceptual de framework SPEM 2.0, [7]
Esta estrategia
de gobierno del Framework Metodológico permitiría la realización permanente del
ciclo PHVA sobre el repositorio, de forma que se logre una constante mejora y
empleo del mismo.
Se sugiere que la
construcción de este Framework Metodológico sea apoyada por herramientas que permitan
su fácil mantenibilidad y cumplimiento con estándares de especificación de
procesos de Ingeniería de Software, como SPEM 2.0 (mantenido por la OMG). De
igual forma se sugiere el uso del Eclipse Process Framework como herramienta de
construcción y administración de los métodos y procesos construidos.
4
Beneficios
esperados del framework metodológico.
A continuación se enumeran los beneficios
esperados de la construcción y uso de un framework metodológico por parte de
los docentes de Ingeniería de Sistemas, el cual se convertiría así en el hilo conductor
para la realización de prácticas, componentes, sistemas de información,
proyectos de grado, trabajos del semestre, proyectos de investigación y tesis
de maestría al interior de la academia, que involucren producción de software:
- Una biblioteca de procesos y métodos que permita a los docentes y
alumnos contar con un referente unificado para construcción de software de
diferentes alcances dentro de la academia.
- Lograr una absorción del Proceso Software por parte de los
estudiantes.
- Un proceso “adherido” en “ADN cognitivo” por el uso coherente y
continuado por parte de los profesores, tanto a lo transversal como
horizontal del pregrado.
- Buenas prácticas de desarrollo de software empleadas por el estudiante
durante todas las prácticas de la carrera.
- Una documentación uniforme generada, tanto horizontal como
verticalmente en la carrera.
- Una industria con menores tiempos y costos de capacitación y de
certificación en estándares debido a la formación en procesos y buenas
prácticas de los egresados.
- Un sector software más fuerte y con menos ciclos de certificación en
estándares de la industria.
5
Referencias
[1] AHERN, Dennis M., CLOUSE, Aaron and
RICHARD TURNER, CMMI Distilled: A Practical Introduction to Integrated
Process Improvement, Addison Wesley, 2003
|
[2]
CENTRO NACIONAL DE TECNOLOGÍAS DE INFORMACIÓN.
Metodología de la red nacional de integración y desarrollo de software libre
(MeRinde): Guía detallada.
|
[3]
CHRISSIS, Mary Beth, KONRAD, Mike and SHRUM, Sandy; (2007). CMMI:
Guidelines for Process Integration and Product Improvement. Second Edition.
Pearson Education, Inc., Boston, MA, USA, 676 p.
|
[4]
CONCEJO NACIONAL DE ACREDITACION (C. N. A.).
Información estadística sobre acreditación de alta calidad. [en línea].
(Citada: 9 de Septiembre. 2012)
<http://www.cna.gov.co/1741/articles-188924_recurso_1.pdf>
|
[5]
DE LA VILLA, Manuel, RUIZ, Mercedes, RAMOS, Isabel.
Modelos de Evaluación y Mejora de Procesos: Análisis . (Citada: 9 de Septiemb
de 2012)
|
[6]
ECLIPSE. Eclipse Process Framework - Getting Started. [en línea]
(Citada: 17 de Junio de 2012). http://www.eclipse.org/epf/general/getting_started.php
|
[7]
ECLIPSE. Eclipse Process Framwork [en línea]. (Citada:
17 de Junio de 2012) <http://www.eclipse.org/epf/>
|
[8]
ECLIPSE. Introduction to OpenUP (Open Unified Process) [en
línea]. (Citada: 16 de Junio. 2012) <http://www.eclipse.org/epf/general/OpenUP.pdf>
|
[9]
ÉCOLE POLYTECHNIQUE DE MONTRÉAL. Unified Process for
Education (UPEDU) [en línea]. (Citada: 16 de Junio. 2012) <http://www.upedu.org/>
|
[10]FORD, Gary and GIBBS,Normanl, Mature
Profession of Software Engineering, SEI, 1996
|
[11]Guide to the Software Engineering
Body of Knowledge (SWEBOK) (Citada: 16 de Junio. 2012)
|
[12]HAUMER, Peter. Eclipse Process
Framework Composer. Part 1: Key Concepts. 2007. [en línea] (Citada: 17 de
Junio de 2012). <http://www.eclipse.org/epf/general/EPFComposerOverviewPart1.pdf>
|
[13]IBM. Rational Process Library: The
industry’s most robust collection of best practices guidance [en línea]. (Citada: 16 de
Junio. 2012) <http://www–01.ibm.com/software/awdtools/rmc/library/>
|
[14]OBJECT MANAGEMENT GROUP (OMG).
Software & Systems Process Engineering Metamodel Specification (SPEM)
Version 2.0. . [en línea]. (Citada: 17 de Junio de 2012)
<http://www.omg.org/spec/SPEM/2.0/PDF>
|
[15]PALACIO, Juan. Sinopsis de los modelos SW-CMM
y CMMI. 2006. [en línea] (Citada: 9 de Septiemb de 2012)
<http://www.navegapolis.net/files/articulos/sinopsis_cmm.pdf>.
|
[16]RUIZ, Francisco y VERDUGO, Javier. Guía de
Uso de SPEM 2 con EPF Composer Versión 3.0. [en línea]. (Citada: 17 de Junio
de 2012) < http://alarcos.esi.uclm.es/ipsw/doc/guia-spem2&epf_v30.pdf>.
|
[17]SOFTWARE ENGINEERING INSTITUTE. CMMI
® for SCAMPI Class A Appraisal Results. 2011 End-Year Update. [Informe]. -
Pittsburgh : [s.n.], 2012.
|
[18]SOFTWARE ENGINEERING INSTITUTE. CMMI
® for SCAMPI Class A Appraisal Results. 2011 End-Year Update. Pittsburgh,PA : s.n.,
2012.
|
[19]SOFTWARE ENGINEERING INSTITUTE. CMMI
for development, version 1.3 [en línea]. (Citada: 16 de Junio. 2012)
<http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm>
|
SOFTWARE EDUP - Una metodología de desarrollo de software para proyectos academicos
Comparto el sitio en el cual publique mi tesis de maestría
Es un framework metodológico para desarrollo de software en ambientes académicos.
Se encuentra basado en:
Es un framework metodológico para desarrollo de software en ambientes académicos.
Se encuentra basado en:
- RUP (IBM Rational Unified Process)
- CMMi
- PMBoK
- Algunas prácticas Ágiles
Fuentes
miércoles, abril 06, 2005
TIPOS DE PRUEBAS DE SOFTWARE
A continuación se describen las principales tipos pruebas que se pueden realizar a cualquier tipo de software. Cada prueba contendrá como mínimo a siguiente información:
- Objetivo de la prueba
- Descripción de la prueba
- Técnica
- Criterio de Completitud
- Consideraciones Especiales
PRUEBAS UNITARIAS
Prueba Unitaria
| Objetivo de la Prueba: | Se focaliza en ejecutar cada módulo (o unidad minima a ser probada, ej = una clase) lo que provee un mejor modo de manejar la integración de las unidades en componentes mayores.
Busca asegurar que el código funciona de acuerdo con las especificaciones y que el módulo lógico es válido. |
| Descripción de la Prueba: |
|
| Técnica: |
|
| Criterio de Completitud: |
|
| Consideraciones Especiales: | Para la elaboración de pruebas unitarias en java se puede utillizar el JUNIT y CACTUS. |
PRUEBAS DE INTEGRACIÓN
Prueba de Integración
| Objetivo de la Prueba: | Identificar errores introducidos por la combinación de programas probados unitariamente.
Determina cómo la base de datos de prueba será cargada.
Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan correctamente.
Verificar que las especificaciones de diseño sean alcanzadas.
Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente.
|
| Descripción de la Prueba: | · Describe cómo verificar que las interfaces entre las componentes de software funcionan correctamente. · Determina cómo la base de datos de prueba será cargada. · Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente. · Decide qué acciones tomar cuando se descubren problemas. Por cada Caso de Prueba ejecutado:
|
| Técnica: |
|
| Criterio de Completitud: |
|
| Consideraciones Especiales: | Ninguna |
Prueba de Regresión
| Objetivo de la Prueba: | Determinar si los cambios recientes en una parte de la aplicación tienen efecto adverso en otras partes. |
| Descripción de la Prueba: | En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados durante el debugging, mantenimiento o desarrollo de la nueva versión del sistema buscando efectos adversos en otras partes. |
| Técnica: |
|
| Criterio de Completitud: |
|
| Consideraciones Especiales: | Ninguna |
Pruebas de Humo (Smoke Testing o Ad Hoc)
| Objetivo de la Prueba: | Los objetivos son los siguientes:
|
| Descripción de la Prueba: | Toma éste nombre debido a que su objetivo es probar el sistema constantemente buscando que saque “humo” o falle. En algunos proyectos este tipo de prueba va junto con las pruebas funcionales. Permite detectar problemas que por lo regular no son detectados en las pruebas normales. Algunas veces, si las Pruebas ocurren tarde en el ciclo de desarrollo está será una forma de garantizar el buen desarrollo.
Las pruebas de humo NO SON exhaustivas, pero van de extremo a extremo de la aplicación.
|
| Técnica: | 1. Realizar una integración de todo el sistema cada cierto periodo (se recomienda un día, máximo una semana) 2. Realizar los casos de prueba asignados a los casos de uso finalizados ese día más los realizados en días anteriores 3. Buscar eficientemente errores |
| Criterio de Completitud: | · Todas las pruebas planeadas han sido ejecutadas. · Todos los defectos que se identifcaron han sido tenidos en cuenta. |
| Consideraciones Especiales: | Cuando se encuentre un error en el release correspondiente al periodo elegido para hacer las integraciones del sistema, se detiente el desarrollo hasta que el error es corregido.
Este tipo de pruebas es útil en la programación extrema (extremme programming) y de sistemas complejos.
Es útil el uso de programas de prueba automáticas que se encarguen de probar os casos de prueba ya ejecutados en realeases anteriores. |
PRUEBAS DEL SISTEMA
Pruebas del Sistema
| Objetivo de la Prueba: | Asegurar la apropiada navegación dentro del sistema, ingreso de datos, procesamiento y recuperación. |
| Descripción de la Prueba: | Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados directamente de casos de uso y reglas y funciones de negocios. El objetivo de estas pruebas es verificar el ingreso, procesamiento y recuperación apropiado de datos, y la implementación apropiada de las reglas de negocios. Este tipo de pruebas se basan en técnicas de caja negra, ésto es, verificar el sistema (y sus procesos internos), la interacción con las aplicaciones que lo usan via GUI y analizar las salidas o resultados.
En esta prueba se determina qué pruebas de Sistema (usabilidad, volumen, desempeño, etc.) asegurarán que la aplicación alcanzará sus objetivos de negocio.
La prueba de Sistema incluye: Prueba funcionalidad Prueba de Usabilidad Prueba de Performance Prueba de Documentación y Procedimientos Prueba de Seguridad y Controles Prueba de Volumen Prueba de Esfuerzo (Stress) Prueba de recuperación Prueba de múltiples sitios
Para sistemas web se recomienda especialmente realizar mínimo el siguiente grupo de pruebas de sistema: · Humo. · Usabilidad · Performance · Funcionalidad
Para capitalizar el trabajo hasta ahora completado, los casos de prueba de las pruebas previas realizadas pueden frecuentemente ser reorganizados y rehusados durante la prueba de sistema. No obstante, deben ser desarrollados casos de prueba adicionales para aquellos aspectos del sistema, tales como documentación, procedimientos y desempeño que no han sido probados durante la prueba unitaria y de integración.
La prueba de sistema es compleja porque intenta validar un número de características al mismo tiempo, a diferencia de otras pruebas que sólo se centran en uno o dos aspectos del sistema al mismo tiempo.
|
| Técnica: | · Ejecute cada caso de uso, flujo básico o función utilizando datos válidos e inválidos, para verificar que: · Los resultados esperados ocurren cuando se utiliza un dato válido. · Los mensajes de error o de advertencia aparecen en el momento adecuado, cuando se utiliza un dato inválido. · Cada regla de negocios es aplicada adecuadamente. |
| Criterio de Completitud: |
|
| Consideraciones Especiales: |
|
Pruebas de Desempeño
| Objetivo de la Prueba: | Validar el tiempo de respuesta para las transacciones o funciones de negocios bajo las siguientes dos condiciones:
|
| Descripción de la Prueba: | Las pruebas de desempeño miden tiempos de respuesta, índices de procesamiento de transacciones y otros requisitos sensibles al tiempo. El objetivo de las pruebas de desempeño es verificar y validar los requisitos de desempeño que se han especificado (en este caso, el desempeño ofrecido por el proponente).
Las pruebas de desempeño usualmente se ejecutan varias veces, utilizando en cada una, carga diferente en el sistema. La prueba inicial debe ser ejecutada con una carga similar a la esperada en el sistema. Una segunda prueba debe hacerse utilizando una carga máxima.
Adicionalmente, las pruebas de desempeño pueden ser utilizadas para perfilar y refinar el desempeño del sistema como una función de condiciones tales como carga o configuraciones de hardware
Las principales actividades son:
Los objetivos de nivel de servicio definidos deben guiar la prueba de performance. Algunas características que afectan el desempeño son:
Las pruebas de desempeño utilizan las técnicas de caja blanca y caja negra.
|
| Técnica: |
|
| Criterio de Completitud: |
|
| Consideraciones Especiales: | · Unas pruebas de desempeño integrales incluyen tener una carga en background en el servidor. Hay varios métodos que pueden ser utilizados para hacer ésto: o Transacciones dirigidas directamente al servidor, usualmente en forma de sentencias SQL.· o Creación de usuarios virtuales para simular muchos clientes (usualmente varios cientos). Se utilizan herramientas de Emulación de Terminales Remotas para obtener esta carga. Esta técnica también puede ser utilizada para cargar de tráfico la red. o Use múltiples clientes físicos, cada uno corriendo los scripts de prueba.
· Las pruebas de desempeño deben ser ejecutadas en una máquina dedicada o en un tiempo dedicado. Esto permite control total y medidas precisas. · La Base de datos utilizada para pruebas de desempeño debe ser de un tamaño real o proporcionalmente más grande que la diseñada. |
Pruebas de Carga
| Objetivo de la Prueba: | Verificar el tiempo de respuesta del sistema para transacciones o casos de uso de negocios, bajo diferentes condiciones de carga. |
| Descripción de la Prueba: | Las pruebas de carga miden la capacidad del sistema para continuar funcionando apropiadamente bajo diferentes condiciones de carga.
La meta de las pruebas de carga es determinar y asegurar que el sistema funciona apropiadamente aún más allá de la carga de trabajo máxima esperada. Adicionalmente, las pruebas de carga evalúan las características de desempeño (tiempos de respuesta, tasas de transacciones y otros aspectos sensibles al tiempo). |
| Técnica: |
|
| Criterio de Completitud: |
|
| Consideraciones Especiales: |
|
Pruebas de Stress
| Objetivo de la Prueba: | Verificar que el sistema funciona apropiadamente y sin errores, bajo estas condiciones de stress:
NOTAS: La meta de las pruebas de stress también es identificar y documentar las condiciones bajo las cuales el sistema FALLA.
|
| Descripción de la Prueba: | Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o completitud de recursos. Poca memoria o espacio en disco puede revelar defectos en el sistema que no son aparentes bajo condiciones normales. Otros defectos pueden resultar de incluir recursos compartidos, como bloqueos de base de datos o ancho de banda de la red. Las pruebas de stress identifican la carga máxima que el sistema puede manejar.
El objetivo de esta prueba es investigar el comportamiento del sistema bajo condiciones que sobrecargan sus recursos. No debe confundirse con las pruebas de volumen: un esfuerzo grande es un pico de volumen de datos que se presenta en un corto período de tiempo.
Puesto que la prueba de esfuerzo involucra un elemento de tiempo, no resulta aplicable a muchos programas, por ejemplo a un compilador o a una rutina de pagos.
Es aplicable, sin embargo, a programas que trabajan bajo cargas variables, interactivos, de tiempo real y de control de proceso.
Aunque muchas pruebas de esfuerzo representan condiciones que el programa encontrará realmente durante su utilización, muchas otras serán en verdad situaciones que nunca ocurrirán en la realidad. Esto no implica, sin embargo, que estas pruebas no sean útiles. Si se detectan errores durante estas condiciones “imposibles”, la prueba es valiosa porque es de esperar que los mismos errores puedan presentarse en situaciones reales, algo menos exigentes. |
| Técnica: |
|
| Criterio de Completitud: | Todas las pruebas planeadas han sido ejecutadas y excedidas sin que el sistema falle. ( O si las condiciones en que el sistema falle ocurren por fuera de las condiciones especificadas). |
| Consideraciones Especiales: | · Producir stress en la red puede requerir herramientas de red para sobrecargarla de tráfico. · El espacio en disco utilizado para el sistema debe ser reducido temporalmente para limitar el espacio disponible para el crecimiento de la Base de datos. · Sincronización de varios clientes accediendo simultáneamente los mismos registros. |
Pruebas de Volumen
| Objetivo de la Prueba: | · Verificar que la aplicación funciona adecuadamente bajo los siguientes escenarios de volumen: o Máximo (actual o físicamente posible) número de clientes conectados (o simulados), todos ejecutando la misma función (peor caso de desempeño) por un período extendido. o Máximo tamaño de base de datos (actual o escalado) y múltiples consultas ejecutadas simultáneamente |
| Descripción de la Prueba: | Las pruebas de volumen hacen referencia a grandes cantidades de datos para determinar los límites en que se causa que el Sistema falle. También identifican la carga máxima o volumen que el sistema puede manejar en un período dado. Por ejemplo, si el sistema está procesando un conjunto de registros de Base de datos para generar un reporte, una prueba de volumen podría usar una Base de datos de prueba grande y verificar que el sistema se comporta normalmente y produce el reporte correctamente.
El objetivo de esta prueba es someter al sistema a grandes volúmenes de datos para determinar si el mismo puede manejar el volumen de datos especificado en sus requisitos.
Algunos ejemplos de escenarios de prueba de volúmenes: · Un compilador puede ser alimentado por un programa para compilar que sea absurdamente grande. · Un editor de nexos puede recibir un programa que contenga miles de módulos. · Un simulador de circuito electrónico puede recibir un circuito diseñado con miles de componentes.
Puesto que obviamente, la prueba de volumen es una prueba costosa, tanto en tiempo de máquina como en personal, se debe tratar de no exceder los límites. Sin embargo, todo programa debería ser expuesto, al menos, a algunas pruebas de volumen. |
| Técnica: | · Utilice los scripts diseñados para las pruebas de desempeño. · Deben usarse múltiples clientes, ya sea corriendo las mismas pruebas o pruebas complementarias para producir el peor caso de volumen (ver pruebas de stress) por un período extendido. · Se utiliza un tamaño máximo de Base de datos. (actual, escalado o con datos representativos) y múltiples clientes para correr consultas simultáneamente para períodos extendidos. |
| Criterio de Completitud: | Todas las pruebas planeadas han sido ejecutadas y los límites especificados en el sistema se han conseguido o excedido sin que el sistema falle. |
| Consideraciones Especiales: |
|
Pruebas de Recuperación y Tolerancia a fallas
| Objetivo de la Prueba: | Verificar que los procesos de recuperación (manual o automática) restauran apropiadamente la Base de datos, aplicaciones y sistemas, y los llevan a un estado conocido o deseado. Los siguientes tipos de condiciones deben incluirse en la prueba: · Interrupción de electricidad en el cliente. · Interrupción de electricidad en el servidor · Interrupción en la comunicación hacia el servidor (caídas de red) · Interrupción en la comunicación con los controladores de disco. · Ciclos incompletos (procesos de consultas interrumpidos, procesos de sincronización de datos interrumpidos) · Llaves o apuntadores de base de datos inválidos · Elementos corruptos o inválidos en la base de datos. |
| Descripción de la Prueba: | Estas pruebas aseguran que una aplicación o sistema se recupere de una variedad de anomalías de hardware, software o red con pérdidas de datos o fallas de integridad.
Las pruebas de tolerancia a fallas aseguran que, para aquellos sistemas que deben mantenerse corriendo, cuando una condición de falla ocurre, los sistemas alternos o de respaldo pueden tomar control del sistema sin pérdida de datos o transacciones.
Las pruebas de recuperación son contrarias a las pruebas en que la aplicación o sistema es expuesto a condiciones extremas (o condiciones simuladas), tales como fallas en dispositivos en entrada/salida o llaves o apuntadores inválidos de base de datos. Los procesos de recuperación se invocan y la aplicación es monitoreada y/o inspeccionada para verificar que éstos mecanismos se han ejecutado en forma apropiada.
El objetivo de esta prueba es determinar la habilidad del sistema para recuperarse de una falla de hardware o software. Esta prueba evalúa las características de contingencia construidas en el sistema para procesar interrupciones y para volver a puntos específicos en el ciclo de procesamiento del sistema. La recuperación debe ser considerada en el proceso de diseño. Errores de programación o de datos pueden ser incorporados ex profeso en un sistema para determinar si se puede recuperar de ellos. Las fallas de equipo (por ejemplo errores de paridad en memoria, errores en dispositivos de entrada/salida) pueden ser simuladas.
|
| Técnica: | Se deben utilizar las pruebas creadas para la Funcionalidad del sistema y Procesos de Negocios para crear una serie de transacciones. Una vez se alcanza el punto inicial de las pruebas de recuperación, se deben realizar o simular las siguientes acciones: · Interrupción de electricidad en el cliente. · Interrupción de electricidad en el servidor: simular o iniciar procedimientos de pérdida de energía para el servidor. · Interrupción de la comunicación en la red. (desconectar físicamente los cables o apagar los hubs o routers) · Interrupción de la comunicación con los controladores de disco: simular o eliminar físicamente la comunicación con uno o mas controladores o dispositivos.
Una vez se realizan estas acciones, se deben ejecutar series de transacciones, y luego, una vez alcanzado el segundo punto de pruebas, se deben invocar los procedimientos de recuperación.
Las pruebas para ciclos incompletos utilizan la misma técnica que se describe arriba, excepto que los procesos de Base de datos deban ser abortados o terminados prematuramente.
Las pruebas para estas condiciones requieren que se llegue a un estado conocido previamente en la Base de datos. Algunos campos, apuntadores y llaves deben ser modificados manualmente, valiéndose de las herramientas que ofrezca la SSPD. Las transacciones adicionales deben ser ejecutadas utilizando las pruebas para Funcionalidad de la aplicación y para Procesos de Negocios.
|
| Criterio de Completitud: | En todos los casos mencionados, la Base de datos, aplicación y otros sistemas deben retornar a un estado conocido y deseado, una vez se completan los procedimientos de recuperación. Este estado podría incluir que el daño de datos se limite solamente a los campos, llaves o apuntadores que se sabe que fueron alterados, y reportes indicando los procesos o transacciones que no fueron completadas debido a las interrupciones producidas.
|
| Consideraciones Especiales: | · Las pruebas de recuperación pueden llegar a ser molestas. Los procedimientos para desconectar cables o simular pérdida de electricidad pueden ser poco factibles o deseables. Podrían llegar a requerirse métodos alternativos, como herramientas de diagnóstico. · Se requiere la participación de personal de la red, administradores de la base de datos y del sistema. · Estas pruebas deben ser ejecutadas en horas no laborables o en máquinas aisladas.
|
Prueba de Múltiples Sitios
| Objetivo de la Prueba: | Detectar fallas en configuraciones y comunicaciones de datos entre múltiples sitios. |
| Descripción de la Prueba: | El propósito de esta prueba es evaluar el correcto funcionamiento del sistema o subsistema en múltiples instalaciones.
|
| Técnica: | Realizar casos de prueba que verifiquen mínimo lo siguiente:
|
| Criterio de Completitud: |
|
| Consideraciones Especiales: | Ninguna |
Prueba de Compatibilidad y Conversión
| Objetivo de la Prueba: | Buscar problemas de compatibilidad y conversión en los sistemas. |
| Descripción de la Prueba: | El propósito es demostrar que los objetivos de compatibilidad no han sido logrados y que los procedimientos de conversión no funcionan.
La mayoría de los programas que se desarrollan no son completamente nuevos; con frecuencia son reemplazos de partes deficientes, ya sea de sistemas de procesamiento de datos, o sistemas manuales. Como tales, los programas tienen a menudo objetivos específicos con respecto a su compatibilidad y a sus procedimientos de conversión con el sistema existente. |
| Técnica: | Desarrollar casos de prueba que permitan detectar deficiencias con: · Compatibilidad entre programas · Conversión de datos |
| Criterio de Completitud: |
|
| Consideraciones Especiales: | Ninguna |
Pruebas de Integridad de Datos y Base de Datos
| Objetivo de la Prueba: | Asegurar que los métodos de acceso y procesos funcionan adecuadamente y sin ocasionar corrupción de datos. |
| Descripción de la Prueba: | La Base de datos y los procesos de Base de datos deben ser probados como sistemas separados del proyecto |
| Técnica: |
|
| Criterio de Completitud: | Todos los métodos de acceso y procesos de la Base de datos funcionan como fueron diseñados y sin corrupción de datos |
| Consideraciones Especiales: |
|
Pruebas de Seguridad y Control de Acceso
| Objetivo de la Prueba: | Nivel de seguridad de la aplicación: Verifica que un actor solo pueda acceder a las funciones y datos que su usuario tiene permitido.
Nivel de Seguridad del Sistema: Verificar que solo los actores con acceso al sistema y a la aplicación están habilitados para accederla. |
| Descripción de la Prueba: | Las pruebas de seguridad y control de acceso se centran en dos áreas claves de seguridad:
Las pruebas de seguridad de la aplicación garantizan que, con base en la seguridad deseada, los usuarios están restringidos a funciones específicas o su acceso está limitado únicamente a los datos que está autorizado a acceder. Por ejemplo, cada usuario puede estar autorizado a crear nuevas cuentas, pero sólo los administradores pueden borrarlas. Si existe seguridad a nivel de datos, la prueba garantiza que un usuario “típico” 1 puede ver toda la información de clientes, incluyendo datos financieros; sin embargo, el usuario 2 solamente puede ver los datos institucionales del mismo cliente.
Las pruebas de seguridad del sistema garantizan que solamente aquellos usuarios autorizados a acceder al sistema son capaces de ejecutar las funciones del sistema a través de los mecanismos apropiados.
Debido a la creciente preocupación de la sociedad por la privacidad de la información, muchos programas tienen objetivos específicos de seguridad.
El objetivo de esta prueba es evaluar el funcionamiento correcto de los controles de seguridad del sistema para asegurar la integridad y confidencialidad de los datos. El foco principal es probar la vulnerabilidad del sistema frente a accesos o manipulaciones no autorizadas. Una manera de encontrar esos casos de prueba es estudiar problemas conocidos de seguridad en sistemas similares y tratar de mostrar la existencia de problemas parecidos en el sistema que se examina.
Algunas consideraciones de prueba son:
|
| Técnica: | · Funciones / Seguridad de Datos: Identificar cada tipo de usuario y las funciones y datos a los que se debe autorizar. · Crear pruebas para cada tipo de usuario y verificar cada permiso, creando transacciones específicas para cada tipo de usuario. · Modificar tipos de usuarios y volver a ejecutar las pruebas. En cada caso, verificar si los datos o funciones adicionales quedan correctamente permitidos o denegados. · Acceso al sistema (ver consideraciones especiales) |
| Criterio de Completitud: | Para cada tipo de usuario conocido, las funciones y datos apropiados y todas las transacciones funcionan como se esperaba. |
| Consideraciones Especiales: | El acceso al sistema debe ser revisado y discutido con los administradores de la red y/o del sistema. Esta prueba puede no ser requerida como tal, sino como una función de los administradores de red o del sistema. |
PRUEBAS DE VALIDACIÓN A SISTEMAS A LA MEDIDA
Pruebas del Ciclo del Negocio
| Objetivo de la Prueba: | Asegurar que el sistema funciona de acuerdo con el modelo de negocios emulando todos los eventos en el tiempo y en función del tiempo. |
| Descripción de la Prueba: | Las pruebas del ciclo de negocio deberían emular las actividades ejecutadas en el |
| Técnica: | Ejecute cada caso de uso, flujo básico o función utilizando datos válidos e inválidos, para verificar que: · Incremente el número de veces en que una función es ejecutada para simular diferentes usuarios sobre un periodo especificado · Todas las fechas o funciones que involucren tiempos serán probadas con datos válidos e inválidos de fechas o periodos de tiempo. · Todas las funciones ocurren en un periodo de tiempo serán ejecutadas en el tiempo apropiado. · Los resultados esperados ocurren cuando los datos válidos son usados. · Los mensajes de error o de advertencia aparecen en el momento adecuado, cuando se utiliza un dato inválido. · Cada regla de negocios es aplicada adecuadamente. |
| Criterio de Completitud: | · Todas las pruebas planeadas han sido ejecutadas. · Todos los defectos que se identificaron han sido tenidos en cuenta. |
| Consideraciones Especiales: | · Las fechas y eventos del sistema pueden requerir actividades especiales de soporte. · Se requiere un modelo de negocios para identificar requisitos y procedimientos de prueba apropiados.
|
Pruebas de GUI
| Objetivo de la Prueba: | Verifica lo siguiente:
|
| Descripción de la Prueba: | La prueba de interfaz de usuario verifica la interacción del usuario con el software. El objetivo es asegurar que la interfaz tiene apropiada navegación a través de las diferentes funcionalidades. Adicionalmente, las pruebas de interfaz aseguran que los objetos de la interfaz a ser probada se encuentra dentro de los estandares de la industria |
| Técnica: | Pruebas de crear / modificar cada ventana para verificar la adecuada navegación y estado de los objetos. |
| Criterio de Completitud: | Cada ventana elegida será totalmente verificada y comparada con similares en el mercado logrando una buena aceptación dentro del estándar. |
| Consideraciones Especiales: | Ninguna |
Pruebas de Configuración
| Objetivo de la Prueba: | Validar y verificar que el cliente del sistema funciona apropiadamente en las estaciones de trabajo recomendadas. |
| Descripción de la Prueba: | Estas pruebas verifican la operación del sistema en diferentes configuraciones de hardware y software. En la mayoría de los ambientes de producción, las especificaciones para las estaciones de trabajo, equipos de red y servidores pueden variar. Las estaciones pueden tener diferentes versiones de software instaladas (Sistemas Operativos, Drivers, etc) y en cualquier momento, pueden llegar a utilizarse diferentes combinaciones.
Con frecuencia, el número de configuraciones posibles es demasiado grande para intentar una prueba de cada una de ellas, pero el programa debe probarse al menos con cada tipo de dispositivo y con las configuraciones mínima y máxima posibles.
|
| Técnica: | · Use los scripts para Integración y Pruebas del Sistema. · Incluya la apertura o cierre de varias aplicaciones Microsoft, como Excel y Word (o algun tipo de software similar a la que se esta probando ) como una parte de la prueba, ya sea al comienzo o en algún momento intermedio. · Ejecute algunas transacciones para simular actividades cotidianas del usuario, dentro y fuera de las aplicaciones que interactúan con la Base. · Repita estos pasos, minimizando la cantidad de memoria convencional disponible en los clientes.
|
| Criterio de Completitud: | Para cada combinación de aplicaciones que interactúan con la Base de datos a probar, las transacciones deben ser ejecutadas sin fallas.
|
| Consideraciones Especiales: | · Qué aplicaciones están disponibles para los clientes? · Qué aplicaciones se utilizan normalmente? · Qué tipos de datos manejan estas aplicaciones? (ej. Una larga hoja de cálculo, o un documento de 100 pág. En Word.) · Los sistemas, software de red, servidores, bases de datos también deben ser incluidas como parte de estas pruebas.
|
Prueba de Estilo
| Objetivo de la Prueba: | Comprobar que la aplicación sigue los estándares de estilo propios del cliente. |
| Descripción de la Prueba: | Se entienden como tales el formato de las ventanas, colores corporativos, tipos de letra etc. |
| Técnica: | · Se realiza una navegación por la aplicación verificando si se cumplen con los estándares de GUI del cliente. · Validar objetos gráficos contra el manual de estilos del cliente. |
| Criterio de Completitud: | · Todas las pruebas planeadas han sido ejecutadas. · Todos los defectos que se identificaron han sido tenidos en cuenta. |
| Consideraciones Especiales: |
|
Prueba de Aceptación
| Objetivo de la Prueba: | Determinación por parte del cliente de la aceptación o rechazo del sistema desarrollado. |
| Descripción de la Prueba: | La prueba de aceptación es ejecutada antes de que la aplicación sea instalada dentro de un ambiente de producción. La prueba de aceptación es generalmente desarrollada y ejecutada por el cliente o un especialista de la aplicación y es conducida a determinar como el sistema satisface sus criterios de aceptación validando los requisitos que han sido levantados para el desarrollo, incluyendo a documentación y procesos de negocio.
Basado en esta prueba el cliente determina si acepta o rechaza el sistema
Estas pruebas están destinadas a probar que el producto está listo para el uso operativo. Suelen ser un subconjunto de las Pruebas de Sistema.
Sirve para que el usuario pueda validar si el producto final se ajusta a los requisitos fijados, es decir, si el producto está listo para ser implantado para el uso operativo en el entorno del usuario.
Esta prueba es complementada por la prueba de estilo.
|
| Técnica: | Realización de los documentos de planes de prueba de aceptación y especificación de los mismos, basados en los criterios de aceptación del cliente.
Los casos prueba de aceptación han de ser planificados, organizados y formalizados de manera que se determine el cumplimiento de los requisitos del sistema. Para la realización de estas pruebas se necesita disponer de los siguientes documentos:
Realizar Pruebas de estilo |
| Criterio de Completitud: | · Todas las pruebas planeadas han sido ejecutadas. · Todos los defectos que se identificaron han sido tenidos en cuenta. |
| Consideraciones Especiales: | Las Pruebas de Aceptación se suelen realizar en un entorno de pre-producción. |
Prueba de Instalación
| Objetivo de la Prueba: | Verificar y validar que el sistema se instala apropiadamente en cada cliente, bajo las siguientes condiciones: · Instalaciones nuevas, nuevas máquinas a las que nunca se les ha instalado el sistema. · Actualizar máquinas previamente instaladas con el sistema. · Instalar versiones viejas en máquinas previamente instaladas con el sistema. |
| Descripción de la Prueba: | Las pruebas de instalación tienen dos propósitos. El primero es asegurar que el sistema puede ser instalado en todas las configuraciones posibles, tales como nuevas instalaciones, actualizaciones, instalaciones completas o personalizadas, y bajo condiciones normales o anormales; estas últimas incluyen insuficiente espacio en disco, falta de privilegios para algunas tareas, etc.
El segundo propósito es verificar que, una vez instalado, el sistema opera correctamente. Esto usualmente implica correr un número significativo de pruebas de Funcionalidad. |
| Técnica: | · Diseñar sripts para validar las condiciones de la máquina a instalar . · Realizar la instalación |
| Criterio de Completitud: | Las transacciones de la aplicación se ejecutan sin fallas. |
| Consideraciones Especiales: | · Qué transacciones del sistema se deben seleccionar para realizar una prueba confiable de que el sistema ha sido instalado exitosamente y no hace falta ningún componente del sistema? |
Pruebas Funcionales
| Objetivo de la Prueba: | Se asegura la trabajo apropiado de los requisitos funcionales, incluyendo la navegación, entrada de datos, procesamiento y obtención de resultados |
| Descripción de la Prueba: | Las pruebas Funcionales deben enfocarse en los requisitos funcionales, las pruebas pueden estar basadas directamente en los Casos de Uso (o funciones de negocio), y las reglas del negocio. Las metas de estas pruebas son:
Este tipo de pruebas están basadas en técnicas de caja negra, que es, verificar la aplicación (y sus procesos internos) mediante la interacción con la aplicación vía GUI y analizar la salida (resultados). Lo que se identifica a continuación es un diseño preliminar de las pruebas recomendadas para cada aplicación.
|
| Técnica: | Se ejecuta cada caso de uso, flujo de caso de uso, o función, usando datos válidos e inválidos, para verificar lo siguiente:
|
| Criterio de Completitud: |
|
| Consideraciones Especiales: | Identifique o describa aquellos aspectos (internos o externos) que impactan la implementación y ejecución de las pruebas de funcionalidad. |
Prueba de Documentación Y Procedimiento
| Objetivo de la Prueba: | Evaluar la documentación del usuario |
| Descripción de la Prueba: | Evaluar la exactitud y claridad de la documentación del usuario y para determinar si el manual de procedimientos trabajará correctamente como una parte integral del sistema.
Muchos defectos son identificados cuando un probador competente chequea totalmente los manuales y documentación del usuario.
Muchos programas son parte de sistemas mayores, no completamente automatizados, que contienen procedimientos realizados por operadores. Cualquier procedimiento humano, tal como los que llevan a cabo el operador, el administrador de la base de datos, o el usuario de terminal, debe ser probado durante la prueba de sistemas.
|
| Técnica: | Revisar la documentación del proyecto contra las funcionalidades del sistema y su configuración física.
|
| Criterio de Completitud: |
|
| Consideraciones Especiales: | Ninguna. |
Prueba de Usabilidad
| Objetivo de la Prueba: | Determinar la usabilidad del sistema. |
| Descripción de la Prueba: | Determina cuán bien el usuario podrá usar y entender la aplicación. Identifica las áreas de diseño que hacen al sistema de difícil uso para el usuario.
La prueba de usabilidad detecta problemas relacionados con la conveniencia y practicidad del sistema desde el punto de vista del usuario.
|
| Técnica: | Verificar que la aplicación no presenta los siguientes problemas de usabilidad típicos:
Se deben crear casos de prueba para comprobar que se puede operar en el sistema de forma adecuada.
|
| Criterio de Completitud: |
|
| Consideraciones Especiales: | Ninguna |
Prueba de Campo
| Objetivo de la Prueba: | Correr el sistema en el ambiente real para encontrar errores y validar el producto contra sus especificaciones originales. |
| Descripción de la Prueba: | Realizar un subconjunto válido de pruebas de sistema. |
| Técnica: | Determinar que pruebas de sistema serán corridas para validar el sistema en producción. |
| Criterio de Completitud: |
|
| Consideraciones Especiales: | Ninguna |
PRUEBAS DE VALIDACIÓN A APLICACIONES GENÉRICAS
Pruebas Alfa
| Objetivo de la Prueba: | Prueba de aceptación para detectar errores en el sistema bajo un ambiente controlado. |
| Descripción de la Prueba: | La verificación involucra la ejecución de partes o todo del sistema en ambientes simulados, con el fin de encontrar errores.
La retroalimentación de esta fase produce cambios en el software para resolver los errores y fallas que se descubren.
|
| Técnica: | Realizar las pruebas de sistema bajo las siguientes características:
Se selecciona un grupo de usuarios para el alpha test y se les pide trabajen con el sistema como parte de las pruebas. |
| Criterio de Completitud: |
|
| Consideraciones Especiales: | Ninguna |
Pruebas Beta
| Objetivo de la Prueba: | Realizar la validación del sistema por parte del usuario. |
| Descripción de la Prueba: | Prueba de aceptación donde La validación (o pruebas beta) involucra el uso del software en un ambiente real.
|
| Técnica: | Se selecciona un grupo de usuarios que ponen a trabajar el sistema en un ambiente real. Usan el sistema en sus actividades cotidianas, procesan transacciones y producen salidas normales del sistema.
Las transacciones y personas que usan el sistema son reales y trabajan en su área de trabajo real. El desarrollador no esta presente.
Los usuarios están advertidos de que están usando un sistema que puede fallar.
Los usuarios realizan pruebas a su antojo realizando uso de la aplicación. |
| Criterio de Completitud: | Se establece un periodo de pruebas beta en el que los errores detectados no sean de carácter crítico para el sistema. |
| Consideraciones Especiales: | Se deben considerar mecanismos de comunicación entre los desarrolladores y los usuarios de manera que los errores detectados puedan ser corregidos. |
Suscribirse a:
Entradas (Atom)