Menú

¿Qué son las pruebas de software? Más de 100 tutoriales de prueba manuales gratuitos

what is software testing

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Una guía completa de pruebas de software con más de 100 tutoriales de pruebas manuales con definición de pruebas, tipos, métodos y detalles del proceso:

¿Qué son las pruebas de software?

La prueba de software es un proceso de verificación y validación de la funcionalidad de una aplicación para determinar si satisface los requisitos especificados. Es el proceso de encontrar defectos en una aplicación y verificar dónde funciona la aplicación de acuerdo con los requisitos del usuario final.

¿Qué es la prueba manual?

La prueba manual es un proceso en el que se compara el comportamiento de un fragmento de código desarrollado (software, módulo, API, función, etc.) con el comportamiento esperado (requisitos).

Lo que vas a aprender:

Lista de tutoriales de pruebas de software manuales

Esta es la serie más detallada de tutoriales sobre pruebas de software. Repase los temas mencionados en esta serie detenidamente para aprender las técnicas de prueba básicas y avanzadas.

Esta serie de tutoriales enriquecerá su conocimiento y, a su vez, mejorará sus habilidades de prueba.

Practique la capacitación gratuita de pruebas manuales de extremo a extremo en un proyecto en vivo:

Tutorial #1: Conceptos básicos de las pruebas de software manuales
Tutorial #2: Introducción al proyecto en vivo
Tutorial #3: Escritura de escenarios de prueba
Tutorial #4: Escriba un documento de plan de prueba desde cero
Tutorial #5: Redacción de casos de prueba a partir del documento SRS
Tutorial #6: Ejecución de pruebas
Tutorial #7: Seguimiento de errores y aprobación de la prueba
Tutorial #8: Curso de pruebas de software

Ciclo de vida de las pruebas de software:

Tutorial #1: STLC

Web Testing:

Tutorial #1: Pruebas de aplicaciones web
Tutorial #2: Prueba de navegador cruzado

Gestión de casos de prueba:

preguntas y respuestas de la entrevista unix pdf

Tutorial #1: Casos de prueba
Tutorial #2: Ejemplo de plantilla de caso de prueba
Tutorial #3: Matriz de trazabilidad de requisitos (RTM)
Tutorial #4: Cobertura de prueba
Tutorial #5: Gestión de datos de prueba

Gestión de pruebas:

Tutorial #1: Estrategia de prueba
Tutorial #2: Plantilla de plan de prueba
Tutorial #3: Estimación de prueba
Tutorial #4: Herramientas de gestión de pruebas
Tutorial #5: HP ALM Tutorial
Tutorial #6: Jira
Tutorial #7: Tutorial de TestLink

Ensayos técnicos:

Tutorial #1: Prueba de casos de uso
Tutorial #2: Prueba de transición estatal
Tutorial #3: Análisis de valor límite
Tutorial #4: Partición de equivalencia
Tutorial #5: Metodologías de prueba de software
Tutorial #6: Metodología ágil

Gestión de defectos:

Tutorial #1: Ciclo de vida de los errores
Tutorial #2: Informe de errores
Tutorial #3: Prioridad de defectos
Tutorial #4: Tutorial de Bugzilla

Pruebas funcionales

Tutorial #1: Examen de la unidad
Tutorial #2: Pruebas de cordura y humo
Tutorial #3: Pruebas de regresión
Tutorial #4: Prueba del sistema
Tutorial #5: Test de aceptación
Tutorial #6: Pruebas de integración
Tutorial #7: Prueba de aceptación de usuarios de UAT

Pruebas no funcionales:

Tutorial #1: Pruebas no funcionales
Tutorial #2: Pruebas de rendimiento
Tutorial #3: Pruebas de seguridad
Tutorial #4: Pruebas de seguridad de aplicaciones web
Tutorial #5: Pruebas de usabilidad
Tutorial #6: Prueba de compatibilidad
Tutorial #7: Prueba de instalación
Tutorial #8: Prueba de documentación

Tipos de pruebas de software:

Tutorial #1: Tipos de pruebas
Tutorial #2 : Prueba de caja negra
Tutorial #3: Prueba de base de datos
Tutorial #4: Prueba de extremo a extremo
Tutorial #5: Prueba exploratoria
Tutorial #6: Prueba incremental
Tutorial #7: Pruebas de accesibilidad
Tutorial #8: Prueba negativa
Tutorial #9: Pruebas de backend
Tutorial #10: Prueba alfa
Tutorial #11: Prueba Beta
Tutorial #12: Pruebas alfa vs beta
Tutorial #13: Prueba gamma
Tutorial #14: Pruebas de ERP
Tutorial #15: Pruebas estáticas y dinámicas
Tutorial #16: Pruebas ad hoc
Tutorial #17: Pruebas de localización e internacionalización
Tutorial #18: Pruebas de automatización
Tutorial #19: Prueba de caja blanca

Carrera de pruebas de software:

Tutorial #1: Elegir una carrera en pruebas de software
Tutorial #2: Cómo obtener un trabajo de prueba de control de calidad - Guía completa
Tutorial #3: Opciones de carrera para probadores
Tutorial #4: Conmutador de pruebas de software a software
Tutorial #5: Ponga en marcha su carrera de pruebas manuales
Tutorial #6: Lecciones aprendidas durante 10 años en pruebas
Tutorial #7: Sobrevivir y progresar en el campo de pruebas

Preparación de la entrevista:

Tutorial #1: Preparación de CV para control de calidad
Tutorial #2: Preguntas de la entrevista de prueba manual
Tutorial #3: Preguntas de la entrevista sobre pruebas de automatización
Tutorial #4: Preguntas de la entrevista de control de calidad
Tutorial #5: Manejar cualquier entrevista de trabajo
Tutorial #6: Obtenga un trabajo de prueba como un nuevo

Prueba de aplicación de dominio diferente:

Tutorial #1 : Prueba de aplicaciones bancarias
Tutorial #2: Pruebas de aplicaciones de atención médica
Tutorial #3: Prueba de pasarela de pago
Tutorial #4: Prueba del sistema de punto de venta (POS)
Tutorial #5: Pruebas de sitios web de comercio electrónico

Prueba de certificación de control de calidad:

Tutorial #1: Guía de certificación de pruebas de software
Tutorial #2: Guía de certificación CSTE
Tutorial #3: Guía de certificación CSQA
Tutorial #4: Guía ISTQB
Tutorial #5: ISTQB avanzado

Temas de pruebas manuales avanzadas:

Tutorial #1: Complejidad ciclomática
Tutorial #2: Prueba de migración
Tutorial #3: Pruebas en la nube
Tutorial #4: Pruebas ETL
Tutorial #5: Métricas de prueba de software
Tutorial #6: Servicios web

¡Prepárese para echar un vistazo al primer tutorial de esta serie de pruebas manuales!

Introducción a las pruebas de software manuales

La prueba manual es un proceso en el que se compara el comportamiento de un fragmento de código desarrollado (software, módulo, API, función, etc.) con el comportamiento esperado (requisitos).

¿Y cómo sabrá cuál es el comportamiento esperado?

Lo sabrá leyendo o escuchando los requisitos con atención y comprendiéndolos por completo. Recuerde, comprender los requisitos completamente es muy importante.

¿Cuál es la diferencia entre el reenvío de puertos y la activación de puertos?

Piense en usted mismo como un usuario final de lo que va a probar. Después de eso, ya no está obligado al documento de requisitos de software ni a las palabras que contiene. Luego, puede comprender el requisito básico y no solo comparar el comportamiento del sistema con lo que está escrito o dicho, sino también con su propio entendimiento y con lo que no está escrito o dicho.

A veces, puede ser un requisito omitido (requisito incompleto) o un requisito implícito (algo que no necesita una mención separada pero que debe cumplirse), y también debe probarlo.

Además, no es necesario que un requisito esté documentado. Puede muy bien tener conocimiento de la funcionalidad del software o incluso puede adivinar y luego probar un paso a la vez. Generalmente lo llamamos pruebas ad-hoc o pruebas exploratorias.

Echemos un vistazo en profundidad:

Primero, comprendamos el hecho: Ya sea que esté comparando la prueba de una aplicación de software u otra cosa (digamos un vehículo), el concepto sigue siendo el mismo. El enfoque, las herramientas y las prioridades pueden diferir, pero el objetivo principal sigue siendo el MISMO y es SIMPLE, es decir, comparar el comportamiento real con el comportamiento esperado.

En segundo lugar - La prueba es como una actitud o mentalidad que debería provenir de adentro. Las habilidades se pueden aprender, pero te convertirás en un probador exitoso solo cuando tengas algunas cualidades dentro de ti por defecto. Cuando digo que las habilidades de prueba se pueden aprender, me refiero a educación formal y enfocada en torno al proceso de prueba de software.

Pero, ¿cuáles son las cualidades de un probador exitoso? Puede leer sobre ellos en el siguiente enlace:

Léalo aquí => Cualidades de probadores altamente efectivos

Recomiendo encarecidamente leer el artículo anterior antes de continuar con este tutorial. Le ayudará a comparar sus características con las que se esperan en la función de Probador de software.

Para aquellos que no tienen tiempo para leer el artículo, aquí hay una sinopsis:

“Su curiosidad, atención, disciplina, pensamiento lógico, pasión por el trabajo y capacidad para analizar las cosas es muy importante para ser un Tester Destructivo y Exitoso. Funcionó para mí y creo firmemente que también funcionará para usted. Si ya tienes estas cualidades, entonces realmente funcionó para ti también '.

Hemos hablado de los prerrequisitos básicos de convertirse en un probador de software. Ahora entendamos por qué las pruebas manuales han tenido y siempre tendrán su existencia independiente con o sin el crecimiento de las pruebas de automatización.

¿Por qué se requieren pruebas manuales?

¿Sabes qué es lo mejor de ser un Tester, que también un Tester Manual?

Es el hecho de que aquí no puede depender solo del conjunto de habilidades. Tienes que tener / desarrollar y mejorar tu proceso de pensamiento. Esto es algo que realmente no se puede comprar por unos pocos dólares. Tú mismo tienes que trabajar en ello.

Tendras que desarrollar el hábito de hacer preguntas y tendrá que preguntarles cada minuto cuando esté realizando la prueba. La mayoría de las veces debería hacerse estas preguntas a sí mismo que a los demás.

Espero que haya leído el artículo que recomendé en la sección anterior (es decir, las cualidades de los probadores altamente efectivos). Si es así, entonces sabrá que las pruebas se consideran un proceso de pensamiento y el éxito que tendrá como evaluador depende completamente de las cualidades que posee como persona.

Veamos este flujo simple:

  • Haces algo realizar acciones ) mientras lo observa con cierta intención (comparándolo con lo esperado). Ahora tu observación habilidades y disciplina realizar cosas entra en escena aquí.
  • ¡Voila! ¿Qué fue eso? Notaste algo. Lo notaste porque estabas dando perfecto atención a los detalles frente a ti. No lo dejarás ir porque estás curioso . Esto no estaba en tu plan de que suceda algo inesperado / extraño, lo notarás y lo investigarás más a fondo. Pero ahora lo estás haciendo. Puedes dejarlo ir. Pero no debes dejarlo pasar.
  • Estás feliz, averiguaste la causa, los pasos y el escenario. Ahora comunicará esto de manera adecuada y constructiva al equipo de desarrollo y a las demás partes interesadas de su equipo. Puede hacerlo a través de alguna herramienta de seguimiento de defectos o verbalmente, pero debe asegurarse de que está comunicándolo constructivamente .
  • ¡UPS! ¿Y si lo hago de esa manera? ¿Qué sucede si ingreso un entero adecuado como entrada pero con espacios en blanco iniciales? ¿Y si? … ¿Y si? … ¿Y si? No termina fácilmente, no debería terminar fácilmente. Vas a imagina muchas situaciones y escenarios y, de hecho, también se sentirá tentado a realizarlos.

El diagrama que se muestra a continuación representa la vida útil de un probador:

Vida de un probador

Lea esos cuatro puntos mencionados anteriormente una vez más. ¿Notaste que lo mantuve muy breve pero aún destaqué la parte más rica de ser un probador manual? ¿Y notó el resaltado en negrita sobre algunas palabras? Esas son precisamente las cualidades más importantes que necesita un comprobador manual.

Ahora bien, ¿de verdad crees que estos actos pueden ser completamente reemplazados por cualquier otra cosa? Y la tendencia actual de hoy: ¿alguna vez puede ser reemplazada por la automatización?

En SDLC con cualquier metodología de desarrollo, pocas cosas permanecen siempre constantes. Como evaluador, consumirá los requisitos y los convertirá en escenarios de prueba / casos de prueba. Luego, ejecutará esos casos de prueba o los automatizará directamente (sé que algunas empresas lo hacen).

Cuando lo automatizas, tu enfoque es constante, lo que automatiza los pasos escritos.

Volvamos a la parte formal, es decir, ejecutando los casos de prueba escritos manualmente.

Aquí, no solo se enfoca en ejecutar los casos de prueba escritos, sino que también realiza muchas pruebas exploratorias mientras lo hace. ¿Recuerdas, tienes curiosidad? Y te lo imaginarás. Y no podrás resistir, de hecho harás lo que imaginaste.

La imagen que se muestra a continuación muestra cómo se simplifica la escritura de casos de prueba:

Escritura de casos de prueba simplificada

Estoy completando un formulario y he terminado de completar el primer campo. Soy demasiado vago para que el mouse cambie el enfoque al siguiente campo. Pulsé la tecla 'tabulación'. Ya terminé de completar el siguiente y último campo también, ahora necesito hacer clic en el botón Enviar, el enfoque todavía está en el último campo.

Vaya, accidentalmente presioné la tecla 'Enter'. Déjame comprobar lo que pasó. O hay un botón de enviar, voy a hacer doble clic en él. No satisfecho. Hago clic en él varias veces, demasiado rápido.

¿Te diste cuenta? Hay tantas acciones posibles del usuario, tanto intencionadas como no intencionadas.

No logrará escribir todos los casos de prueba que cubren su aplicación bajo prueba al 100%. Esto tiene que suceder de forma exploratoria.

Continuará agregando sus nuevos casos de prueba mientras prueba la aplicación. Estos serán casos de prueba para errores que haya encontrado para los que anteriormente no se había escrito ningún caso de prueba. O, mientras está probando, algo activó su proceso de pensamiento y obtuvo algunos casos de prueba más que le gustaría agregar a su conjunto de casos de prueba y ejecutarlos.

Incluso después de todo esto, no hay garantía de que no haya errores ocultos . El software sin errores es un mito. Solo puede apuntar para llevarlo cerca de Cero, pero eso no puede suceder sin una mente humana que se dirija continuamente a lo mismo, de manera similar, pero no limitada, al proceso de ejemplo que vimos anteriormente.

Al menos a día de hoy, no existe ningún software que piense como una mente humana, observe como un ojo humano, haga preguntas y responda como un humano y luego realice acciones intencionales y no intencionales. Incluso si sucede algo así, ¿qué mente, pensamientos y ojos de quién imitarán? ¿Tuyo o mio? Nosotros, los humanos, tampoco tenemos el mismo derecho. Todos somos diferentes. ¿Entonces?

Necesidad de pruebas manuales cuando la automatización está presente:

Las pruebas de automatización tienen su propia parte de gloria en estos días y tendrán aún más en los próximos años, pero simplemente no pueden reemplazar las pruebas de control de calidad manuales (lea pruebas humanas / exploratorias).

Debes haber oído antes ... ' No automatiza las pruebas, automatiza la verificación '. Esta frase habla mucho sobre dónde se encuentran las pruebas de control de calidad manuales con las pruebas de automatización. Muchos grandes nombres de todo el mundo han escrito y hablado sobre este tema, por lo que no me preocuparé mucho por esto.

La automatización no puede reemplazar las pruebas en humanos porque:

  • Exige los juicios en tiempo de ejecución sobre todo lo que sucede frente a sus ojos (mientras prueba) y, en algunos casos, también detrás de escena.
  • Exige una observación clara y constante.
  • Exige interrogatorio.
  • Exige una investigación.
  • Exige razonamiento.
  • Exige acciones no planificadas según sea necesario durante la prueba.

Las pruebas pueden ser reemplazadas por una herramienta / máquina que será capaz de absorber los detalles, procesarlos, ordenar acciones y ejecutarlas como una mente humana y humana, y todo esto en tiempo de ejecución y en todos los contextos posibles. De nuevo, esta herramienta tiene que ser como todos los seres humanos posibles.

En resumen, las pruebas en humanos no se pueden reemplazar. Tal vez alguna película de ciencia ficción de Hollywood en unos años se parezca a eso, pero en la vida real, no puedo verlo venir durante unos cientos de años, que puedo imaginar. No lo descartaré para siempre porque creo en infinitas posibilidades.

En una nota aparte, incluso si realmente sucede después de unos cientos de años, la imagen que puedo imaginar es la de un mundo aterrador con seguridad. Era de Transformers. :)

= >> Lectura recomendada - Las mejores empresas de servicios de pruebas manuales

¿Cómo se complementa la automatización con las pruebas manuales?

Dije antes y lo vuelvo a decir que la automatización ya no se puede ignorar. En un mundo donde la integración continua, la entrega continua y la implementación continua se están convirtiendo en cosas obligatorias, las pruebas continuas no pueden quedarse inactivas. Tenemos que encontrar formas de hacerlo.

La mayoría de las veces, desplegar más y más mano de obra no ayuda a largo plazo para esta tarea. Por lo tanto, el probador (jefe de pruebas / arquitecto / gerente) tiene que decidir con cautela qué automatizar y qué aún debe hacerse manualmente.

Se está volviendo extremadamente importante tener pruebas / verificaciones muy precisas escritas para que puedan automatizarse sin ninguna desviación de la expectativa original y puedan usarse mientras se retrocede el producto como parte de las 'Pruebas continuas'.

Nota: La palabra continua del término 'Prueba continua' está sujeta a llamadas condicionales y lógicas similares a los otros términos que usamos anteriormente con el mismo prefijo. Continuo en este contexto significa cada vez más a menudo, más rápido que ayer. Si bien tiene sentido, puede significar cada segundo o nano-segundo.

Sin tener una combinación perfecta de Human Testers y verificaciones automatizadas (pruebas con pasos precisos, resultado esperado y criterios de salida de dicha prueba documentados), lograr las Pruebas Continuas es muy difícil y esto, a su vez, hará que la integración, la entrega continua y el despliegue continuo. más difícil.

Usé deliberadamente el término criterios de salida de una prueba anterior. Nuestros trajes de automatización ya no pueden ser similares a los tradicionales. Tenemos que asegurarnos de que si fallan, fallarán rápido. Y para que fallen rápidamente, los criterios de salida también deben automatizarse.

Ejemplo:

Digamos que hay un defecto de bloqueo en el que no puedo iniciar sesión en Facebook.

La funcionalidad de inicio de sesión debe ser su primera verificación automatizada y su paquete de automatización no debe ejecutar la siguiente verificación donde el inicio de sesión es un requisito previo, como publicar un estado. Sabes muy bien que está destinado a fallar. Así que haga que falle más rápido, publique los resultados más rápido para que el defecto se pueda resolver más rápido.

Lo siguiente es nuevamente algo que debes haber escuchado antes: No puede ni debe intentar automatizar todo.

Seleccione casos de prueba que, si se automatizan, se beneficiarán considerablemente. a Human Testers y tiene un buen retorno de la inversión. De hecho, existe una regla general que dice que debe intentar automatizar todos sus casos de prueba de Prioridad 1 y, si es posible, Prioridad 2.

La automatización no es fácil de implementar y requiere mucho tiempo, por lo que se recomienda evitar la automatización de los casos de baja prioridad al menos hasta que haya terminado con los de alta. Seleccionar qué automatizar y centrarse en ello mejora la calidad de la aplicación cuando se utiliza y mantiene de forma continua.

Conclusión

Espero que a estas alturas ya haya entendido por qué y en qué medida se requieren pruebas manuales / humanas para ofrecer productos de calidad y cómo la automatización lo complementa.

Aceptar la importancia de las pruebas manuales de control de calidad y saber por qué es especial es el primer paso para ser un excelente probador manual.

En nuestros próximos tutoriales de pruebas manuales, cubriremos un enfoque genérico para realizar pruebas manuales, cómo coexistirá con la automatización y muchos otros aspectos importantes también.

Estoy seguro de que obtendrá un conocimiento inmenso de las pruebas de software una vez que haya revisado la lista completa de tutoriales de esta serie.

cómo abrir un archivo torrent en mac

Nos encantaría saber de ti. Siéntase libre de expresar sus pensamientos / sugerencias en la sección de comentarios a continuación.

Lectura recomendada

^