Jorge Serrano
  • Home

¿Son realmente necesarias las pruebas de testing en el desarrollo del Software?

  • By jorge
  • Mar-19-2018
  • Opinión, Testing
  • 1 Comment.

Parece una pregunta obvia, lógica y recurrente, muy recurrente, quizás demasiado…, pero si esta pregunta sigue siendo recurrente y sigue apareciendo en libros, charlas de metodologías y buenas prácticas, videos, blogs o en discusiones en redes sociales, debe ser (digo yo) porque por alguna razón no todo el mundo puede hacerlas o sencillamente, no le da la misma importancia a las pruebas de testing.

Existen muchas empresas y desarrolladores que siguen desarrollando Software sin hacer pruebas de testing, o haciéndolas a medias, que para el caso es lo mismo con el hándicap de que nos estamos engañando a nosotros y a nuestros clientes, y perdiendo un tiempo estúpido haciendo algo que no sirve para nada a excepción de hacernos creer que hacemos más o menos bien.

Pero la pregunta clave como decía es si las pruebas de testing son realmente necesarias o no.
Yo tengo mi propia opinión que voy a exponer, pero al final de la entrada hago una seria de preguntas para aquellas personas que no opinan igual o que quieran dejar sus comentarios al respecto.

De hecho, cuando lanzas esta pregunta normalmente la mayoría de las personas afirman que por supuesto lo son.
Pero en muchas empresas no se justifica esto sobre todo de acuerdo a los costes, ya que eso significa incrementar los mismos y decirle a nuestro cliente que el desarrollo que costaba x va a costar x + y.
El temor a que el cliente se de la vuelta y vaya a otro proveedor existe y es humano.
También a veces, nos interesa trabajar con el cliente abc y para ello, debemos asumir ciertos riesgos y ciertas pérdidas.

¿Pero merece la pena realmente trabajar con un cliente que prima la baja calidad y nos supone un elevado riesgo?.
Pues si es lo que el cliente quiere y a nosotros nos interesa trabajar con él, parece lógico que echemos a un lado las pruebas, desarrollemos con un mínimo de calidad, cerremos los ojos y tiremos para adelante.

Otro incremento de costes es cuando en el mismo proyecto incorporas personas de diferentes niveles y perfiles, dónde lógicamente un desarrollador experimentado tendrá una tarifa más alta que otro desarrollador con menos experiencia.
Si el cliente tiene un presupuesto ajustado, podemos cerrar los ojos nuevamente y tirar para adelante o hacerle entender ciertos detalles de suma importancia.
Una vez más, podemos estar dispuestos a querer bailar con la persona más fea de la fiesta, pero debemos asumir los riesgos que esa empresa entraña.

Nuestra obligación (a veces no sencilla) es la de intentar convencer a nuestro cliente de lo que basándonos en nuestra experiencia entendemos como importante y de explicar lo que suponen los riesgos en los que incurrirá nuestro cliente de no variar su planteamiento.

Para aclarar todo esto un poco más, voy a quitarme por un momento la gorra de programador de Software y me voy a poner la gorra de otras profesiones según el caso para explicar mejor todo esto.

Hablando de costes en el desarrollo Software, tener un equipo que cubra diferentes perfiles es lo habitual.
Desde luego, cuanto mayor es el nivel de los profesionales, mejores resultados teóricos obtendremos, pero eso incrementa los costes lógicamente.
Sin embargo, tener un equipo mixto enriquece no sólo a la empresa que nos encarga el trabajo sino al propio equipo.
Todos los desarrolladores necesitamos mentores que contribuyan, corrijan, faciliten y ayuden a otros desarrolladores más noveles en su crecimiento como programadores, porque lo normal es que el desarrollo del Software tenga problemas que deban ser solucionados de forma ágil y eficiente.
Ejemplo:
Imaginemos que vienes a operarte de apendicitis al hospital.
Te puede operar el cirujano jefe por un coste determinado, a priori algo elevado como es lógico.
También te puede operar Manolo, un tipo muy simpático y con muy buena planta y actitud que acaba de aprobar el MIR y que ha entrado ayer a trabajar al Hospital. Manolo te cobrará la mitad que el cirujano jefe ya que va a realizar una de sus primeras intervenciones contigo y su experiencia no es la misma como es lógico.
Como término medio, Manolo también te podría operar con el cirujano jefe supervisando parte del trabajo. El coste estaría entre medias de los dos anteriores ya que el cirujano jefe sólo estará una pequeña porción del tiempo supervisando a Manolo. Pero la mayoría del peso de la operación la hará Manolo.
Lo siento por Manolo que no me ha hecho nada, pero a no ser que seas masoca, dudo que te interese que te opere Manolo únicamente e irías al modelo de Manolo con el cirujano jefe, o directamente no te la jugarías e irías directamente a que te operara el cirujano jefe.

Pues aunque parezca mentira, muchas empresas quieren que los desarrollos de Software los hagan «Manolos» nada más.
Luego llegan las lamentaciones y el rechinar de dientes.

Y hablando de costes y justificación de las pruebas de testing en sí voy a poner otro ejemplo.

Imaginemos que fabricamos coches.
Hagámonos unas sencillas preguntas.
¿Estaríamos dispuestos a fabricar un coche para nuestro cliente que no haya sido probado?.
¿Tendríamos la tranquilidad de entregar a nuestro cliente un coche del que no conocemos su fiabilidad, rendimiento, etc?.
¿Estaría nuestro cliente a admitir esto para ahorrarse un dinero?.
Si la respuesta es sí, nuestro cliente es un temerario y nosotros también.
Vamos… que una vez entregamos las llaves del coche, si nuestro cliente nos dice que si nos montamos con él, seguro que buscamos una excusa para no hacerlo.
Evitar ese tipo de clientes nos ahorrará a la larga muchos problemas, porque cuando haya problemas, nunca admitirá su error y siempre echará la culpa a quién hizo el Software afectándonos a nuestra reputación.

Llevando todo esto con ejemplos más orientados al desarrollo de Software en sí, imaginemos que vamos a hacer un Software que manipula planchas de oro que tienen un coste de 800 € cada plancha de oro.
¿El cliente daría por bueno un Software que va a manipular ese delicado y costoso material sin estar seguro de que no va a provocar problemas serios que generen pérdidas millonarias?.

Sé que vivimos en un mundo competitivo.
La competencia es bastante feroz, y muchas empresas proveedoras de servicios bajan sus tarifas incluso por debajo de los márgenes con tal de ganar cuota de mercado.
Pero estas prácticas son pan para hoy y hambre para mañana.

El testing nos permite encontrar errores y bugs durante la fase de desarrollo y antes de llevar nuestro Software a la fase de producción.
Se sabe a ciencia cierta, que encontrar y resolver un bug que se encuentra en la etapa de desarrollo de Software es cerca de 80 veces más barato y rápido que hacerlo cuando el Software está publicado y en el mercado.
Todos los que tenemos un poco de experiencia seguro que tenemos anécdotas de esto que acabo de decir.

Una buena estrategia de testing nos ahorrará muchos problemas y muchos disgustos, tanto a la empresa encargada de desarrollar el Software como al cliente.
Querer clientes satisfechos de nuestro trabajo debe ser un objetivo a cumplir siempre.
Si el cliente no quiere las pruebas porque quiere ahorrarse el dinero, debe ser consciente de los riesgos que esto entraña, y deberíamos hacerle firmar una claúsula de contrato que nos exima de toda responsabilidad en el caso de que se produzca algún error grave derivado de la ausencia de pruebas de testing.
Esta claúsula que indico hace que muchos clientes se lo piensen, porque prácticamente ninguno la aceptará.
Pero para la empresa que desarrolla Software, puede provocar en el futuro cercano problemas legales serios que a veces terminan incluso en los tribunales de justicia.
Debemos asumir que algunos clientes se echarán atrás tras comentar estas cosas y buscarán otro proveedor diferente con el que trabajar.
Y sólo los clientes serios, responsables y coherentes, no pondrán duda alguna a trabajar de esto modo.

Alguno me puede decir que no es lo mismo un desarrollo Software que otro, y cierto es que así es, pero también es cierto que detrás de todo esto hay una palabra:

CALIDAD

Si alguien no quiere desarrollo de calidad, es normalmente porque ese Software inicialmente no está justificado.
A veces lo está, como el desarrollo de una PoC o Proof of Concepts (Pruebas de Concepto en nuestra lengua), u otros desarrollos muy puntuales, pero hablando de desarrollos de Software de cierto tamaño, envergadura y profundidad, desarrollar sin pruebas es una temeridad como estoy exponiendo.

Las entregas deben cumplir los propósitos encomendados cumpliendo unos estándares mínimos de calidad.
Debe ser fiable, rápido, eficiente, y debe facilitar su mantenimiento.

Cuando llevemos algo a producción, debemos estar confiados en su funcionamiento.
Si por debajo de la mesa estamos cruzando los dedos, tenemos un problema serio, y tarde o temprano dará la cara y nos la partirá.

Los costes que se incrementan al propio desarrollo del Software en sí por incluir testing están SIEMPRE justificados.
Es más, yo que he estado trabajando como consultor y en empresa final que recibía ofertas de consultores, admito que una empresa de Software que me presenta un presupuesto de desarrollo sin incluir una partida de testing me hace sospechar.
Esta es la clave.
El testing no es un ente separado que flota en el aire y que podemos usar o no en el desarrollo del Software como si fuera el extra de un coche. Debe venir de serie. Forma parte de él y debe ser una parte indivisible del mismo.

Si el cliente se la quierer jugar sin incluir el testing, que lo haga, pero debemos ser sinceros con él y exponerle los riesgos a los que está expuesto.
Es como si un cliente comprara un coche que no llevara de serie el freno de mano.
Si aparca todos los días en una cuesta y pone una marcha, el coche el principio no se moverá.
Si gira la rueda y pega con el bordillo, tampoco se moverá.
Pero no podemos asegurar que el coche se vaya cuesta abajo un buen día.

Como digo, evidentemente podemos desarrollar Software sin testings, pero no me montaría en una cápsula espacial acoplada a un cohete que nunca fue probado.
Dicho de otro modo, si fuera el cliente, no pondría en producción algo del que no tengo claro que vaya a funcionar como se espera o que vaya a fallar en un momento dado inesperado.

Una de las leyes de Murphy que debemos comentar siempre a nuestros clientes dice que si algo puede salir mal, saldrá mal.
En desarrollo de Software también.
Incluso el testing en sí, no evita que eso pueda ocurrir, pero minimizaremos esa posibilidad enormemente.
Testing no significa 0 errores, significa tender a 0 esos errores que es diferente.

Para finalizar, dentro del abanico de las pruebas de testing me gustaría recalcar las que a mi juicio personal son las dos principales que deberíamos tener marcadas en rojo en nuestra guía de ruta del desarrollo del Software.
Las pruebas unitarias y las pruebas de integración.

Las pruebas unitarias nos permitirán probar unitariamente las rutinas, métodos y lógica de Software que estamos desarrollando.
Las pruebas de integración nos permitirá unir todas esas partes que unitariamente funcionan tal y como esperamos y ver que su comportamiento en conjunto, sigue siendo el esperado.

Algunos desarrolladores que encuentran un bug en una de las pruebas unitarias, corrigen ese método o porción de código, y vuelve a pasar la prueba unitaria que daba error hasta que pasa, obviando un principio clave en testing, que es que si una sola prueba unitaria falla, debe darse por inválido todo el modelo de pruebas, teniendo que empezar de cero todo su conjunto una vez corregimos el bug detectado.
Por lo que hacer testing no resuelve el problema de la calidad, simplemente nos ayuda a resolverlo.
Como hagamos ese testing es clave también.

A pesar de todo lo que comento, puede ser que a lo mejor no estés de acuerdo conmigo, así que pregunto en alto para conocer otros puntos de vista diferentes que justifiquen otros planteamientos.
¿Tú ves justificable que no se hagan pruebas de testing en los desarrollos de Software?.
¿En qué escenarios ves que las pruebas de testing no son necesarias y porqué?. ¿Qué justificación das?.

Happy Coding!

Comments

One Responseso far

  1. Walter Valverde dice:
    5 abril, 2019 a las 10:30 pm

    Definitivamente no lo veo justificable, siempre debe haber calidad en la creación de un software, es parte de la buena práctica. Creo que no es necesario un testing en un sistema de escritorio; ya que no todo el mundo tiene acceso, lo que sucede es que la tendencia es desarrollar software en web y esto está al alcance de todos.

    Responder

Deja un comentario Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

← Previous Post Next Post →

Jorge Serrano

MVP Reconnect


¡Subscríbete a mi canal!
YouTube

Donaciones
Donation

Entradas recientes

  • Go – Arrays
  • Go – Operators
  • Go – Constants
  • Go – Tipos de Datos
  • Go – Variables
  • Hello Go-rld!
  • Introducción a Go o Golang
  • JSON Patch en ASP.NET Core 5 Web API
  • Null Checking en C#
  • ¿Porqué mi página web por defecto de ASP.NET Core no se vé en mi Azure Web App y me da un 404?

Categorías

  • .NET 5
  • .NET Core
  • .NET Core 3.0
  • .NET Core 3.1
  • .NET Framework 2.0
  • .NET Framework 3.0
  • .NET Framework 3.5
  • .NET Framework 4.0
  • .NET Framework 4.5
  • .NET Framework 4.6
  • .NET Framework 4.7
  • .NET Framework 4.8
  • .NET Standard 2.0
  • .NET Standard 2.1
  • AMQP
  • Android
  • Angular
  • API REST
  • Apple
  • Apple iOS
  • Apple macOs
  • Arquitectura
  • ASP.NET
  • ASP.NET Core
  • ASP.NET Core 3
  • ASP.NET Core 5
  • AWS
  • Azure App Service
  • Azure Application Insights
  • Azure Cosmos DB
  • Azure Database Migration Service
  • Azure Databricks
  • Azure DevOps
  • Azure Event Grid
  • Azure Functions
  • Azure IoT
  • Azure Portal
  • Azure PowerShell
  • Azure Queue Storage
  • Azure SQL
  • Azure Storage
  • Azure Virtual Datacenter
  • Azure WebApps
  • Big Data
  • Bing
  • Blazor
  • Blog
  • Bots
  • C#
  • C# 7.0
  • C# 7.1
  • C# 7.2
  • C# 7.3
  • C# 8.0
  • C# 9.0
  • Channel 9
  • Codeplex
  • Codespaces
  • Containers
  • Debugging
  • DevOps
  • Docker
  • Electron
  • Entity Framework
  • Entity Framework Core
  • Entity Framework Core 3.0
  • Entity Framework Core 5
  • Eventos
  • F#
  • FaaS
  • FeatureFlags
  • FeatureToggles
  • Feeds
  • Fluent Assertions
  • General
  • GIMP
  • Git
  • GitHub
  • Go
  • Google
  • Google Analytics
  • Gradle
  • gRPC
  • GSA
  • Historia de la Informática
  • HoloLens
  • HtmlAgilityPack
  • IdentityServer4
  • Inkscape
  • Ionic
  • iOS
  • IoT
  • Java
  • JavaScript
  • JDBC
  • JSON
  • Kubernetes
  • Lenguajes de Programación
  • Libros y Cursos
  • LINQ
  • Linux
  • LiteDB
  • Machine Learning
  • macOS
  • Microservices
  • Microsoft
  • Microsoft .NET Framework 4.5
  • Microsoft 365
  • Microsoft Azure
  • Microsoft Build
  • Microsoft Ignite
  • Microsoft Learn
  • Microsoft Orleans
  • Microsoft Surface Go
  • Microsoft Teams
  • ML.NET
  • MQTT
  • MRO
  • MS-DOS
  • MsCoders Madrid
  • MVP
  • NancyFx
  • Node.js
  • NoSQL
  • NuGet
  • NUnit
  • OData
  • ODP.NET Core
  • Office 2007
  • Office 2010
  • Office 2013
  • Office 2016
  • Office 2019
  • Office 365
  • Open Source
  • Open XML SDK
  • Opinión
  • Orchard CMS
  • OT
  • PaaS
  • Patterns
  • PdfSharpCore
  • Performance
  • PHP
  • Postman
  • Power BI
  • PowerShell
  • PowerShell Core
  • Productividad
  • Project Server 2019
  • R
  • Rendimiento
  • Scala
  • Scraper
  • Security
  • Serverless
  • Service Fabric
  • SharePoint Server 2019
  • SignalR
  • Sin categoría
  • Sistemas Distribuidos
  • Skype
  • Skype for Business Server 2019
  • Small Basic Online
  • SQL Server 2005
  • SQL Server 2008
  • SQL Server 2012
  • SQL Server 2014
  • SQL Server 2016
  • SQL Server 2017
  • SQL Server 2019
  • STOMP
  • Swagger
  • Testing
  • TFS 2017
  • TFS 2018
  • Tools
  • TypeScript
  • Unity
  • UWP
  • UX
  • Visio
  • Visual Basic
  • Visual Studio 2010
  • Visual Studio 2012
  • Visual Studio 2013
  • Visual Studio 2015
  • Visual Studio 2017
  • Visual Studio 2017 for Mac
  • Visual Studio 2019
  • Visual Studio 2019 for Mac
  • Visual Studio App Center
  • Visual Studio Code
  • Visual Studio IntelliCode
  • Visual Studio Live Share
  • Visual Studio Live Share Audio
  • Visual Studio Online
  • VS Anywhere
  • Vue.js
  • Web API
  • WebAssembly
  • WinDbg
  • Windows
  • Windows 10
  • Windows Compatibility Pack
  • Windows Phone 10
  • Windows Phone 7
  • Windows Phone 8
  • Windows Server 2008
  • Windows Server 2012
  • Windows Server 2016
  • Windows Server 2019
  • Windows Service
  • WinForms
  • WinUI
  • WPF
  • Xamarin
  • Xbox
  • Xcode
  • Xiaomi Mi Band 2
  • xUnit
  • YAML

Archivos

  • enero 2021
  • diciembre 2020
  • noviembre 2020
  • octubre 2020
  • septiembre 2020
  • agosto 2020
  • julio 2020
  • junio 2020
  • mayo 2020
  • abril 2020
  • marzo 2020
  • febrero 2020
  • enero 2020
  • diciembre 2019
  • noviembre 2019
  • octubre 2019
  • septiembre 2019
  • agosto 2019
  • julio 2019
  • junio 2019
  • mayo 2019
  • abril 2019
  • marzo 2019
  • febrero 2019
  • enero 2019
  • diciembre 2018
  • noviembre 2018
  • octubre 2018
  • septiembre 2018
  • agosto 2018
  • julio 2018
  • junio 2018
  • mayo 2018
  • abril 2018
  • marzo 2018
  • febrero 2018
  • enero 2018
  • diciembre 2017
  • noviembre 2017
  • octubre 2017
  • septiembre 2017
  • agosto 2017
  • julio 2017
  • junio 2017
  • febrero 2015
  • octubre 2014
  • junio 2014
  • marzo 2014
  • febrero 2014
  • enero 2014
  • diciembre 2013
  • septiembre 2013
  • agosto 2013
  • julio 2013
  • junio 2013
  • abril 2013
  • febrero 2013
  • enero 2013
  • diciembre 2012
  • noviembre 2012
  • septiembre 2012
  • agosto 2012
  • junio 2012
  • mayo 2012
  • abril 2012
  • marzo 2012
  • febrero 2012
  • enero 2012
  • diciembre 2011
  • noviembre 2011
  • octubre 2011
  • septiembre 2011
  • agosto 2011
  • julio 2011
  • junio 2011
  • mayo 2011
  • abril 2011
  • marzo 2011
  • enero 2011
  • diciembre 2010
  • noviembre 2010
  • octubre 2010
  • septiembre 2010
  • agosto 2010
  • julio 2010
  • junio 2010
  • mayo 2010
  • abril 2010
  • marzo 2010
  • febrero 2010
  • enero 2010
  • diciembre 2009
  • noviembre 2009
  • octubre 2009
  • septiembre 2009
  • agosto 2009
  • julio 2009
  • junio 2009
  • mayo 2009
  • abril 2009
  • marzo 2009
  • febrero 2009
  • enero 2009
  • diciembre 2008
  • noviembre 2008
  • octubre 2008
  • septiembre 2008
  • agosto 2008
  • julio 2008
  • junio 2008
  • mayo 2008
  • abril 2008
  • marzo 2008
  • febrero 2008
  • enero 2008
  • diciembre 2007
  • noviembre 2007
  • octubre 2007
  • septiembre 2007
  • agosto 2007
  • julio 2007
  • junio 2007
  • mayo 2007
  • abril 2007
  • marzo 2007
  • febrero 2007
  • enero 2007
  • diciembre 2006
  • noviembre 2006
  • octubre 2006
  • septiembre 2006
  • agosto 2006
  • julio 2006
  • junio 2006
  • mayo 2006
About This Site

A cras tincidunt, ut tellus et. Gravida scel ipsum sed iaculis, nunc non nam. Placerat sed phase llus, purus purus elit.

Archives Widget
  • January 2010
  • December 2009
  • November 2009
  • October 2009
Categories
  • Entertainment
  • Technology
  • Sports & Recreation
  • Jobs & Lifestyle
Search
  • twitter

Powered by WordPress  |  Business Directory by InkThemes.

This site uses cookies: Find out more.