¿Has escuchado acerca del mayor apagón en la historia de Norte América? En 2003 el suministro de eléctrico fue suspendido en diferentes estados de Canada y el Noroccidente de los Estados Unidos, dejando alrededor de 55 millones de personas sin electricidad. Este evento se conoce como el Northeast Blackout de 2003 y es un grandioso ejemplo de ¿por qué? las pruebas de software son necesarias y ¿por qué? seguir una filosofía de pruebas continuas puede reducir la probabilidad de tener errores en producción.

Dedica unos minutos a leer brevemente la entrada en wikipedia titulada Northeast blackout of 2003. Ahora revisa las fotos publicadas por The Huffington Post .

El caso del Northeast Blackout evidencia cómo un evento singular puede tener un impacto inesperado en las actividades de los humanos, cuando este evento ocurre en un servicio de alto consumo. Tal como es reportado en la nota de wikipedia, la causa del apagón fue un bug en un sistema de alertas. Algo tan sencillo como la falta de una notificación o una "ventana" alertando el problema, fue la causa de una cadena de acontecimientos que emergieron de forma caótica y resultaron en el apagón más grande de la historia.

¿El apagón fue el producto de un mal proceso de pruebas?

Dado que la causa del apagón fue un bug en el software, es fácil atribuirle la culpa a la falta de pruebas, pero la culpa también se la podemos atribuir a un error en el diseño o en la implementación. Independientemente de la verdadera causa del error, no cabe duda que la falla en el sistema pudo haberse detectado con un proceso de pruebas. La pregunta que surge ahora es ¿Cuál proceso de pruebas?

Este libro te va a ayudar a responder esa pregunta (en general), y en particular a diseñar procesos de pruebas de software de forma estratégica. El contenido en este libro reune nuestra experiencia como académicos, profesionales, e investigadores (no al estilo de CSI pero si al estilo de un grupo de investigación) en diferentes tipos de proyectos del área de Ingeniería de Software (que incluye obviamente testing). En varios de esos proyectos hemos visto que (i) los procesos de pruebas de software aún son poco valorados por algunos profesionales y en algunas organizaciones, y (ii) aún hay equipos reacios al uso de pruebas (semi) automáticas. Pero eso puede cambiar, porque nuestros objetivos con ese libro son ayudar a cambiar ese comportamiento, y convencer al lector de la importancia de hacer pruebas (semi) automáticas.

Antes de empezar con los capítulos, piensa en cuántas entradas deben utilizarse para asegurar que un método que (i) recibe dos números binarios de 10 posiciones y (ii) retorna la suma binaria de los dos números, es 100% libre de errores.