No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Tipos de pruebas

13/29
Recursos

Necesitamos tener otra clasificación adicional. En los niveles sabemos la profundidad de las pruebas, pero en los tipos independientemente de su profundidad son las técnicas que vamos a usar para encontrar los defectos.

Pruebas funcionales: Cómo funciona un sistema, qué debe estar haciendo, cómo está interactuando el usuario con él.

Pruebas no-funcionales: El usuario puede estar experimentando otro tipo de cosas que aún funcionando puede tener la sensación de lentitud, falta de legibilidad o claridad. Esas características de usabilidad están asociadas a estas pruebas.

Pruebas estructurales: Tienen que ver con la tecnología y el stack usado para construir nuestro producto. Nos tenemos que asegurarnos que nuestra base de datos o servidor funcionen de la manera correcta. Son conocidas como pruebas de caja blanca.

Prueba de manejo de cambios: Es probar nuevamente un componente ya probado para verificar que no ha sido impactado por actualizaciones.

Aportes 57

Preguntas 5

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Cuando estuve haciendo pruebas de videojuegos lo que hacía era poner planillas de excel, cada pestaña era un área/nivel del juego, e iba haciendo una lista por dónde estaba y haciendo un pequeño informe de la conducta del juego. Cada vez que encontraba un bug ponía el ID para que sea más fácil de encontrarlo.

Diferencia entre caja blanca, gris y negra
Aunque no se menciono a profundidad en esta clase, voy a explicar brevemente que significan:

  • Caja blanca/transparente: es cuando probamos el sistema viendo como funciona por dentro. Por ejemplo, al tener muchos datos en una base de datos que nosotros conocemos de ante mano y hacer pruebas con esos datos.
  • Caja negra: tiene que ver con hacer pruebas con datos, en este caso que no sabemos previamente. Aquí puede que descubramos un bug al no saber el tipo de datos que se podría ingresar.
  • Caja gris: Una combinación de ambas cajas.

A diferencia de la clasificación de los niveles, aquí se busca es clasificar la técnica usada para probar, estas son:

FUNCIONALES: se busca probar el que debe hacer el sistema y que cumpla con las funciones definidas en los requerimientos

NO FUNCIONALES: se busca probar el como funciona el sistema (rendimiento , usabilidad, consumo de datos, etc), esto definido en los requerimientos no funcionales

ESTRUCTURALES: buscan probar la infraestructura del sistema , es decir probar servidores, bases de datos, etc; en termino de estrés.

MANEJO DE CAMBIOS: buscan probar que tanto cambio el componente o el sistema de manera histórica y en que manera se genero el error

Tras haber hecho los cursos de arquitectura de Software me ayuda a entender mucho mejor todo esto, de forma conceptual!

  1. Pruebas funcionales son aquellas que validan el comportamiento del sistema, a su vez tienen subtipos dependiendo de lo que validan:

    • Unitarias: Validación de piezas individuales.
    • De integración: Validación de interacción entre componentes.
    • Aceptación: Pruebas de usuario.
    • Regresión: Las conocidas como pruebas de no afectación.
  2. Pruebas no funcionales validan aspectos que no están relacionados directamente a la funcionalidad sino a otros factores.

    • De seguridad: Hacking ético.
    • De rendimiento: El software responde ante una determinada carga.
    • De usabilidad: UX.
    • De accesibilidad: Visualización y empatía con todos los usuarios.
  3. Pruebas estructurales validan la tecnología y el stack

  4. Pruebas para manejo de cambios verifican que en las actualizaciones no hay impacto.

Las pruebas de caja negra prueban el funcionamiento sin entender el comportamiento interno, mientras que en las de caja blanca de comprende a nivel técnico como funcionan las piezas de software.

Ejemplo

Caja negra: Probar que se carga una imagen al dar clic en el botón.

Caja blanca: Probar que el componente button abre el explorador de archivos y solo deja cargar imagenes de tipo jpg.

Apuntes:

Tipos de Pruebas de Software

Cuando hablamos de tipos de pruebas, nos estamos refiriendo al grupo de actividades específicas que vamos a realizar, esto basado en objetivos.

Pruebas Funcionales

Se entiende como las funcionalidades del sistema como “lo que el sistema hace”.

Pruebas no Funcionales

El objetivo de es aes probar “cómo funciona el sistema”.

Pruebas Estructurales

Para poder llevar a cabo estas pruebas, normalmente el tester debe tener conocimientos acerca de la tecnología y el stack que se está empleando. Conocida como pruebas de caja blanca.

Pruebas de Manejo de Cambios

Es probar nuevamente un componente ya probado para verificar que no ha sido impactado por actualizaciones.

¿Cómo organizo mis pruebas? Hago uso de herramientas como Confluence y el sistema de comentarios de Jira, el cual utilizamos para darle seguimiento a las tareas de cada uno de los proyectos, siempre reviso lo que se espera con ese nuevo feature y que exista una descripción clara, para poder definir el alcance y estrategia de las pruebas; como mencioné siempre todo queda documentado para dejar evidencia en caso de que se esté o no cumpliendo con uno o varios de los puntos que se señalaron para aprobar la nueva característica.

Pruebas Estructurales : Pruebas de CAJA BLANCA
Pruebas Funcionales y NO Funcionales : Pruebas de CAJA NEGRA

Funcionales:

  • Pruebas de Componentes
  • Pruebas al código
  • Pruebas de humo
    • Revision de puntos criticos al sistema
  • Pruebas de sanidad.
    • Verificar funcionalidades nuevas y su estabilidad

No-Funcionales:

  • Pruebas de Cargas
  • Pruebas de Rendimiento
  • Pruebas de Estrés
  • Pruebas de Resistencia

Estructurales:

  • Algoritmos
  • Funciones
  • Flujos de Control / Condicionales
  • Recursos
  • Metadatos
  • Variables y Constantes
  • Flujos de Datos

Manejo de Cambios o Regresión:

  • Verificar estabilidad del sistema
  • Nuevas funcionalidades
  • Estabilidad e Integridad de los datos

Actualmente no organizo mis pruebas, ya que soy desarrollador y quiero comenzar a escribir mis pruebas hasta ahora 😃

Cuando hacía pruebas de firmware, los tipos de prueba que teníamos identificados eran:

  • Físicas
  • Equipo
  • Comunicación
  • Funcionales
  • Desempeño
  • Fiabilidad
  • Integración
  • Fallas conocidas
  • No regresión

En mi trabajo organizamos las pruebas de la siguiente manera:

  1. Funcionales, las podemos hacer por cada frontal o por flujo de proceso del modelo de negocio
  2. no funcionales, verificando la velocidad del sistema y validando la experiencia del usuario desde el punto de vista del usuario final que va a manejar el frontal
  3. manejo de cambios, según los BUGS reportados y solucionados se prueba el frontal, el modulo o el flujo de proceso que interactúe con el frontal afectado

Normalmente hacemos pruebas funcionales en gran medida. También hacemos unas pruebas que llamamos pruebas de integración porque verificamos intercambio de información entre sistemas, que la información se guarde dónde debe y como debe, pensaría que pueden entrar en esas de caja blanca que mencionas.
Algunas veces hemos hecho pruebas No Funcionales haciendo Carga y Stress; y también hemos hecho de regresión.

Ejemplos de Pruebas en mi Trabajo * Automation Testing * Regression Testing * Integration Testing * E2E Testing * On-demand Executions
Pruebas de caja blanca: Pruebas estructurales(stack tecnologico) Pruebas de caja negra: Pruebas funcionales y no funcionales Pruebas de manejo de cambios: Pruebas de regresion
  • Pruebas funcionales: ¿Qué debe hacer el sistema?

  • Pruebas no funcionales: ¿Cómo está haciendo el sistema lo que se debe hacer?

  • Pruebas estructurales: ¿Cómo funciona cada componente del sistema entre ellos? Por medio de pruebas de caja blanca.

  • Pruebas de manejo de cambios: El sistema funciona correctamente después de un cambio realizado.

Necesitamos tener otra clasificación adicional. En los niveles sabemos la profundidad de las pruebas, pero en los tipos independientemente de su profundidad son las técnicas que vamos a usar para encontrar los defectos.

Pruebas funcionales
Cómo funciona un sistema, qué debe estar haciendo, cómo está interactuando el usuario con él.

Pruebas no funcionales
El usuario puede estar experimentando otro tipo de cosas que aún funcionando puede tener la sensación de lentitud, falta de legibilidad o claridad. Esas características de usabilidad están asociadas a estas pruebas.

Pruebas estructurales
Tienen que ver con la tecnología y el stack usado para construir nuestro producto. Nos tenemos que asegurarnos que nuestra base de datos o servidor funcionen de la manera correcta. Son conocidas como pruebas de caja blanca.

Prueba de manejo de cambios
Es probar nuevamente un componente ya probado para verificar que no ha sido impactado por actualizaciones.

Estas serian la clasificacion de actividades de cuando se prueba en el Frontend, Backend o la estructura, en base a cambios, nuevas caracteristicas o cuando se estan arreglando defectos

Tipos de pruebas de software: Son el grupo de actividades especificas que vamos a usar para tratar de hallar los defectos.

Tipos de pruebas:

  1. Pruebas funcionales: Buscan responder esta pregunta: ¿Cómo funciona un sistema? Prueban que el sistema funciona.

  2. Pruebas no funcionales: Aquí se engloban las características como la usabilidad. accesibilidad y performance.

  3. Pruebas estructurales: Pruebas de caja blanca, aquí se debe conocer la tecnología y el stack que se este usando para el desarrollo.

  4. Pruebas de manejo de cambios: Se usan para verificar que los nuevos cambios realizados no afecten al flujo del software.

  5. Pruebas estáticas: Son aquellas que se hacen sin necesidad de ejecutar el código. Como puede ser la revisión estática de código.

  6. Pruebas dinámicas: son aquellas en las cuales tengo que ejecutar el software para poder probarlo. Como ejemplo, unas pruebas funcionales, en las que tenemos la aplicación en marcha y accedemos a la misma para realizar una serie de pruebas.

Voy entendiendo de manera mas global el proceso e identificando las necesidades y falencias que tenemos actualmente en el desarrollo de pruebas

Los tipos de pruebas de software se pueden clasificar de acuerdo a diferentes criterios, como la **funcionalidad**, el **nivel de desarrollo** o el **tipo de técnica** utilizada. **Según la funcionalidad**, las pruebas de software se pueden clasificar en: * **Pruebas funcionales:** Se centran en verificar que el software cumpla con los requisitos funcionales especificados. * **Pruebas no funcionales:** Se centran en verificar aspectos del software que no son funcionales, como el rendimiento, la escalabilidad, la seguridad, la usabilidad, etc. **Según el nivel de desarrollo**, las pruebas de software se pueden clasificar en: * **Pruebas unitarias:** Se centran en verificar que los componentes individuales del software funcionen correctamente. * **Pruebas de integración:** Se centran en verificar que los componentes individuales del software interactúen correctamente entre sí. * **Pruebas de sistema:** Se centran en verificar que el sistema como un todo funcione correctamente. * **Pruebas de aceptación:** Se centran en verificar que el sistema cumpla con los requisitos del usuario. **Según el tipo de técnica**, las pruebas de software se pueden clasificar en: * **Pruebas manuales:** Se realizan por un probador humano. * **Pruebas automatizadas:** Se realizan por un software de prueba. * **Pruebas de caja negra:** Se centran en el comportamiento externo del software. * **Pruebas de caja blanca:** Se centran en el funcionamiento interno del software. **Algunos ejemplos de tipos de pruebas de software son:** * **Pruebas de regresión:** Se realizan para verificar que los cambios realizados en el software no han introducido nuevos errores. * **Pruebas de estrés:** Se realizan para verificar que el software puede soportar una carga de trabajo elevada. * **Pruebas de seguridad:** Se realizan para verificar que el software es resistente a ataques maliciosos. * **Pruebas de usabilidad:** Se realizan para verificar que el software es fácil de usar. **La elección del tipo de pruebas de software a realizar depende de varios factores, como los requisitos del software, el presupuesto y el tiempo disponible.** A continuación se presenta una descripción más detallada de cada tipo de pruebas de software: **Pruebas funcionales** Las pruebas funcionales se centran en verificar que el software cumpla con los requisitos funcionales especificados. Los requisitos funcionales son las funciones que el software debe realizar. Las pruebas funcionales se pueden clasificar en: * **Pruebas de caja negra:** Se centran en el comportamiento externo del software. El probador no tiene conocimiento del funcionamiento interno del software. * **Pruebas de caja blanca:** Se centran en el funcionamiento interno del software. El probador tiene conocimiento del código fuente del software. **Pruebas no funcionales** Las pruebas no funcionales se centran en verificar aspectos del software que no son funcionales, como el rendimiento, la escalabilidad, la seguridad, la usabilidad, etc. Las pruebas no funcionales se pueden clasificar en: * **Pruebas de rendimiento:** Se centran en verificar que el software puede soportar una carga de trabajo elevada. * **Pruebas de escalabilidad:** Se centran en verificar que el software puede funcionar correctamente a medida que aumenta la carga de trabajo. * **Pruebas de seguridad:** Se centran en verificar que el software es resistente a ataques maliciosos. * **Pruebas de usabilidad:** Se centran en verificar que el software es fácil de usar. **Pruebas de nivel de desarrollo** Las pruebas de nivel de desarrollo se clasifican según el nivel de desarrollo del software en el que se realizan. * **Pruebas unitarias:** Se realizan en los componentes individuales del software. * **Pruebas de integración:** Se realizan en la interacción entre los componentes individuales del software. * **Pruebas de sistema:** Se realizan en el sistema como un todo. * **Pruebas de aceptación:** Se realizan para verificar que el sistema cumple con los requisitos del usuario. **Pruebas manuales y automatizadas** Las pruebas manuales se realizan por un probador humano. Las pruebas automatizadas se realizan por un software de prueba. Las pruebas manuales son más flexibles y pueden adaptarse a cualquier tipo de software. Las pruebas automatizadas son más eficientes y pueden realizarse de forma repetitiva. **Pruebas de caja negra y caja blanca** Las pruebas de caja negra se centran en el comportamiento externo del software. Las pruebas de caja blanca se centran en el funcionamiento interno del software. Las pruebas de caja negra son más fáciles de realizar, pero pueden ser menos efectivas que las pruebas de caja blanca. Las pruebas de caja blanca son más difíciles de realizar, pero pueden ser más efectivas que las pruebas de caja
Generalmente organizo un Excel y en las columnas principales coloco la inofrmación mas impotante acerca del Bug, posterior al realizar reuniones colocolo fecha en una nueva columna y dejo comentarios de que sucedio con ese Bug y si hay alguna fecha estimada la aclaro para tener registro de la vida del Bug.
Las pruebas las hago mediante mensajes de depuracion e investigo si el lenguaje que estoy usando ya tiene integradas herramientas que me ayuden a lanzar mensajes que me sirvan como guia para saber donde falla el software, tambien me esmero en tener un buen manejo de errores, ya que eso facilita todo.
## Los diferente tipos de pruebas ### 1. Pruebas unitarias Las pruebas unitarias son de muy bajo nivel y se realizan cerca de la fuente de la aplicación. Consisten en probar métodos y funciones individuales de las clases, componentes o módulos que usa tu software. En general, las pruebas unitarias son bastante baratas de automatizar y se pueden ejecutar rápidamente mediante un servidor de integración continua. ### 2. Pruebas de integración Las pruebas de integración verifican que los distintos módulos o servicios utilizados por tu aplicación funcionan bien en conjunto. Por ejemplo, se puede probar la interacción con la base de datos o asegurarse de que los microservicios funcionan bien en conjunto y según lo esperado. Estos tipos de pruebas son más costosos de ejecutar, ya que requieren que varias partes de la aplicación estén en marcha. ### 3. Pruebas funcionales Las pruebas funcionales se centran en los requisitos empresariales de una aplicación. Solo verifican el resultado de una acción y no comprueban los estados intermedios del sistema al realizar dicha acción. A veces, se confunden las pruebas de integración con las funcionales, ya que ambas requieren que varios componentes interactúen entre sí. La diferencia es que una prueba de integración puede simplemente verificar que puedes hacer consultas en la base de datos, mientras que una prueba funcional esperaría obtener un valor específico desde la base de datos, según dicten los requisitos del producto. ### 4. Pruebas de extremo a extremo Las pruebas integrales replican el comportamiento de un usuario con el software en un entorno de aplicación completo. Además, verifican que diversos flujos de usuario funcionen según lo previsto, y pueden ser tan sencillos como cargar una página web o iniciar sesión, o mucho más complejos, como la verificación de notificaciones de correo electrónico, pagos en línea, etc. Las pruebas integrales son muy útiles, pero son costosas de llevar a cabo y pueden resultar difíciles de mantener cuando están automatizadas. Se recomienda tener algunas pruebas integrales clave y depender más de pruebas de menor nivel (unitarias y de integración) para poder detectar rápidamente nuevos cambios. ### 5. Pruebas de aceptación Las pruebas de aceptación son pruebas formales que verifican si un sistema satisface los requisitos empresariales. Requieren que se esté ejecutando toda la aplicación durante las pruebas y se centran en replicar las conductas de los usuarios. Sin embargo, también pueden ir más allá y medir el rendimiento del sistema y rechazar cambios si no se han cumplido determinados objetivos. ### 6. Pruebas de rendimiento Las pruebas de rendimiento evalúan el rendimiento de un sistema con una carga de trabajo determinada. Ayudan a medir la fiabilidad, la velocidad, la escalabilidad y la capacidad de respuesta de una aplicación. Por ejemplo, una prueba de rendimiento puede analizar los tiempos de respuesta al ejecutar un gran número de solicitudes, o cómo se comporta el sistema con una cantidad significativa de datos. Puede determinar si una aplicación cumple con los requisitos de rendimiento, localizar cuellos de botella, medir la estabilidad durante los picos de tráfico y mucho más. ### 7. Pruebas de humo Las pruebas de humo son pruebas básicas que sirven para comprobar el funcionamiento básico de la aplicación. Están concebidas para ejecutarse rápidamente, y su objetivo es ofrecerte la seguridad de que las principales funciones de tu sistema funcionan según lo previsto. Las pruebas de humo pueden resultar útiles justo después de realizar una compilación nueva para decidir si se pueden ejecutar o no pruebas más caras, o inmediatamente después de una implementación para asegurarse de que la aplicación funciona correctamente en el entorno que se acaba de implementar.
<h3>Nivel de pruebas</h3>

Es a que tipo de nivel se esta haciendo las pruebas, ya que pueden ser:

  • Comandos
  • Integracion
  • Sistemas
  • Aceptabilidad
<h3>Tipo de pruebas</h3>

Nos dice el tipo de pruebas que se van a realizar sin importar el nivel de pruebas en el que nos encontremos

Como desarrollador back.
Funcionales: Trato de validar y verificar los requerimientos, si se puede pido un ejemplo de como debe ser el requerimiento. Con base en la información recolectada y tiempo, creo unos escenarios de prueba para cubrir la cantidad de escenarios posibles
No funcionales: Herramientas como Jmeter me ayudan a validar tiempo y buscar optimización en los algoritmos.
Prueba de manejo cambio: En ese caso, además de evaluar la nueva funcionalidad, busco evaluar también las pruebas; (TDD) si escribo una prueba y se cambia la funcionalidad, mis pruebas desarrolladas deben fallar.

Se va entendiendo y entrando poco a poco en lo que son las pruebas de caja negra y caja blanca, muy interesante todo hasta el momento

Tipos de Pruebas
Necesitamos tener otra clasificación adicional. En los niveles sabemos la profundidad de las pruebas, pero en los tipos independientemente de su profundidad son las técnicas que vamos a usar para encontrar los defectos.
Pruebas funcionales
Cómo funciona un sistema, qué debe estar haciendo, cómo está interactuando el usuario con él.
Pruebas no-funcionales
El usuario puede estar experimentando otro tipo de cosas que aún funcionando puede tener la sensación de lentitud, falta de legibilidad o claridad. Esas características de usabilidad están asociadas a estas pruebas.
Pruebas estructurales
Tienen que ver con la tecnología y el stack usado para construir nuestro producto. Nos tenemos que asegurarnos que nuestra base de datos o servidor funcionen de la manera correcta. Son conocidas como pruebas de caja blanca.
Prueba de manejo de cambios
Es probar nuevamente un componente ya probado para verificar que no ha sido impactado por actualizaciones.

Pruebas funcionales–lo que el sistema hace
Pruebas no-funcionales–como funciona el sistema
Pruebas estructurales–tienen que ver con la tecnología
Prueba de manejo de cambios–es probar nuevamente un componente ya probado para verificar

Aunque no se discutió en profundidad durante esta clase, voy a explicar brevemente qué significan estos términos: * **Caja Blanca/Transparente**: Se refiere a probar el sistema teniendo conocimiento de su funcionamiento interno. Por ejemplo, cuando realizamos pruebas utilizando datos de una base de datos que ya conocemos de antemano. * **Caja Negra**: En este caso, hacemos pruebas con datos que no conocemos previamente. Este método puede revelar errores ya que desconocemos el tipo de datos que podrían ingresarse. * **Caja Gris**: Una combinación de las pruebas de caja blanca y caja negra.

Importante que se mencionen las pruebas Alfas y Betas, las cuales son criterios importantes a tener en cuenta en la calidad final del producto

APUNTES DE LA CLASE
En los tipos de prueba es donde se aplican las diferentes técnicas empleadas para tratar de encontrar
los defectos. Nos referimos al grupo de actividades especificas a realizar
PRUEBAS FUNCIONALES
Se entiende como las funcionalidades del sistema como “lo que el sistema hace”. Osea que el sistema
funciona.
PRUEBAS NO-FUNCIONALES
Cuando el usuario experimenta actividades diferentes, por ejemplo que esta muy lento. son todas las
caracteristicas de funcionabilidad y usabilidad
PRUEBAS ESTRUCTURALES
tienen que ver más ocn la tecnología y el stack que se esta utilizando con el producto. Es asegurarse
que el servidor y la base de datos funcionen, tambien conocidas como las pruebas de caja blanca por
que se ve que hay dentro de el.
PRUEBAS PARA MANEJO DE CAMBIOS
Se va a probar el software en diferentes capas y situaciones, entonces quizas despues de arreglar
un defecto sea necesario revisar el software y que este funcione de acuerdo a los cambios

En donde yo trabajo utilizamos clickup para coordinar los distintos grupos de trabajo

.

Las pruebas de software son las encargadas de determinar si el producto cumple o no con lo esperado por el cliente, estas se clasifican en pruebas de caja blanca, caja negra, unitarias, de integración, validación y del sistema, y que se documentan mediante casos de prueba.

Las pruebas de software son tan necesarias para garantizar la calidad y que nuestros clientes se sientan satisfechos

organizo la forma de empezar a realizar la pruebas en esta caso puede ser por módulos, una vez realizadas las pruebas e identificar si algo salió mal o esta todo bien se procede a cerrar los casos de pruebas dependiendo.

  1. Pruebas funcionales: Demostrar las acciones del sistema.
  2. Prueba no funcionales: Probar cada funcion del sistema.
  3. Prueba estructurales: Que nuestra base de datos o servidor funcionen de la manera correcta.
  4. Prueba de manejo de cambios: Volver a probar de nuevo algun componente.

eníamos identificados eran:

Físicas
Equipo
Comunicación
Funcionales
Desempeño
Fiabilidad
Integración
Fallas conocidas
No regresión

Interesante

En cuanto a los tipos de prueba considero importante completar los planes y estrategicas con cada una de estos, pues se logran evaluar muchos aspectos deteminantes de la aplicacion o sistema, no es conveniente que solo se ejecuten pruebas de un solo tipo.
De igual forma el testers debe aprender e implmentar estos tipos de prueba no solamente con el objetivo de encontrar un mejor trabajo sino por fortalecer su skill, por mejorar procesos, por generar valor a sus pruebas y cumplirr de forma concreta con sus labor.

Realizamos pruebs funcionales , no funcionales y estructurales, se documentan en monday para listar las tareas a realizar y en el gitlab se llevan los registros de los issues.

Ejecutar los diferentes tipos de prueba en un orden establecido, siempre iniciando tambien por las pruebas de humoo checllist resumido, luego inicar con las FUncionales, No funcionales, en ciertos casos en las manuales no es necesario las de caja blanca y la de manejo de cambios siempre es necesaria para retestear los issues o nuevos componentes realizados que interactuan con partes importantes del negocio

Independientemente de la profundidad de la prueba, aquí nos enfocaremos en las técnicas que vamos a emplear para tratar de encontrar los defectos.

  1. Pruebas funcionales: Se entiende como las Funcionalidades del Sistema como “lo que el sistema hace”.
  2. Pruebas no funcionales: El objetivo de esta es probar “como funciona el sistema”. -> UX y usabilidad, por ejemplo.
  3. Pruebas estructurales: Para poder llevar a cabo estas pruebas, normalmente el tester debe tener conocimientos acerca de la tecnología y el stack que se está empleando.
  4. Pruebas de manejo de cambios: Es probar nuevamente un componente ya probado para verificar que no ha sido impactado por actualizaciones.

Necesitamos tener otra clasificación adicional. En los niveles sabemos la profundidad de las pruebas, pero en los tipos independientemente de su profundidad son las técnicas que vamos a usar para encontrar los defectos.

Pruebas funcionales: Cómo funciona un sistema, qué debe estar haciendo, cómo está interactuando el usuario con él.

Pruebas no-funcionales: El usuario puede estar experimentando otro tipo de cosas que aún funcionando puede tener la sensación de lentitud, falta de legibilidad o claridad. Esas características de usabilidad están asociadas a estas pruebas.

Pruebas estructurales: Tienen que ver con la tecnología y el stack usado para construir nuestro producto. Nos tenemos que asegurarnos que nuestra base de datos o servidor funcionen de la manera correcta. Son conocidas como pruebas de caja blanca.

Prueba de manejo de cambios: Es probar nuevamente un componente ya probado para verificar que no ha sido impactado por actualizaciones.

Necesitamos tener otra clasificación adicional. En los niveles sabemos la profundidad de las pruebas, pero en los tipos independientemente de su profundidad son las técnicas que vamos a usar para encontrar los defectos.

Pruebas funcionales: Cómo funciona un sistema, qué debe estar haciendo, cómo está interactuando el usuario con él.

Pruebas no-funcionales: El usuario puede estar experimentando otro tipo de cosas que aún funcionando puede tener la sensación de lentitud, falta de legibilidad o claridad. Esas características de usabilidad están asociadas a estas pruebas.

Pruebas estructurales: Tienen que ver con la tecnología y el stack usado para construir nuestro producto. Nos tenemos que asegurarnos que nuestra base de datos o servidor funcionen de la manera correcta. Son conocidas como pruebas de caja blanca.

Prueba de manejo de cambios: Es probar nuevamente un componente ya probado para verificar que no ha sido impactado por actualizaciones.

Tipos de pruebas de software
Grupo de actividades a realizar basado en objetivos

  • Pruebas funcionales: lo que el sistema hace.
  • Pruebas no-funcionales: Como funciona el sistema
  • Pruebas estructurales: acerca de la tecnología y el stack
  • Pruebas para manejo de cambios: Probar nuevamente componentes y verificar que siguen funcionando después de actualizaciones

Resumen
Tipos de pruebas:
1 pruebas funcionales:como funciona el sistema,que debe estar haciendo, lo que el sistema hace. Conocidas como pruebas de caja negra.
2 pruebas no funcionales: usabilidad, accesibilidad(usuario que no ve muy bien los datos). Conocidas como pruebas de caja negra.
3 pruebas estructurales: conocimiento acerca de la tecnología. Conocidas como pruebas de caja blanca.
4 pruebas de manejo de cambios: es probar nuevamente un componente ya probado para verificar que no ha sido afectado (pruebas de regresión).

Para más información, recomiendo este artículo en la Wikipedia

A seguir aprendiendo…

La forma como organizaba mis pruebas eran funcionales de cómo funcionaba el sistema. Cuando necesitaba hacer pruebas no-funcionales las solicitaba con un equipo especial que se encargaba de eso e incluían las pruebas de seguridad.
En cuanto a las pruebas de manejo de cambios lo hacía con las pruebas de regresión después de certificar un incidente o un cambio importante dentro de un sistema.

Tipo de pruebas
Técnicas que vamos a usar para encontrar defectos
Grupo de actividades específicas que vamos a usar (objetivos)

  • Funcionales: “Lo que el sistema hace” (negra)
  • No Funcionales: “Como funciona el sistema” (negra)
  • Pruebas estructurales (caja blanca): Tecnología / Stack del producto
  • Manejo de cambios: Regresión, probar un componente de nuevo después de actualizarlo

Tengo una duda, para convertirse en tester jr. es necesario tener conocimientos de todas las áreas, ej. programación, diseño, etc? también, cuales serían los pasos a seguir cuando te entregan un producto para hacerle tester, es decir, cuáles son los tests iniciales y así?

Tipos de pruebas
Los tipos de pruebas los podemos clasificar en:

  • Funcionales: tiene que ver con que el sistema funcione
  • No funcionales: es todo lo que no tiene que ver con la funcionalidad del sistema, ya sea el diseño, la aceptabilidad, el performance, etc.
  • Estructurados: tiene que ver con el stack que estamos usando (bases de datos, lenguaje de programación, etc.)
  • De cambio: tiene que ver el hacer cambios y que todo funcione de manera normal