lunes, 23 de noviembre de 2015

CUESTIONARIO

1.       Las pruebas de software, en inglés testing son los procesos que permiten
Verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego.

1.       ¿Qué son las pruebas de software?
Las Pruebas de software son los procesos que permiten verificar y revelar la calidad de un producto software. El programa se ejecuta con la intención de descubrir un error.

2.       ¿Con que fin se realizan las pruebas de software?
El fin de las pruebas es presentar información sobre la calidad del producto a las personas responsables de este. Teniendo esta afirmación en mente, la información que puede ser requerida es de lo más variada. Esto hace que el proceso de testing sea completamente dependiente del contexto en el que se desarrolla

3.       ¿Que son las estrategias de prueba de software y para que se emplean?
Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que dan como resultado una correcta construcción del software. Y lo que es más importante, una estrategia de prueba del software proporciona un mapa a seguir para el responsable del desarrollo del software, a la organización de control de calidad y al cliente: un mapa que describe los pasos que hay que llevar a cabo como parte de la prueba, cuándo se deben planificar y realizar esos pasos, y cuánto esfuerzo, tiempo y recursos se van a requerir. Por tanto, cualquier estrategia de prueba debe incorporar la planificación de la prueba, el diseño de casos de prueba, la ejecución de las pruebas y la agrupación y evaluación de los datos resultantes.

4.       ¿Cuál es la prueba que se enfoca en los requisitos necesarios para el usuario final y que técnicas utiliza?
Prueba alfa y beta: En este servicio, los consultores de Testhouse se encargan de
Dirigir a los usuarios finales y asegurar que se prueban todos los requisitos y se cumplen los criterios de aceptación especificados previamente en el plan de pruebas del sistema. Como resultado de estas pruebas se elabora un informe que determina la aceptación o rechazo del sistema en base los criterios de aceptación acordados.

5.       ¿Cuáles son los tres enfoques para el diseño de pruebas y en qué consiste?
Enfoque estructural o de caja blanca: consiste en centrarse en la estructura interna (implementación) del programa para elegir los casos de prueba.
Enfoque funcional o de caja negra: consiste en estudiar la especificación de las funciones, la entrada y la salida para derivar los casos.
Enfoque aleatorio: consiste en utilizar modelos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba.

6.       ¿En qué consiste el enfoque estructural o caja blanca?
Consiste en centrarse en la estructura interna (implementación) del programa para elegir los casos de prueba.

7.       ¿En qué consiste el enfoque funcional o de la caja negra?
Consiste en centrarse en la estructura interna (implementación) del programa para elegir los casos de prueba

8.       ¿En que consiste la prueba de regresión?
consiste  intentan descubrir las causas de nuevos errores (bugs), carencias de funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, inducidos por cambios recientemente realizados en partes de la aplicación que anteriormente al citado cambio no eran propensas a este tipo de error. Esto implica que el error tratado se reproduce como consecuencia inesperada del citado cambio en el programa.

9.       ¿Cuáles son las dos formas de integración y en qué consisten?
-          Integración descendente
Es un enfoque incremental para la construcción de la arquitectura del software. Los módulos se integran al descender por la jerarquía de control, empezando con el módulo de control principal. Los módulos subordinados al módulo de control principal se incorporan en la estructura de una de dos maneras: primero en profundidad o primero de anchura.

-          Integración ascendente
Empieza la construcción y la prueba con módulos atómicos (es decir, componentes de los niveles más bajos de la estructura del programa). Debido a que los componentes se integran de abajo hacia arriba, siempre está disponible el procesamiento requerido para los componentes subordinados a un determinado nivel y se elimina la necesidad de resguardos

10.   ¿Qué es un producto alpha, beta y master?
Alfa es la primera versión del programa
El beta es la primera versión completa del programa que puede ser inestable
Master pueden responder a las necesidades actuales del área de desarrollo de software.

11.   ¿Qué diferencia hay entre una prueba de caja negra y caja blanca?
Las de caja negra se aplican a la interfaz del software (examina un aspecto funcional con poca relación con la arquitectura del sistema).

Las de caja blanca prueba las rutas lógicas del software y la colaboración entre componentes. Se conoce y se tiene en cuenta

12.   ¿La prueba y la depuración son lo mismo? ¿Por qué?
-          Prueba: Es el proceso mediante el cual se establece la existencia de errores.
-          Depuración: Es el proceso mediante el cual se localizan los errores.
Ambos casos tienen el objetivo de localizar y establecer los posibles errores que se están presentando en la aplicación.

13.   ¿Qué tipo de prueba se basa en sus componentes y la forma como están sus estructuras?
Pruebas de Integración, ya que este tipo de prueba está basado en los requisitos no funcionales

14.   ¿Las pruebas de aceptación son definidas por el desarrollador?  ¿Por qué?
Las pruebas de aceptación aseguran el comportamiento del sistema, son escritas por el usuario y especifican los aspectos a probar cuando una historia de usuario ha sido correctamente implementada.
En esta herramienta se definen las actividades que deben ser realizadas por el cliente por lo tanto es a partir de ahí que el programador implementa los arreglos a posibles fallas o correcciones.

15.   Defina cada uno de los procesos de las pruebas de software

v  Pruebas Unitarias
v  Pruebas De Integración
v  Pruebas De Validación
v  Pruebas De Sistema
v  Caja Blanca
v  Caja Negra
v  Pruebas De Regresión

16.   ¿Qué diferencia existe entre un fallo, un erro y un defecto?
Falla: En terminología IEEE, una falla es la discrepancia visible que se produce al ejecutar un programa con un defecto, el cual es incapaz de funcionar correctamente (no sigue su curso normal).

Error: Es una equivocación cometida por el desarrollador. Algunos ejemplos de errores son: un error de digitación, una malinterpretación de un requerimiento o de la funcionalidad de un método. El estándar 829 de la IEEE coincide con la definición de diccionario de error como "una idea falsa o equivocada". Por tal razón un programa no puede tener o estar en un error, ya que los programas no tienen ideas; las ideas las tienen la gente.

Defecto: Un defecto se encuentra en un artefacto y puede definirse como una diferencia entre la versión correcta del artefacto y una versión incorrecta. Coincide con la definición de diccionario, "imperfección".

17.   ¿Es necesario realizar las pruebas de aceptación?
Las pruebas de aceptación, al igual que las de sistema, se realizan sobre el producto terminado e integrado; pero a diferencia de aquellas, están concebidas para que sea un usuario final quien detecte los posibles errores

18.   Establezca a diferencia entre las diferentes estrategias de pruebas
Se han propuesto varias estrategias de prueba del software en distintos libros. Todas proporcionan al desarrollador de software una plantilla para la prueba y todas tienen las siguientes características generales:
v  La prueba comienza en el nivel de módulo y trabaja «hacia fuera», hacia la integración de todo el sistema basado en computadora.
v  Según el momento son apropiadas diferentes técnicas de prueba.
v  La prueba la lleva a cabo el responsable del desarrollo del software y (para grandes proyectos) un grupo independiente de pruebas.
v  La prueba y la depuración son actividades diferentes, pero la depuración se debe incluir en cualquier estrategia de prueba.
Una estrategia de prueba del software debe incluir pruebas de bajo nivel que verifiquen que todos los pequeños segmentos de código fuente se han implementado correctamente, así como pruebas de alto nivel que validen las principales funciones del sistema frente a los requisitos del cliente. Una estrategia debe proporcionar una guía al profesional y proporcionar un conjunto de hitos para el jefe de proyecto. Debido a que los pasos de la estrategia de prueba se dan a la vez cuando aumenta la presión de los plazos fijados, se debe poder medir el progreso y los problemas deben aparecer lo antes posible.

19.   ¿Cuál es la diferencia entre validación y verificación?
Muchas veces se confunde “verificación” con validación”. Barry W. Boehm (1979) puso en claro con pocas palabras la diferencia:

v  Validación: ¿Estamos construyendo el producto correcto? Se ocupa de controlar si el producto satisface los requerimientos del usuario

v  Verificación: ¿Estamos construyendo correctamente el producto? implica controlar que el producto conforma su especificación inicial.

En la Validación el resultado final del desarrollo software se debe ajustar a lo que el usuario quería (sus necesidades). En la mayoría de las ocasiones el producto desarrollado no casa con la ideas del cliente, normalmente porque a éste suele faltarle capacidad técnica de expresión.

En la Verificación el código que estamos construyendo debe estar en armonía con la especificación que hemos tomado del usuario. El resultado final del desarrollo software debe concordar con la especificación (requisitos) del sistema, por lo que debemos asegurarnos que el desarrollo final coincida con dicha especificación

20.   ¿Porque es difícil aplicar pruebas de unidad a un módulo altamente acoplado?
Porque es difícil aplicar pruebas de unidad a un módulo altamente acoplado.
si para cambiar un módulo en un programa tenemos que cambiar otro módulo, entonces hay acoplamiento entre ellos.
El acoplamiento puede aparecer bajo varias formas. Por ejemplo, si hay código repetido esparcido entre los módulos, también habrá un cierto acoplamiento, porque cambiar un fragmento de código repetido implica cambiarlo en todos los módulos que aparecen.
Incluso puede que haya dependencias entre módulos y no nos demos cuenta de ello.
Pero el acoplamiento también ocurre cuando el código de un módulo utiliza código de otro módulo, bien porque llama a un método, o accede a sus datos.
Por ello, como tal, el acoplamiento no es algo que debas evitar a toda costa.
Porque aunque dividamos nuestro programa en módulos, esos módulos tendrán que interactuar entre sí de alguna manera (si no tendríamos distintos programas independientes) y tendremos algo de acoplamiento entre ellos.
Hay distintos tipos y lo que es más importante, grados de acoplamiento.
Lo que es malo, y puede que lo estés padeciendo, es tener un acoplamiento alto, fuerte, entre los módulos.
Y peor si es incontrolado, es decir, si no sabes claramente qué módulos dependen de otros módulos.

21.   De tres ejemplos de pruebas, aplique pruebas de caja negra y pruebas de caja blanca

Tipos de pruebas
v  Pruebas Unitarias
v  Pruebas De Integración
v  Pruebas De Validación
v  Pruebas De Sistema

Prueba de caja blanca:
Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas estructurales)
Se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente. El testeador escoge distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los valores de salida adecuados.

Las principales técnicas de diseño de pruebas de caja blanca son:
                   Pruebas de flujo de control
                   Pruebas de flujo de datos
                   Pruebas de bifurcación (branch testing)
                   Pruebas de caminos básicos

Pruebas de la caja negra: 
Las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del módulo. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.

21.   Explique los métodos de pruebas orientados a objetos

Prueba de Unidad
El encapsulamiento dirige la definición de clases y objetos. Esto significa que cada clase e instancia de clase (objeto) empaqueta los atributos (datos) y las operaciones (también conocidas como métodos o servicios) que manipulan estos datos. Por lo tanto, en vez de módulos individuales, la menor unidad a probar es la clase u objeto encapsulado. Una clase puede contener un cierto número de operaciones, y una operación particular puede existir como parte de un número de clases diferentes. Por tanto, el significado de prueba de unidad cambia ampliamente frente al concepto general visto antes.

Prueba de Integración
no tiene una estructura de control jerárquica, las estrategias convencionales de integración ascendente y descendente poseen un significado poco relevante en este contexto. Generalmente se pueden encontrar dos estrategias diferentes de pruebas de integración en sistemas. La primera, prueba basada en hilos (o threads), integra el conjunto de clases necesario para responder a una entrada o evento del sistema. Cada hilo se integra y prueba individualmente. El segundo enfoque para la integración, prueba basada en el uso.
Concretamente, se pueden realizar los siguientes pasos para generar casos de prueba a partir de un diagrama de secuencias:
1.       Definir el conjunto de secuencias de mensajes a partir del diagrama de secuencia. Cada secuencia ha de comenzar con un mensaje m sin predecesor (habitualmente, un mensaje enviado al sistema por un actor), y estará formada por el conjunto de mensajes cuya ejecución dispara m.
2.       Analizar sub-secuencias de mensajes a partir de posibles caminos condicionales en los diagramas de secuencia.
3.       Identificar los casos de prueba que se han de introducir al sistema para que se ejecuten las secuencias de mensajes anteriores, en función de los métodos y las clases afectadas por la secuencia.

Prueba de Sistema
En el nivel de prueba del sistema, los detalles de las conexiones entre clases no afectan. El software debe integrarse con los componentes hardware correspondientes y se ha de comprobar el funcionamiento del sistema completo acorde a los requisitos. Como en el caso del software convencional, la validación del software se centra en las acciones visibles del usuario y las salidas del sistema reconocibles por éste. Para asistir en la determinación de casos de prueba de sistema, el ejecutor de la prueba debe basarse en los casos de uso que forman parte del modelo de análisis.

Prueba de Aceptación

La prueba de aceptación en un sistema es semejante a la prueba de aceptación en un software tradicional. El motivo es que el objetivo de este tipo de prueba es comprobar si el cliente está satisfecho con el producto desarrollado y si este producto cumple con sus expectativas, en términos de los errores que genera y de la funcionalidad que suministra. Al igual que las pruebas convencionales serán los clientes quienes realicen estas pruebas y suministren los casos de prueba correspondientes.
Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como desarrollo de software o producción de software (Bohem, 1976).
La ingeniería de software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).
La ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación, y mantenimiento del software.
Esta disciplina trasciende la actividad de programación, que es el pilar fundamental a la hora de crear una aplicación. El ingeniero de software se encarga de toda la gestión del proyecto para que éste se pueda desarrollar en un plazo determinado y con el presupuesto previsto.
La ingeniería de software, por lo tanto, incluye el análisis previo de la situación, el diseño del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto funcionamiento y la implementación del sistema.