¿Puedo automatizar todo tipo de pruebas (prueba de unidad, ... etc.) para que no necesite el equipo de control de calidad para hacer el testado manual? Y si no, ¿por qué?¿Las pruebas manuales de QA están inactivas?
Yo lo resumiría así:
pruebas automatizadas son para encontrar los problemas que se sabe acerca de (código incorrecto).
Las pruebas manuales son para encontrar los problemas que usted no sabe acerca de (diseño/especificaciones incorrectos).
Si utiliza pruebas manuales para encontrar problemas con el código, eso es ineficiente. Si usa pruebas automáticas para encontrar problemas con el diseño, eso es inexcusable.
Las pruebas de caja negra nunca desaparecerán mientras los seres humanos usen su producto. No hay sustituto para la capacidad humana de identificar "algo raro pasando".
1 Esta es realmente la verdad por desgracia ... –
No sé si es desafortunado; no hay nada mejor que tener buenas personas de control de calidad. –
¿Puedo automatizar todo tipo de pruebas (prueba de unidad, ... etc.) para que no necesite el equipo de control de calidad para hacer el testado manual?
Sin
Y si no, ¿Por qué?
No todas las tecnologías/pruebas son adecuadas para la automatización.
Aparte de eso, si el código de prueba automático está escrito por la misma persona que escribió el código para probar, entonces es posible que la prueba carezca de algún aspecto importante (aún no detectado por el desarrollador original) para ser validado
Casi todas las pruebas se pueden automatizar. Hay pruebas para CSS, imitación de prueba de usuarios, prueba de carga y todo lo demás. Las pocas cosas que pueden no ser fácilmente comprobables son la prueba exploratoria y arrastrar y soltar. – Phil
Nº
Su garantía de calidad puede ser un equipo más pequeño, y su propósito se convierte en la búsqueda de cosas inesperadas. Pueden jugar con el sistema de forma que un usuario pueda. De formas que los programadores no esperaban.
Una vez que encuentran algo, escribes una prueba automática para que no tengan que repetirla. Pero aún necesitas que encuentren esos casos.
no mencionar, que van a encontrar cosas como errores tipográficos, problemas de usabilidad con la interfaz de usuario, difícil de leer combinaciones, etc
No!
No todo se puede probar con pruebas automatizadas. Por favor, no sugieras eso! La estética de la interfaz de usuario es algo que su equipo de control de calidad debería ayudarlo a solucionar, algo que las pruebas automatizadas no pueden hacer. Solo para nombrar uno.
Una de las razones de la experiencia de Vista era supuestamente que MSFT había reducido los probadores "meramente humanos" en favor de los programadores de prueba que escribieron guiones.
Por supuesto, los guiones no se dio cuenta cosas como la amplia gama de temas diferentes, ya que fuimos más profundamente en el panel de control, o los cuadros de diálogo de copia estimación u otras características GUI 'menores' que hicieron la mirada basura todo producto
Las pruebas automáticas son solo tan buenas como las pruebas. Teóricamente, si pudiera escribir una prueba para cada posible interacción que el usuario haga con su sistema, las pruebas manuales quedarían obsoletas. Sin embargo, eso no es práctico, en absoluto.
Una buena prueba reducirá la cantidad de pruebas manuales requeridas por un equipo de control de calidad, pero no las eliminará. Además, las buenas pruebas de automatización pueden ayudar a evitar tener que volver a probar los problemas de forma manual, ya que una vez que se descubre un problema, se puede desarrollar una buena prueba para manejar automáticamente ese escenario específico en el futuro.
Absolutamente no. Las pruebas automatizadas son código. Pueden tener errores propios que enmascararán errores en el AUT. Además, ninguna prueba automática es capaz de preguntar: "¿Qué pasa si hago esto?", O es capaz de adivinar dónde es más probable que ocurran las fallas. La prueba exploratoria automatizada no existe.
En el lado mecánico de las cosas, también es generalmente ineficiente escribir una prueba automática que solo se ejecutará una vez. Si hacerlo manualmente toma menos tiempo que desarrollar la prueba, es un desperdicio automatizarlo.
QA manual, más conocido como Blackbox QA, está lejos de estar muerto.
Es cierto que las pruebas unitarias y las pruebas automáticas generales pueden cubrir al menos el 90% de las pruebas de ruta de código. Lo que muchos no se dan cuenta es que el 10% del último manual puede ser uno de los trabajos más importantes que puede realizar una organización de software y hardware.
Tomemos la interfaz de usuario, por ejemplo. Una prueba de unidad puede indicarle que se coloca una casilla de verificación en la ubicación correcta y se enciende y apaga como se espera. Lo que la prueba no puede decirle es que tiene un mapa de bits horrible y se ve terrible con el espantoso esquema de color púrpura y amarillo en la aplicación.
La razón más importante de Blackbox QA es que terminas con una sólida defensa del cliente dentro de tu organización. Muchas de estas personas de QA (incluido yo mismo) tienen más antecedentes creativos que un fondo de programación. Mientras que algunos pueden pensar que esto es un error, estas son las personas a las que no les importa cómo funciona el código: les importa cómo funciona el producto. Pasan tiempo pensando como un cliente, en lugar de un desarrollador; "Oh, mi iPod casi muerto terminó de sincronizar, eso significa que puedo cerrar mi computadora portátil y dejarla cargar. Sí, y luego voy a sacarla cuando mi máquina esté dormida (aunque estaba reproduciendo música de ella en mi computadora) y todo estará bien ".
Los desarrolladores y probadores saben cómo se supone que un producto funciona, y todos ejercen un producto según las especificaciones. Es un buen trabajo para un examinador usar el producto de una manera descuidada, para asegurarse de que las cosas malas no sucedan. Saca un disco USB de una computadora mientras copias datos, ¿estás loco? Claro, esa es una idea realmente estúpida. Pero la gente lo hace todo el tiempo. Y una buena persona de QA hará exactamente eso, para asegurarse de que sacar un disco duro no le quita todo el sistema. O apague el WiFi cuando descargue una película o sincronice música mientras compra contenido nuevo y luego cambie la contraseña y la dirección de correo electrónico de su cuenta al mismo tiempo. O instalando un sistema operativo en un reproductor de MP3 e intentando arrancar desde allí, luego sacando el reproductor del sistema mientras está arrancando desde el dispositivo (Sí, lo hice y encontré un error muy bueno).
Joel on Software dice "¿Por QA" mucho más elocuente que yo - http://www.joelonsoftware.com/items/2010/01/26.html
Sin
automatización Bec se utiliza principalmente para pruebas de regresión no para todos los casos de prueba.
Las pruebas manuales son de hoja perenne.
pruebas ad hoc y pruebas exploratorias se debe hacer con manual sólo
¿Tiene referencias? – SShaheen
Haciendo caso omiso de las pruebas manuales hará que se pierda errores importantes que la automatización simplemente no puede coger. Las pruebas del mundo real requieren la combinación correcta de pruebas manuales y automáticas.
La experiencia del usuario y los problemas de interfaz solo se pueden identificar con pruebas manuales.
La automatización es ideal para las pruebas de regresión porque se realiza en un entorno estable donde la experiencia del usuario ya ha sido investigada.
La automatización también es ideal para eliminar una gran cantidad de tareas tediosas para los evaluadores, de modo que puedan centrar los esfuerzos en nuevas características o áreas donde los errores de la interfaz de usuario sean más probables.
Al comienzo del nuevo proyecto Obtenemos SRS o Prototipos, por lo que una vez que solo QA entiende el flujo de trabajo de la aplicación, puede utilizar la automatización de la aplicación. La automatización no entra en juego si no se realizan pruebas manuales. la prueba es posible siempre
automatizado se puede hacer pero no comprobar el diseño de lo que si u comprobar el diseño o la interfaz de usuario u puede hacer la prueba manual
[En mi experiencia en el uso de ambos Manual & Automatización]
Manual Testing: Se trata de una prueba real en la que puede probar diferentes escenarios en función de la situación actual, por ejemplo, cuando la red no funciona bien, puede desconectar y conectar la red y verificar resultados. Esto ayuda a tratar con errores funcionales y también errores de UI.
Automatización de Pruebas: Cuando el sigue script ejecutado con regularidad, donde estos scripts también necesitan ser actualizadas similar a la actualización de la aplicación también existe la posibilidad de proporcionar resultados incorrectos si hay un retraso en la carga de páginas o de respuesta de la red o lentitud.
Ambos tienen sus pros y sus contras, sin embargo, Automation no puede reemplazar las pruebas manuales para una aplicación lógica más grande. Escenarios de interacción del usuario como la videoconferencia no son aconsejables para la automatización. Los scripts de automatización son en sí mismos el código, que también puede tener errores, donde a veces puede producir resultados incorrectos. La automatización puede adaptarse para algunas aplicaciones en las que los contenidos permanecen iguales durante días más largos y también la funcionalidad y los valores son estáticos principalmente.
víctima posible: http://stackoverflow.com/questions/663231/can-automated-testing-completely-replace-the-need-for-manual-testing –