translated up to 4.2

Author: sanguino

readme-es.md

@@ -589,7 +589,7 @@ Una alternativa más elegante seria usar solo la aserción de una sola linea que
 
 <br/>
 
-❌ **De lo contrario:** Sería muy dificil deducir a partir de los informes de test (por ejemplo, informe de CI) que es lo que ha salido mal
+❌ **De lo contrario:** Sería muy dificil deducir a partir de los reportes de test (por ejemplo, reporte de CI) que es lo que ha salido mal
 
 <br/>
 
@@ -672,7 +672,7 @@ describe("Order service", function() {
 
 <br/>
 
-❌ **De lo contrario:** Cuando nos enfrentamos a un reporte con una lista plana de test, tendremos que leer rápidamente textos largos para determinar los escenarios principales y relacionar los test fallidos. Considera el siguiente caso: Cuando 7/100 test fallan, revisar una lista plana te exige leer el tesxto de las pruebas que fallan para ver como se relacionan entre ellas y que tienen en común. Sin embargo, en un informe jerarquizado, si los 7 estan bajo un mismo flujo o categoria, puedes saber rápidamente cual o donde puede estar la causa raiz del fallo
+❌ **De lo contrario:** Cuando nos enfrentamos a un reporte con una lista plana de test, tendremos que leer rápidamente textos largos para determinar los escenarios principales y relacionar los test fallidos. Considera el siguiente caso: Cuando 7/100 test fallan, revisar una lista plana te exige leer el tesxto de las pruebas que fallan para ver como se relacionan entre ellas y que tienen en común. Sin embargo, en un reporte jerarquizado, si los 7 estan bajo un mismo flujo o categoria, puedes saber rápidamente cual o donde puede estar la causa raiz del fallo
 
 <br/>
 
@@ -1536,9 +1536,9 @@ Consejos de implementación: es posible que quieras configurar la integracion co
 
 <br/>
 
-### :clap: Example: Un informe de cobertura típico
+### :clap: Example: Un reporte de cobertura típico
 
-![alt text](assets/bp-18-yoni-goldberg-code-coverage.png "Un informe de cobertura típico")
+![alt text](assets/bp-18-yoni-goldberg-code-coverage.png "Un reporte de cobertura típico")
 
 <br/>
 
@@ -1552,24 +1552,25 @@ Consejos de implementación: es posible que quieras configurar la integracion co
 
 <br/><br/>
 
-## ⚪ ️ 4.2 Inspect coverage reports to detect untested areas and other oddities
+## ⚪ ️ 4.2 Inspecciona los reportes de cobertura para detectar áreas no testadas y otras cosas raras.
+
+:white_check_mark: **Haz:** Algunos problemas se ocultan por debajo del radar y son realmente difíciles de encontrar utilizando herramientas tradicionales. Estos no son realmente bugs sino más bien un comportamientos curiosos de la aplicación que podrían tener un gran impacto. Por ejemplo, a menudo algunas áreas de código no se invocan nunca o rara vez - puedes pensar que la clase 'PricingCalculator' siempre determina el precio del producto, pero resulta que en realidad nunca se invoca, aunque tenemos 10000 productos en DB y muchas ventas… Los reportes de nos ayudan a darnos cuenta de si la aplicación se comporta de la manera que esperamos. Aparte de eso, también podemos resaltar qué tipos de código no se testean: que el 80% del código se testea, no nos indica si las partes críticas están cubiertas. Generar reportes es fácil: simplemente ejecute su aplicación en producción o durante test con cobertura y luego revisa los reportes que resaltan la frecuencia con la que se invoca cada parte del código. Si le dedicas un tiempo para echar un vistazo a estos datos, puedes encontrar algunas errores
 
-:white_check_mark: **Haz:** Some issues sneak just under the radar and are really hard to find using traditional tools. These are not really bugs but more of surprising application behavior that might have a severe impact. For example, often some code areas are never or rarely being invoked — you thought that the ‘PricingCalculator’ class is always setting the product price but it turns out it is actually never invoked although we have 10000 products in DB and many sales… Code coverage reports help you realize whether the application behaves the way you believe it does. Other than that, it can also highlight which types of code is not tested — being informed that 80% of the code is tested doesn’t tell whether the critical parts are covered. Generating reports is easy — just run your app in production or during testing with coverage tracking and then see colorful reports that highlight how frequent each code area is invoked. If you take your time to glimpse into this data — you might find some gotchas
 <br/>
 
-❌ **De lo contrario:** If you don’t know which parts of your code are left un-tested, you don’t know where the issues might come from
+❌ **De lo contrario:** Si no sabes qué trozos de código no se testean, no sabes dónde pueden aparecer problemas
 
 <br/>
 
 <details><summary>✏ <b>Código de Ejemplo</b></summary>
 
 <br/>
 
-### :thumbsdown: Ejemplo Anti Patrón: What’s wrong with this coverage report?
+### :thumbsdown: Ejemplo Anti Patrón: ¿Qué hay mal en este reporte de cobertura?
 
-Based on a real-world scenario where we tracked our application usage in QA and find out interesting login patterns (Hint: the amount of login failures is non-proportional, something is clearly wrong. Finally it turned out that some frontend bug keeps hitting the backend login API)
+Basado en un escenario real en el que rastreamos el uso de nuestra aplicación en el control de calidad y descubrimos patrones de login interesantes (Sugerencia: la cantidad de fallos de login no es proporcional, algo está claramente mal. Finalmente, resultó que algún error de la interfaz provocaba que se siguiera llamando al API de login en segundo plano)
 
-![alt text](assets/bp-19-coverage-yoni-goldberg-nodejs-consultant.png "What’s wrong with this coverage report?")
+![alt text](assets/bp-19-coverage-yoni-goldberg-nodejs-consultant.png "¿Qué hay mal en este reporte de cobertura?")
 
 </details>