1. ¿Qué es Software Testing?
Respuesta:
Software testing es el proceso de evaluar un sistema o aplicación para detectar diferencias entre los resultados esperados y los reales. Su objetivo es identificar defectos, verificar que el software cumple los requisitos y asegurar que funciona correctamente antes de entregarlo a los usuarios.
Objetivos principales:
- Encontrar defectos antes de producción
- Verificar que cumple los requisitos
- Validar que satisface las necesidades del usuario
- Asegurar la calidad del producto
- Reducir riesgos de fallos en producción
2. ¿Cuáles son las Fases del Ciclo de Pruebas de Software?
Respuesta:
El STLC (Software Testing Life Cycle) tiene 6 fases:
1. Análisis de Requisitos
- Revisar y entender los requisitos
- Identificar qué es testeable
- Definir tipos de testing necesarios
2. Planificación del Testing
- Crear estrategia de testing
- Estimar recursos y esfuerzo
- Definir criterios de entrada y salida
3. Diseño de Test Cases
- Escribir casos de prueba detallados
- Preparar datos de prueba
- Crear matriz de trazabilidad
4. Configuración del Ambiente
- Setup del ambiente de testing
- Preparar datos de prueba
- Configurar herramientas necesarias
5. Ejecución de Testing
- Ejecutar test cases
- Reportar bugs encontrados
- Re-testear defectos corregidos
- Realizar regression testing
6. Cierre del Ciclo
- Generar reportes finales
- Analizar métricas
- Documentar lecciones aprendidas
3. ¿Por Qué es Importante el Análisis de Requisitos?
Respuesta:
El análisis de requisitos es crítico porque:
1. Costo de corrección
- Un defecto en requisitos puede costar 100x más corregirlo en producción que en esta fase
- Previene malentendidos costosos
2. Define el alcance
- Clarifica QUÉ testear y qué NO
- Establece criterios de aceptación claros
- Evita desperdicio de esfuerzo
3. Identifica riesgos temprano
- Detecta dependencias
- Señala ambigüedades
- Previene retrabajo
4. Asegura testeabilidad
- Verifica que los requisitos son medibles
- Identifica qué necesitamos para testear
- Define condiciones de éxito
5. Alinea expectativas
- Todo el equipo entiende lo mismo
- Cliente, developers y QA están sincronizados
4. ¿Qué Información Básica Debe Tener un Buen Caso de Prueba?
Respuesta:
Un test case debe incluir:
1. ID único
- Ejemplo: TC_LOGIN_001
2. Título descriptivo
- “Verificar login exitoso con credenciales válidas”
3. Precondiciones
- Usuario registrado: test@example.com
- Password: Test123!
- Sistema en estado inicial
4. Pasos de ejecución
- Ir a /login
- Ingresar email
- Ingresar password
- Click en “Iniciar Sesión”
5. Resultado esperado
- Usuario redirigido a dashboard
- Nombre visible en header
- Sesión activa
6. Datos de prueba
- Credenciales específicas
- URLs
- Valores de entrada
7. Información adicional
- Prioridad (Alta/Media/Baja)
- Tipo (Funcional/Regresión/Smoke)
- Autor y fecha
5. ¿Qué Información Básica Debe Tener un Buen Reporte de Bug?
Respuesta:
Un bug report completo incluye:
1. ID único
- BUG-1234
2. Título claro y específico
- “Login falla cuando email contiene espacios iniciales”
3. Severidad y Prioridad
- Severidad: Alta (no puedes hacer login)
- Prioridad: Alta (funcionalidad crítica)
4. Ambiente
- Browser: Chrome 120
- OS: Windows 11
- URL: https://staging.app.com/login
- Versión: v2.3.1
5. Pasos para reproducir
- Ir a página de login
- Escribir ” test@example.com” (con espacio inicial)
- Escribir password correcto
- Click en “Iniciar Sesión”
6. Resultado actual
- Error: “Credenciales inválidas”
- Usuario no puede acceder
7. Resultado esperado
- Sistema debe eliminar espacios automáticamente
- Login exitoso
8. Evidencia
- Screenshots
- Video de reproducción
- Logs de consola
9. Información adicional
- Frecuencia: Siempre reproducible
- Workaround: Eliminar espacios manualmente
- Impacto: Usuarios no pueden acceder
6. ¿Cuál es el Ciclo de Vida de un Bug?
Respuesta:
El bug pasa por estos estados:
1. New/Open
- QA encuentra y reporta el bug
- Estado inicial
2. Assigned
- Bug asignado a un developer
- En cola para corrección
3. In Progress
- Developer está trabajando en el fix
- Código en desarrollo
4. Fixed/Resolved
- Developer completó el fix
- Código mergeado a rama de testing
- Listo para re-testing
5. Retest
- QA verifica la corrección
- Ejecuta pasos originales
6. Verified/Closed
- QA confirma que el bug está corregido
- Caso cerrado exitosamente
Estados alternativos:
Reopened
- Fix no funcionó
- Bug persiste
- Regresa a “Assigned”
Rejected/Won’t Fix
- No es un bug (comportamiento esperado)
- Demasiado costoso de arreglar
- Prioridad muy baja
Deferred/Postponed
- Se corregirá en versión futura
- No crítico para release actual
Duplicate
- Ya fue reportado anteriormente
- Se cierra referenciando el bug original
7. ¿Qué Tipos de Pruebas Hay?
Respuesta:
Por nivel de testing:
1. Unit Testing
- Testea componentes individuales
- Lo hace el developer
- Ejemplo: Función que suma dos números
2. Integration Testing
- Testea interacción entre módulos
- Ejemplo: Login + Base de datos
3. System Testing
- Testea el sistema completo
- End-to-end
- Ejemplo: Flujo completo de compra
4. Acceptance Testing (UAT)
- Usuario final valida
- Verifica que cumple necesidades del negocio
Por tipo de funcionalidad:
5. Functional Testing
- Verifica funcionalidades según requisitos
- Ejemplo: Botón hace lo que debe
6. Non-Functional Testing
- Performance (velocidad, carga)
- Security (vulnerabilidades)
- Usability (facilidad de uso)
- Compatibility (navegadores, dispositivos)
7. Regression Testing
- Verifica que cambios no rompieron funcionalidades existentes
- Se ejecuta después de cada cambio
8. Smoke Testing
- Verificación básica de build
- “¿Funciona lo fundamental?”
- Se ejecuta primero
9. Sanity Testing
- Verificación rápida de funcionalidad específica
- Después de un bug fix
Por técnica:
10. Black Box Testing
- Sin conocer código interno
- Basado en requisitos
11. White Box Testing
- Con conocimiento del código
- Testea lógica interna
12. Gray Box Testing
- Conocimiento parcial del código
- Combinación de black y white box
Por ejecución:
13. Manual Testing
- Humano ejecuta los tests
14. Automated Testing
- Scripts ejecutan los tests
8. ¿Cuándo se Debería Automatizar un Caso de Prueba?
Respuesta:
Se debe automatizar cuando:
1. Tests repetitivos
- Se ejecutan frecuentemente (10+ veces)
- Regression suite
- Smoke tests que corren cada build
2. Tests estables
- Feature no cambia constantemente
- UI estable
- ROI positivo
3. Data-driven testing
- Mismo test con 100+ combinaciones de datos
- Ejemplo: Login con diferentes usuarios
4. Tests críticos
- Funcionalidades core del negocio
- Flujos de compra, pagos, registro
5. Tests en CI/CD
- Necesitas feedback automático rápido
- Corren cada commit sin intervención humana
6. Performance y load testing
- Imposible ejecutar manualmente
- Necesitas simular miles de usuarios
7. Cálculo de ROI positivo
- Tiempo de automatización < Tiempo de ejecuciones manuales
NO se debe automatizar cuando:
❌ Feature nueva que cambia mucho ❌ Test se ejecuta raramente (1-2 veces) ❌ Testing exploratorio (requiere creatividad) ❌ Validación visual compleja ❌ UX y usability testing ❌ Tests que requieren juicio humano ❌ Costo de automatización > Beneficio
Fórmula simple:
Automatizar SI:
(Tiempo ejecución manual × Número de ejecuciones)
>
(Tiempo de automatización + Tiempo de mantenimiento)9. ¿Qué Herramientas se Usan para Automatizar Pruebas?
Respuesta:
Para Web Testing:
1. Selenium
- Más usado en la industria
- Soporta múltiples lenguajes (Java, Python, C#, JavaScript)
- Open source
- Multiplataforma (Chrome, Firefox, Safari, Edge)
2. Cypress
- Moderno y rápido
- JavaScript/TypeScript
- Excelente developer experience
- Limitado a navegadores Chromium-based
3. Playwright
- Nuevo y potente
- Microsoft
- Soporta múltiples navegadores
- Muy rápido
Para API Testing:
4. Postman + Newman
- Testing manual y automatizado
- Colecciones reutilizables
- Fácil de usar
5. Rest Assured
- Java
- Específico para APIs REST
- Muy popular en Java shops
6. Requests (Python)
- Librería Python simple
- Para scripting de APIs
Para Mobile Testing:
7. Appium
- Cross-platform (iOS y Android)
- Similar a Selenium
- Open source
8. Espresso (Android)
- Nativo de Android
- Muy rápido
9. XCUITest (iOS)
- Nativo de iOS
- De Apple
Frameworks de Testing:
10. JUnit
- Java
- Unit y integration testing
11. TestNG
- Java
- Más avanzado que JUnit
- Popular en Selenium
12. Pytest
- Python
- Simple y potente
13. Jest
- JavaScript
- Para frontend y Node.js
Para Performance Testing:
14. JMeter
- Load testing
- Open source
- Simula miles de usuarios
15. Gatling
- Performance testing
- Scala-based
- Reportes excelentes
Para CI/CD:
16. Jenkins
- Automatización de pipelines
- Más usado en empresas
17. GitHub Actions
- CI/CD nativo de GitHub
- Fácil de configurar
18. GitLab CI/CD
- Integrado en GitLab
Gestión de Testing:
19. Jira + Zephyr/Xray
- Gestión de test cases
- Tracking de bugs
20. TestRail
- Gestión de test cases
- Reportes
Cloud Testing:
21. BrowserStack
- Testing en cloud
- Múltiples browsers/devices sin instalar
22. Sauce Labs
- Similar a BrowserStack
- Para testing distribuido
