James Bach: ¿Qué es la automatización de pruebas?

Prólogo del traductor: A finales de 2008, tuve una conversación con un ingeniero que había trabajado en Sun durante casi toda su vida (Sun estaba a punto de ser adquirida en ese momento y estaba muy deprimido). Explicó en detalle la arquitectura de prueba interna de Sun y mencionó que Sun ha desarrollado de forma independiente una gran cantidad de herramientas de prueba automatizadas en las últimas décadas, por lo que tuve una pregunta: ¿No es la prueba automatizada un concepto que ha surgido? en los últimos años? ¿Cuál es el estado y la función de las pruebas automatizadas? ¿Pueden las pruebas automatizadas resolver los problemas que enfrentan las pruebas? En los últimos años, mi comprensión de las pruebas ha mejorado y vi el artículo de James Bach "¿Qué es la automatización de pruebas?". Tengo opiniones similares a las suyas, así que lo traduje para que todos lo vean. La automatización de pruebas es cualquier prueba asistida por herramientas. Este tipo de prueba ha aparecido casi desde los primeros días de la industria informática. Y la historia nunca ha visto algo así como "la automatización de pruebas reemplaza el trabajo de los ingenieros de pruebas", a menos que se ignore por completo el trabajo real de los evaluadores. Por la misma razón, las sondas espaciales autónomas nunca se han utilizado para "reemplazar el trabajo de los científicos espaciales". Sólo amplían el alcance de la exploración científica. Las pruebas automatizadas también significan ampliar el alcance de la exploración para los evaluadores. La automatización de pruebas no es nada nuevo (estoy de acuerdo en algunos círculos: traductor Orz), y el concepto de ingenieros de pruebas independientes es más nuevo que eso. Hace mucho tiempo, alrededor de finales de la década de 1940, los ingenieros de pruebas independientes no existían en absoluto. Los desarrolladores prueban los programas ellos mismos. En la década de 1960, los artículos sobre pruebas (como los de la conferencia IFIPS) trataban sobre cómo los desarrolladores probaban sus propios programas. Tampoco se distinguen los conceptos de prueba y depuración. A medida que la escala de los sistemas de software se hace cada vez mayor, el concepto de pruebas independientes se pone de moda. La primera conferencia sobre pruebas de software se celebró en Chapel Hill en 1972. Esta conferencia promovió la discusión sobre las pruebas de software como una tecnología independiente del desarrollo. Pero en esta reunión creo que se equivocaron en una cosa. Es que ponen muchas expectativas y entusiasmo en la automatización de pruebas. Esta expectativa no se cumplió con éxito, pero no por falta de práctica, sino por falta de comprensión suficiente. Lo que no entendieron, y lo que muchos programadores contemporáneos no entendieron (creo que muchos programadores hoy no entienden - traductor) es que las buenas pruebas de software son natural e inevitablemente una actividad humana, más que accidental. Las pruebas son una actividad social y una actividad psicológica. Cuanto más complejo sea el software, mayor será el papel que desempeñan los humanos en el uso y la identificación de problemas con el software. Pero la conferencia de Chapel Hill estuvo dominada por personas formadas como programadores e ingenieros eléctricos, y faltaba gente que supiera pensar. (¿Quién es este tipo pensante? Jerry Weinberg. Su tesis doctoral de 1965 sobre resolución de problemas es simplemente fantástica. Escribió La psicología de la programación informática en 1970, que incluía una serie sobre software en la década de 1960. Un artículo sobre pruebas. En En su libro de 1961, Fundamentals of Software Development, dedicó un capítulo a las pruebas de software. Desafortunadamente, Jerry no asistió a la conferencia de Chapel Hill, pero sí asistió a la conferencia CAST en Toronto para probadores independientes capacitados. El concepto es más nuevo que el concepto de automatización. pruebas, pero en comparación con la automatización de pruebas, este concepto no se acepta lo suficiente porque la capacitación de los evaluadores es realmente mala. (Por qué no en nuestro país - Traductor) Entonces, algunas personas entienden que las pruebas son una tecnología simple. Las pruebas sirven para garantizar que la llamada a la API no haga que el programa vaya a ninguna parte como una bestia descontrolada. La filosofía sigue ahí, me refiero a Microsoft. Mi esposa todavía tiene que pedirme que la ayude a solucionar problemas con el software de Microsoft Office.

Me dijeron que Microsoft Office, un software que todavía está creciendo, fue escrito por desarrolladores que no habían aprendido sistemáticamente a probar software, con el apoyo de esas "herramientas de prueba automatizadas". (Afortunadamente, mi colega, Michael Bolton, ¿este tipo también es bueno cantando? El traductor Orz, recientemente dio una clase de prueba en Microsoft, así que tal vez haya esperanza). La automatización de pruebas no puede reproducir la concepción de la prueba del ingeniero de pruebas. Aquellos creativos pensamientos que intervienen en el control de las pruebas, la modificación de las pruebas, la observación y la evaluación del producto. La automatización de pruebas no puede completar esas pruebas de alta calidad. Por lo tanto, la automatización de pruebas nunca ha significado automatizar los servicios proporcionados por esos ingenieros de pruebas. En pocas palabras, la automatización de pruebas significa utilizar herramientas de prueba. La automatización de pruebas es un concepto antiguo y el concepto de ingenieros de pruebas independientes es más nuevo que esto. La industria aún no ha intentado (excepto en un pequeño ámbito interno) capacitar sistemáticamente a los probadores. Simplemente nombran el puesto "ingeniero de pruebas" o "ingeniero de pruebas de desarrollo" y luego lanzan algunas herramientas de prueba con las que no están familiarizados. ¡Espero que puedan trabajar duro! ¡Lucha! (Además, soy programador. Escribí programas en mi computadora Apple II, mucho antes de escuchar acerca de los ensambladores. A principios de la década de 1990, dirigí el equipo de pruebas de Borland Turbo Debugger en el proyecto Borland C. —Debugger es una herramienta de depuración. para desarrolladores, lo que demuestra que James tiene un buen conocimiento del trabajo de los desarrolladores. Antes de esto, dirigí el equipo de desarrollo de herramientas de prueba en Apple, desarrollando pruebas humanas y pruebas automatizadas basadas en GUI. de pruebas automatizadas que no se basan en GUI Mis experiencias incluso me han traído algunos problemas nuevos cuando me enfrento a la nueva generación de probadores (refiriéndose a probadores independientes capacitados, nota del traductor) y parezco un poco impaciente cuando se trata de desarrolladores que tienen. nunca usé las llamadas herramientas de prueba automatizadas) Traductor: James Bach Lo que quiere decir es que deberían ser los ingenieros de pruebas independientes quienes revolucionen las pruebas automatizadas, y no al revés. ¿Se pueden resolver hoy los problemas que las pruebas automatizadas no resolvieron hace 50 años? Se aceptan debates.