No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Compra acceso a todo Platzi por 1 a帽o

Antes: $249

Currency
$209/a帽o

Paga en 4 cuotas sin intereses

Paga en 4 cuotas sin intereses
Suscr铆bete

Termina en:

14D
16H
50M
14S

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 52

Preguntas 5

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

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.

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

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

  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.

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

驴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.

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

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 鈥渓o que el sistema hace鈥.

Pruebas no Funcionales

El objetivo de es aes probar 鈥渃贸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.

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

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

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

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.

<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

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鈥搇o que el sistema hace
Pruebas no-funcionales鈥揷omo funciona el sistema
Pruebas estructurales鈥搕ienen que ver con la tecnolog铆a
Prueba de manejo de cambios鈥揺s probar nuevamente un componente ya probado para verificar

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.

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.
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

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 鈥渓o 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

.

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

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.

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

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.

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

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 鈥渓o que el sistema hace鈥.
  2. Pruebas no funcionales: El objetivo de esta es probar 鈥渃omo 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

  • 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.

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: 鈥淟o que el sistema hace鈥 (negra)
  • No Funcionales: 鈥淐omo 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