Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 8 vistas

    Preguntas Técnicas

    Cargado por

    siemensromo
    El documento presenta información sobre conceptos y metodologías relacionadas con pruebas de software como pruebas unitarias, de sistema, de aceptación, funcionales y no funcionales. También define términos como caso de uso, historia de usuario, definición de hecho y gestor de pruebas.

    Copyright:

    © All Rights Reserved
    Descargue como DOCX, PDF, TXT o lea en línea desde Scribd

    Preguntas Técnicas

    Cargado por

    siemensromo
    8 vistas7 páginas
    El documento presenta información sobre conceptos y metodologías relacionadas con pruebas de software como pruebas unitarias, de sistema, de aceptación, funcionales y no funcionales. También define términos como caso de uso, historia de usuario, definición de hecho y gestor de pruebas.

    Descripción original:

    Para entrevistas

    Título original

    Preguntas técnicas

    Derechos de autor

    © © All Rights Reserved

    Formatos disponibles

    DOCX, PDF, TXT o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    El documento presenta información sobre conceptos y metodologías relacionadas con pruebas de software como pruebas unitarias, de sistema, de aceptación, funcionales y no funcionales. También define términos como caso de uso, historia de usuario, definición de hecho y gestor de pruebas.

    Copyright:

    © All Rights Reserved
    Descargue como DOCX, PDF, TXT o lea en línea desde Scribd
    Descargar como docx, pdf o txt
    8 vistas7 páginas

    Preguntas Técnicas

    Cargado por

    siemensromo
    El documento presenta información sobre conceptos y metodologías relacionadas con pruebas de software como pruebas unitarias, de sistema, de aceptación, funcionales y no funcionales. También define términos como caso de uso, historia de usuario, definición de hecho y gestor de pruebas.

    Copyright:

    © All Rights Reserved
    Descargue como DOCX, PDF, TXT o lea en línea desde Scribd
    Descargar como docx, pdf o txt
    Está en la página 1de 7

    SE REPORTA, EL LIDER TECNICO LO VE SI NO ES RECHAZADO O SE PONE EN HOLD O SE

    ASIGNA A UN DEVELOPER O SE DIFIERE

    ERROR: fallo humano DEFECTO = representación de la falla

    AZURE, SELENIUM, JMETER

    JIRA, PYTHON, SQL, POSTMAN

    PROXYMAN, XCODE, ANDROID, KANBAN

    PROXYMAN, XCODE, ANDROID STUDIO, SQL SELENIUM


    1. PRUEBAS UNITARIAS :

    - NO DEPENDER DE OTRAS PRUEBAS UNITARIAS.


    - QUE CADA COMPONENTE DE UN PROGRAMA FUNCIONE AISLADAMENTE. (BASE
    - NO DEPENDER DE FACTORES EXTERNOS (o sea que se puedan ejecutar en la
    computadora, la de tu compañero, etc.)
    - DEBEN DE SER AUTOMATIZABLES.
    - DEBEN DE SER RÁPIDAS (en la etapa de preparación y la etapa de comprobación)
    - DEBEN SER MANTENIBLES (reescritas)

    No deben depender de otras pruebas.


    No deben depender de otras funciones como bases de Datos.
    Pruebas rápidas, automatizables.

    2. PRUEBAS DE SISTEMA:
    Nos centramos en el COMPORTAMIENTO DEL SISTEMA aquí se hacen pruebas
    funcionales y las no funcionales (rendimiento, seguridad, usabilidad)

    3. PRUEBAS DE ACEPTACIÓN:

    Se centran en medir las capacidades y comportamientos de todo el sistema la


    responsabilidad recae en los usuarios finales. Pruebas ALFA y BETA

    caso de uso: son las instrucciones para llevar a cabo un proceso a nivel funcional.

    historia de usuario: son los requerimientos técnicos.

    DEFINITION OF DONE: criterio de aceptación en el que se define qué requisitos debe de cumplir
    las historias de usuario para darlas por finalizadas. Es un criterio para todas las historias y
    básicamente dice algo así como independientemente de todo lo que se haya hecho, con que debe
    de cumplir para que haya quedado muy bien! Y este criterio aplica para todas las historias de
    usuario.

    GESTOR DE PRUEBAS: es un tablero donde se escriben los flujos de ciertas historias de usuario en
    el que se hace digamos un checklist a cada paso del flujo para que cualquier miembro del equipo o
    desarrollador tenga conocimiento.

    * MENSAJESA TRAVEZ DEL FORMATO ESTANDAR ISO 8583 = mensajes emitidos de tarjetas de
    crédito o SISTEMA QUE INTERCAMBIA TRANSACCIONES ELECTRÓNICAS.

    SMOKE TEST: = prueba que se hace sin un scrpit o planeamineto previo “son pruebas rápidas para
    verificar la funcionalidad (flujo correcto o happy path)

    CREACIÓN DE CASOS DE PRUEBA: ya se puede determinar a qué tipos de prueba es candidato el


    desarrollo. Ejem. en la última empresa el cliente quería que en la THANK U PAGE…

    ¿cómo haces para diseñar un caso de prueba? Entendiendo el requerimiento por parte de
    dirección… al finalizar las pruebas se tienen debidamente que documentar los casos de éxito así
    como los bugs.

    Se mandaban parámetros al desarrollo implementado para validar la respuesta de esa

    ¿CÓMO HACIAS TUS PRUEBAS DE CARGA Y ESTRÉS?

    Se revisaba la respuesta de lo que se probaba. Generalmente se prueban mico servicios.

    Con la herramienta de jmeter se hacían las pruebas a microservicios y lo que hacíamos era
    meter el número de hilos7treads que serían los usuarios, se establecía el tiempo de carga
    y los loops o ciclos. Se envían cientos de peticiones para probar las robustez y límites del
    código.

    ¿CÓMO SE REPORTA UN BUG?

    - Historia de usuario.
    - Ambiente.
    - Tipo de usuario.
    - El path

    Se crea el bug a la tarea que estas ligando y se asigna al desarrollador (esto es DOCUMENTAR
    EN AZURE)
    - Se vuelve a probar porque quizás sea una intermitencia.
    - Ese microservicio se prueba en postman, XCODE, Android, etc. Para ver que arroja el
    RESPONSE; a veces no hay nada malo.

    1. Se prueba dos, tres veces INTERMITENCIA


    2. Se envía un mensaje a dev para ver si no ha sido reportado.
    3. Se prueba ese microservicio en postman para ver que arroja
    4. Se documenta todo el ambiente, la historia de usuario, TIPO DE USUARIO Y EL PATH
    EXACTO para¿PARA QUÉ SIRVE POSTMAN?

    Para hacer peticiones a micro servicios.

    Se checaba el requerimiento petición get en caso de que fuera put o post, se le enviaban los
    parámetros y se validaba que la respuesta fuera la esperada un 200.

    Se revisaba el micoservicio o url a la que se iba a apuntar y en caso de que fuera una petición put o
    post se mandaban los parámetros y se validaba la respuesta del micro servicio. Se validaban tanto
    con parámetros correctos y erróneos.

    ¿PARA QUE SIRVE PROXYMAN?

    Para peticiones a micro servicios con emuladores generalmente de aplicaciones.

    ¿Cómo USABAS PROXYMAN? Validaba todos los micoservicios de los flujos que se realizaban en el
    front. Revisaba el body de la peticón y el body del response, así como la URL del microservicio.

    ¿CÓMO REALIZABAS TUS ESTIMACIONES DE TIEMPO?

    Y dependiendo el número y la dificultad de los requerimientos se puede daba una estimación.

    ¿CÓMO REALIZABAS TU MATRIZ DE CASOS DE PRUEBAS?

    De acuerdo los requiemiento estudiado previamnete se reaiza una matriz con los diferrentes casos
    de prueba que se le pueden realizar al desarrollo. ejem. se hací todo un flujo con el USUARIO
    cliente

    Una vez entendido el requerimiento por parte de dirección ya se podía determinar a qué tipo de
    pruebas era candidato el desarrollo
    ¿CÓMO HACIAS TUS PRUEBAS DE REGRESÍON?

    De acuerdo a lo que ya está implementado se vuelve a probar el flujo completo de inicio a fin casi
    casi desde descargar la app hasta comprar el articulo.

    DE ACUERDO A LO QUE YA ESTABA IMPLEMENTADO SE VUELVE A PROBAR EL FLUJO COMPLETE DE


    INCIO A FIN BÁSICAMENTE DESDE DESCARGAR LA APP

    ¿CÓMO HACIAS TUS PRUEBAS EN APLICACIONES MOBILES?

    1. Se lee el requerimiento.
    2. Se abre el emulador Android o ios, y se hace el flujo para llegar a la funcionalidad o al
    microservicio que se va a probar.

    Hacíamos el flujo requerido en el front para después el verificar el back en Proxyman.

    VALIDABAMOS EL BODY DEL REQUEST Y RESPONSE

    Se lee el requerimiento, se abre el emulador y se hace el flujo PARA LLEGAR A LA FUNCIONALIDAD


    DESEADA O AL MICROSERVICIO A PROBAR. Es decir se hace el flujo en el Front para despúes
    verificar que responde el back.

    ¿Qué SON LAS PRUEBAS RECORD AND PLAY Y COMO SE HACEN?

    Con una extensión de Chrome hacia mi flujo introduciendo los valores, los guarda y lo reproducía.

    ¿Qué SON LAS PRUEBAS UNITARIAS?

    Las pruebas unitarias se hacen para probar de manera aislada un componente de un desarrollo
    para garantizar su funcionamiento de manera otra vez <aislada>.

    ¿Qué SON LAS PRUEBAS DE INTERGRACIÓN?


    Las pruebas de integración se hacen para probar todo el flujo desde inició de sesión hasta la
    página de gracias por tu compra.

    PRUEBAS FUNCIONALES.

    Son las pruebas que se hacen a los desarrollos para probar que su correcta funcionalidad ejem.
    que hagan lo que se suponen que deben de hacer, que no tengan errores (bugs), que respondan
    en un tiempo adecuado.

    PRUEBAS NO FUNCIONALES.

    Son las pruebas que se hacen a las partes del desarrollo que no implican funcionalidades perse
    tales como el look and feel diseño de la página.

    4. Las Pruebas UNITARIAS deben:

    - NO DEPENDER DE OTRAS PRUEBAS UNITARIAS.


    - QUE CADA COMPONENTE DE UN PROGRAMA FUNCIONE AISLADAMENTE. (BASE
    DE DATOS O UNA LLAMADA A UNA API WEB ejem: verificar una lógica donde haces
    un cálculo de impuestos)
    - NO DEPENDER DE FACTORES EXTERNOS (o sea que se puedan ejecutar en la
    computadora, la de tu compañero, etc.)
    - SE PRUEBA LA UNIDAD MÍNIMA DE UNA FUNCIÓN (método y operaciones)
    - DEBEN DE SER AUTOMATIZABLES.
    - DEBEN DE SER RÁPIDAS (en la etapa de preparación y la etapa de comprobación)
    - DEBEN SER MANTENIBLES (reescritas)

    5. PRUEBAS DE SISTEMA
    Nos centramos en el comportamiento del sistema aquí se hacen pruebas funcionales y
    las no funcionales (rendimiento, seguridad, usabilidad)
    6. PRUEBAS DE ACEPTACIÓN
    Se centran en medir las capacidades y comportamientos de todo el sistema la
    responsabilidad recae en los usuarios finales. Pruebas ALFAS y BETAS
    7. PRUEBAS DE REGRESIÓN:
    Las pruebas de regresión son para observa sí la solución de un defecto no haya afectado
    ninguna otra funcionalidad.
    GESTOR DE PRUEBAS.

    Es una interfaz donde se pueden configurar las pruebas a realizar.

    AZURE DeVops
    1. ¿QUÉ ES? Es un tablero en el cuál se lleva el registro y de las historias de usuario, tareas,
    impedimentos y bugs así como la documentación y lo he manejado con la metodología
    SCRUM.

    SCRUM
    A grandes rasgos y de manera simple en SCRUM se van entregando poco a poco partes del
    desarrollo y hay equipos especializados para cada tarea.

    55555

    También podría gustarte