Tu preguntaste:
En la empresa para la que trabaja, ¿escribe las pruebas para las características que desarrolla o alguien más lo hace?
¡Estoy hablando de e2e y pruebas de integración, no de pruebas unitarias!
- ¿Qué edad se considera "demasiado viejo" para que un desarrollador de software se una a una startup?
- Cómo conseguir trabajo en Google New York como desarrollador de software o para aprendizaje automático justo después de la universidad
- ¿Por qué a los vendedores se les paga más que a los ingenieros / desarrolladores de software?
- Soy un desarrollador de software, con 3 años de experiencia en una base de productos de inicio en la India. ¿Cómo puedo obtener un trabajo de software permanente en Australia o Singapur?
- ¿Cuándo es demasiado tarde para despedir a los desarrolladores de software? Se suponía que el proyecto estaría completo en 4 meses, pero han pasado 10 meses. Hay muchos errores en la aplicación y parece barata. ¿Qué tengo que hacer?
Mira, me acabas de cortar.
- Tengo que asumir que usted está en la gestión, porque esos dos tipos de pruebas provienen de dos paradigmas de prueba diferentes, y tienden a no mezclarse bien.
- Las pruebas de integración reales requieren pruebas unitarias, por lo que lo que está preguntando allí es imposible. Es parte del modelo de pruebas SDLC ( Software Development Life Cycle ), y usted ha engullido en una parte, mientras tira (¡explícitamente!) Las otras partes que hacen que esa parte funcione.
- Lo que está llamando “e2e”, el resto del mundo lo llama “prueba de interfaz de usuario”, y su capacidad para hacerlo está limitada por una serie de factores.
Esto es realmente atractivo para la administración, especialmente para los sitios SaaS y otros sitios donde el acceso principal es a través de un portal web. La gerencia lo quiere porque, si fuera fácil de hacer, garantizaría una experiencia de usuario consistente, y la mayoría de las quejas de los clientes implican la experiencia del usuario.
Cabe señalar en este punto que la consistencia de la experiencia es algo malo, si la experiencia es siempre mala .
Tendrá que escribir diferentes pruebas para cada plataforma, por lo que puede crear su propio marco encima de los marcos de prueba para cada plataforma, y luego escribir sus pruebas en su marco general.
- Es fácil de hacer para aplicaciones binarias, que no son sitios web , en Windows o OSF / Motif, pero solo si sigue algunas pautas bastante rígidas que casi nadie sigue , y solo en sistemas que permiten la introspección de las jerarquías de widgets, lo que significa no puede usarlo en la mayoría de los dispositivos móviles, y no puede usarlo en aplicaciones de reproducción de contenido, que están perversamente diseñadas para prohibir la introspección a fin de prohibir la copia de contenido.
- Es más difícil de hacer en Mac OS X, debido a los cambios en la fuente del sistema y la coincidencia de mapas de bits en lugar de la introspección de la jerarquía. Es factible
- También puede hacerlo en sitios web conocidos para la validación del navegador, si es un proveedor de navegadores. Felicitaciones, Apple, Microsoft, Google, Opera y Firefox.
- Hacer lo contrario, la validación del sitio web en muchos navegadores, es prohibitivamente difícil, porque los más importantes que le interesarán serán en Windows, y no hay un marco de prueba real entre navegadores, e incluso entonces, usted ‘ deje comparar la salida visual con la salida visual esperada para asegurarse de que lo que se renderizó es lo que pretendía renderizar.
Es posible, pero le costará mucho dinero o requerirá mucho trabajo humano (elija uno).
Si quieres preguntar cómo hacer pruebas efectivas durante un ciclo de vida del software, o cómo, dado eso, Apple tiende a equivocarse realmente, o Google tiende a arruinarlo realmente, está bien.
Si desea dar un ejemplo de IU que está fuera del dominio de reproducción de medios / acceso al contenido, está bien.
Pero como se le preguntó, la pregunta es a la que muchos gerentes les gustaría una buena respuesta para que puedan marcar la casilla de verificación y pasar a otras cosas, y omite la mayor parte del valor que obtendría de cualquier tipo de prueba real.