¿Cómo conviven en su empresa los Analistas, Programadores y Probadores?

developers vs testersComo para comenzar, estoy convencido que el abismo que años atrás existía entre el Programador y el Probador, ya no es tan grande, hasta me arriesgaría a decir (por experiencias personales) que comulgan en muchos aspectos.

¿Será porque desde hace muy poco tiempo, herramientas que permiten la automatización del testing ha facilitado el acercamiento entre las partes? … ummm….para pensarlo.

Por otra parte, muchos Analistas Funcionales se han mudado al área de los Probadores (como así también Programadores, no quiero dejar de lado este hecho) con lo cual el conocimiento y experiencia de ambos se potencia.

Hay casos en los que una persona con extracción funcional se muda al área de QA&QC, y es aquí donde el perfil de Analista Probador toma «presencia» y se ven beneficiadas las áreas involucradas, ya que el Analista Probador podrá entender el alcance y la profundidad de un requerimiento, como así también hacer uso de las distintas herramientas que giran en torno al mismo, conocimiento de antemano el impacto que tendrá.

Ahora bien, no todas las empresas (son las menos, creo) tienen estas tres áreas separadas, por así decirlo ya que hay proyectos en donde conviven varios de sus integrantes. Incluso hay empresas donde dos de estos perfiles se encuentran en una sola persona, y hasta puedo apostar que las tres funciones pueden estar a cargo de una sola persona, ¿no es cierto? ¿o me equivoco? jajajaja («…es lo que hay…» como se suele decir cotidianamente en Argentina)

Es obvio que por cualquiera de los dos esquemas, (a) teniendo los tres perfiles separados ó (b) teniendo lo dos o tres a cargo de una sola persona, obliga a gestionar los recursos de una cierta manera e impacta en el proyecto indudablemente.

Me cabe aquí una pregunta, ¿todo lo escrito hasta aquí aplica tanto a proyectos del tipo waterfall y en agiles también?

La cuestión es, y para llegar al foco de esta discusión tras esta breve intro, ¿cómo se llevarán en el cotidiano (léase : en el día a día) estas personas entre sí? ¿qué ventajas y desventajas pueden ver en cada uno de estos dos esquemas? ¿puede llegar a haber ventajas con el segundo esquema donde una persona cumple con el rol de Analista Funcional y Programador, o, con el rol de Programador y Probador?

Y la última pregunta que me hago/que les hago y que esta asociada a todo lo que hasta ahora he escrito: ¿en cuánto influye el trabajo remoto en cada uno de estos esquemas? ¿podría llegar a facilitar el trabajo remoto si un proyecto se «mueve» bajo el esquema (b)?

.

¿Te sentís identificado con algo de aquí?

¿Has tenido alguna experiencia similar?

¿En tu empresa hay alguno de estos dos esquemas aquí planteados?

Gus Terrera

Apasionado por el agile testing y la ia.

Esta entrada tiene 6 comentarios

  1. admin

    El siguiente comentario fue publicado por Paul Welsch en el debate que generé dentro del grupo de discusión TESTING & QA en LinkedIn.

    Por un lado pienso que: No se recomienda que los desarrolladores de software sean quienes ejecuten las pruebas, esto si o si, tiene que pasar por una área de testing especializada y las pruebas se ejecuten en funciones de los rq funcionales más que ver como se comportan o si se cumple determinadas condiciones en el código.
    Con respecto a las metodologías, para esto depende de dos factores que son primero el organizacional y el otro el tipo de software a desarrollar, ya que para un sistema de seguridad critica, no podemos usar una metodología agil.
    Respecto de las competencias, si es o no Analista Técnico Funcional, que comparto con Ud., lo veo muchos en los reclutamientos, es un invento, y se da porque pienso que no existe organización de quienes hacemos IT en como ocurre en otras disciplinas.
    By Paul Welsch

  2. admin

    El siguiente comentario fue publicado por Carolina Ragazzon en el debate que generé dentro del grupo de discusión TESTING & QA en LinkedIn.

    En base a mi experiencia, es conveniente que muchos sean los que realicen distintas pruebas.
    Los programadores tienden a probar lo que más les conviene, un conjunto de pruebas mínimas para ver si algo funciona y así lo pasan al siguiente paso. Rara vez pude verificar que se habían hecho varias pruebas, reiterativas, iterativas, por bien y por mal, etc.
    Siempre reclamé a los programadores puros que no hacen las pruebas suficientes para poder continuar con tras pruebas. El ejemplo más burdo es una división. Jamás pruebas si alguno de las partes no existe. Si alguna es cero. etc. Y como eso, el caso del formato de fecha y hasta fecha inválida (o anterior al 1900).

    Luego se deberían realizar distintos tipos de pruebas o testeos, involucrando ya tanto a QC como QA y Homologación, si existe. El usuario también debe poder participar de pruebas ya cercano a la posible implementación, o como condición de UAT.

    Hay muchas evaluaciones que los distintos grupos involucrados pueden realizar y que seguramente no fueron consideradas en su momento por los funcionales, diseñadores, programadores, etc. En consecuencia, son los programadores que primero deben realizar las pruebas suficientes y con un grado de satisfacción alto para poder pasar el módulo, código o sistema al siguiente nivel de evaluación. Pero deben realizarlas. Es increíble como algunas veces en su afan de terminar, presentan código que ni siquiera puede compilar!

    Ojalá las empresas realmente se den cuenta que en sistemas no se deberían superponer roles para reducir cantidad de personas y sueldos.
    By Carolina Ragazzon

  3. admin

    El siguiente comentario fue publicado por Jorge Alberto Palacios en el debate que generé dentro del grupo de discusión TESTING & QA en LinkedIn.

    Buenos Días, por mi experiencia existen múltiples factores y para todos los gustos, no todas las empresas cuentan con test automatizado, el conocimiento de los integrantes es variado, calculo por muchas razones, no olvidemos que estamos en Argentina, y el factor dinero o costo es un tema complicado, lo que hace que en muchos casos se quiera unificar los 3 sectores en uno solo, (actualmente hay muchos avisos publicados, ya que me encuentro en plena búsqueda que apuntan a eso), lo enmascaran dentro del Analista Técnico Funcional con testing, por otro lado como existe la necesidad de trabajar la gente se va acomodando a las distintas circunstancias, ¿que esta bien y que esta mal?, no lo se, me vaso en mi experiencia, en los lugares donde los 3 sectores están bien diferenciados, me resulto muy positiva la experiencia, en donde cada cual cumple su rol, y en las reuniones si bien se discuten las distintas posiciones, se trata de llegar a una solución determinada con la opinión de cada cual, ahora donde todos saben todo, observo que llegar a la solución es un tanto mas difícil, ya que se pierde tiempo en criticar lo que ya esta realizado y como, se ven muchos roses y de interferencias de terceras o cuartas personas en los grupos, con lo cual para mi se termina perdiendo un poco el foco, no se es mi opinión, ojo a lo mejor a esto ultimo se debería incluir el respeto no solo profesional sino individual, cosa que últimamente esta faltando en muchos lados.

    Saludos y nos seguimos leyendo
    Buena jornada…!!!
    By Jorge Alberto Palacios

  4. admin

    El siguiente comentario me lo dejó Leonardo Romano (Leo es un ex-compañero de trabajo) en Google +

    «…
    Las vueltas de la vida me han llevado a hacer pruebas eatando en todos los perfiles. Lo que puedo asegurar es que al tener experiencia de los distintos puntos de vista (desarrollador, analista funcional, tester y analista tester) y conocer los ciclos completos del software te potencia para cualquiera de los puestos que quieras ejercer.

    Hoy me siento totalmente capacitado para ejecutar casos unitarios, de sistema, de integración, hacer ers, planes de testing, manuales de calidad, de procedimientos y fundamentalmente casos de uso.

    Creo que estos ultimos estan tendiendo a desaparecer con el tiempo, por diversos motivos. Puede ser por vagancia, por falta de calidad, por desconocimiento o por el uso de nuevas metodologias, pero se ven cada vez menos casos de uso.

    Con respecto a si una persona ocupa todos los puestos en simultaneo para un mismo desarrollo no me parece el escenario ideal, ya que cuesta mucho pasar de un bando a otro en medio de un proyecto. No digo que sea imposible pero si que es dificil.

    Lo que si veo es que muchas empresas tienden a cubrir varios puestos con un solo recurso mal escudandose en argumentos como el uso de metodologias agiles o dinamismo.

    Como es la relación entre los diferentes perfiles es dificil de contestar, ya que depende mucho de la estructura de la organización, la cercanía de los equipos de trabajo, la metodología utilizada y principalmente de la gente que compone cada equipo. No nos olvidemos qie todos somos distintos y reaccionamos diferente al mismo estimulo.

    Igualmente considero que si las politicas organizacionales son correctas, los lideres fuincionan bien y bajan una linea correcta se convive y hasta te digo que se forma una buena sinergia entre los equipos de trabajo.

    …»

    «…
    Cuando hablo de la tendencia a desaparecer de los casos de uso me refiero a que muchas empresas los están omitiendo, ya sea porque parecen ser documentos irrelevantes (para ellos), ya sea porque utilizan metodologías «agiles», en donde cada uno de sus miembros cubre casi cualquier posición, entonces es innecesario realizarlos, o directamente el uso de user storys termina siendo el documento clave en estas metodologías, ojo que también he visto que no incluyen casos de uso en la negociación de los contratos.
    La realidad es que, si bien implica mucho tiempo su diseño, tiempo que normalmente es usado para otras cosas, para mi es muy necesario contar con este nivel de explotación para tener un entendimiento de cada uno de los eventos del sistema.
    Está claro que uno se puede ir dando cuenta con el uso del sistema y apoyado por un funcional, de hecho cuantas veces hemos armado casos de prueba desde funcionales y sin disponer de casos de uso? Como diría alguien en el texto… es lo que hay… jaja.
    Igualmente insisto, me parece un documento clave tanto para desarrolladores como para testers. Matarlo es un despropósito, deberíamos ponerlo en cautiverio 🙂

    …»

    Gracias Leo!
    Como siempre

  5. Nelson Pataquiva

    Es mi caso, soy administrador de empresas y por esas cosas de la vida termine en el mundo del testing, me apasione por el tema y enfoque mis estudios de tal manera que se acrecentaran mis competencias (me sentía inferior a un desarrollador) ahora creo que mis raíces funcionales en mix con mi pasión que son las pruebas, es un mezcla fabulosa.

    1. admin

      Excelente Nelson, y esas experiencias como la tuya, son las que ayudan a que siga creciendo esta actividad profesional que cada día se profesionaliza más.
      Además, sin lugar a dudas, te permite tener otra perspectiva de los temas por tu extracción. Que bueno!!!

      Nelson, te invito a que sugieras artículos y si queres, podes mandarme que los publico.

      Te mando un fuerte abrazo y gracias por tu participación.

Deja una respuesta