Uso Feedly para gestionar los post de los blogs que sigo. Diariamente, hago una selección de artículos para leer en el momento y otros los guardo para chusmearlos luego. Esta selección la hago por categoría, nombre de autor (algunos leo con más frecuencia que otros) y también hago selección por título.
En este contexto, todos los días me encuentro con que aún se sigue escribiendo (bastante) sobre la "rivalidad", "diferencia", importancia de los testers por sobre los developers o viceversa. A esta altura del partido, creo que este debería ser ya un tema superado. Por esta razón, es que he decidido no leer más artículos con estos contenidos. Títulos tales como "Developers vs. Testers", "¿Por qué los programadores 'odian' a los testers?", "El espíritu destructivo de los testers" están para mi obsoletos. Opino que ambos (devs y testers) deberían estar bajo un mismo rótulo: software makers, o simplemente software developers. Ya no tiene mucho sentido volver sobre lo mismo y debería ser un tema superado en la comunidad del software. Hay que pasar al siguiente nivel de la discusión.
Germán
No puedo estar más de acuerdo, las culturas más avanzadas en el desarrollo de software no tienen esa discusión, bien porque los desarrolladores han entendido la importancia de la calidad en su trabajo y el valor de la figura de los testers, bien porque los testers han entendido el valor de la tarea de los desarrolladores y la importancia de facilitarla, bien porque ambos colectivos se orientan al delivery del software con calidad y no a demostrar quién es más listo que quién.
ResponderEliminarSaludos desde Barcelona!
-- Mauri
Gracias Mauri por leer y comentar.
EliminarSaludos!
Soy SQA hace 1 año pero Dev hace 10. Es verdad que a los Dev no nos gusta que nos digan que lo que hicimos está mal o que nos digan como se debe hacer, Cuando inicie mis labores como SQA, fue un poco agrio, ya que trabajo con mas de 80 Dev y varias empresas de Desarrollo. Las discusiones no paraban pero al final tenia que hacer cumplir las Normas QA, gracias a mi experiencia en Desarrollo pude hacer menos dramático el cumplimiento de las Nuevas Normas, pero al final pudimos lograr un ambiente mas propicio, después de casi un año ya un 95% de los Dev entendían de buena manera las Normas de Calidad y en conjunto pudimos elevar la calidad en el Desarrollo, tanto en la calidad del Código, como en el Rendimiento y disminuir los tiempos de Depuración.
ResponderEliminarCreo que Muchas veces se da esta discusión porque los Testers o SQA no entienden el Trabajo de los Dev y tambien viceversa.
Colaboración es lo que realmente se necesita.
Gracias Hardy por leer y comentar. Efectivamente, este trabajo debe ser netamente colaborativo.
EliminarSaludos!
German el tema se aborda con un nuevo enfoque en el libro "How google tests code". Ellos implementaron un rol de developer que testea, un rol que es una especie de evangelista del testing para los devs, y un rol que es testing puro de aceptacion. Por otro lado a los testers cada dia se le pide que sean mas tecnicos, por los avances de las tecnologias. Tenes razon en esquivar cualquier discusion porque ciertamente atrasa
ResponderEliminarGracias por comentar Gastón! .. y por la referencia. Lo voy a leer.
EliminarTe dejo un saludo
En nuestra empresa tenemos 3 tipos de developers: el App Developer, el Testing Developer y el User Developer. El primero se dedica a desarrollar las funcionalidades esperadas por el usuario (concretamente las historias de usuario), el segundo tiene una perspectiva de calidad interna del codigo y trata con temas de refactorización, comentarios, reuso, integración continua, automatiza, diseña test unitarios y de integración, y el tercero hace evolucionar el software desde la visión pura y exclusiva del usuario. Los tres son developers para nosotros y "crean software". Unos escriben mas código que otros pero al fin todos buscan la máxima calidad del software que estamos construyendo en cada sprint.
ResponderEliminarGracias por comentar Nahuel! Interesante enfoque. Lo único que me parece (a simple vista) es que necesitas gente muy skilled para desarrollar esto. ¿No?
EliminarTe dejo un saludo!
Bueno en nuetra compañía Test-Cloud, no se puede llegar a ser tester senior sin tener como mínimo 10 años de experiencia como programador senior ya que para evaluar aspectos de calidad de una aplicación, ayuda muchísimo saber entre otras cosas como hacerlas. Además en ciertas ocasiones las pruebas no son funcionales, sinó también de evaluación de la calidad de la arquitectura o de la optimización o de la arquitectura del repositorio de datos. Por lo tanto coincido y promuevo la existencia de Ingenieros de QA que sean desarrolladores senior.
ResponderEliminarGracias Diego por leer y comentar. ¡Veo complicado ser tester senior en tu compañía :) !
EliminarDe todas maneras, me parece que el software makers no necesariamente tiene que tener todos los roles. Es algo complicado de lograr. Hace un tiempo escribí sobre "Talent Pool" y la escasez de profesionales en el rubro informático y me parece que debe ser complicado llegar a un equipo como el que detallás. ¿Cómo lo ves desde adentro?
Te dejo un saludo!
Yo estoy con el comentario de Nahuel y le agregaría a los testers funcionales, esos que desde los requerimientos o use cases te sacan test plans y escenarios pero siempre desde un punto de vista funcional. He aquí el problema de la rivalidad o el desencuentro, pues cuando una de estas personas de QA encuentra una combinación rara y sugiere una solución que puede ser compleja, el Dev trata de explicarle que el escenario es poco racional, pero no se llegan a entender, porque también a veces el de QA no quiere aceptar que no es un bug, o no es un bug que justifique una refactorizacion tan compleja.
ResponderEliminarNo se si me explico, pero hay diferentes niveles y no siempre conviven bien entre si, creo que de momento eso lo he visto dentro de una sola empresa, como mucho.
Todos son necesarios y cada uno debe aceptar sus limitaciones y debe haber alguien que los coordine y proponga la mejor interacción ;)
Gracias Gastón por leer y comentar. Entiendo lo que decís. Me parece piola y me gusta el tema del final. Esto es básicamente (palabras más, palabras menos) un entorno ágil, dónde tendrías un Product Owner y un Scrum Master haciendo las veces de coordinadores y de soporte a la toma de decisiones.
EliminarTe dejo un saludos!