Por qué pocos contratan a una empresa (o un servicio) de testing

De los creadores de ¿para qué voy a hacer las cosas con calidad si ningún cliente me va a pagar esa calidad? viene otra de esas frases inmersa de manera profunda en nuestro mundillo, principalmente entre las empresas de desarrollo software y las llamadas empresas cliente. En este caso la frase viene decir algo así como esto: “estimado proveedor de desarrollo, yo, como cliente, las pruebas no las pago, se supone que tú me debes entregar el software bien hecho”.
A diferencia de» ¿para qué voy a hacer las cosas con calidad si ningún cliente me va a pagar esa calidad?», cuya justificación, si conoces un poco cómo funciona la programación, el desarrollo o un proyecto software, carece de sentido y roza lo absurdo, la frase de “yo no pago pruebas” tiene casi tantas justificaciones a favor como en contra.
Tantas que exponerlas todas podría alargar la escritura de este post hasta el anochecer, haciendo que incluso su autor no se pusiera de acuerdo consigo mismo.
Aun así, expondré algunas. Las más importantes y populares (incluso a veces populistas)
Los clientes dicen que no pagan pruebas (bien sea contratando a un tercero para hacerlas, bien sea en una fase de pruebas en bonitamente pintada en un diagrama Gantt enviado a modo de plan de proyecto por el desarrollador o bien sea haciéndolas él mismo) porque la responsabilidad de aquel que desarrolla es hacerlo bien. Para eso se le paga. Por eso se le eligió. Se supone que sabe. ¿Por qué voy a gastar dinero en comprobar que has hecho bien tu trabajo? Hazlo bien.
Y no les falta razón.
Por su parte, los proveedores de pruebas, aquellas empresas o profesionales especializados en el testing, o aquellos que sin serlo quieren dar el salto (de los cuales cada día hay más, dicho sea de paso, hay cada vez más empresa de desarrollo software que con el propósito de vender más cosas que sólo desarrollo software se quieren meter en testing), dicen que como es imposible asegurar que una aplicación software no va a fallar unido a que los proveedores de desarrollo “suelen intentar ahorrar tiempo y dinero en la fase de pruebas”, es necesaria “una opinión independiente” que busque exhaustivamente (bajo pago, obviamente) todos los errores que pueda haber dejado el desarrollador.
Y no les falta razón.
Pero en cualquier caso, siendo pragmáticos y yendo a la realidad, los llamados clientes no entienden los argumentos para justificar un proyecto de testing y como ellos son los que manejan el presupuesto… hoy las pruebas no son un negocio muy rentable (comparado con el desarrollo).
Aún así, los proveedores de testing siguen empeñados en que los clientes entiendan sus argumentos. Y a dicho empeño, no se le puede acusar de falta de ingenio: día sí y día no inventan nuevos eventos, y justificaciones económicas de todo tipo, formulas, cálculos, excels, cualquier cosa para justificar que “la calidad es gratis” y que “las pruebas ahorran dinero”.
Pero a día de hoy, la humanidad aun no ha dado con el Excel perfecto que logre vender Testing. Por lo que el testing hoy sigue siendo un servicio que se vende… pero difícilmente, con un difícil crecimiento, a precios menores, muy alejado de desarrollo y con un complicado futuro… o no.
En este punto conviene matizar que los anteriores argumentos, y experiencias, aplican mayoritariamente a un tipo de testing que es el mayoritario: el funcional, demasiado cercano al bodyshopping (ya sabes el mayor negocio tecnológico del país). Pero hay muchos más tipos de testing, otros (ya lo comentamos en ¿Pruebas de integración, funcionales, de carga…? ¡Qué jaleo! ¿Qué diferencias hay?), y me aventuro a decir que con un mejor futuro.
Porque como ya hemos comentado en otros tantos post, aquel testing que pocos saben hacer, el de especialista altamente cualificado, en testing técnico, el testing del especialista en carga, el en automatización, el del Sherlock Holmes que descubre porque la aplicacion va tan lenta, el cercano al DevOps, etc., tiene más claro «su Excel» de venta: su presencia acorta los tiempos para poner cosas en producción y ese testing, más alejado del alcance de las grandes consultoras, sí que día sí y día no algún cliente te comenta lo de “oye no conocerás a un especialista que me pueda hacer las pruebas técnicas de…”

0 comentarios en “Por qué pocos contratan a una empresa (o un servicio) de testing”

  1. Quizá una de las cosas que no se tiene claro a la hora de «comprar» testing es el objetivo final del mismo. Y seguramente es así porque el objetivo NO ES ÚNICO. Como bien dices, depende de las necesidades: Hay una aceptación de proveedores externos? hay una «depuración» de nuestro equipo de desarrollo? Es una exploración rápida para detectar los errores más comunes? son pruebas técnicas para garantizar la estabilidad?
    Para mí, el problema de fondo es que las «grandes» consultoras intentan estandarizar el enfoque del testing y venderlo a través de la red comercial convencional. Mi visión de la jugada es que el testing es una consultoría que explota un conocimiento y una experiencia en el contexto del cliente adaptandolo a sus necesidades (obviamente lejos de los argumentarios comerciales).
    Afortunadamente se empieza a distinguir entre la «consultoría» (Qué problemas tengo y qué soluciones me ofrecen) y la prestación del servicio. Este año he participado en varias propuestas de este tipo (primero te cuentan qué problemas hay y luego te piden una solución en forma de servicio continuo)y creo que el cliente obtiene una servicio más acorde con sus necesidades.
    Saludos

    1. Estoy muy de acuerdo con el post y con el comentario de Pedro. Como bien dice Pedro, el testing se vende mejor cuando es la solución a un determinado problema, pero es muy difícil venderlo como algo preventivo que ayuda a evitar defectos graves en producción.
      El bodyshopping tampoco ayuda porque da la sensación de que el testing no es más que «fuerza bruta». Parece que no se requiere ningún tipo de conocimiento especial y que basta con poner a mucha gente delante de la aplicación aporreando teclas para probar el software…

  2. Existen empresas especializadas en ello? No me refiero a una consultora q haga de todo o a las q estan especializadas solo en vulnerabilidades. Danos algunos nombres, Javier. 🙂
    Para pruebas de usuario siempre se puede acudir a las de UX.

    1. Hola,
      Sí, en España hay varias empresas que se venden como especializadas en Testing. Luego si recuerdo los nombres los pongo 😉
      Y tambien profesionales con mucho conocimento en el tema y que se dedican especificamente a ello, Pedro, el del comentario 1 es uno de ellos.
      Saludos

      1. Gracias, Javi, hago lo que puedo 🙂
        El problema no es tanto que haya empresas especializadas, que las hay, el problema es que se vende el proyecto/servicio como algo genérico, independiente de los problemas y del contexto del cliente. De ahí que nadie lo vea imprescindible, porque no se identifica como solución a un problema concreto, son soluciones generalistas.
        No quiero ponerme pesado con esto, que ya doy bastante la brasa en el blog con el contexto. El contexto lo es todo en el testing: No me digas lo bueno que es el testing, dime qué problemas me vas a resolver y cómo lo vas a aplicar.

  3. Estoy totalmente de acuerdo contigo. El cliente no paga el testing, porque al tercerizar el desarrollo, también está transfiriendo parte del riesgo. Lo que pasa es que habría que exigir del lado del cliente un equipo de testing pues uno no puede ser juez y parte, y que sino lo tienen se puede poner, osea contratar un servicio de testing, porque si bien el desarrollo se crea siguiendo los más extrictos estandares de calidad, la garantía del servicio de desarrollo solo aplicaría si está documentado qué es un fallo y que no y esto debe ser a través de una figura objetiva y no vinculada a ninguna de las partes… seria lo ideal …

  4. Pingback: Por qué pocos contratan a una empresa (o...

  5. intereasante post, gracias Javier. Por favor podrias desarrollar más estos temas:
    – cual es el testing cercano a DevOps?
    – por testing tecnico te refieres a tests unitarios y de integracion?
    – tambien pones automatizacion. Pero este no es el funcional?

    1. Lo intentaré…
      – El que facilita que rápidamente y con seguridad se pueda pasar a producción o pre-producción lo más pronto, y frecuentemente, posible. Lo que implica muchas veces conocer cosas como los Puppet de turno (o el equivalente que en cada caso ocupe)
      – Unitarios, integración, pero yo creo que hoy ya sobre esos tenemos que hablar de BDD (y relacioados), smoke test, test exploratorio, etc. Saber qué automatizar, en qué medida (que no siempre lo máximo es lo mejor) y dónde.
      – Hay una automatización funcional, la más popular, pero yo me refería más a los anteriores tipos de automatización.

  6. En mi experiencia se añade también el problema del conocimiento profundo del producto a probar.
    En nuestro caso hemos contratado testing externo en alguna ocasión pero la efectividad era inferior a la de cualquier miembro del equipo testeando.
    Hicimos Exploratory Testing, con informes detallados de bugs por sesión, issues, etc, vamos, lo mismo que hacemos internamente pero contratado.
    Comparando resultados, en varias ocasiones vimos que los bugs que se encontraban desde fuera eran mucho menos importantes.
    En nuestro caso hay que pensar que un usuario de Plastic es un developer, luego te ves probando Plastic + VStudio, Plastic + Eclipse, IntelliJ, JIRA, Bamboo, etc, etc, etc. Vamos, que o tienes un developer probando o no te vale para nada. Y algunos perfiles de testing no han sido developers antes.
    Al final acabamos haciendo validaciones de cada tarea que se va a integrar, que no es otra cosa que un Exploratory acortado. Y en eso estamos involucrados todos… lo que a veces es cargante cuanto te encuentras que ha pasado el día y has estado… probando! :-S

  7. Yo soy cliente de proveedores. En el contrato firmado ellos se comprometen a entregarme un software en unas condiciones, entre las cuales se encuentran alcanzar unos valores en un par de métricas calculadas por medio del SonarQube. Una de esas métricas está relacionada con el testing (cobertura y densidad de éxito). Sin un valor del 80% en el área del testing no pueden alcanzar el mínimo de calidad exigido. Hasta aquí el proveedor está de acuerdo, ha plasmado su firma en el contrato, y esa firma le obliga.
    Los problemas vienen cuando empiezan a «picar código» (como vulgarmente lo denominan ellos mismos) dejando para el final las pruebas. Aquí es cuando se empieza a retorcer la rentabilidad de un proyecto, justo al principio. Como no desarrollan pruebas automáticas las pruebas se vuelven manuales, lo que significa dedicar recursos, que podrían estar volcándose en «picar» más código, a las pruebas, lo que alarga los períodos de entrega, puesto que deben asegurarse de que funciona correctamente (y si no se aseguran tendremos un problema). Además, como las pruebas se dejan para el final es frecuente que cuando empiezan a codificarlas se encuentren con problemas que les exigen refactorización; ya tenemos el problema, el programa ya está hecho y tratan de vender la idea de que el testeo es innecesario.
    Mientras, a lo largo de los meses, les hemos ido advirtiendo de que desarrollar las pruebas al finalizar el proyecto es la peor idea que podrían tener, pero casi todos esperaban en los primeros tiempos que pusimos en marcha el sistema de calidad en nuestra organización, que una vez finalizada la programación obviásemos el hecho de que no existiesen pruebas.
    Yo no sé cuál es el nivel de las empresas en cuanto a las pruebas, mis conclusiones se basan siempre en lo que nos entregan; lo que sí puedo asegurar es que las entregas de nuestros proveedores son revisadas dedicando mucha atención a las pruebas codificadas, invalidando nosotros aquellas mal programadas o aquellas que ocultan o falsifican los resultados de las mismas. Es sorprendente, pero hay entregas en las que ni una sóla prueba es real.
    Además, brillan por su ausencia las pruebas de carga, rendimiento o estrés, por poner un ejemplo de las que nos vemos obligados nosotros a desarrollar para encontrar el motivo por el cual una aplicación es demasiado lenta, para descubrir el punto exacto en el que el rendimiento cae, o por qué el servidor no aguanta con el dimensionamiento de memoria especificado por el proveedor (cuando lo especifican, aunque lo exigimos siempre). Y cuando los problemas de rendimiento aparecen siempre se echa la culpa al hardware, a la infraestructura o a terceros servicios, pero nunca aportan una sóla prueba que los avale, sólo pruebas circunstanciales, es decir, pruebas que avalan una falta de rendimiento, pero que no indican en qué punto, siquiera aproximado, se encuentra el problema. En nuestra experiencia, esos problemas de rendimiento siempre han estado causados por una mala programación, bien sea del código tradicional (en nuestro caso Java) o por un mal diseño de servicios bpel.
    Tras casi tres años de intenso trabajo en este sentido nos hemos dado cuenta de que todos los proveedores tratan de vender la idea de que los problemas de codificación se resuelven con más «hierro»: más cpu’s, más memoria, más disco, más ancho de banda… Es decir, el proveedor no entrega aplicaciones con la calidad que se comprometió, y, en lugar de asumir una quita por no cumplir con el contrato, pretende que el cliente pague más (al fin y al cabo más recursos hardware significa más inversión). Es más, que la fase de testing es algo externo a los contratos de desarrollo. Yo no lo entiendo así: si me contratan para desarrollar un software es para que lo haga lo mejor posible, no para que me paguen más dinero posteriormente para hacerlo razonablemente usable, estable o fiable.

    1. Ramón, gracias por acercarnos la visión del cliente.
      Se me saltan las lágrimas leyendo esto porque es algo que llevo viendo desde que estoy en pruebas (hace ya años, eh?). La idea es que el proveedor de desarrollo traslada la responsabilidad (y el coste) de hacer software con calidad. Lo más triste y lo más común es que el cliente transige con estos comportamiento y suele ver el software de mala calidad como algo inevitable.
      Por cierto, hace algunas semanas escribí un post titulado «Si va lento, mete más hierro» http://pedrosebastianmingo.com/si-va-lento-mete-mas-hierro/ en el que trataba precisamente este tema del que hablas en el último párrafo. En vez de invertir en hacer software eficiente y dimensionar la instalación (pruebas de dimensionamiento), se derrocha en instalaciones monstruosas e ineficientes.

Deja un comentario

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

Share This
Ir arriba