¿Qué errores comunes cometen los probadores de software?

Aquí están los 5 errores comunes cometidos

1) No tener un probador dedicado / profesional para hacer las pruebas. Todavía vemos empresas donde los desarrolladores o analistas de negocios hacen pruebas.

La prueba es un arte en sí mismo, y los desarrolladores que escriben el código a menudo pueden pasar por alto errores semánticos o sintácticos en su propio código, lo que requiere la perspectiva de un probador profesional para encontrarlo. Los desarrolladores pueden apresurar la fase de prueba en plazos ajustados, lo que da como resultado un código incorrecto.

2) No dar suficiente tiempo para la prueba. La fase de prueba se ve obligada a absorber cualquier retraso de las fases aguas arriba.

Si la fase de diseño o implementación del SDLC lleva más tiempo que el asignado, el tiempo de prueba se acorta para lograr un plazo ajustado. Las fases ascendentes causan presión a la baja, lo que resulta en un software defectuoso para lograr el objetivo de “tiempo de comercialización”

3) Comience las pruebas después de la codificación y se complete UT (Prueba de unidad). Las pruebas deben comenzar tan pronto como el requisito esté disponible. Esto puede ayudar a eliminar 20-30% de defectos por adelantado.

¡Uno de los principios utilizados en las metodologías ágiles de ingeniería de software es escribir pruebas unitarias antes de que se complete la implementación! Esto es efectivo ya que garantiza que los requisitos se cumplan como se especifica, en lugar de probar funciones que se comportan como los programadores esperan.

4) No implementar la trazabilidad en todo el ciclo de vida. Requisito-> Caso de prueba-> Código de defecto. Otro error que a menudo se comete es no medir la cobertura. Es posible que no necesitemos medir el 100% de cobertura, pero debe ser objetivo / científicamente decidido.

La trazabilidad del código defectuoso es crítica para tener una rápida rotación de la corrección de errores, de lo contrario se convierte en un proceso lento. Además, el seguimiento de la cobertura es importante para garantizar que todas las funciones involucradas se hayan probado de alguna manera.

5) No analizar los defectos encontrados en ninguna de las pruebas para determinar la causa. El análisis de causa raíz (RCA) ayuda a reducir los defectos en versiones / ciclos posteriores.

La identificación de la causa raíz de un defecto permite la capacidad de corregirlo, lo que garantiza que no surjan otros errores debido a esa causa raíz en particular. La clasificación de defectos por causa raíz también puede arrojar luz sobre qué parte del SDLC salió mal (error de requisito, error de prueba, error de código, etc.)

Leer más: 5 errores comunes en las pruebas de software – PCQuest

Buscando un software de negocios para pequeñas empresas, consulte este software de contabilidad para obtener más detalles.

Hay una razón por la cual los humanos están involucrados en el proceso de prueba. Es porque podemos aplicar el pensamiento crítico y el procesamiento a un escenario, comprender la aplicación que se está probando y explorar lo que se debe explorar y probar hasta que estén seguros de que tiene calidad con una certeza razonable. Crear una herramienta como la que usted sugiere requeriría una comprensión extremadamente íntima de la aplicación bajo prueba y del entorno del que forma parte. Si fuera capaz de construir una herramienta como la que está sugiriendo, sería un fracaso para el propósito porque estaría mejor equipado para hacer las pruebas exploratorias usted mismo o crear automatización para probar los escenarios que determine.

En una escala más simple, crear una automatización que pruebe errores comunes sería una opción mucho más factible. Probar cosas como entradas no válidas en un formulario es un excelente ejemplo y muy adecuado para la automatización.

Tal vez entendí mal su complicada pregunta, pero según mi comprensión, esa es mi opinión.

Encontré algunos probadores de nivel principiante que:

1. no informaría defectos menores y triviales (p. ej., cosméticos) porque suponen que el usuario final puede dejarlo pasar.
2. asumiría de inmediato que los desarrolladores deben ser culpados por los defectos, sin conocer la causa raíz.
3. dependería demasiado de la explicación del desarrollador de un comportamiento (y si debería ser un error o no), sin verificarlo con un analista de negocios.
4. cuando está bajo restricción de tiempo, pasaría demasiado tiempo investigando un defecto muy particular, incluso cuando toda la información necesaria para crear un informe de error claro esté disponible, y desestabilizando los otros casos de prueba más importantes que deben ejecutarse.
5. supondría que la automatización de pruebas es la bala de plata que puede reemplazar completamente las pruebas manuales.

Los probadores de software de Hmm son humanos, puede haber muchos errores como,

• Problemas de comunicación y miedo a hacer preguntas.
• Tratando de arreglar el mío.
• Intentando hacer múltiples tareas a la vez.
• Deja de aprender

Para más detalles, vaya al siguiente enlace, ‘

Errores comunes en las pruebas de software y cómo superarlos

No estoy seguro si entendí lo que quieres decir con herramienta crítica y el conocimiento que debes almacenar, pero soy un desarrollador, pero tal vez pueda dar algunas opiniones, ya que he trabajado con probadores.

Una de las cosas que he notado es que algunos probadores pueden depender de los desarrolladores para comprender qué y cómo probar ciertas implementaciones. Si bien un desarrollador es consciente de cómo las funcionalidades en un software pueden estar relacionadas indirectamente (por lo que saben que un cambio puede influir en otras partes del software, como componentes comunes, por ejemplo), es malo depender principalmente de ellos, ya que los desarrolladores pueden influir en el resultados de la prueba. Un probador debe elaborar principalmente casos de prueba basados ​​en el conocimiento funcional que tiene y pensar en cómo usarán la aplicación los usuarios del software.

Además, otra cosa que a menudo se olvidan de hacer es hacer pruebas fuera de los escenarios / casos de prueba elaborados. A veces, los usuarios pueden cometer errores y hacer cosas inesperadas, y no probar el software contra cosas locas puede provocar algunos dolores de cabeza más adelante.