GPS Para MoProSoftv1.0

Gua de Pruebas de Software (GPS)

GUA DE PRUEBAS DE SOFTWARE (GPS) PARA MOPROSOFT

Silvia Guardati1 Alain Ponce2

1 2

Profesora del Departamento Acadmico de Computacin Divisin Acadmica de Ingeniera - ITAM Maestra en Tecnologas de Informacin y Administracin - Divisin Acadmica de Ingeniera - ITAM

GPS - Guardati & Ponce

1


I. INTRODUCCIN................................................................................ 3I.1 Implantar un lineamiento base ................................................................................................... 4 I.2 Incrementar la eficiencia ............................................................................................................ 5 I.3 Organizacin del documento...................................................................................................... 7

II. GUA DE PRUEBAS DE SOFTWARE (GPS)................................ 9II.1 Alta Direccin (DIR)................................................................................................................... 10 II.2 Gerencia (GER) .......................................................................................................................... 13 II.3 Operacin (OPE)........................................................................................................................ 16 II.3.1 Administracin de Proyectos Especficos [OPE.1] .............................................................. 17 II.3.2 Desarrollo y Mantenimiento de Software [OPE.2] ............................................................... 23

III. PRUEBA DE SOFTWARE: CONCEPTOS BSICOS................56III.1 Pruebas estticas y dinmicas............................................................................................... 56 III.2 Requerimientos ...................................................................................................................... 59 III.3 Planeacin de pruebas........................................................................................................... 61 III.4 Actividades comunes de pruebas .......................................................................................... 62 III.5 Ciclos de pruebas................................................................................................................... 64

REFERENCIAS .....................................................................................66


2


I. INTRODUCCINEn un mercado tan competitivo como el actual, una PyME no puede permitirse entregar productos de mala calidad o fabricar software que no realice las actividades para las que fue diseado. Un error cometido por una PyME dentro de sus primeros meses e incluso aos de vida puede ser un factor determinante para su permanencia o no en el mercado. Esta gua est enfocada a las PyME-TIC que aplican MoProSoft [1]. El negocio principal de estas organizaciones es crear o mejorar software para otras reas de la misma organizacin o para terceros. Con el seguimiento de la gua, las empresas podrn lograr: Disminucin de los tiempos de entrega. Reduccin de codificacin incorrecta o innecesaria. Reduccin de defectos en el producto final. Entrega de productos alineados a los requerimientos de las empresas cliente. Definicin cuantitativa del programa de calidad. Mayor tiempo de permanencia en el mercado de los productos. Creacin de una memoria institucional con los proyectos concluidos, constituyendo una referencia para los nuevos proyectos. Mayor claridad entre empresas con respecto a niveles de calidad del software desarrollado. Soporte de pruebas al modelo MoProSoft en sus 3 categoras.

Estrategia de la EmpresaValoracin y Mejora Continua

Gestin de procesosAdministracin de proyectos especficos

Gestin de Defectos

Gestin de Proyectos

Gestin de Recursos

Desarrollo y Mantenimiento de Software

Figura 1- Integracin de actividades de pruebas al ciclo de desarrollo del proyecto.


Teora de Pruebas

3

Gua de Pruebas de Software (GPS) Se toma como base MoProSoft para aplicar la gua de pruebas en las distintas etapas del modelo (figura 1), y tratando de cumplir con dos objetivos: 1. Implantar un lineamiento base: fomentar el desarrollo de las pruebas en cualquier proyecto de la empresa mediante una integracin de esta teora con la estrategia, planeacin y procesos de la organizacin. 2. Incrementar la eficiencia: para cada una de las tareas del modelo MoProSoft es posible ejecutar pruebas adecuadas a la PYME, enfatizando en aquellas donde se pueden observar mejoras a largo plazo.

I.1 Implantar un lineamiento basePara lograr el primer objetivo se aplica la gua de pruebas dentro de las categoras de Alta Direccin y Gerencia de MoProSoft.

I.1.1 Alta DireccinEn la tabla 1 se presentan las tareas que se desarrollan en la gua dentro de la categora Alta direccin, incluyendo sus beneficios. En la misma se muestra la actividad de pruebas a desarrollar dentro de cada tarea especfica de las actividades de Planificacin Estratgica y Valoracin y Mejora Continua de MoProSoft, as como los beneficios que se obtienen al desarrollarla. Por ejemplo, desarrollar el plan estratgico de la empresa y su validacin son actividades de pruebas a ejecutar dentro de la tarea A1.11, en la actividad de Planificacin Estratgica, obteniendo como beneficios: La reduccin de malentendidos, documentacin incompleta y huecos en el plan. Mayor conocimiento y entendimiento de ste dentro de la organizacin.Alta direccin Actividad de Pruebas Obtener una imagen real de la calidad de los servicios de la empresa.

Proceso

Actividad MoProSoft

Tarea

A1. Planificacin Estratgica (O1) A1.2.

Beneficios Conocimiento de las fortalezas y debilidades de la empresa enfocandose en aquellas actividades que las pruebas pueden mejorar. Formacin de una base estratgica de las pruebas que est enfocada en reforzar las debilidades que se requiere desarrollar dentro de la organizacin.

DIR.1 Gestin de Negocio


Desarrollar objetivos para el rea de pruebas, enfocados a incrementar la calidad de los productos finales. Desarrollar las estrategias del rea, con las que se pretender cubrir dichos objetivos. Desarrollar el plan estratgico de la empresa, incluyendo la estrategia a tomar en todo lo relacionado a las pruebas. Validar el plan estratgico de la empresa mediante el uso de herramientas de pruebas estticas.

Evitar defectos en el plan estratgico, tales como: malentendidos, documentacin incompleta y huecos en el plan. Reduccin de tiempos para el entendimiento total del plan estratgico.


A3. Valoracin y Mejora Continua A3.1. (O3)

Contar con una base de criterios que permitan recibir informacin acerca de procesos y actividades que necesitan ser mejoradas.

Facilidad de mejora mediante la actualizacin de los procesos de pruebas de la organizacin.

Tabla 1 - Beneficios en la aplicacin de pruebas en la categora Alta Direccin.


4


I.1.2 GerenciaLa gua incluye actividades de pruebas dentro de dos de los procesos de la categora de Gerencia: Gestin de Procesos y Gestin de Recursos. La eleccin de los mismos obedece a los beneficios esperados (ver tabla 2).Proceso GES.1 Gestin de Procesos Actividad MoProSoft Tarea Gerencia Actividad de Pruebas Beneficios Control completo de las diferentes actividades y procesos de pruebas usados por la empresa.

Implementar una nomenclatura y librera de procesos enfocados en las pruebas. A1. Planificacin (O1) A1.1. Determinar criterios para la adquisicin de bienes enfocados a realizar pruebas. Determinar los planes de capacitacin necesarios para incrementar la eficiencia en la realizacin de las pruebas.

GES.3 Gestin de Recursos

A1. Planificacin de Recursos (O1, O2) A1.3.

Planeacin de gastos en las pruebas, determinacin de Costo/Beneficio de estos gastos. Determinacin de un calendario de utilizacin de los recursos de pruebas de la empresa.

A3. Investigacin de Tendencias Tecnolgicas (O3)

Determinar el impacto de las nuevas Visibilidad de las nuevas tendencias de tecnologas en la eficiencia de la ejecucin mercado, as como probable evaluacin de de pruebas de la empresa. stas antes de su implementacin. A3.1.

Tabla 2 - Beneficios en la aplicacin de pruebas en la categora Gerencia.

Para Gestin de Procesos es necesario implementar una nomenclatura dentro de los procesos de las pruebas, obteniendo un control nico de las diferentes actividades y procesos de pruebas usados por la empresa. Para la Gestin de Recursos bsicamente se integran los criterios de pruebas para planificar los recursos necesarios para llevar a cabo las actividades de la gua, adems de facilitar la mejora de estas actividades mediante la retroalimentacin proveniente de la operacin.

I.2 Incrementar la eficienciaPara lograr este objetivo, la gua ofrece elementos para incluir las pruebas en la categora Operacin dentro de sus dos procesos: Administracin de proyectos especficos y Desarrollo y Mantenimiento de Software.

I.2.1 Administracin de proyectos especficosEn este proceso se integra el conocimiento general de pruebas dentro de la planificacin del esfuerzo requerido en las distintas etapas de la creacin de software. Una actividad de pruebas importante aqu es la determinacin del nmero de ciclos y actividades adecuados para cada tipo de pruebas, haciendo posible planear de una manera real el esfuerzo requerido para lograr un objetivo de cobertura deseada por la empresa. Esta actividad de pruebas tambin permite realizar un plan de ejecucin detallado y enfocado a maximizar los recursos disponibles dentro de la organizacin. Otra de las actividades importantes dentro de este proceso es formalizar las condiciones de cierre para cada fase del proyecto. Esta actividad permite establecer los criterios a cumplir dentro de cada etapa con el fin de tomar decisiones de continuacin o paro de la fase (o del proyecto), de acuerdo a la calidad alcanzada (que podr ser


5

Gua de Pruebas de Software (GPS) medida). Los beneficios obtenidos por aplicar la gua en esta categora se pueden observar en la tabla 3.Proceso OPE 1. Administracin de Proyectos Especficos Actividad MoProSoft Tarea Operacin Actividad de Pruebas Determinar el nmero de ciclos y actividades adecuados para cada tipo de pruebas. Determinar el tiempo esperado para cada actividad de pruebas. Conformar un equipo de trabajo de pruebas. Beneficios Defininir las actividades necesarias para obtener la cobertura de pruebas deseada en cada proyecto. Disminuir la variacin en la planeacin de recursos de pruebas. Determinar la mejor manera de obtener recursos de pruebas, de acuerdo a las caractersticas especficas de la empresa. Obtener una lnea base real para el desarrollo de las actividades de pruebas, soportando el enfoque de estas hacia la mejora del producto final.

A1. Planificacin (O1) A1. Planificacin (O1)

A1.4. A1.6.

A1. Planificacin (O1)

A1.8. Generar calendarios de trabajo de las pruebas.

A1. Planificacin (O1)

A1.9. Formalizar las condiciones de cierre en las Entregar bases cuantitativas acerca de la diferentes fases de programacin y del calidad esperada en cada una de las proyecto total. diferentes etapas del desarrollo del software. Estas bases se pueden utilizar como parte de un contrato de calidad del proyecto.

A4. Cierre (O1)

A4.1.

Tabla 3 - Beneficios en la aplicacin de pruebas en el proceso OPE1, de la categora Operacin.

I.2.2 Desarrollo y mantenimiento de softwarePara el proceso de Desarrollo y Mantenimiento de Software la gua presenta diferentes actividades, tcnicas y fases de pruebas que se deben de considerar dentro de la etapa de desarrollo (o mantenimiento) del proyecto. Dentro de estas actividades destaca la revisin de requerimientos, donde se especifican las funcionalidades que debe tener el sistema una vez terminado. Una validacin aqu es tan crtica que de ella puede depender que el sistema, como un todo, cumpla o no el objetivo para el que fue desarrollado. En la fase de pruebas unitarias, de integracin de componentes y de sistema, se desarrollan procedimientos que brindan como beneficio la disminucin de los defectos tpicos de cada una y el aprovechamiento de recursos. Un ejemplo de eficiencia de recursos es evitar gastar demasiado tiempo en el registro de errores en la fase de pruebas unitarias, debido a que por su naturaleza es muy difcil mantener un control exacto de stos. As mismo, GPS agrega la fase de pruebas de Aceptacin de Usuario, donde se valida el software desde una perspectiva de negocio, obteniendo beneficios como: ganar confianza del usuario final y reducir los riesgos al implantar el sistema en condiciones de operacin reales. Finalmente, el registro de mtricas de pruebas se encuentra inmerso en cada fase del modelo MoProSoft, con lo que es posible conocer en todo momento el estado actual de stas y la calidad del proyecto en general.


6

Gua de Pruebas de Software (GPS)Operacin Actividad de Pruebas Beneficios Asegurar que los requerimientos Software alineado a los requerimientos del cliente. se encuentran alineados a lo que Software aplicable en los procesos de negocio del cliente. el cliente requiere. Software fcil de usar. Software enfocado al cliente.

Proceso

Actividad MoProSoft Tarea A2. Realizacin de la A2.2. fase de Requerimientos(O1, O3)

A2. Realizacin de la fase de Requerimientos(O1, O3) A2. Realizacin de la fase de Requerimientos(O1, O3) A3. Realizacin de la fase de Anlisis y Diseo (O1,O3) OPE 2. Desarrollo y Mantenimiento de Software A3. Realizacin de la fase de Anlisis y Diseo (O1,O3) A4. Realizacin de la fase de Construccin (O1, O3)

A2.3.

Identificacin y validacin Requerimientos claros para todos los niveles de la esttica de los requerimientos del organizacin, as como para el cliente, permitiendo proyecto. disminuir el esfuerzo empleado en la creacin de mdulos no importantes fuera del alcance. Bases para la elaboracin Eliminacin de tiempos insuficientes u holgados dentro de correcta de un plan de la fase de la creacin del plan. pruebas de sistema y aceptacin. Conforme se obtiene experiencia los datos son ms reales para cada empresa. Validacin de la estructura interna Reduccin de malentendidos tcnicos que pudieran del sistema. ocasionar retrasos y mayores costos debido a fallas de diseo bsicas de los diferentes mdulos del proyecto. Bases para la elaboracin correcta de un plan de la fase de pruebas de integracin. Aplicar pruebas unitarias de componentes. Reduccin en los tiempos de planeacin. Consideracin total de las actividades necesarias para las pruebas de integracin. Reduccin de fallos en el cdigo desde etapas tempranas, proporcionando calidad con menor esfuerzo. Registro de mtricas de defectos en la etapa de codificacin. Creacin de una gua parametrizable de ejecucin de pruebas con la que ser posible delegar esta actividad a miembros del equipo con menor conocimiento del funcionamiento del negocio. Reduccin en el tiempo de ejecucin de pruebas. Facilidad en el descubrimiento de defectos causados por datos no comunes en la operacin normal. Reduccin de defectos en el nivel de comunicacin entre componentes, lo que ocasiona reduccin de defectos en etapas posteriores del proyecto.

A2.7.

A3.2.

A3.7.

A4.2.

N/A

N/A

Definir casos de prueba y escenarios.

N/A

N/A

Definir datos de pruebas.

A5. Realizacin de la fase de Integracin y Pruebas (O1, O3) A5. Realizacin de la fase de Integracin y Pruebas (O1, O3)

A5.2.

Realizar fase de integracin.

A5.6.

Realizar pruebas de sistema y de Con las pruebas de sistema se puede determinar una aceptacin. confiabilidad de la operacin del software desde un punto de vista ms real hacia el usuario. Con las pruebas de aceptacin se permite entregar confianza al usuario final acerca de la operacin total del software, tal como se utilizar en las condiciones normales del da a da. Cierre del proyecto, en base a mtricas de pruebas. Fase de entrega o rechazo del proyecto de acuerdo a los parmetros definidos al inicio de ste. Lo que permite identificar con claridad los cumplimientos del contrato efectuados en la firma del proyecto. Adicin al manual de mantenimiento de las diferentes caractersticas necesarias para la operacin correcta del sistema bajo los ambientes requeridos.

A6. Realizacin de la fase de Cierre(O2)

N/A

A6. Realizacin de la fase de Cierre(O2)

A6.1

Soporte en el manual de mantenimiento (ambientes de pruebas).

Tabla 4 - Beneficios en la aplicacin de pruebas en el proceso OPE2, de la categora Operacin.

I.3 Organizacin del documentoEste documento consta de tres captulos. En el primero se presentaron las actividades de MoProSoft cubiertas por GPS y los beneficios esperados. El captulo dos est dedicado a la gua, en l se presenta para cada una de las categoras de MoProSoft las actividades sugeridas por GPS, as como material requerido para ejecutar dichas actividades.


7

Gua de Pruebas de Software (GPS) En el captulo tres se presentan algunos de los conceptos ms importantes de la teora de pruebas. Este captulo pretende servir como auxiliar en la capacitacin de los miembros de una organizacin que realizar actividades de pruebas. Este captulo puede ser omitido por aquellos lectores que ya poseen los conocimientos del rea y que slo requieren de una gua para la implementacin de las pruebas en el marco de MoProSoft. Por ltimo, se presentan las referencias bibliogrficas.


8


II. GUA DE PRUEBAS DE SOFTWARE (GPS)A continuacin se presenta la Gua de Pruebas de Software (GPS), adecuada a la PyME y relacionada directamente a cada una de las actividades de MoProSoft en las cuales se considera que las pruebas son ms eficientes y/o necesarias. La gua est estructurada de acuerdo al modelo MoProSoft, con objeto de simplificar la localizacin de las diferentes actividades de prueba que componen a cada una de las categoras del modelo. En la figura 2, de cada categora, se colorean (sombreadas) las actividades cubiertas por la gua.Gestin de Negocio Gerencia

Planeacin estratgica Gestin de procesos Preparacin para la realizacin Gestin de recursos Valoracin y mejora continua Gestin de proyectos

Operacin Administracin de proyectos especficos Desarrollo y mantenimiento de software Inicio Fase de Requerimientos Planeacin Fase de Anlisis y Diseo Fase de Construccin Realizacin Fase de Integracin y Pruebas Cierre

Figura 2 - Actividades del modelo MoProSoft cubiertas por la gua.


9

Gua de Pruebas de Software (GPS) Al inicio de cada seccin de la gua (ver figura 3), se encuentra una descripcin y un esquema de las actividades que contiene la categora del proceso, relacionndolas con las actividades de pruebas. La expresin Oi, junto al nombre de la actividad Aj de MoProSoft, hace referencia al objetivo i del proceso alcanzado por medio de la actividad Aj.

II.1 Alta Direccin (DIR)La teora de pruebas enfocada a la categora Alta Direccin (DIR) es un pilar fundamental del proyecto de pruebas, ya que es indispensable que la cabeza de la organizacin conozca los beneficios de la implantacin de stas dentro de un enfoque de negocios. Dentro del modelo MoProSoft, en la categora Alta Direccin se encuentran las diferentes actividades relacionadas al proceso de Gestin de Negocio.Gestin de Negocio Planificacin estratgica

Preparacin para la realizacin Valoracin y mejora continua

MoProSoft ActividadesA1. Planificacin Estratgica (O1) A3. Valoracin y Mejora Continua (O3)

Tareas A1.2 A1.3 A1.11 A3.1

Actividades GPS 1. Entender la situacin actual 2. Desarrollar o actualizar objetivos y estrategias 3. Verificar el Plan Estratgico Anlisis de la informacin y evaluacin del desempeo

Figura 3 - Cobertura de la gua en la categora Gestin de Negocio de MoProSoft.

II.1.1 Gestin de Negocio [DIR.1]GPS se enfoca en dos estrategias dentro del proceso de Gestin de Negocio: a. Planificacin Estratgica (O1). b. Valoracin y Mejora Continua (O3).

a. Planificacin EstratgicaLas siguientes tareas estn relacionadas a la actividad de Planeacin Estratgica: 1) Entender la situacin actual, 2) Desarrollar o actualizar objetivos y estrategias y 3) Verificar el plan estratgico.


10

Gua de Pruebas de Software (GPS) 1) Entender la situacin actual Dentro de la tarea A1.2 de MoProSoft, la gua se enfoca directamente a la ejecucin del Anlisis de la situacin interna, donde es indispensable determinar la calidad de los productos que actualmente se estn entregando al usuario final. Para realizar este anlisis lo ms recomendable es aplicar una entrevista o encuesta tanto al equipo de ventas como al usuario final, enfocndose en aspectos como: Confiabilidad del sistema (robustez, disponibilidad, portabilidad). Cumplimiento de lo esperado (% de satisfaccin). Facilidad de uso y aspecto (look & feel). Tiempo de entrega (das). Tiempo de retraso estimado (das). Calidad de la documentacin. Costo. Tiempos de resolucin de problemas. Aunque el usuario final no lo perciba, el enfoque de la encuesta debe ser tal que sea posible observar las diferentes desviaciones de costo y tiempo en la entrega de los resultados, respecto al plan original. Este tipo de ejercicios permite obtener datos reales y concretos en cuanto a la percepcin final del producto que est desarrollando la empresa, las reas de mejora existentes y las fortalezas ya desarrolladas que hay que mantener. El siguiente paso en el Anlisis de la situacin interna es el de determinar si las oportunidades existentes se pueden cubrir implementando la teora de pruebas en los diferentes niveles del ciclo de vida del proyecto.

2) Desarrollar o actualizar objetivos y estrategias Una vez que se ha concluido con el Anlisis de la situacin interna, entonces es posible determinar los objetivos del rea de pruebas que se desee as como las estrategias para lograrlos a corto, mediano y largo plazo. Los objetivos del rea de pruebas tienen que estar relacionados de manera general con indicadores estratgicos, tales como: la percepcin de la calidad de los productos finales, la usabilidad de los productos, el anlisis de los beneficios a obtener al invertir en el rea de pruebas y los recursos de la empresa que puede disponer para efectuar estos esfuerzos. Algunos objetivos tpicos en el rea de pruebas son: A corto plazo Contar con una agrupacin de pruebas en un periodo no mayor a 3 meses con un proyecto piloto que comience dentro de ese tiempo. Realizar pruebas en todas las fases de los 5 proyectos ms importantes. Aumentar la utilizacin de las pruebas de aceptacin de usuario a un 50% de los proyectos. A mediano plazo


11

Gua de Pruebas de Software (GPS) Ejecutar las pruebas de sistema en un 100% de los proyectos y las pruebas de aceptacin de usuario en un 80%. Capacitar a todo el personal de pruebas en el uso de herramientas estndares de pruebas en un periodo de 1 ao. Integrar un rea especializada nicamente en pruebas, incluyendo metodologa, herramientas y capacitacin estndar. Realizar la compra de una herramienta especial de administracin de casos de prueba. A largo plazo Utilizar herramientas de administracin de pruebas dentro de todos los ciclos y proyectos de la empresa. Ofrecer al mercado proyectos de pruebas, y que esto represente el 10% de la facturacin anual de la empresa. Estos ejemplos son slo algunas ideas que pueden aplicarse en cualquier organizacin PyME. Sin embargo, la nica manera de aplicarlo es entendiendo las necesidades especficas de la empresa, as como las bondades que llegarn a sta al realizar pruebas de manera formal. Es importante recalcar que para una PyME es muy difcil cubrir varios objetivos al mismo tiempo, por lo que es muy recomendable asignar prioridades a stos, con la idea de enfocarse primero en aquellos que beneficien ms a la empresa en su situacin actual. La estrategia del rea de pruebas, desde el punto de vista de las pruebas, es la de determinar las diferentes actividades que se realizarn dentro de la empresa, as como los diferentes criterios de utilizacin de ellas en los proyectos, con el fin de lograr los objetivos planteados. A continuacin se muestran 5 ejemplos de estrategias de pruebas que se pueden aplicar en cualquier organizacin: Formalizar el proceso de pruebas. Los beneficios que puede brindar formalizar estas actividades son poco tangibles; sin embargo, es un hecho que es el primer paso para lograr una ejecucin correcta de las pruebas, sirviendo de base para la implementacin de otras estrategias ms elaboradas. Utilizacin de herramientas estndares de pruebas. En esta estrategia se determinan las diferentes herramientas que se utilizarn dentro de cada una de las actividades de pruebas, tales como: el anlisis de ambigedades (pruebas estticas), formatos de casos de prueba o las herramientas de administracin de defectos (pruebas dinmicas). Determinar el nivel de involucramiento del rea de pruebas. Esta estrategia indica los criterios de participacin del rea de pruebas en los diferentes proyectos de la empresa. Por ejemplo, Las pruebas en los proyectos menores a $XXX sern realizadas en su totalidad por el grupo de pruebas de la empresa, mientras que en los proyectos de ms de $XXX sern ejecutadas por un grupo externo y validadas por miembros de nuestra empresa. El beneficio inmediato que se puede ver con esta estrategia es el de dosificar los esfuerzos del personal de pruebas sin descuidar la calidad del producto. Determinar la cobertura de las pruebas con relacin al ciclo de vida total del proyecto. Para que todos los involucrados manejen la misma informacin, se debe establecer claramente las actividades del proyecto donde se aplicarn actividades de pruebas. Lo ms recomendable es


12

Gua de Pruebas de Software (GPS) ejecutar dichas actividades desde el arranque del proyecto, debido a que un requerimiento mal definido desde el principio ser una funcionalidad no deseada del sistema, en otras palabras: un defecto. Uno de los beneficios inmediatos que se pueden obtener con esta estrategia, es apoyar de manera inmediata aquellas reas de oportunidad detectadas en el anlisis de la situacin interna. Entregar informacin relacionada a las pruebas en todos los proyectos. Es una estrategia enfocada a ganar confianza en el nivel de calidad de los productos de la empresa, mediante la entrega de informacin de la ejecucin exitosa de las pruebas de los productos. Al mismo tiempo, esta informacin ayudar a contar con una base de datos de proyectos exitosos que permitir adoptar las mejores prcticas de los programadores para reducir defectos. Para poder aplicar alguna de estas estrategias (o cualquier otra) en el rea de pruebas, es necesario que est completamente alineada a la estrategia global de la organizacin. 3) Verificar el plan estratgico Un anlisis de ambigedades (prueba esttica) es ideal durante la creacin del plan estratgico para eliminar cualquier mal entendido dentro de los diferentes documentos que lo integran, y para asegurar documentacin completa.

b. Valoracin y Mejora Continua (O3)Para la actividad de Valoracin y Mejora Continua se considera tarea: Anlisis de la informacin y evaluacin del desempeo. Durante la adopcin de pruebas por parte de una empresa, es tambin necesario definir un proceso de recoleccin de mtricas en todos los proyectos involucrados. Algunos de los indicadores ms importantes son: Nmero de defectos encontrados en cada fase, por tipo de proyecto. Tiempo utilizado en la resolucin de los defectos. Nmero de ciclos ejecutados en cada fase de los proyectos. Cantidad de recursos utilizados. Fallas en produccin.

II.2 Gerencia (GER)El objetivo de MoProSoft para esta categora consiste en establecer los procesos de la organizacin, as como definir, planear e implantar las actividades que ayuden a realizar las mejoras necesarias en ellos. El objetivo especfico para la gua en esta categora es nicamente definir los procesos de pruebas establecidos dentro del plan estratgico. Por lo tanto, contiene actividades para los procesos de Gestin de Procesos y Gestin de Recursos.


13


Gerencia Gestin de Procesos Gestin de Recursos Gestin de Proyectos

MoProSoft Actividades GPS Actividades A1. Planificacin (O1)A1. Planificacin de Recursos (O1, O2) A3. Investigacin de Tendencias Tecnolgicas (O3)

Tareas A1.1 A1.1 A3.1

Establecer o actualizar la definicin de elementos de procesos Generar o actualizar el Plan de Adquisiciones y Capacitacin Generar Propuestas Tecnolgicas

Figura 4 - Cobertura de la gua en la categora Gerencia de MoProSoft.

II.2.1 Gestin de Procesos [GES.1]Para este proceso, la gua se enfoca en la actividad de Planificacin (O1).

Planificacin (O1)La teora de pruebas se puede aplicar en la tarea Establecer o actualizar la definicin de elementos de procesos, relacionada a la actividad de Planificacin de MoProSoft. Es necesario implementar una nomenclatura y una librera de procesos enfocados a pruebas donde se pueda documentar la informacin referente a cada uno y las relaciones entre ellos.

II.2.2 Gestin de Recursos [GES.3]El enfoque de la gua en este proceso se presenta en las siguientes actividades de MoProSoft: a. Planificacin de Recursos (O1, O2) b. Investigacin de Tendencias Tecnolgicas (O3)

a. Planificacin de Recursos (O1, O2)Dentro de esta actividad, la teora de pruebas se puede aplicar en el Plan de adquisiciones y capacitacin.


14

Gua de Pruebas de Software (GPS) Adquisiciones. Dependiendo del grado en que la empresa realice las pruebas, requerir o no de insumos especiales para llevarlas a cabo. Por ejemplo, para validar los requerimientos de la ejecucin del sistema en un servidor especfico, para hacerlo en condiciones reales, es necesario contar con dicho servidor. Esto no implica necesariamente que la empresa deba comprarlo, podra conseguirlo por arrendamiento o prstamo. Independientemente de la forma de conseguir los insumos, es necesario considerar todos los casos que puedan presentarse y su mejor solucin. Es importante tener en cuenta los posibles insumos, clasificados por categoras: Hardware Equipos Servidores. Almacenamiento de datos. Computadoras personales (incluye PDAs, telfonos inteligentes, etc.). Equipo de interconexin. Dispositivos especiales. Software Sistemas operativos (PC, Servidores, Telfonos, etc.). Bases de datos. Software para la administracin de pruebas. Contratos externos (outsourcing) Personal temporal para ejecutar las pruebas (Testers). Equipos de profesionales de pruebas externos. Capacitacin. En esta seccin es necesario crear un plan especfico de entrenamiento en el rea de pruebas que ayude a disminuir el tiempo necesario para adoptar todo el conocimiento que la empresa requiera, segn sus objetivos y estrategias. Para establecer un plan de capacitacin se pueden considerar los siguientes temas: Contenidos en esta gua Creacin de requerimientos. Revisin de ambigedades. Creacin de casos de prueba. Administracin de ejecuciones de pruebas. Creacin de datos para pruebas. Administracin de defectos. Recoleccin e interpretacin de mtricas. Cursos avanzados Herramientas comerciales para la administracin de pruebas. Herramientas comerciales para ejecucin automtica de pruebas. Tcnicas avanzadas de diseo de pruebas. Administracin de ambientes de prueba. Pruebas sin requerimientos.


15

Gua de Pruebas de Software (GPS) Si los requerimientos de capacitacin de la empresa son muy demandantes en trminos de tiempo y contenido, se puede delegar la capacitacin a empresas externas. Sin embargo, en estos casos el conocimiento ser bsicamente terico y ser necesario realizar al menos uno o dos proyectos para alcanzar el nivel de capacitacin deseado.

b. Investigacin de Tendencias Tecnolgicas (O3)Dentro de esta actividad se trabaja con la tarea Generar propuestas tecnolgicas. La teora de pruebas no puede estar ajena a las tendencias tecnolgicas, ya que las mismas pueden determinar el nivel del xito alcanzado. Las tecnologas ms conocidas en el rea de pruebas son: Las herramientas automticas de pruebas. Tcnicas de pruebas enfocadas a validar tecnologas emergentes. Outsourcing global de pruebas. A pesar de que existen muchas propuestas de tecnologa aplicada a las pruebas es importante determinar el costo/beneficio de cada una de ellas. De cualquier manera, ste es un punto que las organizaciones con experiencia en pruebas deben de considerar, ya que el dominio de una tecnologa emergente por parte de una PyME le dara una ventaja competitiva que sera un detonante inmediato en su crecimiento dentro del mercado.

II.3 Operacin (OPE)Dentro de la categora Operacin, se establecen y ejecutan las actividades enfocadas a lograr los objetivos de un proyecto especfico, de forma sistemtica. Al analizar la categora desde un enfoque de pruebas, se determinan las actividades a realizar para asegurar el funcionamiento correcto del producto entregado en cada una de las fases de desarrollo. As mismo, aqu se implementa el registro y control de mtricas en las ejecuciones con el fin de tener los datos reales de cada uno de los proyectos. Esto proporciona a la gerencia y a la alta direccin material sobre cada una de las etapas del desarrollo que le permite la toma de decisiones correctamente informadas. Las pruebas a realizar dentro de la categora Operacin se enfocan en los procesos: 1) Administracin de proyectos especficos y 2) Desarrollo y Mantenimiento de Software (figura 5).


16


Operacin Administracin de proyectos especficos Desarrollo y mantenimiento de software Inicio Fase de Requerimientos Planeacin Fase de Anlisis y Diseo Fase de Construccin Realizacin Fase de Integracin y Pruebas Cierre

Figura 5 - Cobertura de la gua en la categora de Operacin del modelo MoProSoft.

II.3.1 Administracin de Proyectos Especficos [OPE.1]Dentro de la Administracin de proyectos especficos se encuentra la actividad de Planificacin en la cual se elabora el Plan del proyecto. Adems se encuentra la actividad de Cierre que tiene como objetivo formalizar los acuerdos para poder completar cada fase del proyecto, as como los indicadores para aprobar la terminacin total de ste (ver figura 6).


17


Administracin de Proyectos Especficos Planificacin

Realizacin

Evaluacin y Control

Cierre

MoProSoft ActividadesA1. Planificacin (O1)

A4. Cierre (O1)

Tareas A1.4 A1.6 A1.8 A1.9 A4.1

Actividades GPS 1. Identificar ciclos y actividades 2. Determinar el tiempo estimado para cada actividad 3. Conformar el equipo de trabajo 4. Generar el calendario de trabajo Formalizar la terminacin del ciclo y del proyecto

Figura 6 - Cobertura de la gua en el proceso de Administracin de Proyectos Especficos.

a. Planificacin (O1)La teora de pruebas dentro del proceso de Administracin de proyectos especficos se aplica en las siguientes tareas: 1) Identificar ciclos y actividades, 2) Determinar el tiempo estimado, 3) Conformar el equipo de trabajo, y 4) Generar el calendario de trabajo. 1) Identificar ciclos y actividades Ciclos. El nmero de ciclos de pruebas se define de acuerdo a los objetivos de la organizacin y de las actividades de pruebas que se realicen dentro del proyecto. En la tabla 5 se proponen los ciclos de prueba, de acuerdo al tipo de prueba.Tipo de Prueba Revisin de Documentos Pruebas de Integracin de Componentes Pruebas de Humo Pruebas de Sistema Pruebas de Regresin Pruebas de Aceptacin de Usuario < de 3 Ciclos 3 a 10 Ciclos Ms de 10 Ciclos

Tabla 5 - Cantidad de ciclos de prueba para los tipos de prueba.


18

Gua de Pruebas de Software (GPS) Actividades generales. Son las actividades de pruebas mnimas que deben de ejecutarse en todos los proyectos con el fin de asegurar que la calidad de los entregables cumple con los estndares de la organizacin. Se sugieren las siguientes: Creacin y revisin de documentos de pruebas. Pruebas de Integracin de Componentes. Pruebas de Aceptacin de Usuario. Administracin de las actividades de pruebas. Criterios de aceptacin y/o detencin. Estas actividades generales se aplican de acuerdo a las polticas del rea de pruebas de la organizacin. Actividades especficas. Son las actividades de pruebas especiales que se requiere ejecutar slo en ciertos proyectos, con el objetivo de determinar: los diferentes tipos de pruebas a realizar en el proyecto, el nivel de revisin/aprobacin de documentos, controles de entrada y salida para cada etapa del proyecto, criterios de aceptacin y detencin, etc. Algunos ejemplos de este tipo de actividades son: Ejecutar una fase de pruebas con los usuarios finales en proyectos de gobierno. Ejecutar actividades de control de esfuerzos dentro del proyecto. Realizar una fase de pruebas de conectividad con dispositivos o sistemas externos. Realizar pruebas de estrs. Realizar pruebas en los procesos de recuperacin de desastres. Pruebas de hacking tico. Conforme la empresa adquiera experiencia, es posible mantener la informacin referente a todas estas actividades en una base de datos, as como la aportacin y las lecciones que se hubiesen aprendido. 2) Determinar el tiempo estimado El tiempo estimado para cada actividad vara de acuerdo a la experiencia de la empresa, el tamao del proyecto y los requerimientos especficos de ste. Por lo tanto es muy difcil determinar este tiempo sin contar con una base de informacin de proyectos previos. Es necesario consolidar la informacin adecuada de los proyectos registrados, de tal manera que la misma resulte confiable. A medida que la organizacin gane experiencia, contar con los datos requeridos para realizar estimaciones acertadas. 3) Conformar el equipo de trabajo Equipo de trabajo. Un equipo de trabajo debe estar organizado con el objeto de cubrir los objetivos y estrategias de la organizacin. Puede estar integrado por una o varias personas, dependiendo del proyecto y de la organizacin, y puede incluir personal externo. En general, las PyME no cuentan con personal dedicado exclusivamente a las pruebas. Por lo tanto se deben asignar los roles dedicados a las mismas entre miembros de la organizacin, siendo especialmente importante la participacin del responsable del proyecto.


19

Gua de Pruebas de Software (GPS) Roles involucrados y capacitacin. MoProSoft indica solamente 2 roles para realizar las actividades de pruebas: Responsable de pruebas: persona que tiene el conocimiento y/o la experiencia en la planificacin y realizacin de Pruebas de Integracin y de Sistema. Revisor: persona que tiene el conocimiento en las tcnicas de revisin y experiencia en el desarrollo y mantenimiento del software. Estos roles son fundamentales, sin embargo dentro de la industria podemos encontrar una especializacin de los mismos, en: Administrador de pruebas: persona encargada de administrar las pruebas desde un nivel gerencial. Es decir, valida los planes generales, controla el presupuesto y mantiene la comunicacin entre pruebas y las otras reas que conforman la empresa. Analista de pruebas: es un experto en pruebas que conoce y aplica la teora general de pruebas en los diferentes proyectos con el objetivo de cumplir con la estrategia de pruebas definida por la organizacin. Diseador de pruebas: esta persona se encarga de disear los diferentes casos de prueba, de acuerdo a la cobertura que se dar a cada requerimiento. No requiere dominar toda la teora de pruebas, ya que se encargar de desarrollar los casos de prueba en los formatos pre-establecidos y de revisar los casos de prueba creados por otros miembros del equipo. Sin embargo, s es recomendable que conozca del negocio y que domine los requerimientos del proyecto. Tester: es el encargado de ejecutar las pruebas, no necesita conocer el proyecto ni el sistema a evaluar; simplemente tomar cada caso de prueba y lo ejecutar de manera imparcial, validando que el resultado obtenido corresponde al resultado esperado. Adicionalmente existen otros roles con actividades ms especficas, aunque son empleados nicamente cuando los proyectos son muy grandes: Administrador de datos de pruebas: persona que tiene acceso a las bases de datos de cada uno de los proyectos de pruebas. Las siguientes actividades son responsabilidad de este rol: Entregar los insumos (datos) a utilizar en la ejecucin. Configurar las bases de datos para que estn listas para comenzar la ejecucin. Reiniciar los datos a un estado inicial o ejecutar procesos para obtener una modificacin deseada en ellos. Validar la modificacin de los datos de prueba durante la ejecucin (si el proyecto lo requiere). Administrador de ambientes: es el encargado de administrar el ambiente de pruebas (software) con el objetivo de usar estos recursos de manera eficiente. Entre las actividades que realiza se encuentran: Determinar fechas y horarios de ejecucin para cada proyecto. Administrar el acceso a los diferentes ambientes. Realizar copias de seguridad. Configurar los ambientes de acuerdo a requerimientos especficos. Monitorear las interfaces entre ambientes y sistemas.


20


Administrador de equipos de prueba: encargado de controlar y administrar los diferentes recursos de pruebas que tiene la empresa. Esto incluye hardware, software, licencias de uso, tiempos de utilizacin, etc. Esta persona tambin es experta en la configuracin y puesta a punto de los equipos, por lo tanto puede brindar un servicio integral asegurndose de dar el mejor uso a estos recursos. Administrador de requerimientos y cambios: encargado de crear y actualizar la tabla de requerimientos, utilizando al menos un proceso de control de cambios para realizar cada movimiento. Tambin entrega reportes de cobertura de requerimientos con las pruebas ejecutadas. Administrador de grupos de pruebas: Este rol est enfocado a empresas que tienen distintos equipos de pruebas trabajando con diferentes proyectos al mismo tiempo, ya sean locales, nacionales o internacionales. El rol principal es el de asegurarse que los recursos humanos estn asignados de manera eficiente, pudiendo rotar al personal de un proyecto a otro de acuerdo a sus necesidades. 4) Generar el calendario de trabajo Calendario. Una vez que se tiene conformado el listado de actividades a desarrollar y el grupo de personas que participarn en ellas es posible determinar los tiempos aproximados para completar la fase de pruebas. Conforme el grupo de pruebas de la organizacin gane experiencia, se podr determinar con ms precisin el tiempo requerido para cada actividad. Es importante tener presente algunos factores del mundo de los negocios que pueden influir: Rotacin de personal. Ventas con tiempos estrechos. Requerimientos especficos del proyecto. A pesar de todo, es necesario tener en mente que el calendario de trabajo de pruebas se debe realizar manteniendo un tiempo suficiente para resolver los posibles problemas que ocurran dentro del desarrollo de las mismas. Este tiempo debe de ser el justo (no holgado) y puede estar soportado de un anlisis de los riesgos para completar cada actividad. Para asignar los tiempos es necesario crear una lnea base para cada actividad, de acuerdo a: La complejidad. La cantidad de recursos que se encargarn de realizarla. Referencias propias o de la industria para desarrollar la actividad. Determinar variacin de la duracin de cada actividad, con base en: La experiencia que cada recurso tiene en esa tarea en especfico. La cantidad de veces que se realizar la actividad (a mayor nmero de ejecuciones, menor el tiempo destinado a cada ejecucin nueva). Factores externos. Si no se cuenta con una referencia concreta previa, estos valores pueden estimarse en conjunto con los encargados de desarrollar las actividades. Es importante registrar los tiempos utilizados para cada actividad del proyecto con el objeto de generar informacin que posteriormente


21

Gua de Pruebas de Software (GPS) permitir realizar las estimaciones de una manera rpida y exacta. Para las actividades que requieren de la ejecucin de tareas que no son responsabilidad del grupo de pruebas es necesario tener acuerdos de tiempos de servicio con las reas externas involucradas. En la tabla 6 se presentan algunas estimaciones de tiempos lmites requeridos para resolver problemas, segn la importancia de los mismos y la dificultad de la actividad. Por ejemplo, para una actividad de dificultad media y un defecto de importancia alta se tendrn como mximo 4 horas. Considerando esta informacin ser posible establecer un tiempo base de respuesta.

Dficultad Fcil Medio Dficil

Importancia del defecto encontrado Baja Media Alta Crtica 12 Hrs 4 Hrs 2 Hrs 1 Hr 24 Hrs 10 Hrs 4 Hrs 2 Hrs 36 Hrs 16 Hrs 8 Hrs 6 Hrs

Tabla 6 - Acuerdo de servicio para resolucin de defectos.

Una vez determinadas las actividades, ser necesario asignar fechas de inicio y fin a cada una con el fin de generar el Calendario de Trabajo tomando en cuenta los recursos, la secuencia y la dependencia de las actividades. Es necesario identificar las actividades que se pueden ejecutar de manera independiente a la fase en la que se encuentren, de tal manera de minimizar los tiempos muertos. El calendario global del proyecto debe contemplar el tiempo necesario para realizar las actividades de pruebas, considerando: Revisin de documentos de las pruebas. Creacin de datos de pruebas. Resolucin de defectos (a cargo del grupo de desarrollo). Re-ejecuciones de pruebas. Revisin de la evidencia de las pruebas. Solicitud de cambios. Cada modificacin en las actividades, requerimientos o tiempos del plan original ocasionan un impacto en las pruebas. Dentro del calendario del proyecto es muy difcil determinar el impacto ocasionado por un cambio en las actividades. Sin embargo, si todas las actividades se encuentran correctamente documentadas, cuando ocurra un cambio es posible administrarlo y planearlo de manera ms fcil.

b. Cierre (O1)La teora de pruebas apoya en Formalizar la terminacin del ciclo y del proyecto dentro de la actividad de Cierre. Al tener identificados los requerimientos del proyecto es posible implantar criterios para aprobar el cierre de ciclos y del proyecto. Un criterio muy simple es establecer un porcentaje de requerimientos ejecutados exitosamente (por ejemplo el 90%), o bien la validacin total de ciertos requerimientos crticos para cada ciclo o para el proyecto total.


22


II.3.2 Desarrollo y Mantenimiento de Software [OPE.2]Las seis actividades MoProSoft de esta categora se muestran en la figura 7. Las mismas soportan el ciclo de vida de un proyecto de software. Asimismo, en la figura 7 se presenta un esquema de las actividades cubiertas por esta gua.

Inicio

Desarrollo y mantenimiento de Software

Requerimientos

Anlisis y Diseo

Construccin

Integracin y Pruebas

Cierre

MoProSoft Actividades GPS ActividadesA2. Realizacin de la fase de Requerimientos (O1, O3) A3. Realizacin de la fase de Anlisis y Diseo (O1, O3) A4. Realizacin de la fase de Construccin (O1, O3) Creacin de los casos de prueba ( NI) A5. Realizacin de la fase de Integracin y Pruebas (O1, O3) A6. Realizacin de la fase de Cierre (O2)

Tareas A2.2A2.3 A2.7 NI A3.2 A3.7 A4.2

1. Documentar o modificar la Especificacin de Requerimientos 2. Verificar la Especificacin de Requerimientos 3. Elaborar o modificar Plan de Pruebas de Sistema 4. Pruebas de Aceptacin 1. Generar la descripcin de la estructura interna del sistema y del registro de rastreo 2. Elaborar o modificar Plan de Pruebas de Integracin Definir y aplicar pruebas unitarias a los componentes

NI NI A5.2 A5.6 NI NI A6.1

1. Definir y crear Casos y Escenarios de Pruebas 2. Crear datos de pruebas 1. Realizar integracin y pruebas 2. Realizar las Pruebas de Sistema 3. Realizar las Pruebas de Aceptacin 1. Decisin de finalizacin del proyecto 2. Manual de mantenimiento

Figura 7 - Cobertura de la gua en el proceso de Desarrollo y Mantenimiento de software.


23


a. Realizacin de la fase de RequerimientosLa teora de pruebas apoya las siguientes tareas de la actividad Realizacin de la fase de Requerimientos en el proceso de Desarrollo y Mantenimiento de Software: 1) Documentar o modificar la especificacin de requerimientos, 2) Verificar la especificacin de requerimientos y 3) Elaborar o modificar plan de pruebas de sistema. 1) Documentar o modificar la especificacin de requerimientos La especificacin de requerimientos es un documento formal donde se listan todas las funcionalidades que debe contar el sistema una vez liberado. Este documento debe ser realizado por el analista, el cliente, el usuario y el diseador de las interfaces. MoProSoft seala que los requerimientos se dividen en las siguientes categoras: Funcionales Interfaz de Usuario Interfaces externas Confiabilidad Eficiencia Mantenimiento Existen otras categorizaciones por lo que se recomienda que el grupo de pruebas y los responsables de los requerimientos sigan una misma tipificacin. 2) Verificar la especificacin de requerimientos Una vez que se tiene la especificacin de requerimientos, podemos realizar la verificacin de la misma mediante las siguientes actividades: Identificacin nica de todos los requerimientos del proyecto. Realizar una revisin de los requerimientos (pruebas estticas). Identificacin nica de todos los requerimientos del proyecto. Debido a que se pretende realizar revisiones de todos los requerimientos, es importante contar con un identificador nico para: Mantener un panorama completo del total de los requerimientos del proyecto, as como de su severidad y de los datos relevantes de cada uno de ellos. Facilitar la administracin de las actividades relacionadas a los tipos de pruebas aplicados a cada uno. Soportar la tarea de asegurarse de que todos los requerimientos contienen alguna validacin asociada (cobertura total). Tener una base de requerimientos nica y administrada para facilitar las tareas de fases posteriores del proyecto. Para lograr una identificacin eficiente se pueden seguir los siguientes pasos:


24

Gua de Pruebas de Software (GPS) 1. Agrupar los requerimientos a alto nivel, de acuerdo al rea del negocio a la que pertenecen o al mdulo del sistema en caso de que slo aplique a un rea. A cada grupo se le asigna un identificador que represente el nombre del grupo, el cual se recomienda que se componga de 2 o 3 letras, por ejemplo: CM (Compras), VT (Ventas),GG (Gerencia General), etc. 2. Asignar un nmero nico a cada requerimiento, dentro de cada grupo. La forma ms usada es utilizando una numeracin secuencial, este nmero debe ser precedido del identificador del grupo, por ejemplo: VT.0030. Es importante asegurarse de tener una cantidad adecuada de dgitos para cubrir todos los posibles requerimientos que se encuentran dentro del mdulo. En la tabla 7 se presenta un ejemplo. Realizar una revisin de los requerimientos (pruebas estticas). El objetivo de esta revisin es validar que 1) El requerimiento cumple con lo que la organizacin requiere y 2) Los requerimientos estn redactados claramente.# Descripcin # # Negocio Negocio Consecutivo Requerimiento Descripcin Requerimiento Comentarios

GN

General

0001

GN.0001

GN

General

0002

GN.0002

Usar la imagen de la empresa en todas las pantallas. El sistema debe mostrar una pantalla de arranque indicando versin, fecha de creacin y nombres legales del sistema y de la empresa.

Todas las pantallas deben contener el logo y los colores de la empresa Los nombres se pueden obtener del area de Legal, en el documento "Nombre y Marcas Legales.doc" Nivel 1: Administrador: Se muestran todos los mens del sistema. Nivel 2: Ventas: Se muestran los mdulos de ventas y los de consulta del sistema. Nivel 3: Compras: Se muestran los mdulos de Compras y los de consulta del sistema. No se crear el sistema para soporte a sistemas operativos Mac ni Linux.

Se deben de manejar 3 nveles de usuario, cada nivel contiene un determinado nmero de mdulos que se mostrarn.GN General 0003 GN.0003

GN

General

0004

GN.0004

VT

Ventas

001

VT.001

El sistema debe de soportar los siguientes sistemas operativos: Windows 98, Windows 2000, Windows XP, Windows Vista. Cada venta debe contener la siguiente informacin: Empleado, Cliente, RFC Cliente, Monto total, Tipo de pago, Referencia de pago, Fecha de pedido, Fecha de entrega, Lista de productos y Nmero de factura.

El nmero de factura electrnico debe ser similar al nmero de factura impreso en el papel.

Tabla 7 Ejemplo de listado de requerimientos

1) El requerimiento cumple con lo que la organizacin requiere. Consiste en validar que los requerimientos representan todo lo que la organizacin desea para el proyecto. Elementos a tener en cuenta: Contenido Los requerimientos cumplen con los objetivos del proyecto. Se encuentran documentados todos los requerimientos requeridos para cumplir con estos objetivos (diseo completo). Los requerimientos no se repiten, son independientes y nicos. La definicin de pantallas est documentada. Si existen, los dispositivos especiales se encuentran documentados. Capacidad Los tiempos definidos para las actividades son suficientes. Se tiene la capacidad tecnolgica para cumplir con los requerimientos. Son costeables. Los requerimientos son factibles (por ejemplo, incrementar la capacidad de tomar rdenes en un 20% con la misma base de personal).


25


Negocio Se encuentran alineados con los objetivos de la organizacin. Se estn aplicando todas las actividades definidas en el plan de pruebas. Las caractersticas del proyecto no entran en conflicto con otros productos del mercado. Cualquier asunto legal involucrado se encuentra definido. El producto final expresa lo que el cliente desea. Debido a que las revisiones son requeridas por varios niveles de la organizacin, es difcil reunir a todas las personas involucradas, para esto existen tcnicas que apoyan estas tareas, entre las que se encuentran: Pares: es una revisin informal donde el autor del documento lo entrega a un compaero para que realice observaciones y sugerencias antes de pasarlo a una revisin o a una entrega formal. Grupales: como su nombre lo indica, es una revisin de las personas involucradas en el desarrollo de los requerimientos, generalmente se enfocan slo a la parte del negocio. Estas pruebas se realizan en una reunin en tiempo real, ya sea presencial o soportada por alguna de las tecnologas actuales de telecomunicacin. Guiadas: el autor enva el documento (o secciones de ste) a varias personas que pueden realizar la evaluacin. As, el autor puede guiar de manera directa el criterio que tomar cada persona para realizar la revisin. La retroalimentacin se da de manera escrita pero informal. El propio autor es el encargado de actualizar el documento con base en los comentarios recibidos. Reuniones formales: es una reunin donde se exponen todos los temas relacionados con el rea de dominio del personal que asiste a ella. Se crea una minuta de cada reunin, con firma de acuerdo de cada asistente, con el fin de dejar en evidencia lo acordado y que al final de todas las reuniones se pueda integrar un documento global aprobado por las reas. Se pueden realizar diferentes reuniones formales de revisin, de acuerdo a los temas, el enfoque general del proyecto, con el cliente, etc. Documentos gua: se envan los requerimientos a un grupo de revisores con el objeto de que cada uno registre sus observaciones y correcciones dentro de un documento de control formal que contiene reglas especficas para su llenado. Este documento es el ms difcil de completar pero es tambin aquel que nos proporciona la mayor cantidad de informacin relacionada a las pruebas estticas. Tcnicas: realizadas por personal con buenas habilidades tcnicas. Sirve para determinar la factibilidad del proyecto, los requerimientos tcnicos de cada uno de los objetivos, las especificaciones de diseo y las herramientas a utilizar, entre otros. Gerenciales: el objetivo es reunir a los diferentes encargados de las reas del proyecto (incluyendo al cliente como encargado final), con el fin de llegar a un entendimiento en los asuntos que relacionen a 2 o ms reas. Por ejemplo, el rea legal con la de diseo grfico o contabilidad con programacin. Para estas reuniones se recomienda tener una agenda con temas puntuales donde se requiera llegar a un acuerdo de ambas partes, con el objeto de no alargar las revisiones y poder finalizar las negociaciones de una manera eficaz.


26

Gua de Pruebas de Software (GPS) Con todas estas validaciones se pretende llegar a un acuerdo para aprobar la especificacin de requerimientos obteniendo un documento robusto que incluye la conjuncin de los puntos de vista de todas las reas involucradas. 2) Los requerimientos estn redactados claramente. La segunda parte de la revisin de requerimientos se centra en la redaccin de los mismos, mediante la aplicacin de las tcnicas de revisin grupales. Esta validacin intenta asegurar que los requerimientos cumplen con las siguientes caractersticas: Requerimientos escritos en un lenguaje entendible por todos los involucrados de la organizacin. Todos los trminos estn claramente definidos. Todas las sentencias tienen inicio y fin. Los requerimientos son cuantificables. No existen elementos inconclusos o ambiguos dentro de los requerimientos. Al finalizar con estas 2 actividades, se debe de tener como producto final: El listado de requerimientos completo, donde se tiene identificado de manera nica el rea a la que pertenece cada requerimiento. Los documentos que muestran los defectos de las revisiones formales de los requerimientos. 3) Elaborar o modificar plan de pruebas de sistema Plan de Pruebas. Un plan de pruebas de sistema es un documento formal que incluye un listado de las actividades de pruebas a ejecutarse posterior a la entrega del software por parte del rea de desarrollo. Es recomendable que desde el inicio se asignen tiempos aproximados para dimensionar la duracin total de las pruebas y aunque este tiempo se ir modificando conforme se realicen las revisiones y se avance en el proyecto, la primer estimacin es til porque servir de base para realizar los clculos y planeacin inicial. Dentro de la planeacin de la PyME, suele verse a la fase de Pruebas de sistema como un gran bloque con fechas de inicio y fin, sin embargo, este plan debe de desglosarse al menos en las actividades complementarias, con el fin de determinar el alcance y cobertura y por tanto el grado de confiabilidad de las pruebas. Algunas actividades a considerar dentro de un plan de pruebas de sistema son las siguientes: Pruebas estticas. Estas pruebas se pueden desarrollar en conjunto con la revisin de los requerimientos, dejando los puntos pendientes como una actividad de cierre de pruebas estticas dentro del plan general. Administracin de las pruebas. Es una actividad que abarca todas las fases de las pruebas, es importante debido a los recursos que sta consume, as como los tiempos destinados a revisiones, reuniones y toma de decisiones. Condiciones y escenarios de prueba. La identificacin de estas actividades se realiza para soportar el diseo de los casos de prueba. Las condiciones determinan todas aquellas funciones que el sistema necesita realizar para poder considerarlo completo.


27

Gua de Pruebas de Software (GPS) Los escenarios identifican la cobertura que es necesario alcanzar de acuerdo a la estrategia de pruebas definida en la estrategia general de la empresa para el tipo de proyecto a realizar. Creacin de casos de prueba. Es el periodo determinado para analizar, disear y construir los casos de prueba que sern ejecutados dentro de esta fase de pruebas. Es posible incluirlo como una actividad macro o dividirlo por mdulos, tipo de prueba o funcionalidad del sistema. Revisin de los casos de prueba. Esta es una actividad que va a la par con la creacin de los casos de prueba. Sin embargo, dependiendo de los requerimientos, es posible definirla como una actividad individual. Un ejemplo claro de esto es cuando se desarrollan casos de prueba que tienen que ser autorizados por un rea ajena a la ejecucin de stos, tal como contabilidad o finanzas. Creacin y carga de datos de prueba. Es el tiempo destinado para comprobar, migrar o agregar datos en el sistema, tales como: configuracin de cuentas, accesos, pedidos previos, cargas de datos reales, etc. Tambin se debe contemplar el tiempo adecuado para realizar una revisin de los mismos. Plan de ejecucin de las pruebas. Dentro de esta actividad se disean una o varias secuencias de la ejecucin de las pruebas planeadas. Cada secuencia debe de tener por objetivo dar prioridad a un tipo de cobertura. Consecuentemente, se pueden crear varios caminos alternos para el caso de tener problemas con la entrega del sistema final. Ejecucin de las pruebas. Es el tiempo determinado para llevar a cabo la ejecucin de todos los casos de prueba dentro de cada una de las fases del sistema, incluyendo el porcentaje de reejecuciones esperadas y el nmero de ciclos que realizarn dentro de cada fase. El tiempo de reejecuciones generalmente se determina por experiencia, aunque una cifra usada de manera estndar en la industria es el 30% del tiempo normal. Resolucin de defectos. Para determinar el tiempo adecuado para la resolucin de defectos se debe consultar con el rea de sistemas. Una forma sencilla de determinar este tiempo para el caso de que no se tenga experiencia previa es el siguiente: considere un proyecto de 100 requerimientos, donde aproximadamente se tiene un 30% de defectos (re-ejecuciones). Se puede determinar el tiempo usando una curva exponencial de acuerdo a la severidad de resolucin de cada defecto, como se muestra en la tabla 8.

Defectos por Severidad Baja Media Alta Cantidad de Defectos 18 9 3 Tiempo de Resolucin 4 10 24 Tiempo Total (Hrs) 72 90 72 234 Horas requeridas para resolver los defectos 100 RequerimientosTabla 8 - Tiempo aproximado para resolucin de defectos en un proyecto de 100 requerimientos.

De acuerdo a las caractersticas del proyecto y la capacidad del rea de desarrollo es posible prescindir de un tiempo exclusivo para la resolucin de defectos, pero esto ocurre slo en el caso de


28

Gua de Pruebas de Software (GPS) que se pueda realizar la actividad a la par de la ejecucin de otros casos de prueba. Entonces esta actividad sera complementaria a la ejecucin total. En el caso de que el tamao del proyecto, o la duracin de los ciclos de pruebas sean cortos (menor a 2 semanas), es sumamente recomendable agregar el tiempo de resolucin de defectos como una actividad crtica dentro del plan del proyecto. Esto con el fin de dar tiempo al equipo de desarrollo para la resolucin de alguna contingencia. Revisin de resultados y aprobacin de las pruebas. Tambin es importante agregar un tiempo determinado para realizar una revisin detallada de los resultados de la ejecucin de las pruebas, para que de esta manera se pueda garantizar que los resultados obtenidos son correctos y se encuentran correctamente documentadas. Aqu se puede tomar la decisin de realizar una reunin de revisin de cierre de fase de pruebas, donde se acepte que los criterios de salida de la fase se han cubierto de manera satisfactoria. Otras actividades. Adicionalmente a cada actividad se puede agregar un listado de recursos a utilizar, as como los responsables por el cumplimiento de cada una de ellas. Pruebas de aceptacin. Si el sistema lo amerita, ser necesario obtener una acreditacin del usuario mediante las pruebas de aceptacin de usuario. Estas pruebas no se encuentran en el modelo MoProSoft, sin embargo son tiles porque se enfocan en validar el sistema desde el punto de vista del negocio (o del usuario final), ejecutando todas las transacciones necesarias para simular un da normal de operacin. Generalmente, las pruebas de aceptacin se basan en las pruebas de sistema, siendo una simplificacin de stas, debido a que se valida la misma funcionalidad pero desde la perspectiva del negocio. Al momento de asignar tiempos a las actividades de esta fase, se debe recordar que sern ejecutadas por los usuarios finales, quienes no tienen un contexto especfico de las pruebas y las realizarn desde el punto de vista operacional. Existen otras tareas que se pueden realizar dentro de esta fase, tales como: Comprensin y modificacin de casos de prueba de sistema. Se pueden modificar casos de prueba para ajustarlos al enfoque de las pruebas de aceptacin de usuario. Actividades de acondicionamiento del ambiente. Existen algunas actividades requeridas para acercar el ambiente de las pruebas a la realidad de produccin, tales como: carga de archivos externos, encriptacin y carga de datos de produccin, modificacin de fechas de sistema durante las ejecuciones, etc. Administracin de datos de prueba macro. De acuerdo al sistema, es probable que requiera de un tiempo determinado para administrar datos que son afectados dentro de los diferentes escenarios de prueba ejecutados, tales como: archivos contables, reportes finales, consultas mensuales, etc.

b. Realizacin de la fase de Anlisis y DiseoDentro de la actividad Realizacin de la fase de anlisis y diseo, las pruebas se aplican en las siguientes tareas: 1) Generar la descripcin de la estructura interna del sistema y del registro de rastreo y 2) Elaborar o modificar el plan de pruebas de integracin. 1) Generar la descripcin de la estructura interna del sistema y del registro de rastreo GPS - Guardati & Ponce 29

Gua de Pruebas de Software (GPS) Descripcin de la estructura interna del sistema. Las pruebas pueden ayudar a alcanzar 2 objetivos: 1) Identificacin nica del desglose de requerimientos del proyecto y 2) Realizar una revisin del desglose de requerimientos. 1. Identificacin nica del desglose de requerimientos del proyecto. Es necesario asegurarse en continuar con la nomenclatura anterior, agregando un sub-nmero en cada nuevo requerimiento desglosado. En la tabla 9 se presentan algunos ejemplos.

# Requerimiento

Descripcin Requerimiento

# SubRequerimiento GN.0001.001

Desglose del requerimiento (Estructura interna) Existir un objeto "Layout" que contendr los logos y los colores de la empresa. Todas las pantallas podrn utilizar el objeto "Layout Empresa" para heredar sus caractersticas. Creacin de un objeto "Pantalla" que desaparezca despus de cierto tiempo, adems contenga la facilidad de parametrizar sus componentes. Crear un men de nivel 1 que corresponda al de Administrador.

GN.0001

Usar la imagen de la empresa en todas las pantallas. El sistema debe mostrar una pantalla de arranque indicando versin, fecha de creacin y nombres legales del sistema y de la empresa.

GN.0001.002

GN.0002

GN.0002.001

GN.0003

GN.0003.001 Se deben de manejar 3 nveles de usuario, cada GN.0003.002 GN.0003.003 nivel contiene un determinado nmero de mdulos que se mostrarn. GN.0003.004

Crear un men de nivel 2 para Ventas. Crear un men de nivel 3 para Compras. Crear una pantalla de firma digital para seleccionar el men a aplicar.

Tabla 9 - Desglose de requerimientos del proyecto.

2. Realizar una revisin del desglose de requerimientos. Es una tarea sencilla si se mantiene la nomenclatura original en la especificacin de requerimientos, bastando con agregar una marca de desglosado en cada rengln en el que se encuentra realizada la descripcin de la funcionalidad interna. Registro de rastreo. El registro de rastreo es una herramienta que contiene todos los requerimientos y todos los casos de prueba indicando una relacin 1 a 1 o 1 a varios, y ser muy til tanto para la administracin de la ejecucin de las pruebas como para determinar la cobertura que tiene cada caso o escenario de pruebas. El insumo principal del registro de rastreo es la especificacin de requerimientos en el nivel desglosado. Posteriormente ser necesario agregar los tipos de pruebas que se realizarn segn las siguientes fases del proyecto. En esta fase del proyecto no ser posible indicar la relacin entre casos de prueba y requerimientos, pero se podr actualizar conforme se desarrollen las siguientes etapas. En la tabla 10 se presenta un ejemplo.


30

Gua de Pruebas de Software (GPS)Matriz de Rastreo V. 002 Actualizado: 04-ene-08

Listado de Requerimientos# Requerimiento # Sub-Requerimiento

Casos de prueba Caso 1 Caso 2 Caso 3 Caso 4 Caso 5 Caso 6

GN.0001 GN.0002 GN.0003

GN.0004

GN.0001.001 GN.0001.002 GN.0002.001 GN.0003.001 GN.0003.002 GN.0003.003 GN.0003.004 GN.0004.001 GN.0004.002 GN.0004.003Tabla 10 - Ejemplo de registro de rastreo.

2) Elaborar o modificar plan de pruebas de integracin Plan de pruebas de integracin. El plan de pruebas de integracin contiene un desglose detallado de todas las actividades de pruebas a realizar durante la construccin del cdigo nuevo (o modificado), enfocndose en los requerimientos desde un punto de vista tcnico. Se debe de validar principalmente: La interaccin entre los diferentes mdulos que componen al sistema. La interaccin con sistemas externos que soportan o reciben la informacin que es procesada en el software evaluado. El adecuado uso de las interfaces externas del sistema, incluyendo impresoras, lectoras, terminales porttiles, pantallas, etc. El manejo de errores en todas las transacciones validadas. Las actividades incluidas en esta fase deben de soportar la ejecucin de las pruebas en un bajo nivel. Es decir, se deben incluir (entre otras) las siguientes: Entendimiento del diseo interno del sistema, ya que ser la base del diseo de los escenarios. La validacin de los ambientes donde se realizarn las pruebas. La administracin de las versiones de cada pieza mediante un control estricto de cambios. La creacin de escenarios de prueba donde se muestren las relaciones entre los componentes y su prioridad hacia los requerimientos ms crticos del sistema, incluyendo el diseo de los casos para el manejo de errores. El desarrollo de componentes adicionales que simulen las interfaces entre el sistema desarrollado o modificado y otros sistemas. La implantacin de controles de seguridad para ejecutar las pruebas, esto debido a que el tester tendr a disposicin cdigo que puede ser modificado accidentalmente. Configuracin de equipos externos, incluyendo tiempos de entrega, cotizaciones, etc.


31

Gua de Pruebas de Software (GPS) Resolucin de defectos. De ser posible, crear un plan de entrega de mdulos programados (o modificados), con el fin de hacer eficiente la ejecucin de las pruebas. Validacin de resultados y aceptacin del cumplimiento de la fase. De acuerdo al perfil que tengan los testers, esta fase puede ser responsabilidad del grupo de programadores. Sin embargo, es necesaria la validacin de las evidencias de la realizacin exitosa de las pruebas y por tanto del cumplimiento de los criterios de salida de la fase. Para determinar los tiempos y la importancia que se dar a cada requerimiento ser necesario asignar prioridades a cada actividad, de acuerdo a los criterios establecidos en la estrategia de pruebas y a factores como: El riesgo potencial considerando el rea del negocio a la que pertenece. Su importancia. El costo de permitir la aparicin de defectos en produccin. Tamao del requerimiento. Requerimientos regulatorios gubernamentales. La funcionalidad. Uso de tecnologas especiales y su grado de dominio (WiMax, GPS, triple play, etc.) Especificaciones de rendimiento del software (disponibilidad, capacidad de carga, etc.). Conocimiento de la industria a la que se destinar el software. Una vez que se han asignado las prioridades, los requerimientos deben ser agrupados de acuerdo a las categoras pactadas en la especificacin de requerimientos. De esta manera, se forman grupos de ejecuciones que permitirn tener flexibilidad en la ejecucin de las pruebas y poder cambiar el enfoque de stas de acuerdo a los resultados obtenidos da a da.

c. Realizacin de la fase de ConstruccinDurante la fase de construccin se deben de desarrollar las pruebas unitarias de los componentes. Definir y aplicar pruebas unitarias de los componentes El objetivo de estas pruebas es que el programador valide la funcionalidad de cada componente o mdulo programado de manera individual, tanto para casos correctos como para casos de error, con el objeto de validar la capacidad de los componentes para soportar las fallas. Debido a la naturaleza de estas pruebas, es difcil lograr evidencia concreta de cada ejecucin, sin embargo es posible usar alguna de las siguientes tcnicas para administrar el trabajo de una manera adecuada: 1. Control de versiones Como se ha mencionado anteriormente, una administracin adecuada de las versiones permite mejorar el cdigo de manera incremental, evitando duplicar errores que ya se haban corregido con anterioridad o programar con versiones defectuosas. Un control de versiones se puede administrar de forma sencilla, por ejemplo como en la tabla 11.


32

Gua de Pruebas de Software (GPS)Fecha 01/12/2007 02/12/2007 01/12/2007 04/12/2007 01/12/2007 30/11/2007 Versin actual 0.00023 0.00003 0.00001 0.00008 0.00002 0.00001 Nombre de componente Manejador de impresora Matriz de Puntos Manejador de impresora ticket Conectividad con Sistema "e-Gobierno" Exportador de Consultas SQL a txt Registro de Logs de transacciones Validador de Login de Usuario Dueo de versin Carmen Jmenez Carmen Jmenez Erasmo Torres William Whiteriver William Whiteriver William Whiteriver

Tabla 11 Ejemplo de control de versiones.

Si la madurez de los procesos y del grupo de pruebas es avanzada, a esta tabla se le puede agregar informacin adicional, tal como: comentarios, estado actual de la pieza, localizacin fsica, complejidad, etc. 2. Registros de pruebas exploratorias Es un documento donde se guardan los resultados de las pruebas realizadas, as como la versin del componente que se est validando. Ayuda a tener un registro de los defectos encontrados durante la fase de programacin de una manera rpida y fcil de usar. Un ejemplo de un registro de pruebas exploratorias se muestra en la tabla 12.Ejecucin Versin Fecha Pieza Resultado obtenido

Exportador de consultas SQL a archivo de 1 0.00001 21/11/2007 Texto. Exportador de consultas SQL a archivo de 2 0.00002 23/11/2007 Texto.

1. No se ha logrado parametrizar la ruta de manera adecuada.

1. Ya se logr parametrizar la ruta. 2. El archivo est convirtiendo la consulta esperada. 1. La impresin se realiza de manera correcta. 2. Se requiere enviar el control de corte de pgina al 3 0.00001 23/11/2007 Administrador de impresora laser tipo ticket. impresor. 1. El corte de pgina del impresor se realiza de la 4 0.00002 25/11/2007 Administrador de impresora laser tipo ticket. manera adecuada. 1. La impresora no se reestablece despus de que el 5 0.00003 25/11/2007 Administrador de impresora laser tipo ticket. sistema entra en hibernacin.

Tabla 12 Ejemplo de registro de pruebas exploratorias.

d. Creacin de los casos de pruebaEsta es una tarea que no est contemplada dentro del modelo MoProSoft, sin embargo en la teora de pruebas es esencial que se realice de manera previa a la ejecucin de cualquiera de los tipos de pruebas. Las tareas que conforman esta actividad son las siguientes: 1) Definir y crear casos y escenarios de prueba y 2) Crear los datos para pruebas. 1) Definir y crear casos y escenarios de prueba El objetivo de crear los casos y escenarios de pruebas es documentar las acciones que se realizan al ejecutar cada prueba. Los casos de prueba se deben ejecutar de acuerdo al nivel de pruebas que se necesite; es decir: integracin, sistemas y aceptacin de usuario. Adicionalmente, actualizando el registro de rastreo se puede mantener un control de pruebas para documentar el avance de stas, as como guardar evidencia de la realizacin de las mismas. Casos de pruebas de integracin. Los casos de prueba en esta fase se disean de una manera no abstracta (pruebas de caja blanca). Se enfocan en la funcionalidad interna esperada de las distintas


33

Gua de Pruebas de Software (GPS) piezas del software operando de manera conjunta pero desde la perspectiva del programador. La funcionalidad se debe encontrar previamente documentada en la Realizacin de la fase de Anlisis y Diseo, donde se desglos cada requerimiento en especfico. Debido a que las pruebas de integracin son realizadas por los desarrolladores, es difcil crear un caso de prueba dentro de un documento adicional, sin embargo en la ejecucin ser indispensable actualizar el registro de rastreo con las diversas pruebas ejecutadas dentro de esta fase. Casos de pruebas de sistema. Los casos de pruebas de sistema validan que la operacin de los diferentes componentes del mismo cumplan con las condiciones y los requerimientos funcionales del sistema, sin entrar en el detalle de la operacin individual de cada uno de ellos (pruebas de caja negra). El desarrollo de estos casos de prueba se realiza desde el punto de vista de la funcionalidad tcnica del sistema. Algunas validaciones comunes son: Botones El botn realiza las acciones sealadas en el diseo funcional como cerrar la pantalla, abrir un reporte, etc. El botn cumple con el comportamiento especificado para cada uno de sus estados, por ejemplo: en reposo, al presionarlo, cuando el cursor se encuentra sobre el botn, al arrastrarlo, etc. El tamao, color y fuente del texto de los botones es el indicado. El cono o figura para cada estado del botn son los definidos. Campos de texto El campo acepta un nmero mnimo y mximo de caracteres. El campo contiene una mscara predeterminada para el ingreso de datos. El campo slo acepta cierto tipo de caracteres. El campo se llena automticamente cuando cierta condicin sucede. El tamao, color y fuente del campo son los indicados. Funcionalidad al poner el cursor sobre el campo de texto (por ejemplo, globos de texto de ayuda). Iconos e imgenes El tamao de la figura vara de acuerdo al tamao de la pantalla. Al dar clic sobre la figura ocurre una accin esperada. El tamao, color y posicin de la figura son los adecuados. La figura cambia de acuerdo al contenido de un archivo. Filtros El filtro acta sobre una lista adyacente o en un reporte solamente con las condiciones seleccionadas. El filtro contiene las opciones de filtrado obtenidas de una tabla en la base de datos. El filtro muestra las opciones de acuerdo a un orden especificado o a otro pre-filtrado. Mens


34

Gua de Pruebas de Software (GPS) Se despliegan los mens tal como lo indica el diseo funcional. Cada opcin del men realiza la accin especificada. Se despliega el men adecuado al perfil de usuario que ha ingresado al sistema. El color, tamao y tipo de fuente de los mens son los indicados. Pantallas El tamao, color, fuente y atributos estticos de la pantalla son los adecuados. La pantalla se muestra siempre en primer plano. Al cambiar de tamao, los objetos de la pantalla se ajustan. Al no estar activa (o al minimizar) se realiza una accin determinada. Reportes El reporte impreso contiene la misma informacin que el mostrado en pantalla. El reporte est correctamente configurado, en cuanto a colores, tipo de letra y espacio disponible para la informacin contenida en ste. El tamao del reporte satisface los requerimientos fsicos del papel a emplear en su impresin. Los objetos requeridos por los reportes son automticamente cargados por el sistema, de acuerdo a los requerimientos. Funcionalidad Aqu las pruebas se enfocan en que la funcionalidad individual de cada mdulo entregue el resultado de acuerdo al proceso documentado en el diseo funcional del proyecto. Por ejemplo, la generacin de reportes de acuerdo a la opcin seleccionada en la pantalla, la impresin de recibos de acuerdo a una venta realizada, etc. Una vez que se ha determinado las diferentes validaciones del caso de prueba, ste se documenta en un archivo individual y consta al menos de los siguientes datos: Nombre nico. Objetivo. Acciones a ejecutar. Acciones esperadas que realice el sistema. Nmero de requerimiento al que est direccionado. Versin del caso de prueba. Desarrollo del caso de acuerdo al grado de madurez del rea. Como punto inicial un caso de prueba puede contener nicamente la descripcin de la validacin para la que est creado, as como (de forma genrica) las acciones a realizar y los resultados esperados para dichas acciones. Los siguientes ejemplos muestran casos de prueba simples donde se valida la funcionalidad de una pantalla, de un men y de un botn respectivamente.


35

Gua de Pruebas de Software (GPS)Id Req: GN.0002 CP.0001.func.: Verificar pantalla de arranque Fecha de Creacin: 01/12/2007 Objetivo: Versin: Verificar que al arrancar el sistema se muestre la pantalla de "flash", donde muestre el logo, y nombre de la empresa, 0001 as como el mdulo y los datos del usuario registrado.Paso Accion Resultado Esperado

1

Abra el sistema, capture una imagen a la pantalla flash para validar la imagen y textos de la pantalla, as como el tiempo que tarda la pantalla en desaparecer.

La pantalla contiene el logo y el nombre de la empresa, el nombre del mdulo abierto y el usuario registrado en la licencia. Cuando la pantalla flash desaparece, se muestra la pantalla de acceso al sistema, solicitando usuario y password.

Tabla 13 - Caso de prueba para validar una Pantalla.Id Req: CP.0002.func.: Verificar men de administrador al GN.0003 ingresar al sistema.Versin: 0001 Paso

Fecha de Creacin: 01/12/2007

Objetivo: Verificar que al ingresar al sistema con un usuario de tipo "administrador" se muestra el men del "administrador".Accion Resultado Esperado

1

Ingrese al sistema con un usuario del tipo Administrador.

La pantalla muestra despus del logn correcto el men general, con todas las opciones habilitadas, as como el submen "Administrador" tambin con todas las opciones habilitadas.

Tabla 14 - Caso de prueba para validar un Men de acuerdo al tipo de acceso.Id Req: CP.0030.func.: Verificar botn de exportar una GN.0003 cotizacin. Objetivo:Versin: 0001 Paso Fecha de Creacin: 04/12/2007

Validar que el botn "Exportar" funciona adecuadamente dentro de la pantalla "Cotizacin".Accion Resultado Esperado

1Ingrese al sistema con un usuario del tipo Operador de Ventas, realice el alta de una cotizacin y valide las acciones del botn "Exportar".

Dentro de la pantalla "Alta de Cotizacion", el botn "Exportar" presenta las siguientes caractersticas: 1. El botn es color blanco, contiene el cono "Exportar.ico", y el texto "Exportar", as como el tooltip "Realiza una exportacin de la cotizacin actual a otro sistema". 2. Al presionar el botn, el sistema enva una pantalla con las opciones "Microsoft Excel" y "Texto".

Tabla 15 - Caso de prueba para validar un Botn.

El formato de casos de prueba usado en los ejemplos se puede adaptar a cualquier tipo de validacin que la empresa desee realizar, y una de las ventajas de aplicarlo es que en cualquiera de los casos es posible identificar los elementos ms importantes: objetivo, accin y resultado esperado. En la figura 8 se presentan y explican estos elementos para el ejemplo de la tabla 13.


36

Si la empresa cuenta con un grupo de pruebas con experiencia, entonces debe de crear los casos especificando las acciones de manera ms amplia y documentar el resultado esperado para cada una de ellas. Un caso de prueba avanzado debe contener la informacin suficiente para que pueda ser ejecutado por una persona que no conoce el sistema, por ejemplo el de la tabla 15. El nivel de detalle especificado dentro de un caso de prueba tambin vara en relacin a otros factores, tales como:

GPS - Guardati & Ponce 37


La importancia del requerimiento y condiciones a validar. El tiempo especificado para desarrollar los casos de prueba.

Nombre nico que servir como identificador del caso Nmero de requerimiento al que pertenece el casoFigura 8 - Componentes de un caso de prueba.

Fecha de la aprobacin final del caso

Id Req: GN.0002 CP.0001.func.: Verificar pantalla de arranque Versin: 0001 Paso

Fecha de Creacin: 01/12/2007

1

Objetivo: Verificar que al arrancar el sistema se muestre la pantalla de "flash", donde muestre el logo, y nombre de la empresa, as como el mdulo y los datos del usuario registrado. Accion Resultado Esperado La pantalla contiene el logo y el nombre de la empresa, el nombre del Abra el sistema, capture una imagen a la pantalla flash para validar la mdulo abierto y el usuario registrado en la licencia. imagen y textos de la pantalla, as como el tiempo que tarda la pantalla Cuando la pantalla flash desaparece, se muestra la pantalla de acceso en desaparecer. al sistema, solicitando usuario y password.

Nmero y descripcin de las acciones del caso de prueba Versin del caso que fue aprobada como final

Resultado esperado para cada accin ejecutada Objetivo para el que fue creado el caso de prueba

Gua de Pruebas de Software (GPS) Casos de pruebas de aceptacin. Estas pruebas generalmente son realizadas por el usuario final del sistema y se llaman de aceptacin porque es ste quien da el visto bueno de que el sistema funciona de la manera esperada. Las pruebas de aceptacin tienen como objetivo demostrar que el sistema funciona como un todo, de la manera esperada una vez puesto en produccin. Por lo tanto, estas pruebas se desarrollan validando toda la funcionalidad de un ciclo de operacin normal sin detenerse en cada pieza del software (pruebas de caja negra). Estos casos de prueba pueden ser realizados por los expertos de negocio o por la gente que ha estado encargada de las fases previas de prueba. Algunas de las pruebas de sistemas se pueden modificar para convertirse en pruebas de aceptacin, especialmente aquellas usadas para validar alguna funcionalidad del software importante para el negocio. Por ejemplo: ingresar tarjetas de crdito, capturar nmeros de cliente, realizar bsquedas especializadas, etc. Estas pruebas tienen que estar completamente ligadas a los requerimientos funcionales del sistema aunque sin excluir otro tipo de validaciones adicionales como las basadas en experiencia y cualquier otra que el usuario final desee realizar. Para desarrollar casos de prueba de aceptacin, los pasos a realizar tienen que describirse en el lenguaje de la operacin real, no es necesario ingresar cuestiones tcnicas, como nmero y tipos de caracteres, tiempos de espera, etc. Hay que recordar que el usuario final no revisa el tiempo exacto en que tarda una ventana en desplegarse, slo se limita a realizar una apreciacin personal de dichos tiempos. De la misma manera, un usuario final no validar la comunicacin correcta con la impresora, pero s validar el diseo de los reportes, los permisos requeridos para obtenerlos y la facilidad de configuracin de estos. Crear escenarios de prueba Un escenario puede validar una o ms condiciones de prueba, sin embargo esto se permite o se niega de acuerdo a las caractersticas e importancia de cada condicin en particular. Para definir un escenario se requiere tener la especificacin de requerimientos completa, adems del conocimiento acerca del funcionamiento del sistema. As mismo, debido a que las pruebas de aceptacin generalmente se enfocan a un grupo de componentes, que a su vez conforman una operacin completa del da a da es necesario crear escenarios de prueba que documenten las operaciones dentro de cada caso, incluyendo los datos que fluyen dentro de los escenarios y las autorizaciones necesarias. Por ejemplo: la compra de equipo nuevo (cotizacin, aprobacin, pedido, recepcin, pago), un da de venta (ventas, cancelaciones, cambio de turnos, cambio de usuarios, reportes finales), etc. Para crear escenarios de prueba se sugiere realizar los 5 pasos siguientes: 1. A partir del registro de rastreo realizar una matriz donde se liste las operaciones del negocio que involucran a cada requerimiento en especfico (tabla 16).# Requeri

GPS Para MoProSoftv1.0

Documents

Transcript of GPS Para MoProSoftv1.0

Sistemas de localización por GPS para dispositivos móviles ...

GPS+J Los profesionales sanitari os jóvenes y la misericordiasanitarioscristianos.com/doc_plano/identidad/GPS+J... · ocasión del “cierre de campaña” os mando este GPS+J para

Localizador GPS para coche TK103A, TK103BPágina 1 Localizador GPS para coche TK103A, TK103B En este manual te mostraremos como operar con el localizador GPS para coche de una manera

Mapas Vectoriales GRATUITOS Para GPS

PASOS PARA ACTUALIZAR SHERPA 2000 GPS

ACERCA DEL SISTEMA DE POSICIONAMIENTO GLOBAL (GPS)* · Palabras Clave: GPS, GPS Diferencial, SIRGAS, CASA, Cinemática, GPS Colombia. 1. Generalidades del GPS El Sistema de Posicionamiento

GPS Equipos GPS SkyPatrol TT8950 Revo Mérida, Yucatán

Vehículo Autónomo Terrestre Basado en GPS para la ...

Levantamientos con GPS Para el Proceso Catastral

GPS Diferencial

SEÑUELO GPS CARGAS SEGURASCOLCOM GPS SI PIENSA EN CARGAS SEGURAS, PIENSE EN COLCOM GPS.

GPS. Indice O Descripcion del GPS O Historia del GPS O Ventajas del GPS frente a la brujula y el mapa O Funciones del GPS O Algunas aplicaciones que usan.

GPS TRACKING - gpsnorte.cl GPS Tracking.pdf · satelitales solo utilizan los satélites GPS para poder ... PARA RASTREO DE PERSONAS, MOTOS Y ... conexión mini-usb para utilizar como

ROGER - Repetidor GPS para interiores

GPS Telcel powered by Telenav - pronde.com · GPS Telcel powered by Telenav Utilizando GPS Telcel Dentro del menú Herramientas/Extras, el usuario deberá elegir Preferencias para

SELLO ELECTRÓNICO GPS INVIOLABLE PARA CONTENEDORES Y FURGONES.

TUTORIAL GPS GARMIN - speleo.ltspeleo.lt/speleo/upload/TUTORIAL GPS Mapas GARMIN by Iogrea.pdf · Tutorial de mapas para GPS Garmin Realizado por Iogrea v1.2 Página Número: 3 1.-

4 Curso Gps Cartografia Para Gps

DATOS GPS – OCAD VI CLINIC NACIONAL DE CARTOGRAFÍA 2011 CARACTERIZACIÓN DE DATOS GPS PARA SU USO EN OCAD DESCRIPCIÓN DE DATOS DE CALIDAD EN UN GPS PARA.

GPS Equipos GPS SkyPatrol TT8750+ Evolution Mérida, Yucatán