Errores de software más costosos

La destrucción del Mariner I (1962).

18,5 millones de dólares.

La causa fue una fórmula manuscrita que se programó incorrectamente.

La catástrofe del Hartford Coliseum (1978).

70 millones de dólares.

La causa: calculo incorrecto introducido en el software CAD utilizado para diseñar el coliseo.

Explosión del cohete Arian (1996).

500 millones de dólares.

Causa: número real de 64 bits (coma flotante) relacionado con la velocidad se convirtió en un entero de 16 bits

Mars Climate Orbiterm (1999).

655 millones de dólares.

La causa, un programa calculaba la distancia en unidades inglesas (pulgadas, pies y libras), mientras que otro utilizó unidades métricas.

El error en los frenos de los Toyota (2010).

3 billones de dólares.

Un problema software que provocaba un retraso en el sistema anti-bloqueo de frenos

Las migraciones por el año 2000.

296,7 billones de dólares.

Causa: mucho software no había sido previsto para trabajar con el año 2000

* Algunos por error y otros por simplificar el desarrollo

Calidad en el software

En el desarrollo de software, la calidad de diseño acompaña a la calidad de los requisitos, especificaciones y diseño del sistema.

Los 7 principios de Testing (ISTQB)

1. Las pruebas muestran la presencia de defectos
2. Las pruebas exhaustivas son imposibles
3. Pruebas tempranas.
4. Agrupamiento de Defectos
5. La paradoja del "Pesticida"
6. La prueba es dependiente del contexto
7. La falacia de ausencia de errores

Desarrollo de software:

Modelo Tradicional

Modelo Tradicional

Atributos de calidad

Desarrollo de software:

Modelo Agil

Ciclo de desarrollo

Ciclo de testing

Manifiesto testing ágil

• Testing durante SOBRE testing al final
• Prevenir Bugs SOBRE encontrar Bugs
• Entender lo que se prueba SOBRE verificar la funcionalidad
• Construir el mejor sistema SOBRE destruir el sistema
• Responsabilidad de la calidad del equipo SOBRE responsabilidad del tester

Consecuencias

El Testing no es una fase

El Testing hace avanzar el proyecto

Todo el equipo realiza pruebas

Reducir el tiempo para recibir retroalimentación

Código limpio

Reducir la documentación de pruebas

Guiado por pruebas

Tipos de Test

Test unitarios

prueban una funcionalidad única y se basan en el principio de responsabilidad única (la S de los principios de diseño SOLID)

Integración

• prueban la conexión entre componentes, sería el siguiente paso a los test unitarios.

• Las pruebas de integración determinan si las unidades de software desarrolladas de forma independiente funcionan correctamente cuando están conectadas entre sí.

Pruebas de integración estrechas

• ejercitar solo la parte del código en mi servicio que habla con un servicio separado

• utiliza dobles de prueba de esos servicios, ya sea en proceso o de forma remota

• por lo tanto, constan de muchas pruebas de alcance limitado, a menudo no más grandes que una prueba unitaria (y generalmente se ejecutan con el mismo marco de prueba que se usa para las pruebas unitarias)

Pruebas de integración amplias

• requieren versiones en vivo de todos los servicios, lo que requiere un entorno de prueba sustancial y acceso a la red

• ejercitar rutas de código a través de todos los servicios, no solo el código responsable de las interacciones

Funcionales (o Sistema)

prueban la integración de todos los componentes que desarrollan una funcionalidad concreta (por ejemplo, la automatización de pruebas con Selenium serían test funcionales).

Aceptación de Usuarios

Pruebas definidas por el Product Owner basadas en ejemplos (BDD con Cucumber).

Regresión

Prueban que los test unitarios y funcionales siguen funcionando a lo largo del tiempo (se pueden lanzar tanto de forma manual como en sistemas de Integración Continua).

Carga

Prueban la eficiencia del sitema.

Unit of Work!

SUT (System Under Test)

DOC, or Depended On Component

Test doubles

Dummy

DTO con unos valores concretos

Fake

Stubs

Spies

registran información en función de las llamadas que se realizan

Mocks

Tienen expectativas sobre las llamadas que se espera que reciban

Nomenclatura

Estructura(AAA)

• Arrange: en esta fase se prepara el entorno para poder ejecutar la prueba.

• Act: realizamos la prueba en cuestión.

• Assert: comprobamos que el estado del entorno es el esperado.

Estructura(GWT)

• Given: en esta fase se prepara el entorno para poder ejecutar la prueba.

• When: realizamos la prueba en cuestión.

• Then: comprobamos que el estado del entorno es el esperado.

Naming Variables

• target: es el objeto que vamos a testear.

• expected: es el estado objetivo del test.

• actual: es el estado resultado del test.

• optionsServiceStub: es un stub del servicio OptionsService.

• valid_password: un password válido.

Propuestas nombramiento de metodos

MethodName_StateUnderTest_ExpectedBehavior

• isAdult_AgeLessThan18_False
• RetirarMoney_InvalidAccount_ExceptionThrown
• admitStudent_MissingMandatoryFields_FailToAdmit

MethodName_ExpectedBehavior_StateUnderTest

• isAdult_False_AgeLessThan18
• RetirarMoney_ThrowsException_IfAccountIsInvalid
• admitStudent_FailToAdmit_IfMandatoryFieldsAreMissing

test [Característica que se está probando]

• testIsNotAnAdultIfAgeLessThan18
• testFailToWithdrawMoneyIfAccountIsInvalid
• testStudentIsNotAdmittedIfMandatoryFieldsAreMissing
  

Característica a probar

• IsNotAnAdultIfAgeLessThan18
• FailToWithdrawMoneyIfAccountIsInvalid

Should_ExpectedBehavior_When_StateUnderTest

• Should_ThrowException_When_AgeLessThan18
• Should_FailToWithdrawMoney_ForInvalidAccount
• Should_FailToAdmit_IfMandatoryFieldsAreMissing

When_StateUnderTest_Expect_ExpectedBehavior

• When_AgeLessThan18_Expect_isAdultAsFalse
• When_InvalidAccount_Expect_WithdrawMoneyToFail
• When_MandatoryFieldsAreMissing_Expect_StudentAdmissionToFail

Given_Preconditions_When_StateUnderTest_Then_ExpectedBehavior

• Given_UserIsAuthenticated_When_InvalidAccountNumberIsUsedToWithdrawMoney_Then_TransactionsWillFail