Test
SQA
Este test tiene tipos de pregunta que se abren en el reproductor de siempre.
Preguntas del test (100)
1[blank_start]Gestión de Calidad[blank_end] es la disciplina que se encarga de hacer el seguimiento de la calidad del producto en desarrollo, de los procedimientos utilizados y el proceso seguido para tal desarrollo.
- AGestión de Calidad
2El propósito de la [blank_start]Gestión de Calidad[blank_end] es:
Realizar el seguimiento y control de la calidad del sistema en desarrollo.
Realizar el seguimiento y control de la calidad del proceso y los procedimientos seguidos durante un proyecto.
Indicar que acciones correctivas deben tomarse en caso de encontrar inconsistencias o incumplimientos de la calidad.
Asegurar que el sistema desarrollado cumple con determinadas propiedades de calidad preestablecidas.- AGestión de Calidad
3[blank_start]Gestión de la Calidad del Proyecto[blank_end] incluye los procesos y actividades de la organización ejecuntante que determinan responsabilidades, objetivos y políticas de calidad a fin de que el proyecto satisfaga las necesidades por las cuales fue emprendido. Implementa el sistema de gestión de calidad por medio de políticas y procedimientos, con actividades de mejora continua de los procesos llevados a cabo durante todo el proyecto, según corresponda.
- AGestión de la Calidad del Proyecto
4[blank_start]Responsable de SQA[blank_end] es responsable de asegurar la calidad de los productos generados en el proyecto y del proceso utilizado.
- AResponsable de SQA
5Para que el [blank_start]responsable de SQA[blank_end] pueda asegurar la calidad, debe revisar la calidad de los entregables de planificación del proyecto y los entregables de valoración del proyecto
- Aresponsable de SQA
6[blank_start]Responsable de SQA[blank_end] revisa el nivel de apego al modelo de proceso de desarrollo de software y a los planes de Verificación, Gestión de Proyecto y Gestión de Calidad, documentando las desviaciones encontradas.
- AResponsable de SQA
7[blank_start]Responsable de SQA[blank_end] debe conocer los conceptos y técnicas de Gestión de Calidad del Software.
- AResponsable de SQA
8[blank_start]Responsable de SQA[blank_end] debe identificar las propiedades de calidad que deben cumplir los productos del proyecto.
- AResponsable de SQA
9[blank_start]Responsable de SQA[blank_end] debe centralizar y revisar las entregas que se realizan durante el ciclo de vida del proyecto
- AResponsable de SQA
10[blank_start]Responsable de SQA[blank_end] realiza las Revisiones Técnicas Formales (RTF) con los responsables de los productos a revisar.
- AResponsable de SQA
11[blank_start]Responsable de SQA[blank_end] debe asegurarse de que se desarrollen prototipos para probar y eliminar riesgos técnicos que hagan fracasar el proyecto así como también disminuir la calidad del mismo.
- AResponsable de SQA
12[blank_start]Responsable de SQA[blank_end] debe asegurarse de que se realicen estudios de factibilidad.
- AResponsable de SQA
13[blank_start]Responsable de SQA[blank_end] debe asegurarse de que se realice la actividad de implementación y se haga según los estándares de calidad propuestos.
- AResponsable de SQA
14[blank_start]Responsable de SQA[blank_end] debe evitar el desperdicio de esfuerzo en conjunto con el Administrador y el Arquitecto.
- AResponsable de SQA
15[blank_start]Responsable de SQA[blank_end] debe registrar las métricas de aceptación tomando en cuenta el Documento de Validación con el cliente.
- AResponsable de SQA
16El perfil del rol de SQA
Debe conocer los [blank_start]requerimientos del sistema[blank_end].
Debe conocer los [blank_start]estándares[blank_end] o [blank_start]lineamientos del proyecto[blank_end] para asegurar la calidad.- Arequerimientos del sistema
- Bestándares
- Clineamientos del proyecto
17Actividades que son responsabilidad del rol de [blank_start]SQA[blank_end]:
* Planificar la Calidad
* Revisión Técnica Formal (RTF)
* Revisar las Entregas
* Revisar el Ajuste al Proceso
* Evaluar la calidad de los Productos
* Realizar el Informe Final de Calidad- ASQA
18Entregables que son responsabilidad del rol de [blank_start]SQA[blank_end]
* Plan de Calidad
* Informe de RTF
* Entrega Semanal de SQA
* Informe de Revisión de SQA
* Informe Final de Calidad- ASQA
19Actividades en las que está involucrado el rol de [blank_start]SQA[blank_end]
* Identificar los Requerimientos.
* Especificar los Requerimientos.
* Priorizar los Requerimientos.
* Validar los Requerimientos.
* Validar con Prototipo.
* Definir el Alcance del Sistema.
* Definir la Línea Base del Proyecto
* Planificar el Proyecto
* Describir la Versión
* Planificar la Transición
* Seguimiento de Satisfacción del Clente
* Gestión de Riesgos
* Registrar Esfuerzo
* Auto estudio
* Reunión de Equipo
* Preparar Cierre del Proyecto
* Reunión Conmemorativa- ASQA
20Nota: La disciplina está en singular.
La disciplina [blank_start]Requerimiento[blank_end] hace que participe al Responsable de SQA de las reuniones de levantamiento de requerimientos para que este tenga conocimiento del Alcance del Sistema que se quiere desarrollar y de las propiedades de calidad que el Cliente requiere que se cumplan.- ARequerimiento
21La disciplina [blank_start]Gestión de Proyecto[blank_end] informa de las actividades que se realizarán y los resultados obtenidos referentes a la Gestión de Proyecto.
- AGestión de Proyecto
22La disciplina [blank_start]Verificación[blank_end] informa de las actividades que se realizaron y los resultados obtenidos referentes a la [blank_start]Verificación[blank_end].
- AVerificación
- BVerificación
23La disciplina [blank_start]Gestión de Configuración[blank_end] y [blank_start]Control de Cambios[blank_end] informa de las actividades que se realizarán y los resultados obtenidos referentes a la [blank_start]Gestión de Configuración[blank_end] y [blank_start]Control de Cambios[blank_end].
- AGestión de Configuración
- BControl de Cambios
- CGestión de Configuración
- DControl de Cambios
24La gestión moderna de la calidad complementa la [blank_start]dirección de proyectos[blank_end]
- Adirección de proyectos
25[blank_start]Satisfacción del cliente[blank_end]: Entender, evaluar, definir y gestionar las expectativas, de modo que se cumplan los requisitos del cliente.
- ASatisfacción del cliente
26[blank_start]Satisfacción del cliente[blank_end]: Esto requiere una combinación de conformidad con los requisitos (para asegurar que el proyecto produzca aquello para lo cual fue emprendido) y adecuación para su uso (el producto o servicio debe satisfacer necesidades reales).
- ASatisfacción del cliente
27La gestión moderna de la calidad y la [blank_start]dirección de proyectos[blank_end] reconocen la importancia de:
* La satisfacción del cliente.
* La prevención antes que la inspección.
* La mejora continua.
* La responsabilidad de la dirección.- Adirección de proyectos
28La [blank_start]prevención antes que la inspección[blank_end]: Uno de los preceptos fundamentales de la gestión moderna de la calidad establece que la calidad se planifica, se diseña y se integra (y no se inspecciona). Por lo general, el costo de prevenir errores es mucho menor que el de corregirlos cuando son detectados por una inspección.
- Aprevención antes que la inspección
29La [blank_start]mejora continua[blank_end]: El ciclo planificar-hacer-revisar-actuar es la base para la mejora de la calidad, según la definicion de Shewhart, modificada por Deming. Además, las iniciativas de la mejora de la calidad emprendidas por la organización ejecutante, tales como TQM y Six Sigma, deben mejorar tanto la calidad de la dirección del proeycto, como la del producto del proyecto.
Los modelos de mejora de procesos incluyen Malcom Baldrige OPM3R (Organizational Proyect Managment Maturity Model) y CMMIR (Capability Maturity Model Integration).- Amejora continua
30[blank_start]Responsabilidad de la dirección[blank_end]: El éxito requiere la participación de todos los miembros del equipo del proyecto, pero proporcionar los recursos necesarios para lograr dicho éxito sigue siendo [blank_start]responsabilidad de la dirección[blank_end].
- Aresponsabilidad de la dirección
- BResponsabilidad de la dirección
31[blank_start]Identificar las Propiedades de Calidad[blank_end] Esta actividad tiene como objetivo definir aquellas propiedades que permitan evaluar la calidad, se deben identificar los productos que deben ser evaluados para la calidad, además de definir los criterios para evaluar la calidad de cada producto.
- AIdentificar las Propiedades de Calidad
32Se deben encontrar propiedades de calidad, algunas pueden ser, la facilidad de uso, eficiencia, facilidad de mantenimiento, seguridad, portabilidad, etc. como específicos del sistema a construir.
Para la documentación generada durante el proceso, la calidad estará dada por la adhesión de los mismos estándares y normas definidos.
No solo en las reuniones de requerimientos encontramos propiedades de calidad, debemos buscarlas dentro de los productos del proyecto, por ejemplo las estimaciones del proyecto, el plan del proyecto, especificación de requerimientos, etc.
Es conveniente que se seleccione una lista de preguntas (CheckList) para verificar si la propiedad seleccionada se cumple o no.
Todo estoy hace referencia a: [blank_start]Identificar las Propiedades de Calidad[blank_end]- AIdentificar las Propiedades de Calidad
33[blank_start]Planificar la Calidad[blank_end]: Esta actividad tiene como objetivo realizar la planificación de las actividades relacionadas con la calidad del producto a ser desarrollado.
- APlanificar la Calidad
34Basándose en el documento que se proporciona como base para el Plan de Calidad, el responsable de Calidad debe realizar la planificación de las actividades que se realizarán para asegurar un nivel determinado de calidad del producto a ser desarrollado.
Esto hace referencia a: [blank_start]Planificar la Calidad[blank_end]- APlanificar la Calidad
35[blank_start]Evaluar y Ajustar el Plan de Calidad[blank_end]: Esta actividad tiene como objetivo contrastar la situación real de la calidad contra la planificada en el Plan de Calidad al comienzo del Proyecto y en cada iteración.
- AEvaluar y Ajustar el Plan de Calidad
36Se deben identificar las desviaciones que hayan ocurrido respecto a las actividades planificadas, y realizar las correcciones que sean necesarias tanto a las actividades de Calidad actuales como a la agenda prevista en el Plan de Calidad.
Además se debe sacar mediciones de lo hecho contra lo planificado, ejemplos de estas medidas son:
* Actividades realizadas contra planificadas.
* Número de productos revisados comparados con el plan.
Todo esto hace referencia a: [blank_start]Evaluar y Ajustar el Plan de Calidad[blank_end]- AEvaluar y Ajustar el Plan de Calidad
37[blank_start]Evaluar y Ajustar el Plan de Calidad[blank_end]: Los resultados de esta actividad proveerán una medida de lo acertado de la planificación realizada en el Plan de Calidad, y de las actividades efectivamente realizadas en cada iteración lo cual ser registrado en un documento para cada evaluación realizada. Estos documentos se mantendrán adjuntos al plan de Calidad.
- AEvaluar y Ajustar el Plan de Calidad
38[blank_start]Revisión Técnica Formal[blank_end]: El objetivo de esta actividad es descubrir errores en la función, la lógica, la implementación de cualquier producto del software, verificar que satisface sus especificaciones, que se ajusta a los estándares establecidos, señalando las posibles desviaciones detectadas.
- ARevisión Técnica Formal
39[blank_start]Revisión Técnica Formal[blank_end]: Es un proceso de revisión riguroso, su objetivo es llegar a detectar lo antes posible, los posibles defectos o desviaciones en los productos que se van generando a lo largo del desarrollo. Esta característica fuerza a que se adopte esta práctica únicamente para productos que son de especial importancia, porque de otro modo podría frenar la marcha del proyecto.
- ARevisión Técnica Formal
40El [blank_start]Responsable de SQA[blank_end] una vez que conoce los productos que se van a revisar formalmente, establece los grupos que van a llevar a cabo las revisiones, convocando a los participantes por adelantado, e informando del objetivo de la revisión, la agenda y las responsabilidades que tendrán asignadas en la revisión. La revisión se centra en una parte especifica (y pequeña) del software total.
- AResponsable de SQA
41Antes de la revisión el [blank_start]Responsable de SQA[blank_end] debe:
* Convocar a la reunión a los involucrados.
* Informar en la convocatoria el material que ellos deben preparar por adelantado.
* La reunión de revisión no puede ser mayor a 2 horas.
* Estudiar el producto a ser revisado, anotando las preguntas y dudas que le surgen para hacer en la reunión.- AResponsable de SQA
42Solo lee esto, y escribe hola aqui debajo:
[blank_start]hola[blank_end]
Durante la reunión:
Se comienza con la explicación de la/s persona/s que hicieron el producto, explicando como se llego� a ese producto.
Se concluye determinando las �áreas de problema y elaborando un informe de revisión formal que incluye las acciones correctivas.
En la reunión se deben seguir las siguientes directrices:
Revisar el producto, no al productor.
Fijar una agenda y mantenerla.
Limitar el debate y las impugnaciones.
Enunciar �áreas de problema, pero no intentar resolver los problemas. Esto debe ser hecho por el que hizo el producto.
Limitar el numero de participantes de 3 a 5.
Usar checklist para el producto a revisar.
Deben estar agendadas en el cronograma de proyecto y en el Plan de Calidad.
Revisar las revisiones anteriores, incluso para encontrar errores en el propio proceso de revisión.- Ahola
43Escribe hola aqui [blank_start]hola[blank_end] y le esto...
Después de la revisión el Responsable de SQA debe:
Elaborar un informe de revisión técnica formal que incluya las acciones correctivas que deben ser tomadas (por los responsables del producto revisado) para solucionar los problemas o desviaciones detectados en la revisión.
El Responsable de SQA debe realizar el seguimiento del producto revisado para saber si las acciones correctivas fueron realizadas.- Ahola
44[blank_start]Revisar las Entregas[blank_end]: Esta actividad tiene como objetivo asegurar que la entrega semanal al Director del Proyecto cumple con los requerimientos mínimos de calidad.
- ARevisar las Entregas
45Se revisa que se cuente con todos los entregables de la semana. En caso de no contar con un entregable, se debe poner en el documento de entrega semanal de SQA que no se va a entregar, y dar una fecha tentativa de entrega.
El Responsable de SQA verifica que los documentos entregados cumplan con los requerimientos mínimos de calidad como por ejemplo, mismo tipo de letra, página, etc.
Todo esto hace referencia a: [blank_start]Revisar las Entregas[blank_end]- ARevisar las Entregas
46[blank_start]Revisar el ajuste al proceso[blank_end]: Esta actividad tiene como objetivo revisar los productos definidos como claves para verificar el cumplimiento de las actividades definidas en el proceso. Con el fin de asegurar la calidad en el producto final del desarrollo, se deben llevar a cabo revisiones sobre los productos durante todo el ciclo de vida del software.
- ARevisar el ajuste al proceso
47Los documentos claves para recoger la información son el Plan de Proyecto, el plan de la iteración y el plan de verificación ya que muestran el proceso globalmente.
Antes de comenzar ,el Responsable de SQA verifica en los informes de revisión previos que todas las desviaciones fueron corregidas, de lo contrario, las no resueltas son puestas para ser evaluadas. Si se detecta alguna desviación en cuanto a sus especificaciones o a los estándares aplicados, y se considera que es necesario realizar alguna modificación, el Responsable de SQA elabora un informe con el que el director del proyecto tomara las medidas que estime convenientes. El informe de revisión elaborado debe ser distribuido a los responsables de las actividades y el Responsable de SQA debe asegurarse de que son conscientes de las desviaciones o discrepancias por �el encontradas.
Todo esto hace referencia a: [blank_start]Revisar el Ajuste al Proceso[blank_end]- ARevisar el Ajuste al Proceso
48[blank_start]Evaluar la Calidad de los Productos[blank_end]: Esta actividad tiene como objetivo asegurar que cualquier imperfección del producto será llevada a la atención de los responsables para su solución, mejorar la calidad del software monitoreando apropiadamente el software y el proceso de desarrollo que lo produce y asegurar completa y obediecnai entre los estándares y procedimientos establecidos.
- AEvaluar la Calidad de los Productos
49Se deben revisar los productos que se definieron como claves para verificar en el plan de SQA. El Responsable de SQA debe verificar que no quede ninguna corrección sin resolver en los informes de revisión previos, si se encuentra alguna no resuelta, debe ser incluida en esta revisión. Se revisan los productos contra los estándares, usando la checklist definida para el producto.
Esto hace referencia a [blank_start]Evaluar la Calidad de los Productos[blank_end]- AEvaluar la Calidad de los Productos
50El responsable de SQA identifica, documenta y sigue la pista de las desviaciones (si las hay), verifica que se hayan hecho las correcciones e informa periódicamente los resultados de su trabajo al director del Proyecto. El informe de revisión elaborado debe ser distribuido a los responsables del producto y el SQA debe asegurarse de que son concientes de desviaciones o discrepancias por el encontradas.
Esto hace referencia a [blank_start]Evaluar la Calidad de los Productos[blank_end]- AEvaluar la Calidad de los Productos
51[blank_start]Realizar el Informe Final de Calidad[blank_end]: contiene un resumen de las actividades de SQA realizadas y sus resultados a lo largo del proyecto.
- ARealizar el Informe Final de Calidad
52[blank_start]Realizar el Informe Final de Calidad[blank_end]: El Responsable de SQA debe hacer esta actividad donde especificarán todas las actividades de Calidad realizadas durante el proyecto y los datos obtenidos. Se totalizarán estos datos para obtener una evaluación de la calidad del producto desarrollado, el sistema en total, el proyecto, y el ajuste al modelo de proceso.
- ARealizar el Informe Final de Calidad
53[blank_start]Testear[blank_end] tiene los siguientes objetivos:
* Encontrar defectos.
* Adquirir confianza acerca del nivel de calidad.
* Proveer información para la toma de decisiones.
* Prevenir errores.- ATestear
54El objetivo principal del testing en el [blank_start]desarrollo de pruebas[blank_end] (pruebas de integración, componentes) es causar muchos errores con el fin de identificar defectos y arreglarlos.
- Adesarrollo de pruebas
55En [blank_start]pruebas de aceptación[blank_end], el objetivo del testing es confirmar que el sistema trabaja como es esperado con el fin de adquirir confianza de que cumple los requerimientos.
- Apruebas de aceptación
56* Hacer pruebas muestra la presencia de defectos
* Hacer pruebas exhaustivas es imposible
* Hacer pruebas anticipadamente
* Agrupación de errores
* Paradoja del pesticida
* Hacer pruebas depende del contexto
* Falacia de ausencia de errores
Esto hace referencia a [blank_start]7 Principios de Control de Calidad[blank_end]- A7 Principios de Control de Calidad
57La parte visible de hacer pruebas es su ejecución. Para ser efectivo y eficiente, los planes de pruebas deben incluir tiempo estimado en planificación de pruebas, diseño de pruebas, preparación de la ejecución y evaluación de resultados.
El [blank_start]Proceso Fundamental de SQA[blank_end] incluye las siguientes etapas:
* Planificación y Control
* Análisis y Diseño
* Implementación y ejecución de pruebas
* Evaluación del criterio de salida y Reportes
* Pruebas finales- AProceso Fundamental de SQA
58[blank_start]Planificación de pruebas[blank_end] es la actividad de definir los objetivos de pruebas y la especificación de actividades de pruebas.
- APlanificación de pruebas
59[blank_start]Control de Pruebas[blank_end] es la actividad de comparar el progreso actual dentro de lo planificado, y reportar estados.
- AControl de Pruebas
60La [blank_start]planificación de pruebas[blank_end] toma en cuenta la retroalimentación del monitoreo y control de actividades.
- Aplanificación de pruebas
61[blank_start]Análisis y Diseño de Pruebas[blank_end] incluye las siguientes tareas:
* Revisar la base de pruebas (requerimientos, nivel de integridad del software, arquitectura, diseño, especificaciones de interfaces).
* Habilidad de realizar pruebas sobre la base de pruebas y objetos en prueba.
* Identificar y priorizar condiciones de prueba basado en análisis de elementos de prueba, la especificación, comportamiento y estructura del software.
* Diseño y priorización de casos de prueba de alto nivel.- AAnálisis y Diseño de Pruebas
62[blank_start]Implementación y ejecución de pruebas[blank_end] incluye las siguientes tareas:
* Finalizar, implementar y priorizar casos de prueba (incluyendo la identificación de datos de prueba).
* Desarrollar y priorizar procedimientos de prueba, opcionalmente escribir scripts de casos de prueba automatizados.
* Crear suites de casos de prueba para su ejecución.
* Verificar que el ambiente de pruebas ha sido correctamente configurado.
* Guardar el resultado de ejecución de pruebas y guardar las veriones de software.
* Comparar resultados actuales con resultados esperados.- AImplementación y ejecución de pruebas
63[blank_start]Evaluar el criterio de salida[blank_end] es la actividad donde se compara la ejecución de pruebas contra la definición de objetivos. Esto debe realizarse en cada nivel de pruebas
- AEvaluar el criterio de salida
64[blank_start]Evaluar el criterio de salida y reportes[blank_end] incluye tareas como:
* Verificar los logs de pruebas contra los criterios especificados en el plan de pruebas.
* Escribir resúmenes de pruebas para clientes.- AEvaluar el criterio de salida y reportes
65[blank_start]Cierre de actividades de pruebas[blank_end]: Generalmente se realizan en hitos del proyecto como cuando un software es liberado, un proyecto de prueba es completado o cancelado, o un hito ha sido alcanzado.
- ACierre de actividades de pruebas
66[blank_start]Cierre de actividades de pruebas[blank_end] incluye las siguientes tareas:
* Verificar qué entregables planificados han sido liberados.
* Documentar la aceptación del sistema.
* Analizar lecciones aprendidas para determinar cambios necesarios en futuras versiones.- ACierre de actividades de pruebas
67* Cada actividad de desarrollo debe tener una actividad de prueba.
* Cada prueba debe tener un objetivo específico en cada nivel.
* El análisis y diseño de una prueba debe empezar junto con la actividad de desarrollo.
* Los testers deben involucrarse en la revisión de documentos tan pronto como se creen borradores dentro del ciclo de vida del software.
Todo esto hace referencia a: [blank_start]Testeo[blank_end] dentro del [blank_start]ciclo de vida del software[blank_end]- ATesteo
- Bciclo de vida del software
68Para cada [blank_start]nivel de test[blank_end], se debe identificar lo siguiente:
* Objetivos genéricos
* Que va a ser testeado
* Defectos y problemas a ser encontrados
* Enfoque específico y responsabilidades- Anivel de test
69[blank_start]Prueba de Componentes[blank_end] También conocidos como (unit test), pruebas unitarias, pruebas de módulo o de programa.
- APrueba de Componentes
70Base de las pruebas de [blank_start]componentes[blank_end]
* Diseño Detallado
* Código- Acomponentes
71Objetos a ser testeados por las pruebas de [blank_start]componentes[blank_end]
* Componentes
* Programas
* Conversión de datos- Acomponentes
72Base de las pruebas de [blank_start]integración[blank_end]
* Diseño de Software
* Arquitectura
* Workflows
* Casos de Uso- Aintegración
73Objetos a ser testeados por las pruebas de [blank_start]integración[blank_end]
* Sub-sistemas de implementación de base de datos
* Infraestructura
* Interfaces- Aintegración
74Base de las pruebas de [blank_start]sistema[blank_end]
* Especificación de requerimientos de software
* Casos de uso
* Especificaciones funcionales
* Reporte de análisis de riesgos- Asistema
75Objetos a ser testeados por las pruebas de [blank_start]sistema[blank_end]
* Sistema, usuarios y manuales de operación
* Configuración del sistema- Asistema
76Base de las pruebas de [blank_start]aceptación[blank_end]
* Requerimientos de usuario
* Requerimientos del sistema
* Casos de uso
* Proceso del negocio
* Reporte de análisis de riesgos- Aaceptación
77Objeto a ser testeados por las pruebas de [blank_start]aceptación[blank_end]
* Procesos de negocio en sistemas integrados
* Procesos operacionales
* Procedimientos de usuario
* Formularios
* Reportes- Aaceptación
78[blank_start]Pruebas de aceptación de usuario[blank_end] Verifica que el sistema pueda ser usado correctamente por usuarios.
- APruebas de aceptación de usuario
79[blank_start]Pruebas de aceptación operaciones[blank_end] La aceptación del sistema por administradores del sistema incluyendo:
* Pruebas de copias de respaldo/ recuperación
* Recuperación de desastres
* Administración de usuarios
* Tareas de mantenimiento
* Tareas de migración y carga de datos
* Verificación periódica de vulnerabilidades de seguridad.- APruebas de aceptación operaciones
80[blank_start]Pruebas alpha[blank_end] son realizadas en el lugar donde se desarrolla el producto pero no por el equipo de desarrollo.
- APruebas alpha
81[blank_start]Pruebas beta[blank_end] o [blank_start]pruebas de campo[blank_end] son realizadas por clientes o potenciales clientes en sus ubicaciones propias
- APruebas beta
- Bpruebas de campo
82Un [blank_start]tipo de test[blank_end] puede estar enfocado a un objetivo en particular, que puede ser cualquiera de los siguientes:
* Una función a ser realizada por el software.
* Una características no funcional de calidad, como la usabilidad o confiabilidad.
* La estructura o arquitectura del sistema.- Atipo de test
83Las [blank_start]Pruebas Funcionales[blank_end] están basadas en funciones y características del sistema.
- APruebas Funcionales
84Las [blank_start]Pruebas no Funcionales[blank_end] se enfocan en aspectos no "operativos" del sistema. Estas incluyen pero no están limitadas a:
* Pruebas de perfomance
* Pruebas de carga
* Pruebas de stress
* Pruebas de usabilidad
* Pruebas de portabilidad
* Entre otras...
Es la prueba de <<como>> funciona el sistema
Estas pruebas pueden ser realizadas en todos los niveles de testeo.- APruebas no Funcionales
85[blank_start]Coverage[blank_end] o [blank_start]cobertura[blank_end] es el grado en que una estructura ha sido ejecutada por una suite de pruebas (test suite), expresado como el porcentaje de elementos cubiertos.
- ACoverage
- Bcobertura
86[blank_start]Prueba de Regresión[blank_end] es la repetición del testeo en un programa que ya ha sido testeado, después de una modificación, a fin de descubrir cualquier defecto introducido o no cubierto por los cambios realizados.
- APrueba de Regresión
87Las [blank_start]pruebas de mantenimiento[blank_end] se realizan en sistemas operacionales, y son ocasionadas por las modificaciones, migraciones o retiro del software.
- Apruebas de mantenimiento
88Un [blank_start]caso de prueba[blank_end] consiste en un conjunto de valores de entrada, prerrequisitos de ejecución, resultados esperados, y condiciones de post-ejecución desarrollados para cubrir determinados objetivos de prueba.
- Acaso de prueba
89[blank_start]IEEE STD 829-1998[blank_end] Es el estándard para la documentación de pruebas de software que describe el contenido de especificación de diseño de pruebas.
- AIEEE STD 829-1998
90[blank_start]Técnica de Diseño[blank_end] tiene como propósito identificar condiciones de prueba, casos de prueba y datos de prueba.
- ATécnica de Diseño
91[blank_start]Técnicas de caja negra[blank_end] Por definición no usan información relacionada a la estructura interna del componente o sistema.
- ATécnicas de caja negra
92[blank_start]Técnicas de caja blanca[blank_end] están basadas en el análisis de la estructura de un componente o sistema.
- ATécnicas de caja blanca
93[blank_start]Pruebas basadas en la experiencia[blank_end] se refiere a la intuición, habilidad del tester y su experiencia con aplicaciones y tecnologías similares.
- APruebas basadas en la experiencia
94[blank_start]Planificación de pruebas[blank_end] puede ser documentada en un plan de pruebas maestro o en planes separados para los niveles de pruebas como ser pruebas de sistema y pruebas de aceptación (IEEE Std829-1998).
Se ven influenciadas por las políticas de pruebas de la organización, el alcance de pruebas, objetivos, riesgos, restricciones.- APlanificación de pruebas
95El objetivo del [blank_start]monitoreo[blank_end] es proveer retroalimentación y visibilidad de las actividades de pruebas. Esta información puede ser colectada manualmente o automáticamente y puede ser usada para verificar el criterio de salida y cobertura.
- Amonitoreo
96Los [blank_start]incidentes[blank_end] tienen el siguiente objetivo:
* Proveer a los desarrolladores y otras personas involucradas retroalimentación sobre el problema, así como aislar y corregir si es necesario.
* Proveer ideas sobre como mejorar el proceso de pruebas.- Aincidentes
97Para reportar un [blank_start]incidente[blank_end] el detalle puede incluir:
* Fecha del error, autor
* Resultados actuales y esperados
* Ambiente
* Descripción del incidente para facilitar su reproducción y resolución, * incluyendo logs, capturas de pantalla
* Severidad del impacto en el sistema
* Prioridad para ser arreglado
* Estado del incidente (abierto, duplicado, arreglado, en espera de ser arreglado, cerrado)
* Conclusiones, recomendaciones y aprobaciones.- Aincidente
98Las [blank_start]herramientas de apoyo de SQA[blank_end] pueden ser usadas para una o mas actividades relacionadas a SQA, y pueden incluir:
Algunas herramientas usadas directamente en pruebas pueden ser:
Administración de pruebas, resultados de pruebas, datos, requerimientos, incidentes, etc., también reportes y monitores de ejecución de pruebas.
Herramientas que son usadas en reconocimiento (exploración), Ej. herramientas que monitorean actividades de ficheros de una aplicación.
Cualquier herramienta que ayude a hacer pruebas(hoja de calculo)- Aherramientas de apoyo de SQA
99el término [blank_start]test frameworks[blank_end] es usado frecuentemente en la industria y tiene por lo menos dos significados:
* Librerías de pruebas reusables y extensibles que pueden ser usadas para construir herramientas de pruebas.
* Un tipo de diseño de pruebas automáticas (ej. Dirigida por datos, dirigida por palabras).- Atest frameworks
100Tipos de herramientas de apoyo al Control de Calidad:
* Herramientas de apoyo a la [blank_start]especificación de pruebas[blank_end]
* Herramientas de apoyo a la [blank_start]ejecución de pruebas[blank_end] y [blank_start]creación de bitácoras[blank_end]
* Herramientas de apoyo al [blank_start]performance[blank_end] y [blank_start]monitoreo[blank_end]- Aespecificación de pruebas
- Bejecución de pruebas
- Ccreación de bitácoras
- Dperformance
- Emonitoreo
Información
- Descripción
- IDI IDI Test sobre SQA, creado por Jorge Andrés Pérez Montás el 30/05/2016.
- Idioma
- Español
- Visitas
- 2
- Etiquetas
- Valoración
- Aún sin valoraciones Valora este test