Author: francisco
Date: Wed Sep 19 09:20:50 2007
New Revision: 1194

Log:
Capítulo 8. Sección "regression-testing". Párrafo 3-4.

Modified:
   trunk/es/ch08.xml

Modified: trunk/es/ch08.xml
==============================================================================
--- trunk/es/ch08.xml   (original)
+++ trunk/es/ch08.xml   Wed Sep 19 09:20:50 2007
@@ -545,11 +545,11 @@
   de dicha probabilidad, pero no puede eliminar el problema 
completamente.</para>
   
   <para>Como resultado de esta situación, muchos proyectos tienen una
-  <firstterm>herramienta de pruebas</firstterm>, un programa aparte que
+  <firstterm>colección de pruebas</firstterm>, un programa aparte que
   ejecuta el software del proyecto en formas y maneras que se sabe producian
-  errores específicos con anterioridad. Cuando la herramienta de pruebas
+  errores específicos con anterioridad. Cuando la colección de pruebas
   consigue reproducir uno de estos errores, esto es conocido como
-  <firstterm>regresión</firstterm>,  dando a entender que las modificaciones
+  <firstterm>regresión</firstterm>, dando a entender que las modificaciones
   de alguien han vuelto a recrear inesperadamente un error corregido
   con anterioridad.</para>
 
@@ -558,28 +558,29 @@
 
   </sidebar>
 
-<para>Regression testing is not a panacea.  For one thing, it works
-best for programs with batch-style interfaces.  Software that is
-operated primarily through graphical user interfaces is much harder to
-drive programmatically.  Another problem is that the regression test
-suite framework itself can often be quite complex, with a learning
-curve and maintenance burden all its own.  Reducing this complexity is
-one of the most useful things you can do, even though it may take a
-considerable amount of time.  The easier it is to add new tests to the
-suite, the more developers will do so, and the fewer bugs will survive
-to release.  Any effort spent making tests easier to write will be
-paid back manyfold over the lifetime of the project.</para>
-
-<para>Many projects have a <firstterm>"Don't break the
-build!"</firstterm> rule, meaning: don't commit a change that makes
-the software unable to compile or run.  Being the person who broke the
-build is usually cause for mild embarrassment and ribbing.  Projects
-with regression test suites often have a corollary rule: don't commit
-any change that causes tests to fail.  Such failures are easiest to
-spot if there are automatic nightly runs of the entire test suite,
-with the results mailed out to the development list or to a dedicated
-test-results mailing list; that's another example of a worthwhile
-automation.</para>
+<para>Las pruebas de regresión no son un panacea. Por un lado funciona
+bien para programas que tienen un estilo de interfaz de lineas de comando.
+El software que se utiliza principalmente através de una interfaz gráfica
+es mucho más difícil de utilizar mediante otro programa. Otro problema
+radica en que la estructura misma de la colección de pruebas puede ser
+muy compleja, con una curva de aprendizaje y cargas de mantenimiento
+propias. Reducir esta complejidad es una de las cosas más útilies que
+puedes hacer, incluso si ello implica una cantidad de tiempo considerable.
+Cuanto más fácil sea añadir nuevas pruebas a la colección, más
+desarrolladores lo harán, y menos errores sobrevivirán a la versión final.
+Cualquier esfuerzo empleado en que la creación de pruebas sea sencilla
+redundará con intereses en el desarrollo del proyecto.</para>
+
+<para>Muchos proyectos siguen la regla <firstterm>"¡No rompas el código!"
+</firstterm>, queriendo decir: no envíes cambios que hagan que sea
+imposible compilar o ejecutar el software. Ser la persona que rompe el
+código es normalmente causa de cierta vergüenza y burla. Proyectos con
+colecciones de pruebas de regresión tienen amenudo una nueva regla
+a modo de corolario: no envíes ningún cambio que hagan fallar las pruebas.
+Dichos fallos son más fáciles de identificar si se realizan ejecuciones
+automáticas cada noche de toda la colección de pruebas, con los resultados
+enviados por email a los desrrolladores o a listas de correo dedicadas al
+efecto; este es otro ejemplo de automatización que vale la pena.</para>
 
 <para>Most volunteer developers are willing to take the extra time to
 write regression tests, when the test system is comprehensible and

_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators

Reply via email to