Este Debate se planteó hace muy poco tiempo en el grupo de whatsapp que teníamos y que no pude publicarlo antes por falta de tiempo.
Te cuento, por si no lo sabías, que actualmente desde hace una semana tenemos un nuevo espacio para la discusión denominado: Slack TestersDifusion.
Los Testers miembros del grupo de whastapp anterior, se han mudado a este nuevo espacio y ahora cuentan con una nueva organización que por supuesto con el espacio anterior no lo teníamos, los «canales» en donde discutir y compartir info y conocimientos sobre temas específicos, además de poder acceder a las conversaciones que han pasado.
Como siempre, trato en todo momento de seguir los temas e identificar puntos a mejorar para que la comunidad de este Slack se sienta satisfecha.
Fecha del Debate:
[11/8 11:43]
Registro el debate tal y cual se fué dando en el whatsapp.
MiguelB: Sonara extraña pero me gustaría debatir lo siguiente: ¿Cuál es la misión del probador Y quién es el cliente del probador?
MiguelB: Con base en las respuestas a estas dos preguntas hay otra que debe hacer un probador por su cliente
CristianCB: no entiendo la pregunta
MiguelB: En mi opinión el probador tiene la misión de ayudarle al desarrollador a que produzca un código de alta calidad según eso el cliente el probador es el desarrollador
MiguelB: Y con base en esta respuesta el probador debe, además de identificar defectos, ayudarle al desarrollador a encontrar mejores herramientas o mejores caminos para que codifique mejor
CristianCB: te refieres al inspector de código?
PatricioK: a grandes rasgos 1) asegurar que se cumpla la calidad según los criterios de aceptación establecidos encontrando e informando los problemas con la mayor minuciosidad posible en su contexto y circunstancias y 2) el usuario es el cliente, no el desarrollador, porque el usuario es el juez final del entregable. En base a eso, testing, analisis y desarrollo tienen que colaborar para cumplir con el usuario final.
MiguelB: No necesariamente. Al probador funcional también
MiguelB: O al de performance. O al de seguridad
CristianCB: esque depende de la empresa y las obligaciones a tu cargo
MiguelB: En otras palabras además de identificar defectos Cuál es nuestro valor agregado como probador
CristianCB: en mi empresa los de QA no nos metemos en el código
MiguelB: No no no hablo de obligaciones ni de un manual de funciones hablo desde el punto de vista filosófico o comercial o de Mercado
CristianCB: es que todo repercute en lo comercial
CristianCB: teóricamente o vocacionalmente, estas en lo correcto con respecto a la visión de un QA
CristianCB: pero como mencione antes depende de la empresa netamente
MiguelB: Si depende de la empresa Pero abstrayendonos desde el contrato laboral nosotros como probadores qué misión tenemos
FranciscoA: La misión del probador es asegurar que los requerimientos del cliente se cumplan así mismo que lo que ya se tenía no sufra modificación el cliente del probador es el cliente como tal.
PatricioK: miguel, siempre vamos a chocar con la barrera del valor percibido, porque para un comercial en general (hay excepciones) QC agrega costo y tiempo sin un retorno directo en ganancia (es decir, come margen y no ven un $$ en la otra parte de la ecuación). La realidad es que el valor de QC y QA es indirecto, ya que evita costos mucho mayores posteriores. Ej. menor costo en mesa de ayuda y correctivos en producción, mejor imagen de la empresa por calidad de desarrollos, mayor flexibilidad ante cambios de alcance y diseño, disminución de downtime productivo por fallas en el código o infraestructura inadecuada, etc etc etc
PatricioK: choca la visión a corto plazo de la ganancia inmediata contra la visión a largo plazo
PatricioK: y considerando que la mayoría de los comerciales tienen que cumplir con cuotas de ganancia a veces imposibles, es entendible que exista esta diferencia de puntos de vista
PatricioK: el problema es cultural en su base
PatricioK: en mi opinión
MiguelB: Encontrar defectos asegura que los requerimientos no se cumplieron lo cual contradice Tu misión. Estoy de acuerdo contigo, esa es la definición tradicional; pero quiero ir más allá, precisamente buscando generar valor, y no sumar costos
MiguelB: Encontrar defectos no le ayuda a un programador a ser mejor programador
PabloA: El software puede cumplir los requerimientos pero creo que eso no quiere decir que sea lo que al cliente le guste o le parezca mas comodo
FranciscoA: Mientras generes mayor valor, superas las espectativas lo cual hace tener posiblemente mayor ingresos con posibles clientes (ya que entramos en la cadena de la recomendación) y se reducen costos ya que no realizas una implementación ni un desperdicio de materia prima
MiguelB: Demostrar que un software no cumple los requisitos no le genera valor al cliente
MiguelB: Demostrar que un software no cumple requisitos, no disminuye costos, al contrario los aumenta
PatricioK: si lo haces antes de que llegue al usuario final y con tu análisis habilitas que se corrija en tiempo y forma, claro que si.
PatricioK: disminuye los costos a largo plazo, no a corto plazo
MiguelB: Las correcciones son re proceso los reprocesos tienen costos Los costos aumentan el presupuesto no genera este valor aumentaste costas
PatricioK: evita costos de mesa de ayuda. evita costos por pérdidas por mal o no funcionamiento. evita costos de proyectos correctivos necesarios por falta de previsión
PatricioK: la diferencia es cuando pagas el costo. si optimizado dentro del desarrollo o con magnitudes de diferencia en producción
PatricioK: si está correctamente estimado, ni siquiera pagas un costo con delay de entrega
PatricioK: y definitivamente evita pagar el costo de imagen
PatricioK: que es lejos el más difícil de recuperar
MiguelB: Hagamos un ejercicio tú eres el cliente le pagas a un desarrollador el probador te dice que el software no cumple, o cumple parcial. Qué valor tiene el cliente Sí ya invertió su dinero? Qué valor tiene el desarrollador si ya hizo la programación
ManuelA: si el dev lo toma como leccion aprendida, no volvera a cometer el mismo error al codificar
ManuelA: eso es ganancia para él
PatricioK: el error ahí es incluir al tester post mortem. El dev no aprende la lección si no es parte del proceso (por experiencia te lo digo)
PatricioK: y nuevamente, no estas considerando el costo a largo plazo
PatricioK: que hay del costo si no se prueba y el soft genera pérdidas cuando está implementado en producción?
PatricioK: si no es performante
PabloA: Te referías al costo del tester no?
PatricioK: si es una app mobile con 30 seg de carga por pantalla
PatricioK: etc etc
PatricioK: al costo y al proceso
PatricioK: conozco muchas instancias en las que dev no comenzó a hacer unit test hasta que fue parte del proceso. a pesar de la obviedad de la necesidad de hacerlo
PatricioK: solo como ejemplo
Sitio Oficial: Slack
MiguelB: Patrick todo eso lo sé; es lo que hago en el día a día y son los argumentos que le doy a mi cliente; pero hoy, después de la lágrima que me hizo derramar Gusttavo, me puse a reflexionar y pensé: realmente estamos generando valor?
PabloA: Si, el tiempo y costo se va adquiriendo con la experiencia y los conocimientos que el dev tenga.
MiguelB: Pasa un almacén compras una camisa $40 contratas a una persona $5 la persona te dice que la camisa tiene un roto Qué valor generaste
PatricioK: ninguno. porque no incluis a esa persona en el proceso. Es el un Nelson riendose del corte de pelo de Lisa
PatricioK: no un tester
PatricioK: ahora. poné esa persona en el proceso. Antes de que llegue a la tienda la remera, el tester detecta la rotura. Encuentra el proceso que falla y lo informa
PatricioK: no llegan camisas rotas a la tienda
PatricioK: no malgastaste 40$
MiguelB: Okay contrátalo y lo metes en el proceso y encuentra el roto devuelve la camisa al área de Corte ahora la camisa tiene un costo superior al inicial. Qué valor generaste?
PatricioK: que no se pierda una venta e 40$, de hecho que no se pierdan n ventas todo por el mismo costo de 5$ adicionales
MiguelB: Tiene que haber algo más eso es lo que quiero averiguar de lo contrario No valió la pena la lágrima de Gustavo
PatricioK: como qué? que se pueda vender más barato? que se pague menos y se venda más? no termino de entender tu diyuntiva
MiguelB: Que se aseguré que el desarrollador mejora.
PatricioK: no es el papel del tester
MiguelB: Tradicional
PatricioK: el desarrollador tiene que mejorar por propia iniciativa
PatricioK: no podes ponerte en juez y jurado del desarrollador, tenes que ponerte en papel de colaborador de mejora del producto final *con* el desarrollador
MiguelB: No es mi problema ahí le encontré el roto. defiendase Como Puedas. págame mis 5 paga los 40 y el dueño pague al desarrollador Qué valor generamos?
PatricioK: encontraste el roto, buscaste la causa la informaste, permitiste que eso no vuelva a suceder, y por el modico precio de 5$ evitaste pérdidas de n*40$, que esa marca no pierda ventas de otros productos por reputación de mala calidad, que la fábrica pueda optimizar sus procesos
MiguelB: Son mis argumentos. Eso lo digo a diario. Mi pregunta es: hay algo más allá? O eso es todo?
PatricioK: te parece poco?
PatricioK: te doy un ejemplo concreto
MiguelB: Te parece poco una Polaroid? Un hotel? Un periódico?
MiguelB: Algunos pensaron que era poco y salió cámaras digitales, Netflix, uber, airb&b, Facebook
MiguelB: Tal vez concluyamos que eso es todo pero quería hacer la pregunta y abrir el debate
PatricioK: una empresa telco para la que hicimos un proyecto de automatización descubrió gracias a nuestro trabajo que estaba perdiendo todos los ingresos en cierto escenario de roaming con brasil. eso quedó sin detectar durante no saben cuanto tiempo (quizás años) porque no estaba incluido en proceso de testing previo a nuestro trabajo, y no generaba errores detectables. Las pérdidas pueden haber sido millonarias.
PatricioK: ahí tenes un valor con ejemplo concreto. Si se hubiese hecho QC adecuado en el desarrollo, esas pérdidas se habrían evitado
PatricioK: así y todo, el post mortem generó valor concreto al cerrar esa herida
FranciscoA: @?MiguelB? el valor agregado que tiene un tester (viendolo en un producto final *una camisa*) es que al revisar el producto previo a la terminación, si se encuentra alguna observación ahorras en costos de la persona que dobla, así como de la persona que acomoda, de la persona que embolsa, de la persona que empaqueta, de la persona que traslada, de la persona que acomoda en la tienda. Y al encontrar ese defecto antes de salir haces que la tienda ahorre en esos gastos así como también tenga una buena imagen ante el mercado y sus competidores. También del mismo modo si no lo se encuentra se hacen esos gastos antes mencionados de ida (entregar el producto) también de vuelta (devolución del producto) y también sé pierde en el costo final del producto ya que por la devolución tienes que entregar otro producto sin recibir el pago del mismo. Del mismo modo el incluir a un tester no va a ser quien modifique el modo de trabajar del programador ya que el se tiene que enfocar en el producto que se le entrega pero no tiene que enfocarse en quien (que programador) realizó dicho trabajo
MiguelB: Gracias @?FranciscoA?. Sigue abierto el debate. En mi opinión el que encuentra errores en la camisa puede proporcionar más valor que ahorrar costos. Creo que su mayor valor está en identificar tendencias y proponer acciones para remover las causas raíz.
¿Quieres unirte al Slack TestersDifusion?
[gdlr_button href=»https://testingbaires.com/nuevo-slack-testersdifusion/» target=»_self» size=»medium» background=»#000000″ color=»#ffffff» border_color=»#999999″]clic aquí[/gdlr_button]
Gracias por seguirnos y si encuentras algún defecto, por favor envíanos la evidencia a: info@testingbaires.com
Newsletter
¿Quieres suscribirte a nuestro Newsletter y recibir las noticias acerca de nuestra actividad? Ingresa al siguiente enlace y completa el formulario.
[gdlr_button href=»https://app2.fromdoppler.com/Lists/FormProcessing/Form?idForm=hJM6KEWJnAWSWR%2bz3tLgGw%3d%3d» target=»_self» size=»medium» background=»#000000″ color=»#ffffff»]Clic Aquí[/gdlr_button].
