INFORME DE PRUEBAS: S-SQUARE

Objetivo del Instructivo: Describir los posibles enfoques que se deben tener en cuenta durante las pruebas de software.Tiempo Previsto de lectura y entendimiento: 4 horas.ENFOQUES DE LAS PRUEBAS DE SOFTWARELos enfoques en las pruebas de testing constituyen una de las bases para la determinacin de la calidad de un producto de software y dependiendo de las caractersticas de ste se puede aplicar uno u otro de los tipos de testing definidos.

Cada enfoque en las pruebas de testing se especializa segn el requisito al que apunte y evala el nivel de aceptacin de ste y por ende del componente de software.

Al realizar el testing de software utilizando los distintos enfoques o tipos de pruebas se deben seguir los formatos estndar y la documentacin predefinida para realizar el seguimiento de los resultados de las pruebas funcionales del sistema y de todas las dems. Si se observa una falla, se debe generar formalmente un informe del incidente para que ste sea analizado y reparado desde el cdigo. Los encargados no deben perder de vista estos documentos con el propsito de garantizar la calidad del software, y seguir el progreso del proceso de pruebas.1. ENFOQUES EN LAS PRUEBAS DE SOFTWARE

1.1. PRUEBAS DE FUNCIONALIDAD.ObjetivoAsegurar que el comportamiento del sistema se adhiere a los requisitos funcionales.

Descripcin

Las pruebas de funcionalidad de sistema tienen mucho que ver con las pruebas de aceptacin. Se dice que un programa es aceptable cuando:

1. Hace lo que debe hacer

2. No hace lo que no debe hacer.

Todos los requisitos funcionales del sistema deben ser realizables por el sistema. Por ejemplo, si se requiere un sistema de finanzas con el fin de permitir que los usuarios instalen, agreguen, modifiquen, y supriman entradas en las cuentas, y adems impriman los informes, las pruebas de funcionalidad deben asegurarse de que el sistema pueda realizar estas tareas.

Las pruebas de funcionalidad son de caja negra en naturaleza. Se focalizan en las entradas y salidas apropiadas para cada funcin. Las entradas incorrectas e ilegales se deben manejar tambin por el sistema. Todas las funciones deben ser probadas. Muchas de las pruebas a nivel sistema incluyendo pruebas de funcionalidad deben ser diseadas en el tiempo en que se toman los requisitos, e incluirse en el plan maestro de proyecto y por ende en el plan de prueba del sistema. Sin embargo, habr algunos cambios de requisitos y por ende de las pruebas, que presentan la necesidad de que dichos cambios se vean reflejados en el plan de pruebas.

Observaciones Los subtipos pertenecientes a este tipo de prueba estn ordenados segn su prioridad; en algunos casos sin embargo la prioridad entre dos subtipos es la misma o es variable - dependiendo el caso y ser aclarada cuando sea necesario.

Se deben probar todas las funcionalidades del sistema.

1.1.1. Pruebas de requisitos funcionalesObjetivoAsegurar la adhesin del producto de software a los requisitos funcionales planteados.

DescripcinAl inicio de un proyecto de software en la etapa de levantamiento de requisitos, se genera un documento diseado entre el cliente y el arquitecto encargado del proyecto que refleja las necesidades del cliente y los alcances del proyecto, adems de que describe el dominio del sistema. Dicho documento tambin llamado modelo verbal del dominio del sistema - se compone de descripciones pequeas y simples de funcionalidades especficas que el software debe estar en capacidad de cumplir, y esto es lo que se debe garantizar a travs de las pruebas de requisitos funcionales.

Generalmente, la documentacin de requisitos funcionales es usada para generar durante la etapa de anlisis y diseo del proceso de produccin artefactos que describen el dominio de la aplicacin completamente, stos son construidos basados en el lenguaje estndar UML y otros estndares reconocidos a nivel internacional y en ellos aplica tipos distintos de pruebas especficas.

Observaciones En caso de que existan artefactos de anlisis y diseo como casos de uso y diagramas de estados entre otros se deben realizar pruebas relacionas con dichos artefactos preferentemente. Sin embargo, si en dichos artefactos no se contemplan todos los requisitos funcionales existentes se deben hacer sobre stos pruebas de requisitos funcionales.

DiseoCuando se inicia un proyecto de testing, se deben analizar los artefactos provenientes de anlisis y diseo. En ste punto, se deben tomar el documento de casos de uso y el documento de requisitos del mdulo a probar y se debe analizar cuales de los requisitos planteados no son cubiertos en el documento de casos de uso. En caso de encontrarse un requisito que no sea cubierto en el documento de casos de uso, o en caso de que ste no exista, se debe probar que cada requisito correspondiente mediante un conjunto determinado de casos de prueba.

Los casos de prueba diseados para los requisitos deben ir relacionados directamente a comprobar que se cumple funcionalmente con lo que ste dice y no con detalles paralelos no tan relevantes a la funcionalidad, ya que stos se prueban mediante otras instancias.

Los casos de prueba que surgen a partir de un requisito funcional pueden ser correspondientes a distintos tipos, por lo cual los casos de prueba de requisitos funcionales deben ser dirigidos a lo ya planteado en el prrafo anterior, en tanto los casos de prueba de otro tipo que surjan a partir de ste deben ser focalizados a su fin especfico sin invadir el terreno de los casos de prueba de requisitos funcionales y viceversa. La situacin planteada se torna un poco confusa, lo conlleva a plantear las pruebas basadas en requisitos nicamente como complejas y demoradas; sin embargo si los casos de uso fueron diseados correctamente no deberan ser muchos los requisitos no cubiertos por los mismos.

Para disear un caso de prueba de requisito funcional se deben seguir los siguientes pasos:

1. Lea la tabla descriptiva de requisitos despus de haber entendido completamente el dominio. (Si es necesario lea todo el documento de requisitos).

2. Concntrese en los campos de descripcin y especificacin del requisito y basados en estos disee los casos de prueba que cubran lo planteado en la especificacin. Se deben tener en cuenta las secuencias que puedan surgir para cumplir con el requisito.

3. Tenga en cuenta las observaciones al disea los casos de prueba debido a que pueden existir excepciones o secuencias alternativas a lo planteado en la descripcin y especificacin, lo cual puede permitir revelar defectos. Es importante anotar que la mayora de los errores no se encuentran en caractersticas generales, sino en excepciones a una regla o en validaciones que se dan en pocos casos.

1.1.2. Prueba de casos de usoObjetivoAsegurar la concordancia entre los casos de uso que hacen parte de los artefactos de anlisis y diseo y el producto de software construido.

DescripcinLa prueba de casos de uso apunta a determinar si la funcionalidad del sistema en trminos de lo descrito por los casos de usos relacionados sea equivalente, es decir, que cada uno de los elementos tanto del caso de uso grfico (diagrama de casos de uso) como de su tabla explicativa concuerde con el producto de software.

En sta prueba la concordancia entre los casos de uso y el sistema debe ser analizado bidireccionalmente, es decir, desde los casos de uso hacia el producto de software y viceversa hallando y documentando los puntos en que ambos no concuerden. Cabe anotar que los errores hallados pueden pertenecer tanto al producto de software como al caso de uso relacionado segn sea el caso.

Observaciones Se debe tener en cuenta que los casos de uso deben tener asociado adems del diagrama de casos de uso una tabla explicativa que contenga elementos que permitan realizar de manera ptima la prueba relacionada; algunos de los elementos ms representativos de dicha tabla explicativa son: Requisitos funcionales relacionados.

Actores relacionados.

Secuencias de interacciones normales.

Secuencias de interacciones alternativas.

Demora.

Frecuencia.

Riesgo.

Criticidad.

Poscondiciones.

Precondiciones.

Imagen de Interfaz grfica.

Entre otrosDiseoEl documento de casos de uso constituye una de las entradas ms importantes para el rea de testing y es basado en ste que se realiza prueba de casos de uso. Generalmente al realizar stas pruebas, surge la necesidad de realizar tipos de pruebas de tipo funcional para verificar que el sistema es coherente con el caso de uso relacionado.

Para disear un caso de prueba de requisito funcional se deben seguir los siguientes pasos:

1. Lea la tabla descriptiva del caso de uso despus de haber entendido completamente el dominio. (Si es necesario lea todo el documento de casos de uso y el documento de requisitos).

2. Disee casos de prueba teniendo en cuenta las siguientes tips:

a. En cada caso de prueba diseado tenga en cuenta los supuestos, que generalmente sern probados mediante un paso en uno o varios casos de prueba.

b. Genere tantos casos de prueba como sea necesario para comprobar que los actores descritos en la tabla y en el grfico UML sean tenidos en cuentas en el ingreso a las interfaces adjuntas. Cada actor debe ser reconocido segn su rol y sus datos y las propiedades del sistema deben ser las respectivas segn el actor que ingresa al sistema. En caso de que existan casos de uso relacionados directamente con el ingreso de los usuarios al sistema, cuando se estn probando stos se deben disear los casos de prueba respectivos y obviar su diseo en mdulos que los utilicen por flujo de proceso.

c. Cada precondiciones generalmente deben ser chequeada mediante un caso de prueba, en ste se debe comprobar que se cumpla sta a cabalidad. En la mayora de los casos se da que una precondicin viene acompaada de un mensaje del sistema al usuario que le advierte de una u otra forma la necesidad de que cumpla con la precondicin; adems generalmente esto lleva a que el foco en la interfaz cambie segn la precondicin. En los casos de prueba diseados se deben tener en cuenta todos estos detalles para cada precondicin.

En la mayora de los casos las precondiciones son bloqueantes, es decir, detienen el flujo normal de ejecucin de un proceso, no permitiendo que cierta operacin se lleve a cabo hasta tanto sta no se cumpla. Al crear casos de prueba que comprueban las precondiciones se debern crear situaciones en la cuales la precondicin no se cumpla con el fin de observar la reaccin del sistema, y viceversa.

Algunas precondiciones son de existencia de registros u objetos en el dominio, lo cual conduce a que el tester deba ingresar dicho objeto al dominio mediante el sistema. Ejemplo de esto es ingresar un alumno en el sistema de calificaciones dado que no se podr calificar dicho alumno si no sta registrado en el sistema.

d. Se debe crear mnimo un caso de prueba para la secuencia de interaccin normal y otro para la secuencia alternativa del caso de uso, sin embargo en generalidad se crearn ms de un caso de prueba debido a las posibles combinaciones de datos de entrada que se ingresen en el sistema. Es importante no confundir ste tipo de pruebas con pruebas de entradas y salidas, dado que stas buscan es comprobar que el formato y la generalidad de los datos al ser ingresados o al convertirse en salidas del sistema cumplen con su descripcin especfica, y no - como el caso de las pruebas creadas a partir de las secuencias normales y alternativas - comprobar que con datos de entradas especficos las secuencias se cumplen correctamente. En algunos casos las secuencias alternativas son varias al igual que las secuencias normales dependiendo de que tan amplio sea el caso de uso y del nmero de interfaces que se relacionan en el mismo -; en stos casos se deber tener en cuenta cada uno de ellos y por ende cada secuencia mnimo tendr un caso de prueba que lo verifique.

e. Se debe crear uno o varios casos de prueba teniendo en cuenta la demora. La secuencia o pasos del caso de prueba deber corresponder a la secuencia ms larga contemplada en el caso de uso. Se debe verificar que la ejecucin de dicha secuencia si demora lo especificado.

f. Al disear los casos de prueba de un caso de uso, se debe tener en cuenta su criticidad, dado que depende de esto se debern realizar muchas o pocas prueba al aplicativo. En este punto no solo se tiene en cuenta la criticidad si no la frecuencia de uso ya que por ejemplo, es mas recomendable hacer pruebas intensivas a casos de uso con alta criticidad y con frecuencia de uso muy bajos, que a casos de uso poco crticos con altos periodos de uso, es decir, poco usadas.

g. Al crear los casos de prueba se deben contemplar las reglas del negocio asociadas al caso de uso. Es importante aclarar que no es cierto que por cada regla del negocio se cree un caso de prueba o que siempre se deba crear un caso de prueba nicamente para comprobar la aplicacin de una regla del negocio, ya que a veces sta aplicacin est implcita en una secuencia de otro caso de prueba.

h. Al crear los casos de prueba se deben tener en cuenta las validaciones que generalmente arrojarn mensajes al usuario. Se deben comprobar que dichos mensajes y por ende que las validaciones se tengan en cuenta generalmente mediante la creacin de un caso de prueba por cada validacin. Algunas veces las validaciones estn implcitas en casos de prueba de tipo entradas o salidas y en algunos otros no siendo tan comn el ltimo caso - .

i. Las frmulas o clculos se deben en cuenta en los campos calculados o en los resultados que arroja el aplicativo. Si la frmula o clculo es muy compleja se deben crear cuantos casos de prueba se requieran, pero en general otra prueba debern observar la comprobacin de la correctitud de stas frmulas y clculos.

j. Los reportes son considerados como salidas del sistema, y por ende, para probarlos se deben disear casos de prueba de tipo salidas.

k. Los Atributos son considerados como entradas y salidas del sistema, y por ende, para probarlos se deben disear casos de prueba de tipo entrada o salidas segn sea el caso.

l. Para comprobar que las postcondiciones se tienen en cuenta, se deben crear casos de uso que van orientados a verificar, por ejemplo, que un registro se aadi, que se guard correctamente, etc. En muchos casos conviene realizar uno o varios casos de prueba para verificar las postcondiciones, sin embargo hay postcondiciones que son verificadas en casos de pruebas de otros tipos; por ejemplo en pruebas de casos de uso, se puede incluir la postcondicin como final de una secuencia.

m. Todos los casos de prueba diseados para casos de uso se apoyan del grfico UML, dado que en l se expresa de forma simple la interaccin completa de las funciones del sistema y sus actores, adems en cierta medida expresa el flujo de ejecucin del sistema

n. Las pantallas del caso de uso permiten realizar principalmente pruebas de tipo uniformidad de interfaces y acoplamiento con el usuario entre otras, adems ayudan a disear los casos de prueba en general, porque presentan la imagen de las interfaces en las cuales el tester ejecutar los casos de prueba, lo cual conduce a no ser obligatoria la existencia del aplicativo funcional para disear los casos de prueba del mismo.

o. Al disear cual tipo de casos de prueba basado en los casos de uso, se deben tener en cuenta las observaciones, ya que stas son de suma importancia porque pueden contener lo que en el documento de requisitos se conoce como requisitos inversos, es decir excepciones a una regla planteada. En stos casos es donde generalmente se producen ms errores debido a que controlar dichas excepciones es muy complejo y por ende tienden a convertirse en la mayor fuente de bug. Al disear pruebas se deben crear casos de prueba que apunten a comprobar dichas observaciones, aunque algunos van inmersas en otros tipos de casos de prueba.

EjecucinNOTAS:

Se debe tener en cuenta a lo hora de ejecutar un caso de prueba que busque verificar que la demora de la secuencia ms larga del caso de uso es congruente con lo documentado en la tabla explicativa del caso de uso, que si no se cumple dicho valor, se debe reportar un bug de tipo: Anlisis y diseo y con una criticidad baja en la mayora de los casos - . Para construir los comentarios del bug se debe chequear tanto la periodicidad y la criticidad del caso de uso. Si es muy peridico y muy crtico se debe aconsejar reducir el tiempo de ejecucin.

1.1.3. Pruebas de estados del sistemaObjetivoAsegurar la concordancia entre el diagrama de estados del sistema que hace parte de los artefactos de anlisis y diseo y el producto de software construido.

DescripcinEl diagrama de transicin de estados es til para modelar los aspectos dinmicos de un sistema, estos aspectos dinmicos pueden comprender el comportamiento ordenado por eventos de cualquier objeto del mismo.

Las pruebas de estados del sistema buscan determinar que la existencia y transicin de estados del sistema ocurra efectivamente dentro del producto de software lo cual incluye verificar que la condicin y la accin correspondiente sean las correctas. Para sta prueba tanto los estados como las transiciones del sistema son determinables directa o indirectamente a travs de interfaces o mediante pruebas explcitas al cdigo fuente, es por esto que ste tipo de prueba puede ser caja blanca o caja negra, aclarando que en el caso que se utilicen ambas perspectivas ser caja gris.

Es importante aclara en ste punto que sta tcnica tiene mayor o menor cobertura sobre el producto de software segn la forma en que sea aplicada de acuerdo a la orientacin de las tcnicas usadas (caja blanca, caja negra y caja gris).

Observaciones Todos los estados y transiciones eficaces de estado del sistema deben ser ejecutadas y examinadas a travs de sta prueba.

Los diagramas deben lo suficientemente claro, para ello se pueden recurrir a notas UML estndares inmersas en el diagrama o documentacin adicional segn sea requerida.

Es aconsejable construir el diagrama de transicin de estados para aquellas instancias de clases que tengan un comportamiento significativo dentro del sistema (objetos reactivos).

Diseo Para realizar pruebas de caja negra (black box), que prueben los estados del sistema, se deben obviar mucha informacin que posee el diagrama de estados. As pues, la mejor forma de probar los estados del sistema ser mediante pruebas de caja blanca (white box).

PRUEBA DE CAJA NEGRAPara disear un caso de prueba de estados del sistema se deben seguir los siguientes pasos:

1. Obtenga la comprensin del dominio del sistema y del diagrama de estados del sistema completamente. (Si es necesario lea todo el documento de casos de uso y el documento de requisitos).

2. Identifique un estado inicial y estado final para cada prueba teniendo en cuenta todo el conjunto de estados posibles.

3. Se debe recolectar las posibles combinaciones de eventos para ir del estado inicial al estado final, teniendo en cuenta subastados. Estas combinaciones conforman lo que se conoce como poblacin de datos de entrada para las pruebas de transicin de estado.

4. Por cada combinacin de eventos posibles para ir del estado inicial al estado final genere un caso de prueba o varios si es necesario en los cuales tenga en cuenta revisar si es posibles las acciones de entrada, las acciones internas y las acciones de salida. Si stos no son posibles tener en cuenta dado que mediante la interfaz no se pueden visualizar dichas acciones simplemente bvielas, dado que se requiere en estos casos generar una prueba de caja blanca con seguimiento de cdigo mediante debug.

5. Dado que en los diagramas de estados se pueden producir bucles al pasar de un estado a otro mediante eventos, en algunas ocasiones puede suceder que con cierto nmero de ejecuciones de bucle el sistema sea coherente, pero con un nmero menor o mayor falle. sta peculiaridad hace que tengamos que escoger un conjunto de valores de entrada que permita en cierta medida cubrir los casos ms reales y posibles dentro del sistema, teniendo en cuenta tambin la periodicidad y criticidad de los estados asociados que fcilmente se pueden encontrar en los casos de uso relacionados.

6. El intercambio de mensajes es una herramienta muy importante a la hora de presentarse los cambios de estados en el sistema, sin embargo, generalmente los mensajes son pasados mediante cdigo. En algunas ocasiones los mensajes pasados son convertidos en mensajes al usuario mediante ventanas emergentes o cambios en la interfaz visible en el aplicativo, y es en ste punto donde se pueden probar algunos mensajes de diagrama de estados. Generalmente para probar todos los mensajes del diagrama de estados se deben realizar pruebas de caja blanca.

En algunos casos es importante verificar los cambios internos del sistema o acciones para pasar de un estado a otro; esto se logra ya sea verificando ciertos registros en las bases de datos o mediante un debug. En los casos en los cuales estemos realizando pruebas de caja negra es recomendable solo realizar verificacin de acciones a nivel de bases de datos, evitando realizar debug, ya que es un trabajo de ms bajo nivel correspondiente a otro tipo de prueba.

Es importante aclarar como parte final que la eficiencia de las pruebas de transicin de estados se maximiza tan solo cuando se utilizan tcnicas de caja blanca.

Nota: Ver el anexo que explica las primitivas conceptuales del diagrama de estado UML.

AnexoEl siguiente es el esquema genrico de un diagrama de estado UML con sus diferentes primitivas:

1.1.4. Pruebas de secuencias y actividades del proceso.ObjetivoAsegurar la concordancia entre los diagramas de secuencia y de actividades del sistema que hacen parte de los artefactos de anlisis y diseo y el producto de software construido.

DescripcinLos diagramas de secuencias muestran las interacciones entre objetos ordenas en secuencia temporal, muestran los objetos que se encuentran en el escenario y la secuencia de mensajes intercambiados dentro de los objetos para llevar a cabo la funcionalidad descrita por el escenario; por otro lado el diagrama de actividades modela los aspectos dinmicos de un sistema, los cuales se refieren a:

Flujos de datos: actividades definidas como las interacciones de los actores con el sistema.

Operaciones: detalla cada uno de los pasos o acciones adems de los parmetros que recibe una operacin especfica.

La prueba basada en stos dos artefactos indaga que tanto la secuencia de actividades desde el punto de vista de los actores del sistema, como la secuencia de mensajes desde el punto de vista de los objetos del sistema tengan coherencia con lo que se expresa en dichos artefactos.

Dado que estos dos artefactos describen las secuencias completas del producto de software desde distintos puntos de vista, no deben tomarse individualmente para disear la prueba de ste tipo.

Es importante aclara en ste punto que sta tipo tiene mayor o menor cobertura sobre el producto de software segn la forma en que sea aplicada de acuerdo a la orientacin de las tcnicas usadas (caja blanca, caja negra y caja gris). As, el diagrama de actividades enfoca sta prueba a tcnicas de caja negra, mientras que el diagrama de secuencias la enfoca a caja blanca, permitiendo en la mayora de los casos realizar validaciones mediante interfaces (caja negra). Es por stas razones que la prueba de secuencia y actividades del proceso se considera de caja gris.

Observaciones Los diagramas deben ser los suficientemente claros, para ello se pueden recurrir a notas UML estndares inmersas los diagramas o documentacin adicional segn sea requerida.

DiseoDisear ste tipo de casos de prueba, se torna complicado, debido a que requiere adems de un gran conocimiento del dominio total y habilidades para englobar la funcionalidad del aplicativo. Los casos de prueba generados en ste tipo de pruebas se concentran en comprobar de forma global que los procesos, flujos e interacciones planteados en los diagramas de actividades y de secuencias de procesos son reflejados fielmente por TODO el producto de software. Una desventaja de realizar dichas pruebas es que se tiene que hacer sobre todo el aplicativo y una vez que los bug reportados por los dems pruebas hallan sido cerrados, es decir, se convierte en un chequeo final que un ltimo trmino afianza el hecho de que los requisitos y las necesidades del cliente fueran cubiertas.

Las pruebas basadas en el diagrama de secuencias es orientado principalmente a pruebas de caja blanca, sin embargo se pueden obtener pruebas de caja gris mediante comprobaciones contra la base de datos de las secuencias que expresan las interacciones de las diferentes operaciones que el sistema realiza en la base de datos para operaciones especficas.

Por otro lado las prueba basadas en el diagrama de actividades se focalizan en probar la cohesin entre los casos de uso que componen el sistema; es as como un caso de uso corresponde a un proceso o a varios del diagrama de actividades, lo cual permite identificar en que interfaces y/o mdulos se realiza cierto proceso de dicho diagrama.

Para disear un caso de prueba de secuencias y actividades del proceso se deben seguir los siguientes pasos:

1. Obtenga la comprensin del dominio del sistema y del diagrama de secuencias y actividades del sistema completamente, adems del documento de descripcin de procesos. (Si es necesario lea todo el documento de casos de uso y el documento de requisitos).

2. Identifique las secuencias que comprometen directamente transiciones en la bases de datos del sistema.

3. Cree tantos casos de prueba como sean necesarios para comprobar que las transacciones generadas por unas secuencias son registradas en la base de datos.

4. Identifique los procesos del sistema y en que casos de uso se utilizan, encontrando concordancia as entre el diagrama de casos de uso y el diagrama de actividades.

5. Ubique los procesos del sistema del diagrama de actividades en los mdulos e interfaces en los cuales se lleven a cabo.

6. Genere tantos casos de pruebas sean necesarios para corroborar el flujo correcto entre procesos mostrado en el diagrama de actividades. Dado que existen muchas combinaciones para verificar dicho flujo se debern elegir las que sean ms comunes, reales y factibles al interior del sistema.

7. En el documento de descripcin de procesos se deben tener en cuenta la duracin, como se realiza y en dnde se realiza el proceso con el fin de poder describir con ms claridad el caso de prueba que prueba el flujo correcto entre procesos. En ste punto no se realizan comprobaciones de los datos de la tabla explicativa de procesos dado que stos debern concordantes con la tabla explicativa de casos de uso correspondiente al proceso respectivo.

1.1.5. Prueba de acoplamiento con el usuarioObjetivoAsegurar que el producto de software sea coherente con el ambiente en donde este ser implantado y el usuario final en cuanto a sus habilidades y conocimientos.

DescripcinSe busca con ella que el usuario final no encuentre barreras que impidan el efectivo uso del producto de software. La prueba se debe realizar de forma transversal a todo el proceso de pruebas.

Generalmente se chequean que los siguientes aspectos sean comprensibles por el usuario final segn sus habilidades y conocimientos y adems sean concordantes con el ambiente en el cual opere el software:

Etiquetas (label) de las interfaces.

Informacin de interaccin con el usuario (Mensajes emergentes, explicaciones, errores y salidas).

Tooltips y ayudas.

Ttulos de ventanas, componentes (Arboles, Mens, Tablas, entre otros).

Observaciones Entindase por ambiente a los aspectos que determinan el lugar donde se desenvuelve el usuario final, estos aspectos determinan la naturaleza que debe tener la aplicacin.

Es importante tener en cuenta que se requiere tener una descripcin de los usuarios del sistema agrupada segn sus roles con el fin de permita identificar habilidades, conocimientos y ambiente en el cual se desempea el usuario.

Si en el transcurso del desarrollo surge una necesidad de conocimiento o habilidad que el usuario debe desarrollar esta deber ser documentada y comunicada al cliente.

DiseoPara disear un caso de prueba de acoplamiento con el usuario se deben seguir los siguientes pasos:

1. Obtenga la comprensin del dominio del sistema mediante el documento de casos de uso, los artefactos y el documento de requisitos.

2. Observe los actores que se relacionan con el sistema, lo cual puede ser fcilmente determinado mediante el documento de casos de uso y el documento de requisitos.

3. Identifique el perfil de los actores, estructurando una idea de los conocimientos que requiere cada uno.

4. Compruebe en cada interfaz que componga cada caso de uso mediante un caso de prueba, que los textos, ayudas, conceptos, modo de visualizar etc, sean aptos para el perfil del actor que lo va a utilizar. Generalmente al disear casos de prueba de ste tipo, se genera es un proceso de verificacin un poco subjetivo.

En ste tipo de prueba se generarn casos de prueba con una secuencia de ejecucin muy similar ya que est orientado a verificar su usabilidad o acoplamiento con el usuario.

Al momento de ingresar la informacin en el administrador de casos de prueba (testlink), los pasos sern muy similares entre todos los casos de prueba, en contraparte el resultado esperado variar segn los actores involucrados en el uso de la interfaz, en este campo se debe anexar la informacin del perfil de los actores relacionados, toda vez que este ser el criterio para determinar el resultado de la ejecucin del prueba.

EjecucinEn caso de encontrarse un bug al ejecutar un caso de prueba en la mayora de los casos se tendr que reportar como de tipo anlisis y diseo y con criticidad baja.

1.1.6. Prueba de entradasObjetivoAsegurar que el sistema este diseado para que el usuario ingrese los datos necesarios de forma clara y correcta segn las funcionalidades requeridas para el mismo.

DescripcinSon consideradas entradas del sistema cualquier informacin que el usuario suministre y est dispuesta en:

Cajas de texto (textbox, passwordfield).

reas de texto (textarea).

Listas de seleccin (list).

Barra de seleccin deslizable (slider).

Arboles de entrada (tree).

Caja de ajuste de valor (Spinner).

Caja de opciones (combox).

Campos en tablas modificables (Grid).

Botones (button).

Botones de opcin (radiobutton).

Botones de seleccin (checkbox).

Vnculos (link).

Archivos (files).

Dispositivos externos de hardware (devices).

Otros que apliquen la definicin (ver observaciones).

En esta prueba se realizan varias comprobaciones que tienen en cuenta el comportamiento - el cual est relacionado con los requisitos funcionales del sistema - de cada una de las entradas. Las comprobaciones tpicas son:

El nombre de las entradas concuerda con la entrada misma y es suficientemente claro para que el usuario ingrese el dato.

La ubicacin de la entrada y de su nombre deben tener una relacin ubicacin-diseo clara para el usuario.

Se deben aceptar todas las entradas vlidas.

Se deben rechazar todas las entradas invlidas teniendo en cuenta que el sistema debe seguir estando disponible.

Se debe chequear que el sistema retorne informacin de reconocimiento a las entradas correctamente.

Se debe chequear que las opciones no sean excesivas o pocas segn sea el caso.

Se debe comprobar que las entradas no pueden ser redundantes y su interrelacin debe ser correcta, no se deben repetir datos de entrada en las interfaces y adicionalmente no deberan haber datos derivados que ingrese el usuario.

Se debe chequear que los botones y otros componentes si realicen la operacin para la que fueron diseados y respondan a sus eventos de manera adecuada.

Se debe chequear que la activacin y desactivacin de un componente sea la esperada.

Se debe chequear que no hayan vnculos rotos, y que estos direccionen al lugar correcto.

Se debe chequear valores limites en todas las entradas y su posterior comportamiento.

Si un componente posee valores por defecto, se debe verificar su correctitud.

Se debe comprobar que las entradas sean correspondientes a los roles de usuario.

Verificar que los procesos de importacin de archivos sean correctos.

Verificar el comportamiento del sistema en relacin con la interaccin de entrada del usuario y el hardware.

Verificar que los archivo adjuntados cumplan los requisitos funcionales asociados a ellos. Por ejemplo cuando se adjunta una imagen a un formulario se debe chequear que su tamao y su peso sean correctos.

Observaciones Se debe tener muy en cuenta lo descrito en los requisitos del sistema y en las polticas del negocio.

No se debe dejar ninguna entrada sin probar.

Es importante anotar que la interrelacin que existe entre entradas y salidas puede conllevar a realizar anlisis incorrectos de un aplicativo. Es por esta razn que se debe definir qu es y que no es una entrada y una salida y en qu momento una se convierte en otra.

As, una entrada es todo aquel componente o elemento en el sistema con posibilidad de modificacin por parte del usuario y viceversa, sin embargo existen entradas que en un punto en el tiempo se convierten en salidas.

Por otra parte, una salida es generalmente un componente o elemento en el sistema que no puede ser modificado por parte del usuario, sin embargo existen salidas que pueden ser modificadas por el usuario, pero una vez modificada esta salida se convierte en una entrada.

Aunque una entrada se puede convertir en un momento del tiempo en una salida y viceversa, no significa que una entrada pueda ser salida en el mismo instante de tiempo y viceversa; es decir una entrada o salida hace referencia al dato especfico relacionado con el componente. En este punto la aclaracin va dirigida a que una componente como tal si puede ser salida y entrada a la vez pero sin tener en cuenta sus aspectos dinmicos (eventos, estados, etc).

DiseoPara disear un caso de prueba de Entradas se deben seguir los siguientes pasos:

1. Obtenga la comprensin del dominio del sistema mediante el documento de casos de uso, los artefactos y el documento de requisitos.

2. Por cada interfaz de cada caso de uso se deben reconocer las entradas del sistema y mediante la descripcin en la tabla explicativa de los casos de uso en el campo atributos, y los tipos de requisitos de informacin en el documento de requisitos, se deben identificar los posibles valores las entradas ya reconocidas.

3. Teniendo en cuenta las tcnicas de testing, se deben generar los casos de prueba que sean necesarios segn las secuencias de los casos de uso, es decir, por cada secuencia diferente se debe crear un caso de prueba.

4. Se debe generar mediante un archivo de entradas del sistema.

Para diligenciar el formato ya mencionado, se deben ingresar los datos de entradas con su nombre respectivo en la parte superior de la tabla antecediendo cada columna, de sta forma habr una columna por cada entrada del sistema. Posteriormente cada fila deber ser una combinacin de valores para cada entrada del sistema que se escogi mediante una tcnica determinada la cual se indicar en la primera columna a travs del combo dispuesto para tal fin en la tabla.

En general es recomendable realizar solo combinaciones de datos utilizando una sola tcnica; si el caso se deber duplicar el caso de prueba y anexar una tabla con los valores de otra tcnica de testing.

5. Al disear casos de prueba de entrada, se deben tener en cuenta los tips que se describen en la descripcin y observaciones de la parte superior de ste tipo de prueba, dado que cada uno de ellos puede llevar a revelar un defecto en la interfaz.

6. Se debe generar el resultado esperado en forma genrica, de no ser posible, se debe adjuntar una tabla con el resultado esperado por cada caso de prueba descrito en la tabla valores de caso de prueba diligenciada en el paso 4.

EjecucinAl reportar un fallo en un tipo de prueba de entrada, debe dejar claro cual fue el conjunto de datos que ocasionaron el defecto y adems se debe anexar el nmero de combinacin correspondiente en el documento de valores de casos de prueba.

1.1.7. Pruebas de salidasObjetivoAsegurar que el sistema este diseado para que los datos entregados por este sean claros y correctos segn los requerimientos funcionales relacionados.

DescripcinSon consideradas salidas del sistema cualquier informacin que el sistema suministre y est dispuesta en:

Cajas de texto (textbox, passwordfield).

reas de texto (textarea).

Listas de seleccin (list).

Barra de seleccin deslizable (slider).

Arboles de entrada (tree).

Caja de ajuste de valor (Spinner).

Caja de opciones (combox).

Campos en tablas (Grid).

Botones (button).

Botones de opcin (radiobutton).

Botones de seleccin (checkbox).

Vnculos (link).

Archivos (files).

Dispositivos externos de hardware (devices).

Otros que apliquen la definicin (ver observaciones).

En esta prueba se realizan varias comprobaciones que tienen en cuenta el comportamiento - el cual est relacionado con los requisitos funcionales del sistema - de cada una de las salidas. Las comprobaciones tpicas son:

Se debe comprobar que la informacin de las salidas sea significativa y no contenga informacin redundante o innecesaria.

El nombre de la salida concuerda con la salida misma y es suficientemente claro para que el usuario comprenda el dato.

La ubicacin de la salida y de su nombre deben tener una relacin ubicacin-diseo clara para el usuario.

Se deben comprobar que las salidas contengan datos correctos y vlidos.

Las salidas no pueden ser redundantes y su interrelacin debe ser correcta, no se deben repetir datos de salida en las interfaces.

Se debe chequear que la activacin y desactivacin de un componente sea la esperada.

Se debe chequear que no hayan vnculos rotos, y que estos direccionen al lugar correcto.

Se debe comprobar que las salidas sean correspondientes a los roles de usuario.

Verificar que los procesos de exportacin de archivos sean correctos.

Verificar el comportamiento del sistema en relacin con la interaccin de salida del usuario y el hardware.

Verificar que los archivo generados por el sistema cumplan los requisitos funcionales asociados a ellos. Por ejemplo cuando el sistema genera reportes en pdf u en otro formato.

Observaciones Todas las salidas del sistema deben ser probadas.

Es importante anotar que la interrelacin que existe entre entradas y salidas puede conllevar a realizar anlisis incorrectos de un aplicativo. Es por esta razn que se debe definir qu es y que no es una entrada y una salida y en qu momento una se convierte en otra.

As, una entrada es todo aquel componente o elemento en el sistema con posibilidad de modificacin por parte del usuario y viceversa, sin embargo existen entradas que en un punto en el tiempo se convierten en salidas.

Por otra parte, una salida es generalmente un componente o elemento en el sistema que no puede ser modificado por parte del usuario, sin embargo existen salidas que pueden ser modificadas por el usuario, pero una vez modificada esta salida se convierte en una entrada.

Aunque una entrada se puede convertir en un momento del tiempo en una salida y viceversa, no significa que una entrada pueda ser salida en el mismo del tiempo y viceversa; es decir una entrada o salida hace referencia al dato especfico relacionado con el componente. En este punto la aclaracin va dirigida a que una componente como tal si puede ser salida y entrada a la vez pero sin tener en cuenta sus aspectos dinmicos (eventos, estados, etc).

DiseoPara disear un caso de prueba de Salidas se deben seguir los siguientes pasos:

1. Obtenga la comprensin del dominio del sistema mediante el documento de casos de uso, los artefactos y el documento de requisitos.

2. Por cada interfaz de cada caso de uso se deben reconocer las salidas del sistema y mediante la descripcin en la tabla explicativa de los casos de uso en el campo atributos, y los tipos de requisitos de informacin en el documento de requisitos, se deben identificar los posibles valores las salidas ya reconocidas.

3. Teniendo en cuenta las tcnicas de testing, se deben generar los casos de prueba que sean necesarios segn las secuencias de los casos de uso, es decir, por cada secuencia diferente se debe crear un caso de prueba.

7. Se debe generar mediante un archivo de entradas del sistema, en dicho archivo se debe disear una tabla en la cual se ingresan las entradas y sus valores, adems de los conjuntos de datos a utilizar por cada prueba siguiendo el esquema de flujo de proceso descrito en el caso de prueba determinado.

Para diligenciar el formato ya mencionado, se deben ingresar los datos de salidas con su nombre respectivo en la parte superior de la tabla antecediendo cada columna, de sta forma habr una columna por cada entrada del sistema. Posteriormente cada fila deber ser una combinacin de valores para cada entrada del sistema que se escogi mediante una tcnica determinada la cual se indicar en la primera columna a travs del combo dispuesto para tal fin en la tabla.

En general es recomendable realizar solo combinaciones de datos utilizando una sola tcnica; si es el caso se deber duplicar el caso de prueba y anexar una tabla con los valores de otra tcnica de testing.

4. Al disear casos de prueba de salida, se deben tener en cuenta los tips que se describen en la descripcin y observaciones de la parte superior de ste tipo de prueba, dado que cada uno de ellos puede llevar a revelar un defecto en la interfaz.

5. Se debe generar el resultado esperado en forma genrica, de no ser posible, se debe adjuntar una tabla con el resultado esperado por cada caso de prueba descrito en la tabla valores de caso de prueba diligenciada en el paso 4.

EjecucinAl reportar un fallo en un tipo de prueba de salidas, debe dejar claro cual fue el conjunto de datos que ocasionaron el defecto y adems se debe anexar el nmero de combinacin correspondiente en el documento de valores de casos de prueba.

1.1.8. Prueba de manejo de erroresObjetivoAsegurar la claridad y precisin de los errores que el sistema genere, adems se debe asegurar que el sistema maneje correctamente los errores.

DescripcinEn cualquier aplicacin de software se deben contemplar errores de hardware y de software. Es as como la aplicacin debe estar en capacidad de capturar el error, tratarlo y entregar al usuario una alerta descriptiva del mismo, que le permita tomar las acciones pertinentes para solucionarlo. En este punto no solo es importante para el usuario final la buena descripcin de los errores sino tambin para el equipo de desarrollo encargado del mantenimiento del software, dado que entre ms claro y catalogado este el error ms rpida ser su solucin. Algunos de los ms comunes son:

Errores de bases de datos.

Errores de comunicacin entre dispositivos.

Errores de memoria.

Errores de compatibilidad.

Errores del lenguaje de programacin.

Errores inesperados.

En este tipo de prueba se debe verificar que los mensajes de error estn codificados, tipificados, que describan la posible causa del mismo y que den una posible solucin.

Tambin es importante que el sistema sea capaz de responder al error de forma que siga estando disponible una vez que se lanzo la respectiva alerta.

Observaciones Es importante que durante el desarrollo de software se intente evitar que el usuario cometa errores en vez de permitir al usuario cometer errores y mostrarle alertas.

DiseoEste tipo de prueba suele ser de caja blanca, debido a que se verifica que el aplicativo est cubierto totalmente en cuanto a la captura y manejo adecuado de excepciones y errores. La aproximacin que se da a sta prueba en ste caso ser de caja gris, ya que en la mayora de los casos se requerir alguna modificacin en la base de datos o en archivos de sistema.

Para disear un caso de prueba de manejo de errores se deben seguir los siguientes pasos:

1. Obtenga la comprensin del dominio del sistema mediante el documento de casos de uso, los artefactos y el documento de requisitos.

2. Lea el documento de errores y mensajes manejados por el aplicativo, adjunto al core de artefactos de anlisis y diseo.

3. Genere un caso de prueba por cada mensaje o error documentado en el documento de errores y mensajes, en el cual se compruebe que sea manejado correctamente por el sistema.

4. En los resultados esperados se debe ingresar el mensaje de error que contiene el documento ya mencionado con su respectivo cdigo.

5. Se deben contemplar el manejo de errores como falta de conectividad, respuestas de servidor, no existencia de la base de datos, no existencia de registros en la base de datos etc.

Generalmente para que se muestren errores determinados se deben modificaciones directamente en la base de datos o a archivos especficos de configuracin en aplicativos cliente servidor. La captura de errores va ligada directamente a las practicas y estndares de programacin y manejo de errores que tiene la compaa por lo cual las pruebas debern basarse en dichas polticas.

En la test suite que compone el core de documentos se deber adjuntar el documento de errores y mensajes del aplicativo o mdulo especfico.

EjecucinAl ejecutar un caso de prueba, se debe verificar que el mensaje contenga la codificacin estndar y un mensaje que explique qu sucedi y como darle solucin. Adicionalmente en general deber permitir copiar cierta secuencia que tenga detalle tiles para la parte de soporte del aplicativo que son de nivel tcnico alto.

1.1.9. Pruebas de tecladoObjetivoAsegurar el correcto funcionamiento del producto de software desde el punto de vista de su interaccin con el teclado como perifrico de entrada de informacin.

DescripcinEn ste tipo de prueba se busca que los eventos asociados al teclado tales como presionar o soltar una o un conjunto de teclas sean correctamente gestionados por el producto de software teniendo en cuenta los requisitos funcionales asociados. Es importante anotar que dicha prueba es sumamente delicada, debido a que el foco de la interfaz debe estar ubicado en el componente al cual se le desea realizar la prueba.

Generalmente se presenta muchos errores en los aplicativos, debido a que no se contemplaron distintas combinaciones de teclas al momento de disear el mismo.

Se deben realizar pruebas teniendo en cuentas las distintas posibles combinaciones entre las teclas de funcin (Ctrl, Alt, Shift, Alt Gr, las teclas F1-F12) y las dems teclas, adems de combinacin tpicas identificadas con anterioridad como Ctrl+Pause o Ctrl+Insert, etc.

Observaciones Se debe realizar sta prueba a todos los componentes de una interfaz y para cada uno de ellos se debe probar todos los eventos y todas las posibles combinaciones de teclas pertinentes segn sea el caso .

En algunos casos, las pruebas de Teclado, de mouse y de perifricos adicionales pueden realizarse transversalmente, debido a que sus eventos pueden estar interrelacionados.

DiseoSe debe disear un caso de prueba por pantalla, y en caso de que sta tenga componente complejos como grid, arboles, etc., se debe generar un caso de prueba por cada uno de ellos.

Se deben probar por componente las combinaciones especficas que la aplicacin y los requisitos requieran.

Las posibles combinaciones suelen ser muchas, por lo cual se puede abreviar la escritura al describir que se probar, por ejemplo: combinaciones de TODAS las teclas con ALT, combinaciones de todas las teclas con SHIFT, etc.

Adicionalmente se deben probar sobre cada componente el comportamiento de teclas especiales como pause, break, pag. Arriba, pag. Abajo, inicio, fin, insert, suprimir, backspace, teclas direccionales, teclas F1-F12, enter, teclas de Windows, tecla de men contextual, ALT normal, ALT GR etc.

Ejecucin Al probar las combinaciones se debe tener en cuenta que el foco es algo importante y se debe estar atento donde se encuentra.

1.1.10. Pruebas de MouseObjetivoAsegurar el correcto funcionamiento del producto de software desde el punto de vista de su interaccin con el mouse como perifrico de entrada.

DescripcinEn ste tipo de prueba se busca que los eventos asociados al mouse tales como presionar y soltar los botones derecho, izquierdo o central, arrastrar y soltar, entre otros, sean correctamente gestionados por el producto de software teniendo en cuenta los requisitos funcionales asociados.

Un aspecto a tener en cuenta son los mens desplegables (popup) que se generan presionando el botn derecho del mouse, debido a que stos pueden cambiar segn la ubicacin del foco, es decir, el men cambia segn el componente sobre el que se despliegue.

Generalmente se presenta muchos errores en los aplicativos, debido a que no se contemplaron distintas combinaciones de teclas y eventos del mouse al momento de disear el mismo.

Se deben realizar pruebas teniendo en cuentas las distintas posibles combinaciones entre las teclas de funcin (Ctrl, Alt, Shift, Alt Gr, las teclas F1-F12), las dems teclas y los eventos del mouse.

Observaciones Se debe realizar sta prueba a todos los componentes de una interfaz y para cada uno de ellos se debe probar todos los eventos y todas las posibles combinaciones pertinentes segn sea el caso .

En algunos casos, las pruebas de Teclado, de mouse y de perifricos adicionales pueden realizarse transversalmente, debido a que sus eventos pueden estar interrelacionados.

DiseoSe debe disear un caso de prueba por pantalla, y en caso de que sta tenga componente complejos como grid, arboles, etc., se debe generar un caso de prueba por cada uno de ellos.

Bsicamente existen 4 tipo de elementos o acciones asociados con el mouse que desencadenan ciertos eventos: Botn derecho: Se utiliza para desplegar mens contextuales. En algunos casos las aplicaciones tiene como requisito de seguridad no desplegar dicho men dada las posibilidades que tiene (copiar, pegar, cortar entre otros).

Se deben generar casos de prueba para los eventos: clic, doble clic, clic sostenido y arrastrar en los cuales el puntero del mouse se encuentre en cada componentes y fuera de l. En caso de que el componente sea de tipo complejo (grid, arboles etc), se debe comprobar cada uno de los eventos en cada parte del componente, ejemplo en un grid se debe comprobar celdas, filas, columnas, ttulos, conjuntos de los anteriores, etc. Botn izquierdo: Se usa generalmente para desencadenar funciones.

Se deben generar casos de prueba para los eventos: clic, doble clic, clic sostenido y arrastrar en los cuales el puntero del mouse se encuentre en cada componentes y fuera de l. En caso de que el componente sea de tipo complejo (grid, arboles etc), se debe comprobar cada uno de los eventos en cada parte del componente, ejemplo en un grid se debe comprobar celdas, filas, columnas, ttulos, conjuntos de los anteriores, etc. Botn central: es usado para manejar generalmente el scroll de las pantallas cuando se gira la rueda, sin embargo tiene las mismas propiedades de botn, por lo cual sugiere realizar pruebas iguales a las de los dems botones. Movimiento: El cambio de posicin del puntero del mouse generalmente es utilizado para iniciar un proceso que puede ser visual o funcional.

Dependiendo de la plataforma y del tipo de pieza de software (aplicacin escritorio o web), el nmero de eventos podr aumentar, por lo cual se requerir una cantidad de pruebas ms alta y ms exhaustiva para ste tipo de prueba.

ES importante anotar que en algunos casos se generan combinaciones de mouse y teclado como: CTRL + clic derecho, CTRL + clic izquierdo, etc, que hacen que determinadas funciones se realicen. Se deben probar las combinaciones que se vean necesarias para que no se genere error y est contemplado para que se realicen diversas funciones.

Ejecucin Al probar las combinaciones se debe tener en cuenta que el foco es algo importante y se debe estar atento donde se encuentra.

1.1.11. Pruebas de Perifricos de entrada adicionalesObjetivoAsegurar el correcto funcionamiento del producto de software desde el punto de vista de su interaccin con perifricos de entrada de informacin distintos a teclado y mouse.

DescripcinEn ste tipo de prueba se busca que los eventos asociados a perifricos de entrada adicionales al teclado y al mouse, sean correctamente gestionados por el producto de software teniendo en cuenta los requisitos funcionales asociados.

Generalmente se presenta muchos errores en los aplicativos, debido a que no se contemplaron distintas combinaciones de eventos entre perifricos de entrada, por lo cual el nivel de complejidad de sta prueba es determinado por el nmero de perifricos de entrada que la aplicacin contemple.

Observaciones En algunos casos, las pruebas de Teclado, de mouse y de perifricos adicionales pueden realizarse transversalmente, debido a que sus eventos pueden estar interrelacionados.

DiseoAl disear casos de prueba de este tipo se deben identificar perifricos que la aplicacin use directamente tales como: lector de cdigo de barras, lector de huellas, scanner, impresoras, cmaras o dispositivos especializados.

El nmero de casos de prueba a disear depender de que tanta interaccin tenga el aplicativo con los dispositivos y que tantos eventos genere este dentro de la misma.

La combinacin de eventos de teclado y mouse con los eventos generados por dispositivos adicionales puede generar errores que se deben comprobar segn el caso.

1.1.12. Prueba de ortografa y gramticaObjetivoAsegurar la utilizacin correcta del lenguaje (ortografa y gramtica) utilizada en el producto de software.

Descripcinsta prueba revisa aspectos como: ortografa, gramtica, concordancia semntica, sintctica y en general buen uso del lenguaje. En ste caso, la prueba se realiza en mayora de los casos de forma transversal a otros tipos de prueba y en ella se revisa cualquier componente o elemento del producto de software que provea algn tipo de informacin mediante un lenguaje escrito, por ejemplo:

Imgenes con textos

Ttulos.

Etiquetas.

Explicaciones.

Ayudas.

Entre otras.

Se debe comprobar que el producto de software no tenga extranjerismos sin traduccin inmediata debido a que esto es fuente de confunciones para el usuario final.

Observaciones Todo contenido que tenga informacin escrita en el producto de software deber ser probado.

Es importante aclarar que la persona que realiza sta prueba debe tener un buen conocimiento del lenguaje. En el caso de que el producto de software est hecho en idioma espaol, dicha persona deber seguir los lineamientos que la RAE (Real Academia Espaola de la Lengua) define, en caso contrario los lineamientos que se debern seguir sern los contemplados por el organismo reconocido a nivel internacional que estandarice el lenguaje determinado.

En caso de que el producto de software sea multilinge, se debern realizar las pruebas de ortografa y gramtica para cada uno de los lenguajes.

Si entre los requisitos funcionales del software se encuentra la accesibilidad de usuarios con discapacidad de lectura, se deben hacer las pruebas pertinentes segn sea el caso.

DiseoDisee un caso de prueba de este tipo por interfaz, en donde se compruebe todos los elementos textuales de la misma.

1.1.13. Prueba de uniformidad de interfacesObjetivoAsegurar que la apariencia del producto de software es uniforme en todas sus interfaces.

DescripcinEn sta prueba se comprueban los siguientes aspectos:

Las interfaces en conjunto a travs de toda la aplicacin estn interrelacionadas, son uniformes en conversiones, formatos (colores, fuentes, tamaos de fuentes), estilos (negrita, subrayados, cursivas, tachado), abreviaciones de lenguaje entre otros.

Las imgenes utilizadas se visualizan correctamente, no se superponen de forma no controlada y son coherentes a travs de la aplicacin.

Los componentes o elementos del aplicativo de software tiene estndares definidos para su ubicacin, por ende dicho estndar debe ser manejado en todas la interfaces, ejemplo de ello, es la posicin y el aspecto del botn guardar (un botn tpico en cualquier interface) que se debe encontrar en una posicin especifica en todas las interfaces.

Observaciones Segn el tamao del aplicativo o mdulo a probar, sta prueba se puede realizar o no transversalmente a otras.

DiseoSe debe disear un caso de prueba por interfaz teniendo en cuenta los requisitos visuales del aplicativo.

Debe existir una descripcin detallada de los requisitos estticos en el documento de requisitos que sea compatible con lo diseado en los casos de uso.

1.2. PRUEBA COMPATIBILIDADObjetivoAsegurar que el producto de software cumple con los requisitos funcionales de compatibilidad exigidos por el cliente.

DescripcinEsta prueba busca comprobar la compatibilidad de un software frente a diferentes entornos como:

Navegadores: no solo se prueba la compatibilidad entre distintos navegadores sino tambin entre versiones de un mismo navegador.

Framework cliente y servidor: por ejemplo el producto de software esta desarrollado en java se debe verificar que este funcione bien en distintas versiones de la maquina virtual de java.

Sistemas operativos cliente y servidor: en esta prueba generalmente se utilizan sistemas virtualizados en donde se pueden especificar los sistemas operativos y las configuraciones especficas sin necesidad de un gran esfuerzo en cuanto a infraestructura e instalacin.

Plataformas de hardware cliente y servidor.

Dependiendo del tipo de aplicacin (escritorio o web) la prueba de compatibilidad aplica a diferentes subtipos de esta prueba.

Observaciones Generalmente la prueba de compatibilidad se realiza de forma transversal a todas las dems pruebas ya que estas deben ser ejecutadas en diferentes entornos para garantizar que todas las funciones sean ejecuten correctamente.

Todos los casos de prueba para un producto de software deben ser diseados teniendo en cuenta las diferentes combinaciones entre navegadores, sistemas operativos, maquinas virtuales, etc, que se establezcan en los requisitos. La especificacin puede ser dada en cada caso de prueba o en un conjunto de ellos, es decir, en la descripcin de la test suite respectiva.

Diseo Se deben disear casos de prueba que comprueben que las funcionalidades crticas del aplicativo funcionen de manera correcta en los diferentes entornos establecidos en los requisitos del producto de software (Ver descripcin en ste mismo tem).

1.3. PRUEBAS DE CAPACIDADObjetivoAsegurar que el producto de software cumpla los requisitos funcionales y no funcionales asociados al manejo de los datos.

DescripcinDado que una aplicacin de software esta inexorablemente relacionada con conjuntos de datos, ya sean almacenados en bases datos o en archivos con formatos especficos, y teniendo en cuenta que estos son elementos considerados como activos de gran valor al interior de una organizacin, - incluso ms que el producto de software mismo uno de los objetivos de las pruebas de software debe estar centrados en ellos. Es as como las pruebas de capacidad estn dirigidas a evaluar los datos que maneja la aplicacin relacionndolos directamente con los requisitos funcionales y no funcionales de la misma segn sea el caso.

Una de las caractersticas de las pruebas de capacidad es que la ejecucin de stas puede tardar varios das en completarse lo cual implica gran consumo no solo de recursos humanos, sino de recursos tcnicos (hardware y software) por lo cual en el proyecto de planificacin del testing del producto de software deben estar contemplados dichos recursos.

Observaciones La diferencia entre una prueba de stress, una de rendimiento y una de capacidad radica en:

La prueba de capacidad busca asegurar que el producto de software sea capaz de manejar en un rango aceptable el volumen de datos especificado en los requisitos funcionales.

La prueba de stress similarmente a la prueba de capacidad, busca determinar la capacidad del producto de software de manejar un volumen de datos y/o procesos pero intentando encontrar un lmite en el cual el aplicativo tenga un muy bajo rendimiento o se bloquee, es decir, se intenta observar cual es el pico funcionamiento de la aplicacin. Algo muy importante a tener en cuenta es que la prueba de stress utiliza valores superiores a los de las pruebas de capacidad con el fin de llegar a el pico de funcionalidad.

La prueba de rendimiento, sin embargo no es una prueba aislada de las pruebas de capacidad y stress, ya que busca en cada uno de los casos medir el rendimiento del producto de software bajo ciertos criterios especificados por alguna de las mismas, es as como la prueba de rendimiento es transversal a las pruebas de capacidad y stress respectivamente.

1.3.1. Pruebas de volumenObjetivoAsegurar que el producto de software este en la capacidad de manejar los volmenes de datos que los requisitos funcionales establecen.

Tipo de requisitos o artefactos relacionadosRequisitos inversos, Requisitos funcionales, Requisitos de informacin, Requisitos de manejo de errores, Requisitos de interfaz y usabilidad, Requisitos de estndar, Requisitos de interoperabilidad, Requisitos no funcionales, Requisitos del producto, Requisitos de seguridad, Requisitos de confiabilidad, Requisitos de escalabilidad, Requisitos de mantenibilidad, Requisitos de compatibilidad, Requisitos de eficiencia, Requisitos de rendimiento, Requisitos de capacidad.

DescripcinEste tipo de prueba busca determinar si el producto de software es capaz - en su normal ejecucin - de manejar los volmenes de informacin explicitados en los documentos de requisitos funcionales.

Esta prueba est muy ligada a las pruebas de rendimiento y de stress y en conjunto ofrecen la informacin necesaria para determinar si el producto satisface al cliente; en muchos casos estas pruebas se realizaran a la par sin embargo, el hecho de que un aplicativo pase una prueba de volumen no significa que su rendimiento sea aceptable.

Generalmente para chequear la capacidad de volumen de un producto de software se deben tener en cuenta los siguientes aspectos:

Verificar la capacidad del producto de software al realizar importaciones y exportaciones segn el lmite establecido en los requisitos funcionales.

Verificar que el producto de software funcione en rangos aceptables de funcionamiento con una carga de datos establecida en los requisitos funcionales.

Observaciones Para realizar estas pruebas es importante tener en cuenta que generalmente se deben usar tcnicas basadas en codificacin y generacin de script las cuales demandan altos grado de capacidad tcnica y una inversin de tiempo muy alta no solo en su diseo sino tambin en su ejecucin.

DiseoSe deben disear uno o ms casos de prueba por cada accin de upload (Subir archivos) y download (bajar archivos) que se realice en la aplicacin teniendo en cuenta los requisitos funcionales en cuento a la capacidad requerido de dichos archivos. Esta prueba se realiza siguiendo la tcnica de valores lmites. Se deben tener en cuenta todo tipo de archivos y caractersticas asociadas al mismo: tamao (vacio, intermedio, con el lmite), formato interno y externo (estructura), el tipo de codificacin (caracteres vlidos e invlidos).

1.3.2. Pruebas de dimensionamiento de bases de datosObjetivoAsegurar que el dimensionamiento de las bases de datos sea congruente con la realidad.

DescripcinEl dimensionamiento de las bases de datos se realiza para obtener un estimado del consumo del espacio fsico que utilizara el producto de software en trminos de sus base de datos, adems se encarga de proyectar segn la realidad de la compaa donde se implantara el software, cul ser la curva de crecimiento de la base de datos a travs del tiempo.

La prueba de dimensionamiento de bases de datos chequea que el dimensionamiento corresponda a los valores que realmente arroja el sistema (producto de software) relacionado con sus base de datos. Es importante aclarar que no todo el dimensionamiento puede ser probado antes de que el producto sea implantado, debido a que una parte fundamental de este son las proyecciones de crecimiento de las bases de datos a travs del tiempo, las cuales solo son posibles probarlas algn tiempo despus fue entregado al cliente. En este punto se debe tomar la prueba realizada a las proyecciones como una forma de mejorar el estimativo en proyectos posteriores.

Observaciones Entiendas como dimensionamiento al proceso mediante el cual se estima el comportamiento del crecimiento de las bases de datos intrnsecamente relacionados con el producto de software y la organizacin que lo usa.

Generalmente el dimensionamiento tambin obedece a nombres como plan de capacidad o plan fsico.

DiseoEn primera instancia se deben realizar chequeos de las bases de datos que vayan dirigidos a probarlas desde el punto de vista de rendimiento y buena construccin; esto se logra mediante el estudio de tablas, jobs, procesos almacenados y relaciones en donde se busca que las buenas prcticas recomendadas en los estndares y por las compaa diseadoras de cada motor sean tenidos en cuenta.

En segunda instancia se deben crear casos de prueba que basado en un documento de dimensionamiento de bases de datos verifique cada uno de los valores que se especifican en l contra la bases de datos. As si se especifica que por cada entrada de un instrumento al sistema se consumirn 3 kb, se debern ingresar los datos pertinentes a un instrumento en el sistema en el peor de los casos y verificar si el dimensionamiento es correspondiente. (Es importante anotar por ejemplo - que para ingresar al sistema un instrumento se deben ingresar datos en 3 tablas: tbinstrumento, tbdueo, tbuso y por ende los datos ingresados en las 3 tablas son el conjunto que delimita el tamao total en el peor de los casos de un instrumento en el sistema).

1.4. PRUEBA DE STRESSObjetivoEncontrar el pico en cuanto al lmite del rendimiento del producto de software se refiere, que garantice un funcionamiento aceptable bajo ciertos rangos preestablecidos.

Descripcin

Cuando se ejecuta un sistema y se prueba la carga de procesos en l y los resultados relacionados con la asignacin de recursos en cantidades mximas, se est hablando de una prueba de stress o de tensin o prueba en condiciones forzadas.

La meta de la prueba de tensin es intentar romper el sistema; la idea es encontrar las circunstancias bajo las cuales se colapsar. La prueba de stress es importante porque puede revelar defectos en tiempo real, as como las reas dbiles donde el diseo defectuoso podra causar la indisponibilidad del servicio. Esto es particularmente importante para los sistemas en tiempo real donde los acontecimientos imprevisibles pueden ocurrir dando por resultado las cargas de la entrada que exceden lo descrito en los documentos de los requisitos funcionales.

Una de las caractersticas de las pruebas de stress es que la ejecucin de stas puede tardar varios das en completarse lo cual implica gran consumo no solo de recursos humanos, sino de recursos tcnicos (hardware y software) por lo cual en el proyecto de planificacin del testing del producto de software deben estar contemplados dichos recursos.

Las pruebas de stress no solo se deben realizar en etapas de produccin, sino tambin y ms importante aun en etapas tempranas de implantacin con el fin de reducir el riesgo de que en el sistema aparezcan fallos que lleven a bloqueos totales del sistema.

Cabe anotar que las pruebas de stress estn catalogadas como pruebas de importancia superior debido a que detectan fallas y comportamientos anmalos del producto de software y fijan un lmite del mismo en cuanto a su mxima carga transaccional sugerida y soportada.

Aunque el objetivo de las pruebas de stress es el de forzar la aplicacin hasta encontrar el punto en el cual sta ya no responda ms, es importante anotar que no siempre es posible cumplirlo, debido a que puede que sta nunca deje de funcionar, sino que ample los umbrales de tiempo para la ejecucin de sus procesos, caso en el cual deber tomarse en cuenta el rendimiento del sistema y la carga transaccional probada para encontrar un punto de aceptacin mxima que permita tanto a la aplicacin como al usuario final satisfacer sus valores de aceptacin.

Observaciones La diferencia entre una prueba de stress, una de rendimiento y una de capacidad radica en:

La prueba de capacidad busca asegurar que el producto de software sea capaz de manejar en un rango aceptable el volumen de datos especificado en los requisitos funcionales.

La prueba de stress similarmente a la prueba de capacidad, busca determinar la capacidad del producto de software de manejar un volumen de datos y/o procesos pero intentando encontrar un lmite en el cual el aplicativo tenga un muy bajo rendimiento o se bloquee, es decir, se intenta observar cual es el pico funcionamiento de la aplicacin. Algo muy importante a tener en cuenta es que la prueba de stress utiliza valores superiores a los de las pruebas de capacidad con el fin de llegar a el pico de funcionalidad.

La prueba de rendimiento, sin embargo no es una prueba aislada de las pruebas de capacidad y stress, ya que busca en cada uno de los casos medir el rendimiento del producto de software bajo ciertos criterios especificados por alguna de las mismas, es as como la prueba de rendimiento es transversal a las pruebas de capacidad y stress respectivamente.

1.4.1. Pruebas de stress de concurrenciaObjetivoEncontrar el lmite de usuarios o procesos que concurrentemente utilicen el producto de software.

DescripcinLa concurrencia es uno de los factores que ms afecta el desempeo, calidad y operatibilidad de productos de software que funcionen en ambientes cliente-servidor, debido a que generalmente la carga transaccional que el servidor - donde es ejecutado el producto de software- es muy alta a consecuencia de las mltiples conexiones o peticiones de usuarios para realizar procesos en l. Es por sta razn que las pruebas de concurrencia simulan conexiones simultaneas de clientes con el servidor sin que realmente estn ocurriendo. Existen casos en los cuales las pruebas de stress de concurrencia se realizan sin hacer uso de herramientas adicionales, es decir, se observa el sistema bajo condiciones de cargas controladas de usuarios reales en ambientes reales de trabajo. Es poco recomendable a nivel prctico ste tipo de aplicacin de las pruebas de stress de concurrencia, ya que:

Es costoso el gasto de personal humano para realizar dichas pruebas, lo que generalmente conlleva a que la concurrencia lograda no sea muy alta.

Se necesitan muchos recursos de infraestructura para realizar dichas pruebas.

Es difcil realizar varias iteraciones sobre una misma prueba o realizar pruebas similares, debido a que tanto el recurso humano como el recurso de infraestructura no solo est limitado por el tiempo sino por el dinero y su nmero a nivel cuantificable - .

El dinero en cualquier proyecto y en especial en un proyecto de software es limitado.

Las pruebas de stress de concurrencia tiene como base los valores de aceptacin especificados en los requisitos funcionales, sin embargo y generalmente stos no son los utilizados para realizar la prueba, sino que se tiene en cuenta como la base para generar valores ms altos que castiguen al sistema en trminos de cargas transaccionales. Por ejemplo, si el producto de software se requiere para manejar 10 conexiones simultneas en determinado mdulo entonces se estn tensionando las funcionalidades del mismo con una carga de 20 conexiones simultneas a dicho mdulo.

As al ejecutar pruebas de stress se pueden encontrar errores que reflejen por ejemplo que, las rdenes del priorizacin del sistema pueden no estar correctas, que el tratamiento transaccional pueda estar mal disear o que la memoria podra estar mal distribuida, hacindola intil, adems de que las secuencias de la sincronizacin pueden no ser apropiadas para las tareas requeridas entre otros.

Generalmente las pruebas de stress de concurrencia, se deben disear teniendo como base un software o librera que permita emular la concurrencia de usuario o en su defecto de nmero de procesos en unidad de tiempo simultneamente; ste exige que se genere cdigo adicional que ir muy ligado al cdigo fuente generado al construir el aplicativo; adicionalmente, es necesario que dichas pruebas sean diseadas por personal con un alto grado de conocimiento del dominio del producto de software y de la arquitectura del mismo, adems de un dominio total del software o librera sobre la cual disear la prueba.

Observaciones Algunas de las herramientas ms usadas para realizar estas pruebas en el lenguaje java es JMeter (para aplicaciones y en general y especialmente diseadas en java bajo tomcat) y WAST (para aplicaciones diseadas en .NET con asp y aspx).

En entornos de programacin como Visual Studio .NET 2005 existen herramientas que permiten automatizar las pruebas de stress de concurrencia con un nivel de complejidad medio.

Diseo y reporteLas pruebas de stress de concurrencia deben realizarse en primera instancia en entornos de pruebas sobre hardware que se asemeje al hardware en el cual se instalara en etapas productivas; en segunda instancia es recomendable realizar pruebas en los ambientes productivos del cliente.

Lo recomendable y ciertamente poco probable es realizar pruebas de stress a cada interfaz del aplicativo, sin embargo en condiciones normales no es posible por limitaciones de tiempo y dinero, es por esto que se deben identificar las funcionalidades relacionadas con un determinado nmero de interfaces que sean crticas para el sistema. Comnmente se realizan pruebas de stress a la parte inicial de logeo de un aplicativo, y de all derivan las dems pruebas.

Se debe crear un caso de prueba por conjunto de interfaces a probar, es decir, por proyecto de prueba de stress. Se debe documentar las pginas a las cuales se les har la prueba y los datos a utilizar. Los archivos, script y el proyecto de la herramienta para pruebas de stress debern ser anexados al caso de prueba al igual que los resultados, los cuales debern ser reunidos en un documento con los anlisis, grficos, y conclusiones pertinentes.

Al realizar la prueba, es decir, al ejecutar el caso de prueba se debern realizar los procesos pertinentes que requerirn de un dominio tanto de la aplicacin como de la herramienta para realizar las pruebas de stress.

En el documento que se anexe al caso de prueba se deben contemplar los siguientes tems:

1. Descripcin de la aplicacin o mdulo a probar.

2. Antecedentes y resultados esperados de la prueba.

3. Diagrama de flujo de prueba propuesta

4. Descripcin del hardware y plataforma: se deben describir los equipos usados, su capacidad, el estado de la red, y de la plataforma en general.

5. Descripcin de la prueba.

6. Resultados de ejecucin

a. Diagrama de rendimiento con media, mediana y la desviacin estndar (Grfica tiempo vs hilo).

b. Grfica de rendimiento del servidor (Herramientas administrativas de Windows server).

c. Tabla de lmites y rendimientos obtenidos: en sta se deber determinar claramente el lmite sugerido.

d. Anlisis de resultados.

e. Impacto en el producto.

f. Recomendaciones.

7. Conclusiones.

Al realizar el reporte de errores, generalmente se deber reportar un bug de tipo mnimo, en el cual se realicen recomendaciones o sugerencias segn lo arrojado por la prueba. En el caso de que las pruebas arrojen resultados que demuestren un problema de concurrencia grave se deber reporte el bug en el nivel que determine el grupo de pruebas.

1.4.2. Pruebas de stress de capacidad de datosObjetivoEncontrar el lmite de capacidad de datos que el producto de software pueda manipular - en cuanto al software y al hardware se refiere - .

DescripcinDado que los datos son un aspectos relevante en los sistema de cmputo como se mencionado en anteriormente -, se deben realizar pruebas que no solo certifiquen que la aplicacin tenga la capacidad de datos especificada en los requisitos funcionales (Ver pruebas de capacidad), sino que tambin se debe encontrar los lmites mximos que posea el sistema en cuento a la manipulacin de los datos.

Al igual que en las pruebas de stress de concurrencia, las de capacidad buscan extremar el sistema en cuanto a capacidad de datos con el fin de bloquearlo y de sta forma determinar sus lmites; esto ltimo y como ya se haba mencionado no es posible conseguirlo en todos los casos, lo cual conlleva en encontrar un punto de aceptacin en el cual tanto el sistema de cmputo como el usuario final tengan un nivel de satisfaccin admisible.

Tambin es relevante recordar que para realizar stas pruebas se toman como base los valores usados en las pruebas de capacidad de los datos, sin embardo dichos valores debern ser aumentados para aplicarlos al producto de software y as forzarlo en cuanto a la capacidad de datos que maneja.

Observaciones Es importante tener en cuenta que la realizacin de sta prueba a bases de datos es innecesaria ya que no es prctico comprobar los lmites de determinado DBMS (Data Base Management System) debido a que las empresas desarrolladoras de stos documentan dichos lmites y saben de antemano las capacidades y falencias de sus sistemas.

Las pruebas de stress de capacidad de datos van sumamente ligadas a las pruebas de capacidad, en tanto que ambas se disean y ejecutan de forma similar, sin embargo los valores y los objetivos a cumplir son distintos.

Es importante anotar que se deben someter a sta prueba todos los tipos de datos que el productos de software maneje, incluyendo imgenes, textos, nmeros, archivos de distintos formatos entre otros.

DiseoSe deben disear uno o ms casos de prueba por cada accin de upload (Subir archivos) y download (bajar archivos) que se realice en la aplicacin orientando las pruebas a encontrar el lmite de dichas acciones. Se deben tener en cuenta todo tipo de archivos y caractersticas asociadas al mismo: tamao (vacio, intermedio, con el lmite), formato interno y externo (estructura), el tipo de codificacin (caracteres vlidos e invlidos).

sta prueba se debe basar en las pruebas de volumen que aunque no estn orientadas a encontrar el lmite, tienen similitud en cuanto al procesos y pasos a realizar.

Generalmente la capacidad de upload y download es configurada directamente en el servidor web y la base de datos, por lo cual al realizar esta prueba se deben tener en cuenta estos factores.

Los requisitos pueden tener explcita o implcitamente condicionado el lmite de los archivos, por lo cual se debe tener cuidado a la hora de disear pruebas orientadas a encontrar ciertos lmites, dado que superar un lmite especfico podra ser un error o un requisito inverso.

1.5. PRUEBA DE SEGURIDADObjetivoAsegurar que el producto de software cumple con los estndares exigidos en los requisitos no funcionales y adems que contemple los esquemas de seguridad mnimos reconocidas en la industria de software.

Descripcin

La prueba de la seguridad evala las caractersticas del sistema que se relacionan con la disponibilidad, integridad, y confidencialidad de los datos y de los servicios del sistema.

La seguridad del software y los datos puede estar comprometida por:

Criminales que puedan hacer dao, robando datos e informacin, causando la negacin del servicio.

Errores por parte del usuario en donde la aplicacin permite el acceso, creacin, modificacin o destruccin a datos debido a informacin falsa, y mal manejo de privilegios.

Los daos que se pueden hacer a la producto de software pueden ser usando algunos de los siguientes medios:

Virus.

Caballos de Troya.

Puertas traseras abiertas.

Canales ilcitos.

Entre otros.

Los efectos de los ataques contra la seguridad pueden ser extensos y pueden causar:

Prdida de informacin.

Corrupcin de la informacin.

Guardado y visualizacin de Informacin falsa.

Negacin del servicio.

Entre otros

El producto de software al igual que los elementos que interactan con l deben estar asegurados mediante el uso de mecanismos de proteccin tales como contraseas, cifrado, antivirus, aplicaciones que detecten y eliminen puertas traseras, detectores de intrusos entre otros. Las personas encargadas de mantener la plataforma en la cual est instalado el aplicativo deben asegurar la proteccin contra accesos no autorizados, sin embargo, la seguridad asociada directamente con la aplicacin debe ser tratada en el tiempo de diseo y construccin del producto de software. Un ejemplo se relaciona con las caractersticas de una contrasea. Los diseadores necesitan respuestas a las siguientes preguntas sobre la contrasea:

Cul es la mnima y la mxima longitud permitida?

Puede ser alfabtica solamente o debe ser una mezcla de caracteres alfabticos y otros?

Puede ser una palabra del diccionario?

Es permanente, o expira peridicamente?

Los usuarios pueden especificar sus necesidades en esta rea en el documento de los requisitos no funcionales. Un inspector de seguridad de contraseas puede hacer cumplir cualquier regla que los diseadores juzguen necesaria para satisfacer los requisitos de seguridad.

En sta prueba se chequean generalmente los siguientes aspectos: Password Checking (Prueba de contrasea): Se inspecciona la contrasea para asegurar que los usuarios si seleccionen una contrasea que contemple las condiciones de aceptacin de la misma establecidas en los requisitos. Las reglas y las condiciones que especifican una contrasea como vlida se pueden utilizar para disear las pruebas. Los ingresos legales e ilegales por medio de contraseas: Se prueba que los resultados de los intentos de ingresos legales e ilegales al sistema sean los esperados. Pruebas de snifffer y spoofing. Verificacin de concurrencia de sesiones: se realiza sii los requisitos funcionales as lo determinan. Chequeos de expiracin de sesiones.

Expiracin de contrasea: Si se decide que las contraseas expirarn despus de cierto perodo, las pruebas se debe disear para asegurar que el perodo de la expiracin sea el correcto y que los usuarios puedan ingresar y cambiar correctamente su contrasea apropiadamente. Cifrado: Se deben disear pruebas para evaluar la correctitud de los algoritmos de cifrado y de desciframiento para los sistemas donde se codifican los datos y los mensajes. Visualizacin: Se deben evaluar los privilegios al visualizar las interfaces para asegurar que no ocurren ingresos no autorizados. Los tester deben procurar visualizar (navegar) ilegalmente a travs de la aplicacin con el fin de observar las respuestas de sistema. Deben determinarse qu tipos de informacin privada se pueden deducir por navegacin legal e ilegal. La Puerta abiertas: Se deben identificar cualquier entrada desprotegida en el sistema que puede permitir el acceso a travs de los canales inesperados (puertas traseras abiertas). Las pruebas deben intentar lograr la entrada ilegal y observar los resultados en el sistema. Los tester necesitarn la ayuda de los diseadores y programadores para esta tarea. En muchos casos un equipo externo se emplea para procurar tal rompimiento en el sistema. Virus: se deben disear las pruebas para asegurar que los antivirus del sistema previenen o disminuyen la entrada de virus en el mismo. Los tester pueden procurar infectar el sistema con varios virus y observar la respuesta del mismo. Si un virus penetra el sistema, los tester debern determinar qu se ha daado y en qu medida. SQL / URL - INJECTION: mediante tcnicas y herramientas especializadas se deben probar que vulnerabilidades de ste tipo no se presente en la pieza de software.

Observaciones Es importante aclara que nunca hay una garanta total de que el software es totalmente seguro.

Es posible que para realizar pruebas de seguridad se requiera el uso de programas externos, lo cual implica que el personal no solo debe estar en capacidad de utilizarlo, sino tambin debe estar conciente de las tcnicas y repercusiones que puede acarrear su uso.

Diseo

1.6. PRUEBA DE RENDIMIENTOObjetivoMedir la eficiencia de un producto de software en trminos de su rendimiento computacional.

Descripcin

En esta tipo de prueba se verifica que los requerimientos de eficiencia y tiempo de respuesta concuerden con los que arroja el programa. Las pruebas deben ser ejecutadas tratando de demostrar que no se cumplen con los requisitos.

Las pruebas de rendimiento permiten que los tester optimicen o ajusten el sistema, es decir, para optimizar la asignacin de los recursos de sistema. Por ejemplo, los tester pueden encontrar que necesitan reasignar posiciones de la memoria, o modificar el nivel de la prioridad de ciertas operaciones de sistema.

Los objetivos del rendimiento se deben articular claramente por los usuarios o los clientes en los documentos de los requisitos, y se deben indicar claramente en el plan de prueba del sistema. Los objetivos deben ser cuantificados. Por ejemplo, la respuesta: una cantidad de tiempo razonable a un requisito sobre la demora del sistema (tiempos de respuesta), no es un requisito aceptable; el requisito del tiempo se debe especificar en manera cuantitativa. Los resultados de las pruebas del rendimiento son cuantificables. Al final de las pruebas el tester sabr, por ejemplo, el nmero de la ciclos de CPU usados, el tiempo de reaccin real en los segundos (minutos, etc.), el nmero real de las transacciones procesadas por perodo. stos se pueden evaluar con respecto a objetivos de los requisitos.

Los recursos para la prueba de rendimiento se deben asignar en el plan de prueba del sistema. Entre los recursos que se deben tener en cuenta estn:

Fuente de las transacciones para conducir los experimentos. Por ejemplo si se desea hacer un prueba de rendimiento de un producto de software en un sistema operativo, se necesita una fuente de datos que representan interacciones tpicas del usuario. La fuente de la transaccin para muchos sistemas es tpicamente un generador de carga (Script de alimentacin de sistema).

Una base de pruebas (testbed) del sistema experimental que incluye el hardware y el software del sistema requeridos. Los requisitos del testbed a veces suelen incluir el equipo y el espacio especial del laboratorio que deben ser reservados para las pruebas.

Instrumentacin o pautas de prueba del sistema que ayudan a recoger los datos del rendimiento. Las pautas de prueba pueden ser relacionadas con hardware o software. En algunos casos se sondean tareas en donde se toma en cuenta determinado acontecimiento y se toma la medida de la duracin del mismo. Por ejemplo, si se est investigando los requisitos de la memoria para un software se podra utilizar una pauta de prueba del hardware que recoge la informacin sobre el uso de memoria (bloques asignados, bloques desasignados para diversos tipos de la memoria por unidad de tiempo) al momento de la ejecucin del sistema. El probador debe tener en mente que las pautas de prueba pueden tener un impacto en el funcionamiento del sistema (la medicin altera el mismo comportamiento del sistema).

Herramientas del sistema para recoger, almacenar, procesar e interpretar los datos. Muy a menudo, los grandes volmenes de datos se recogen, y sin las herramientas adecuadas los tester pueden tener grandes dificultades en el proceso de analizar los datos en orden para evaluar niveles de rendimiento verdaderos.

Los encargados de las pruebas deben comprobar la disponibilidad de estos recursos, y asignar el tiempo necesario para usarlos en el plan de prueba. Los requisitos del uso para estos recursos necesitan ser descritos como parte del plan de prueba.

Adicionalmente, se deben probar el rendimiento de los procedimientos almacenados y sentencias SQL, jobs entre otros, implementados en las bases de datos con el fin de que estos consigan un afinamiento que hagan posible su funcionamiento ptimo.

Observaciones La diferencia entre una prueba de stress, una de rendimiento y una de capacidad radica en:

La prueba de capacidad busca asegurar que el producto de software sea capa