Os recopilamos las cinco preguntas comerciales que nos encontramos con mayor frecuencia en el ámbito de las pruebas automáticas de software. Si os identificáis con alguna de ellas os animamos a votar en los comentarios cuál es para vosotros LA PREGUNTA.
Llegar a hacerse estas preguntas requiere haber visualizado que es crítico el uso de programas en el desarrollo de tu negocio. Nuestra experiencia nos ha enseñado que existe un colectivo que no es sensible al impacto del software en su cifra de negocio … todavía. Vienen a ser los terraplanistas del aseguramiento de la calidad del software (SQA).
De entre los que ya saben que la tierra es redonda y
que se muestran interesados en las pruebas software,
observamos que típicamente son
Gerentes de Desarrollo, Aplicaciones o SQA
desbordados en su día a día,
invirtiendo en pruebas y
con poco tiempo para atendernos.
¿Te suena?
Nuestra responsabilidad es maximizar su inversión y reducir su carga de trabajo
¿Cómo?
Aportando estabilidad a sus productos gracias al aseguramiento automático.
Por cierto, en este arquetipo cliente casi nadie admite que automatiza pruebas. Casi todos prueban, y casi nadie automatiza. ¿Será por pudor? ¿Será por desconocimiento?
Reconocer o no reconocer
Vamos entonces con las 5 preguntas, todas son igual de significativas, todas son cinco estrellas:
P – ¿Cuándo es posible o útil automatizar pruebas?
Detrás de esta pregunta podemos leer: “es que lo mío es especial”, especial por complicado, por particular, por barato…. Piensan todavía que automatizar pruebas es de Ciencia Ficción o para situaciones idílicas que no aplican en su caso.
Es frecuente que hayan tenido en su equipo alguna iniciativa exploratoria a los mandos de un Selenium o incluso tirando de un Jenkins, que hayan intentado automatizar en los ratos libres y así hayan emitido su diagnóstico de imposibilidad / inviabilidad, simplemente porque no estaba aplicando un criterio de globalidad.
R/ Casi siempre es posible y útil automatizar. El cuándo lo establece el entender la automatización de pruebas como una inversión. Interesa añadir automatización de pruebas en nuestro proceso de construcción y despliegue de software cuando sea rentable para el negocio.
P – ¿Usáis una herramienta en especial? ¿Lo hacéis a base de scripts a medida?
Ésta suele ser la duda entre los que REALMENTE conocen el valor de las pruebas software y saben que es posible automatizarlas, por ello se enfocan en las herramientas de automatización de pruebas.
Así, en algunos casos ya han comprado productos comerciales, como los de la extinta HPE Software (integrada en Micro Focus), pero no están muy seguros de su valor. En otros casos, consideran la posibilidad de trabajar con una herramienta OpenSource.
R/ Las herramientas son la consecuencia de nuestras decisiones a nivel de procesos de aseguramiento de la calidad del software (SQA). Por ejemplo, incorporar el
diseño ágil con TDD requiere alinear la cultura de trabajo en la organización, que es algo mucho más costoso, profundo y rentable que comprar una herramienta. El nivel mínimo de preocupación tiene que ser
cuál es la estrategia de pruebas que vamos a utilizar,
habitualmente, la orientación a pruebas de flujos de negocio es la opción más recomendable.
P – ¿Por dónde empiezo a automatizar?
Problemas con entornos, sistemas monolíticos, desarrollos “patch over patch and patch again”, silos departamentales, etc. Nuestros interlocutores deben convivir con tantos bichos que acaban mostrando una misma reacción alérgica cuando se les habla de pruebas automáticas (¡Otro bicho más!). De ahí su desorientación sobre por dónde empezar.
R/ Para orientarse en esta selva recomendamos empezar identificando tareas de prueba que sean aburridas, repetitivas y sin mucho valor aparente, pero que podrían ser determinantes en momentos muy puntuales o que siempre generan condiciones de fallo en sus sistemas actuales. Es solo un pequeño primer paso pero alivia el escozor.
Luego toca entrar en matices más elaborados, como frecuencia de cambio o criticidades desde negocio. Nuestro foco suele ser asegurar que no se retrocede en el producto, es decir, automatizar las pruebas de regresión funcional.
P – ¿Qué necesitáis para poder automatizar?
Pregunta de carácter defensivo motivada por la presión del día a día, relacionada con la preocupación por la curva de adopción y la falta de expectativa de resultados tangibles. En estos escenarios, el piloto o prueba de concepto se demuestra casi milagroso.
Ojo, no hacemos milagros. Si no se tienen mínimamente documentadas las pruebas manuales actuales, no vamos a poder automatizar nada en el restringido marco de un piloto. Nuevamente, nuestra experiencia es que un cliente que no documenta sus pruebas, suele ser un terraplanista: «probar sistemáticamente el software está sobrevalorado».
R/ Por tanto, nuestra referencia base es que se disponga de un cierto nivel documental para las pruebas manuales. Poca cosa, nos basta con un documento “de los que usan normalmente” y una mínima atención para que nuestros especialistas puedan construir un efectivo Piloto en menos de diez días.
Somos humanos, tenemos nuestros trucos, como orientar las pruebas a flujos de negocio y apoyarnos en
Zahorí como solución base de automatización de pruebas funcionales, cuando estemos ante casos de automatizaciones web o mobile, claro ;).
P – ¿Podéis automatizar cualquier prueba de cualquier aplicación?
Cuando nos plantean esta pregunta, solemos sentirnos en una encrucijada: o necesita empezar ya o no tiene pensado automatizar nada.
Como primera medida os recomendamos nuestra página dedicada al auto-descubrimiento:
R/ La respuesta es: Sí … pero queremos que os salga rentable.
Si se dispone de interfaz web o móvil, SÍ.
En cao de querer automatizar pruebas sobre procesos host/cobol, SÍ.
Si se trata de aplicaciones con altos niveles de integración con sistemas heredados («legacy»), SÍ se puede, pero el mantenimiento del conjunto de estas pruebas automáticas suele ser muy complicado, lo que pone en riesgo la rentabilidad de esta inversión.
Y hasta aquí hemos llegado. Os hemos compartido esta dudas porque entendemos que deben ser resueltas para aprovechar a medio plazo las ventajas que se obtienen al primar el valor entregado como cultura de trabajo. Con ellas esbozamos nuestra respuesta a los necesarios quién, qué, dónde, por qué y cuándo incorporar las pruebas funcionales automáticas en vuestros ciclos de contrucción de software.
¿Hemos conseguido despejar tus principales dudas sobre automatización de pruebas?
¿Sí? ¡Genial!
¿No? ¡Pruébanos, aceptamos el reto!
Preparados para el reto
Según lo que dicen al comienzo del articulo pienso que la pregunta es ¿para que me sirve automatizar? porque no todos están familiarizados con la utilidad de estos procesos y aunque se recalca que el ideal es maximizar la inversión y reducir la carga, las empresas necesitan saber especificamente la implementación de estos procesos que tipos de cargas reducirá y cual sera su retorno de inversión por implementar el proceso de automatización
Efectivamente, como bien dices las empresas deben conocer de antemano qué rentabilidad, o qué Valor, aportará la automatización a sus procesos de SQA. Nosotros entendemos que la automatización será rentable siempre que nos permita a su vez proporcionar valor y experiencias personalizadas a nuestros propios clientes, asegurando su experiencia de usuario mediante un proceso SQA end to end, con una amplia cobertura funcional. Lo contamos también en este artículo, en el que algunas empresas cuentan cómo han encontrado ese valor con la automatización: http://www.elmundo.es/economia/innovadores/2018/02/25/5a904c62e5fdeaa75c8b4674.html
Y como esto depende de los procesos de SQA de cada empresa, también te invito a participar en este cuestionario sobre Automatización: https://goo.gl/forms/njLCuE5oxOVUrNZs2
Gracias por tu aportación!.
Muchas veces nos encontramos con el punto 4, no hay apenas documentación de las pruebas manuales y en algunos casos ni siquiera evidencias…
Buen artículo, gracias!