FUNDAMENTOS DE LOS PROCESOS DE PRUEBA
Las pruebas de software (Software Testing) comprenden el conjunto de actividades que se realizan para identificar posibles fallos de funcionamiento, configuración o usabilidad de un programa o aplicación, por medio de pruebas sobre el comportamiento del mismo.
Los sistemas informáticos, programas y aplicaciones han crecido a niveles inimaginables en complejidad e interoperabilidad, con lo cual también se han incrementado las posibilidades de defectos (bugs), a imple vista insignificantes, pero que pudieran adquirir proporciones catastroficas.
Además factores como el uso de software de terceros desde aplicaciones móviles han añadido niveles adicionales de complejidad y por ende incrementado los posibles puntos de fallas.
Frente a esto, el reto de los profesionales de Software Testing es modernizar sus metodologías, tecnologías y herramientas que les permitan automatizar tareas, ejecutar ciclos de pruebas más rápidos y así reducir al mínimo las posibilidades de errores en el Software.
A continuación pmoinformatica presenta una serie de recursos de apoyo al Software Tester para afrontar el desafío de software desarrollado con agilidad y calidad.
Principio 1: Las pruebas revelan la presencia de bugs, no la ausencia de ellos
Probar reduce la probabilidad de que existan bugs pero nunca se puede asegurar que no quede ninguno oculto.
Además, cada tipo de pruebas que realicemos (de sistema, de integración, añadir auditorías de código…) son más efectivas para detectar un tipo de bug.
Principio 2: Es imposible probarlo todo
El flujo de control de un sistema software no trivial como los que acostumbramos a utilizar en el día a día contiene miles de decisiones.
Estas decisiones se pueden combinar entre ellas para dar lugar a una infinidad de posibles caminos. De entrada, probar todos los caminos es un problema inabordable.
Y eso si no tenemos en cuenta la prueba de requisitos no funcionales, como el rendimiento de un sistema ante una exigente carga de usuarios, o requisitos específicos de seguridad (por ejemplo, en un sistema bancario) para protegerse de usuarios malintencionados.
Todo esto hace necesaria una estrategia de pruebas (un plan) y priorizar a partir de una gestión de riesgos de calidad y de proyecto, y como reza el siguiente principio…
Principio 3: Cuanto antes se comience a probar…mejor
Corregir un bug con una revisión en la fase de captura de requisitos o en una prueba unitaria tiene un coste mucho menor a lo que costará corregir este bug cuando se detecte en una prueba de sistema, o peor aún, en una prueba de aceptación por el cliente.
En demasiadas ocasiones existe una confianza excesiva en las pruebas de sistema, y todo el plan de pruebas (cuando existe) se reduce a estas. Se confía en que todos los componentes que no se probaron con una estrategia de pruebas unitarias y de integración se puedan entender bien a unos días del hito de entrega (cuando corregir un bug ya es demasiado caro, en lo que se denomina una prueba de integración «big-bang»).
Curiosamente estas malas prácticas se realizan para ahorrar costes, y finalmente el coste de la no calidad cambia las tornas: siempre se acaba pagando en unos costes de mantenimiento excesivos (con caídas de la productividad del 50% según Capers Jones).
Principio 4: Las aglomeración de defectos. ¡Los bugs siempre van en pandilla!
Entender esto es muy importante para plantear una buena estrategia de pruebas: los bugs suelen ir en grupo. Se concentran en determinados puntos de un sistema software, no manteniendo una distribución uniforme a lo largo del mismo.
Conclusión: si encuentras un bug en un componente, es muy probable que hayan más. Con lo que una posible estrategia sería centrarse en mejorar las pruebas de aquellos componentes para los que se han reportado un número mayor de bugs, para ser más eficaces a la hora de cazarlos en fases tempranas.
Principio 5: La paradoja del pesticida
O la necesidad de ajustar continuamente tu plan de pruebas… porque según este principio un plan de pruebas va perdiendo efectividad conforme se ejecuta sucesivas veces. Con lo que cada vez tenderá a encontrar menos bugs… ¡lo que no significa que no hayan! (vuelve a leer el primer principio). Se habla de paradoja del pesticida ya que estos matabichos usualmente sirven para un tipo de bichos, pero una vez no queda ninguno del tipo específico que mata el pesticida… ¡nadie te dice que no hayan otros bichos campando a sus anchas!.
Principio 6: Las pruebas se deben adaptar a necesidades específicas
Esto viene a enlazar con lo que he comentado antes. Si tu producto se centra en el ámbito de la seguridad deberás adaptar tus casos de prueba para intentar forzar situaciones o posibles escenarios no amistosos. Si quieres probar una intranet donde los servicios más vitales son los de imputación de horas y el de vacaciones, es lógico centrarse en estos servicios y no invertir tiempo en otros componentes infrautilizados. Además, hay que tener en cuenta que los recursos en los proyectos son siempre escasos, con lo que en el inicio del proyecto hay que preguntarse… qué estrategia debemos seguir para encontrar y corregir lo antes posible los bugs en las funcionalidades de mayor valor para nuestros usuarios.
Principio 7: La falacia de la ausencia de errores
Para terminar, nos encontramos con la satisfacción del usuario y con el hecho de que los usuarios elijan tu software para resolver sus necesidades.Que hayas corregido muchos bugs no significa que finalmente tu software sea un éxito. En ocasiones hay que primar un buen time to market, para luego corregir los problemas de calidad que quedaron por el camino. Y esto si se hace de manera consciente y con una buena estrategia, a priori, no debe ser un problema.
procesos del software
Están compuestos en su mayoría por distintas fases que varían, aunque ligeramente, de modelo en modelo.
- Fase de definición
- Planificación del proyecto de desarrollo software
- Ingeniería de requisitos / Extracción de información
- Análisis (estudio) de esos requisitos
- Fase de desarrollo
- Diseño del software
- Generación del código
- Pruebas del software
- Fase de mantenimiento
- Corrección de errores y reajustes que a veces provienen de nuevos requisitos e implican repetir las actividades de fases anteriores
Pruebas para realizar un software
Siguiendo los pasos de la complejidad inherente de nuestra industria, las pruebas también sufren de una miríada inacabable de tipos, versiones, evoluciones y clases. Pero centrémonos en las más importantes e imprescindibles, según cada caso y contexto.
Prueba unitaria: las pruebas unitarias son pruebas automatizadas que verifican la funcionalidad en el componente, clase, método o nivel de propiedad.
El objetivo principal de las pruebas unitarias es tomar la pieza más pequeña de software comprobable en la aplicación, aislarla del resto del código y determinar si se comporta exactamente como esperamos. Cada unidad se prueba por separado antes de integrarlas en los componentes para probar las interfaces entre las unidades.
Las pruebas unitarias deben escribirse antes (o muy poco después) de escribir un método; siendo los desarrolladores que crean la clase o el método, quienes diseñan la prueba.
Así, conseguimos mantener el foco en lo que debe hacer el código, y se convierte en una poderosa herramienta para aplicar KISS, JIT, y mantener el foco en lo que tiene que hacer en vez de en el cómo, evitando introducir complejidad sin valor.
Pruebas de integración: desde una perspectiva de prueba, las unidades individuales se integran juntas para formar componentes más grandes. En su forma más simple, dos unidades que ya han sido probadas se combinan en un componente integrado y se prueba la interfaz entre ellas.
Las pruebas de integración – o de componentes - identifican problemas que ocurren cuando las unidades se combinan. Los nuevos errores que surgen probablemente estén relacionados con la interfaz entre las unidades en lugar de dentro de las propias unidades; simplificando la tarea de encontrar y corregir los defectos.
Pruebas de regresión: cada vez que se realizan cambios en un proyecto, es posible que el código existente ya no funcione correctamente o que se presenten errores no descubiertos previamente. Este tipo de error se llama regresión.
Para detectar estos defectos, todo el proyecto debe someterse a una regresión: una nueva prueba completa de un programa modificado, en lugar de una prueba de solo las unidades modificadas, para garantizar que no se hayan introducido errores con las modificaciones.
Como se puede deducir, este tipo de pruebas debe ser automatizado porque puede estar compuesto por decenas o miles de pruebas unitarias, de integración o más.
Una versión menos costosa, podría ser construir pruebas que repliquen las acciones que provocaron la regresión, y comprueben que han sido corregidos al no volver a sucederse los errores; además de añadir los test unitarios que aseguren que el código que ha corregido la regresión funciona correctamente.
Pruebas de funcionalidad: pruebas automatizadas o manuales que prueban las funcionalidades de la aplicación o módulo construidos desde el punto de vista del usuario final, con sus diferentes roles, para validar que el software hace lo que debe y, sobre todo, lo que se ha especificado.
En su versión automática son pruebas que se automatizan para "ahorrar tiempo de pruebas". A partir de los casos de prueba de las pruebas manuales, se automatizan los casos de prueba para que se repitan en las ejecuciones. Esos casos suelen ser los más importantes (happy flow) de los módulos o procesos de negocio "vitales" de la aplicación. Es decir, los procesos que siempre tienen que funcionar y que bajo ningún concepto pueden fallar. El objetivo de las pruebas funcionales automáticas es comprobar que no haya regresiones.
Las pruebas obligan a hacer un código desacoplado y promueven la calidad
En el caso de las manuales, las ejecuta un tester como si fuese un usuario, pero siguiendo una serie de pasos establecidos en el plan de pruebas, diseñado en el análisis de los requisitos para garantizar que hace lo que debe (casos positivos), que no falla (casos negativos) y que es lo que se ha solicitado.
El tester realizará las acciones indicadas en cada paso del caso de prueba comprobando que se cumple el resultado esperado. Si el resultado es distinto, se reportará un defecto con todo detalle: descripción, datos utilizados, capturas de pantalla, etc., para facilitar la solución.
El mayor problema con el que se enfrentan las pruebas funcionales para ser automatizadas es su fragilidad. Cada prueba testea miles de líneas de código, centenares de integraciones en todos los tiers, y una interfaz de usuario cambiante. Llegando a no ser sostenible el conjunto de pruebas en relación con su definición, coste y mantenimiento.
PARTICIPANTES EN EL PROCESO DE PRUEBAS
Existen diferentes roles que participan en un proyecto de pruebas. Una persona puede asumir más de un rol en un proyecto y tomar diferentes roles en proyectos distintos.
En general se va creciendo en conocimiento y experiencia a medida que se es capaz de asumir diferentes roles. Se identifican tres tipos de roles dentro de un equipo de testing: Tester de Software, Líder de Testing de Software y Consultor.
Tester de software. En el amplio sentido de la palabra, es quien diseña, ejecuta e informa el resultado de las pruebas sobre un producto de software. Los testers integran el equipo de pruebas e interactúan con el equipo de desarrollo y la gerencia de proyectos.
Líder de testing de software. El Líder de un proyecto de pruebas tiene conocimiento y experiencia en el diseño, ejecución y reporte de pruebas sobre un producto de software, pero también es capaz de estimar, planificar y dar seguimiento a un proyecto de pruebas.
Consultor. Es un rol adecuado para aquellas personas capaces de dirigir un equipo de pruebas y orientar sobre mejores prácticas en testing.
Conceptos del proceso de pruebas
Verificación:El proceso de evaluación de un sistema o de uno de sus componentes para
determinar
si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase.
Validación: El proceso de evaluación de un sistema o de uno de sus componentes durante o al final
del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario.
Defectos: un defecto en el software como, por ejemplo, un proceso, una definición de datos o un
paso de procesamiento incorrectos en un programa.
Fallas: La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones
requeridas dentro de los requisitos de rendimiento especificados.
Errores: tiene varias acepciones
Fallo---------La diferencia entre un valor calculado, observado o medio y el valor verdadero,
especificado o teóricamente correcto.
Defecto--------Un defecto.
Fallo-------Un resultado incorrecto.
Error-------Una acción humana que conduce a un resultado incorrecto.
Pruebas:una actividad en la cual un sistema o uno de sus componentes se ejecuta en
circunstancias previamente especificadas, los resultados se observan y registran y se realiza una
evaluación de algún aspecto
Proceso de pruebas
Las pruebas de calidad en un Software ERP son todos aquellos procesos cuya ejecución permiten
conocer la calidad del mismo, así como los posibles fallos que puedan existir a corto, medio o largo
plazo. Cuando se realizan pruebas en los software de gestión empresarial es posible predecir su
comportamiento durante la implantación, su grado de manejabilidad y su interfaz gráfica.
Existen diferentes maneras para realizar las pruebas de calidad, las mismas van dadas por el
contexto que representa cada uno de los clientes en particular, en otras palabras, no hay un plan
de prueba que pueda servir para todos los escenarios, porque puede ser que una prueba para un
software ERP específico sea perfecta, pero en otro puede llegar a ser perjudicial.
TIPOS DE PRUEBAS DE CALIDAD DE SOFTWARE
Todas las pruebas de este tipo varían, no obstante, su finalidad sigue siendo la misma y es el hecho
de comprobar y dar el visto bueno a todo el software de una empresa, sin importar que se trate de
un ERP para empresas instaladoras o para empresas distribuidoras. A continuación se explican
algunas pruebas de calidad:
PRUEBAS DE FUNCIONAMIENTO: Dentro de esta categoría es posible encontrar tres subgrupos, los
cuales se clasifican, según sus objetivos, en:
Testing de función: Enfocada en conseguir informes sobre la aptitud de las funciones, los métodos
y los servicios que componen el ERP
Testing de seguridad: Ideada para comprobar la seguridad de los datos que maneja el ERP para
Pymes, es decir, los datos de la empresa.
Testing de volumen: Dirigida a medir la velocidad del ERP para procesar grandes cantidades de
información en la base de datos, bien sea en entrada o en salida.
PRUEBAS DE USABILIDAD: La finalidad de éstas es comprobar la relación del usuario con el
software de gestión empresarial, prestando especial atención a la interfaz, la experiencia del
usuario, asistentes de ayuda integrados, interactividad, entre otras cosas.
PRUEBAS DE FIABILIDAD: Al igual que las de funcionamiento, se dividen en tres grupos:
Testing de integridad: Trata de valorar y calificar la resistencia a fallos que presenta el software.
Testing de estructura: Consiste en verificar que cada una de las partes que componen el diseño del
software ERP se encuentren conectadas a las funciones correctas, en otras palabras, que no exista
contenido huérfano en el ERP.
Testing de estrés: Se utiliza para evaluar el comportamiento del software ERP en situaciones poco
usuales, como por ejemplo, una sobre carga de funciones, la saturación de la memoria, la
restricción de los recursos compartidos, etc…
PRUEBAS DE RENDIMIENTO: Miden la relación función resultado de un ERP, éstas se dividen en:
Testing Benchamark: Se encarga de cuantificar el rendimiento de un nuevo componente del ERP,
comparándolo directamente con otro existente.
Testing de contención: Ésta valora la capacidad de respuesta de un elemento, en cuanto a sus
habilidades, al momento de ser requerido por diversos actores, un ejemplo de dicho elemento
podría ser el registro de recursos o la memoria.
Testing de carga: Su finalidad es probar y asegurar los límites operacionales del software de
gestión empresarial, mediante la aplicación de cargas de trabajo promedio. Por ejemplo, si se
quiere hacer la prueba sobre un ERP para una empresa de obras y servicios, es necesario indicar
cuales son las cargas habituales de trabajo de las mismas.
PRUEBAS PARA LA CAPACIDAD DE SOPORTE: Existen dos formas de medirlo, éstas son:
Testing de configuración: Su principal objetivo es asegurarse que un ERP funciona de forma
correcta, sin importar la configuración que la empresa decida aplicar, tanto a nivel de software
como a nivel hardware. De igual forma es posible aplicar esta prueba como un medidor de
rendimiento del sistema, o bien utilizarla en asociación con una prueba especializada en dicho
tema.
Testing de instalación: Es probablemente una de las pruebas más importantes, puesto que de ella
dependerá, en gran medida, la correcta implementación del ERP. Consiste en certificar que el
software ERP se encuentra en plena capacidad de ser instalado en condiciones extremas de
hardware o de software, como por ejemplo, problemas con la capacidad de memoria o con la
velocidad de procesamiento.
Objetivos de prueba
La prueba de software es un elemento crítico para la garantía del correcto funcionamiento del
software. Entre sus objetivos están:
Detectar defectos en el software.
Verificar la integración adecuada de los componentes.
Verificar que todos los requisitos se ha
n implementado correctamente.
Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software
al cliente.
Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes clases de errores,
haciéndolo con la menor cantidad de tiempo y esfuerzo.
Para lograr los objetivos propuestos, un ingeniero de software deberá conocer los principios
básicos que guían las pruebas del software.
Diseño de casos de prueba
El formato para el caso de prueba de inicio de sesión contiene el siguiente formato:
ID del caso de prueba
Parte del escenario de prueba
Pasos de prueba a realizar
Datos de prueba
Resultados esperados
Resultados reales
Resultado de la prueba (exitoso o no)
Ejecución de prueba
Análisis de resultado
El análisis de resultados es la parte del informe en la que estableces las conclusiones del mismo.
Debe ser claro y conciso, ya que el lector suele llegar cansado a esta parte del ensayo. Este análisis
debe proponer cuestiones sobre el tema estudiado y plantear nuevas corrientes y perspectivas
para futuras investigaciones. Desde un Como.com marcaremos una línea de abordaje y te
explicaremos cómo hacer un análisis de resultados.
Pasos a seguir:
1-Empezar con las relaciones y generalizaciones que los propios resultados guardan con informe.
Evidentemente, los resultados salen del desarrollo del informe, por lo que deberás mostrar esas
relaciones en el análisis de resultados.
2-
Señalar los aspectos no resueltos y no tratar de ocultarlos. Delimita lo que no cuadre. En algunos
ensayos puede haber algún resultado que no encaje o cuadre con el desarrollo de la investigación.
Debes señalarlo y dejar abierto el tema.
3-
Mostrar las relaciones de tus resultados con trabajos anteriormente publicados, y también
mostrar las nuevas conclusiones propias de tu ensayo.
4-
Explicar cuáles son las bases teóricas de la investigación y las posibles aplicaciones prácticas que
pueda tener. De donde salen tus conclusiones y para que sirven.
5-
Formular detalladamente y de forma clara las conclusiones.
6-
Dar recomendaciones o sugerencias si es necesario, para facilitar la compresión del informe.
7-
Por último, resumir las pruebas que recogen esa información así como las fuentes.
Ambiente de desarrollo
Cada vez adquiere una mayor importancia la definición de procedimientos adecuados para
administrar los ambientes de desarrollo de software, considerando que las empresas en la
actualidad demandan la ejecución de múltiples proyectos simultáneos, con tiempos de puesta en
producción exigentes, lo que conlleva a muchos desarrolladores de software, tanto internos como
externos a la organización, compartiendo los mismos ambientes de desarrollo.
En este artículo, se exploran algunas buenas prácticas para la administración de ambientes de
desarrollo, que van desde la definición las características adecuadas de infraestructura, base de
datos, organización, plantación y procedimientos de cambios, homologación, altas y bajas.
Presentamos a continuación las buenas prácticas para ambientes de desarrollo de software.
Características del ambiente
Disponer de herramientas de:
Desarrollo (Eclipse, Java Empresarial, Visual Studio .NET, Bases de datos), instalado.
Logging (bitácoras), monitoreo de desempeño y debugging.
Control de versiones automatizado.
Herramientas de gestión de compilaciones (Build Management).
Podría residir en el computador personal del desarrollador, en otros casos, podría ser un servidor
compartido en el cual varios desarrolladores trabajan sobre el mismo proyecto.
Ser lo más similar posible a los ambientes de pruebas y producción, a efectos de prevenir
situaciones en las cuales el software desarrollado presente comportamientos distintos y errores
en esos ambientes.
También en componentes de infraestructura de TI deben ser similares, por ejemplo, ¿usa clusters
en producción?, si es así, ¿Cómo se asegura que los componentes instalados en un servidor
puedan desplegarse hacia otros servidores que componen el cluster?. La única forma, es tener un
ambiente de desarrollo o pruebas configurado en clusters en el cual los desarrolladores puedan
validar sus programas.
Incluir replicas de todos los componentes con los cuales el software tendrá interoperación en
producción incluyendo: otras aplicaciones cliente servidor, bases de datos relacionales,
componentes middleware, interfaces, demonios (daemons), procesos personalizados, utilidades
FTP y otros.
Utilizar nombres de dominio diferentes para los ambientes de producción, pruebas y desarrollo, a
efectos de evitar confusión durante la ejecución de las pruebas.
Tener instalado el mismo manejador de base de datos, versión y calidad de los ambientes de
prueba y producción. Si esto no es posible, usar herramientas automatizadas de propagación de
una base de datos a otros.
Organización y planeación
Encargar la labor de determinar que ambientes se necesitan y asegurar que estén operativos
cuando se necesiten a un arquitecto, gerente de operaciones o gerente de cambios.
Todos los equipos de desarrollo, tanto internos como externos a la organización, deben
suministrar con antelación sus requerimientos de ambiente al ente encargado de la
administración. Los tiempos de antelación deben ser prestablecidos en acuerdos de nivel de
servicio.
Los requerimientos de ambiente de desarrollo deben ser documentados por cada proyecto,
usando los formatos y plantillas prestablecidos).
Usados estrictamente sólo para desarrollo y pruebas (de los desarrolladores).
Los desarrolladores deben realizar su trabajo exclusivamente en ambiente de desarrollo, nunca en
otros ambientes directamente.
Debe ser un ambiente distinto a los de pruebas y producción.
Deben contener sólo datos de prueba que no sean críticos para el negocio, por lo que deben
disponerse de procedimientos para eliminar datos sensibles (blanquear datos), cuando se traen de
ambiente de pruebas o producción.
Pueden disponerse de múltiples ambientes de desarrollo, pero es necesario asegurar que
periódicamente sean homologados entre ellos y con los ambientes de pruebas y producción.
Contar con procesos claramente definidos y auditables para:
Asignación de ambientes.
Uso compartido.
Accesos múltiples.
Acuerdos de nivel de servicio.
Actualizaciones.
Upgrades.
Instalaciones.
Desincorporación.
Preparación.
Conectividad.
Asistencia a los múltiples equipos usuarios del ambiente.
Emitir reportes de uso y carga que asistan a la planeación.
Paradas de mantenimiento o instalaciones
Las paradas de mantenimiento o instalaciones de versiones, homologaciones, o correcciones
deben en la medida de lo posible:
Ser planificadas en el mediano plazo.
Comunicadas a los equipos de desarrollo para considerarlas en su planificación.
Ejecutarse fuera de horario laboral, para no interrumpir las operaciones diarias.
Comunicadas al momento de inicio y finalización
Reindexar las de bases de datos cuando se realiza mantenimiento en las noches, para evitar que al
día siguiente las pruebas tengan fallos por timeout.
Procedimientos de Cambio y Homologación
Asignar un administrador encargado de organizar los cambios al ambiente por múltiples equipo, el
momento en que serán instalados y los procedimientos de revisión y aprobación de cambios.
Implementar procedimientos de control de código fuente, versiones y compilación. Utilizando
herramientas automatizadas.
Realizar revisiones de código antes de comprometer los cambios en una versión e instalación en
un ambiente, evaluar los componentes afectados y evitar instalación de cambios que afecten de
forma adversa los componentes de otro equipo de desarrollo.
Notificar a todos los usuarios los cambios a instalar en un ambiente, para que tengan la
oportunidad de revisar la afectación sobre sus componentes.
Realizar periódicamente comparaciones de configuración de ambientes, existen herramientas
automatizadas capaces de comparar configuraciones, aplicaciones, bases de datos y la
infraestructura subyacente.
Implementar controles que aseguren la reconfiguración de archivos de parámetros de
configuración (por ejemplo Properties en J2EE) al movilizarlos de un ambiente a otro.
La virtualización puede ayudar a evitar riesgos por cambios en configuración de un entorno a otro.
Administración de accesos al ambiente
Puede tener controles menos estrictos de privilegios acceso al sistema, para permitir a los
programadores hacer cambios de registro, base de datos, red o cualquier otro componente con
mayor facilidad. En todo caso, estos accesos especiales deben ser autorizados (según
procedimiento de autorización de accesos).
A pesar de poder tener controles menos estrictos de privilegios de acceso, las altas del sistema
deben ser controladas, por medio de procedimientos de solicitud y autorización.
Las bajas de la organización o equipo de desarrollo deben registrarse lo antes posible en el
ambiente de desarrollo. Adicionalmente, es necesario realizar una revisión periódica del listado de
usuarios, e identificar usuarios que egresaron de la compañía y debían estar de baja.
La actividad de cada usuario debe registrarse en el log (bitácora), en caso de necesitar realizar
alguna investigación
Verificación:El proceso de evaluación de un sistema o de uno de sus componentes para
determinar
si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase.
Validación: El proceso de evaluación de un sistema o de uno de sus componentes durante o al final
del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario.
Defectos: un defecto en el software como, por ejemplo, un proceso, una definición de datos o un
paso de procesamiento incorrectos en un programa.
Fallas: La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones
requeridas dentro de los requisitos de rendimiento especificados.
Errores: tiene varias acepciones
Fallo---------La diferencia entre un valor calculado, observado o medio y el valor verdadero,
especificado o teóricamente correcto.
Defecto--------Un defecto.
Fallo-------Un resultado incorrecto.
Error-------Una acción humana que conduce a un resultado incorrecto.
Pruebas:una actividad en la cual un sistema o uno de sus componentes se ejecuta en
circunstancias previamente especificadas, los resultados se observan y registran y se realiza una
evaluación de algún aspecto
Proceso de pruebas
Las pruebas de calidad en un Software ERP son todos aquellos procesos cuya ejecución permiten
conocer la calidad del mismo, así como los posibles fallos que puedan existir a corto, medio o largo
plazo. Cuando se realizan pruebas en los software de gestión empresarial es posible predecir su
comportamiento durante la implantación, su grado de manejabilidad y su interfaz gráfica.
Existen diferentes maneras para realizar las pruebas de calidad, las mismas van dadas por el
contexto que representa cada uno de los clientes en particular, en otras palabras, no hay un plan
de prueba que pueda servir para todos los escenarios, porque puede ser que una prueba para un
software ERP específico sea perfecta, pero en otro puede llegar a ser perjudicial.
TIPOS DE PRUEBAS DE CALIDAD DE SOFTWARE
Todas las pruebas de este tipo varían, no obstante, su finalidad sigue siendo la misma y es el hecho
de comprobar y dar el visto bueno a todo el software de una empresa, sin importar que se trate de
un ERP para empresas instaladoras o para empresas distribuidoras. A continuación se explican
algunas pruebas de calidad:
PRUEBAS DE FUNCIONAMIENTO: Dentro de esta categoría es posible encontrar tres subgrupos, los
cuales se clasifican, según sus objetivos, en:
Testing de función: Enfocada en conseguir informes sobre la aptitud de las funciones, los métodos
y los servicios que componen el ERP
Testing de seguridad: Ideada para comprobar la seguridad de los datos que maneja el ERP para
Pymes, es decir, los datos de la empresa.
Testing de volumen: Dirigida a medir la velocidad del ERP para procesar grandes cantidades de
información en la base de datos, bien sea en entrada o en salida.
PRUEBAS DE USABILIDAD: La finalidad de éstas es comprobar la relación del usuario con el
software de gestión empresarial, prestando especial atención a la interfaz, la experiencia del
usuario, asistentes de ayuda integrados, interactividad, entre otras cosas.
PRUEBAS DE FIABILIDAD: Al igual que las de funcionamiento, se dividen en tres grupos:
Testing de integridad: Trata de valorar y calificar la resistencia a fallos que presenta el software.
Testing de estructura: Consiste en verificar que cada una de las partes que componen el diseño del
software ERP se encuentren conectadas a las funciones correctas, en otras palabras, que no exista
contenido huérfano en el ERP.
Testing de estrés: Se utiliza para evaluar el comportamiento del software ERP en situaciones poco
usuales, como por ejemplo, una sobre carga de funciones, la saturación de la memoria, la
restricción de los recursos compartidos, etc…
PRUEBAS DE RENDIMIENTO: Miden la relación función resultado de un ERP, éstas se dividen en:
Testing Benchamark: Se encarga de cuantificar el rendimiento de un nuevo componente del ERP,
comparándolo directamente con otro existente.
Testing de contención: Ésta valora la capacidad de respuesta de un elemento, en cuanto a sus
habilidades, al momento de ser requerido por diversos actores, un ejemplo de dicho elemento
podría ser el registro de recursos o la memoria.
Testing de carga: Su finalidad es probar y asegurar los límites operacionales del software de
gestión empresarial, mediante la aplicación de cargas de trabajo promedio. Por ejemplo, si se
quiere hacer la prueba sobre un ERP para una empresa de obras y servicios, es necesario indicar
cuales son las cargas habituales de trabajo de las mismas.
PRUEBAS PARA LA CAPACIDAD DE SOPORTE: Existen dos formas de medirlo, éstas son:
Testing de configuración: Su principal objetivo es asegurarse que un ERP funciona de forma
correcta, sin importar la configuración que la empresa decida aplicar, tanto a nivel de software
como a nivel hardware. De igual forma es posible aplicar esta prueba como un medidor de
rendimiento del sistema, o bien utilizarla en asociación con una prueba especializada en dicho
tema.
Testing de instalación: Es probablemente una de las pruebas más importantes, puesto que de ella
dependerá, en gran medida, la correcta implementación del ERP. Consiste en certificar que el
software ERP se encuentra en plena capacidad de ser instalado en condiciones extremas de
hardware o de software, como por ejemplo, problemas con la capacidad de memoria o con la
velocidad de procesamiento.
Objetivos de prueba
La prueba de software es un elemento crítico para la garantía del correcto funcionamiento del
software. Entre sus objetivos están:
Detectar defectos en el software.
Verificar la integración adecuada de los componentes.
Verificar que todos los requisitos se ha
n implementado correctamente.
Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software
al cliente.
Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes clases de errores,
haciéndolo con la menor cantidad de tiempo y esfuerzo.
Para lograr los objetivos propuestos, un ingeniero de software deberá conocer los principios
básicos que guían las pruebas del software.
Diseño de casos de prueba
El formato para el caso de prueba de inicio de sesión contiene el siguiente formato:
ID del caso de prueba
Parte del escenario de prueba
Pasos de prueba a realizar
Datos de prueba
Resultados esperados
Resultados reales
Resultado de la prueba (exitoso o no)
Ejecución de prueba
Análisis de resultado
El análisis de resultados es la parte del informe en la que estableces las conclusiones del mismo.
Debe ser claro y conciso, ya que el lector suele llegar cansado a esta parte del ensayo. Este análisis
debe proponer cuestiones sobre el tema estudiado y plantear nuevas corrientes y perspectivas
para futuras investigaciones. Desde un Como.com marcaremos una línea de abordaje y te
explicaremos cómo hacer un análisis de resultados.
Pasos a seguir:
1-Empezar con las relaciones y generalizaciones que los propios resultados guardan con informe.
Evidentemente, los resultados salen del desarrollo del informe, por lo que deberás mostrar esas
relaciones en el análisis de resultados.
2-
Señalar los aspectos no resueltos y no tratar de ocultarlos. Delimita lo que no cuadre. En algunos
ensayos puede haber algún resultado que no encaje o cuadre con el desarrollo de la investigación.
Debes señalarlo y dejar abierto el tema.
3-
Mostrar las relaciones de tus resultados con trabajos anteriormente publicados, y también
mostrar las nuevas conclusiones propias de tu ensayo.
4-
Explicar cuáles son las bases teóricas de la investigación y las posibles aplicaciones prácticas que
pueda tener. De donde salen tus conclusiones y para que sirven.
5-
Formular detalladamente y de forma clara las conclusiones.
6-
Dar recomendaciones o sugerencias si es necesario, para facilitar la compresión del informe.
7-
Por último, resumir las pruebas que recogen esa información así como las fuentes.
Ambiente de desarrollo
Cada vez adquiere una mayor importancia la definición de procedimientos adecuados para
administrar los ambientes de desarrollo de software, considerando que las empresas en la
actualidad demandan la ejecución de múltiples proyectos simultáneos, con tiempos de puesta en
producción exigentes, lo que conlleva a muchos desarrolladores de software, tanto internos como
externos a la organización, compartiendo los mismos ambientes de desarrollo.
En este artículo, se exploran algunas buenas prácticas para la administración de ambientes de
desarrollo, que van desde la definición las características adecuadas de infraestructura, base de
datos, organización, plantación y procedimientos de cambios, homologación, altas y bajas.
Presentamos a continuación las buenas prácticas para ambientes de desarrollo de software.
Características del ambiente
Disponer de herramientas de:
Desarrollo (Eclipse, Java Empresarial, Visual Studio .NET, Bases de datos), instalado.
Logging (bitácoras), monitoreo de desempeño y debugging.
Control de versiones automatizado.
Herramientas de gestión de compilaciones (Build Management).
Podría residir en el computador personal del desarrollador, en otros casos, podría ser un servidor
compartido en el cual varios desarrolladores trabajan sobre el mismo proyecto.
Ser lo más similar posible a los ambientes de pruebas y producción, a efectos de prevenir
situaciones en las cuales el software desarrollado presente comportamientos distintos y errores
en esos ambientes.
También en componentes de infraestructura de TI deben ser similares, por ejemplo, ¿usa clusters
en producción?, si es así, ¿Cómo se asegura que los componentes instalados en un servidor
puedan desplegarse hacia otros servidores que componen el cluster?. La única forma, es tener un
ambiente de desarrollo o pruebas configurado en clusters en el cual los desarrolladores puedan
validar sus programas.
Incluir replicas de todos los componentes con los cuales el software tendrá interoperación en
producción incluyendo: otras aplicaciones cliente servidor, bases de datos relacionales,
componentes middleware, interfaces, demonios (daemons), procesos personalizados, utilidades
FTP y otros.
Utilizar nombres de dominio diferentes para los ambientes de producción, pruebas y desarrollo, a
efectos de evitar confusión durante la ejecución de las pruebas.
Tener instalado el mismo manejador de base de datos, versión y calidad de los ambientes de
prueba y producción. Si esto no es posible, usar herramientas automatizadas de propagación de
una base de datos a otros.
Organización y planeación
Encargar la labor de determinar que ambientes se necesitan y asegurar que estén operativos
cuando se necesiten a un arquitecto, gerente de operaciones o gerente de cambios.
Todos los equipos de desarrollo, tanto internos como externos a la organización, deben
suministrar con antelación sus requerimientos de ambiente al ente encargado de la
administración. Los tiempos de antelación deben ser prestablecidos en acuerdos de nivel de
servicio.
Los requerimientos de ambiente de desarrollo deben ser documentados por cada proyecto,
usando los formatos y plantillas prestablecidos).
Usados estrictamente sólo para desarrollo y pruebas (de los desarrolladores).
Los desarrolladores deben realizar su trabajo exclusivamente en ambiente de desarrollo, nunca en
otros ambientes directamente.
Debe ser un ambiente distinto a los de pruebas y producción.
Deben contener sólo datos de prueba que no sean críticos para el negocio, por lo que deben
disponerse de procedimientos para eliminar datos sensibles (blanquear datos), cuando se traen de
ambiente de pruebas o producción.
Pueden disponerse de múltiples ambientes de desarrollo, pero es necesario asegurar que
periódicamente sean homologados entre ellos y con los ambientes de pruebas y producción.
Contar con procesos claramente definidos y auditables para:
Asignación de ambientes.
Uso compartido.
Accesos múltiples.
Acuerdos de nivel de servicio.
Actualizaciones.
Upgrades.
Instalaciones.
Desincorporación.
Preparación.
Conectividad.
Asistencia a los múltiples equipos usuarios del ambiente.
Emitir reportes de uso y carga que asistan a la planeación.
Paradas de mantenimiento o instalaciones
Las paradas de mantenimiento o instalaciones de versiones, homologaciones, o correcciones
deben en la medida de lo posible:
Ser planificadas en el mediano plazo.
Comunicadas a los equipos de desarrollo para considerarlas en su planificación.
Ejecutarse fuera de horario laboral, para no interrumpir las operaciones diarias.
Comunicadas al momento de inicio y finalización
Reindexar las de bases de datos cuando se realiza mantenimiento en las noches, para evitar que al
día siguiente las pruebas tengan fallos por timeout.
Procedimientos de Cambio y Homologación
Asignar un administrador encargado de organizar los cambios al ambiente por múltiples equipo, el
momento en que serán instalados y los procedimientos de revisión y aprobación de cambios.
Implementar procedimientos de control de código fuente, versiones y compilación. Utilizando
herramientas automatizadas.
Realizar revisiones de código antes de comprometer los cambios en una versión e instalación en
un ambiente, evaluar los componentes afectados y evitar instalación de cambios que afecten de
forma adversa los componentes de otro equipo de desarrollo.
Notificar a todos los usuarios los cambios a instalar en un ambiente, para que tengan la
oportunidad de revisar la afectación sobre sus componentes.
Realizar periódicamente comparaciones de configuración de ambientes, existen herramientas
automatizadas capaces de comparar configuraciones, aplicaciones, bases de datos y la
infraestructura subyacente.
Implementar controles que aseguren la reconfiguración de archivos de parámetros de
configuración (por ejemplo Properties en J2EE) al movilizarlos de un ambiente a otro.
La virtualización puede ayudar a evitar riesgos por cambios en configuración de un entorno a otro.
Administración de accesos al ambiente
Puede tener controles menos estrictos de privilegios acceso al sistema, para permitir a los
programadores hacer cambios de registro, base de datos, red o cualquier otro componente con
mayor facilidad. En todo caso, estos accesos especiales deben ser autorizados (según
procedimiento de autorización de accesos).
A pesar de poder tener controles menos estrictos de privilegios de acceso, las altas del sistema
deben ser controladas, por medio de procedimientos de solicitud y autorización.
Las bajas de la organización o equipo de desarrollo deben registrarse lo antes posible en el
ambiente de desarrollo. Adicionalmente, es necesario realizar una revisión periódica del listado de
usuarios, e identificar usuarios que egresaron de la compañía y debían estar de baja.
La actividad de cada usuario debe registrarse en el log (bitácora), en caso de necesitar realizar
alguna investigación
Comentarios