Ver la versión completa : Java Tarifas QA de software / Testing
Estimados apañeros,
recientemente estoy envuelto en un proyecto final de estudios en el que tengo que realizar un proyecto de calidad de software. La idea es definir todos los procesos que envuelven un proyecto de testing, tanto funcional como no funcional, que incluya pruebas estaticas, dinamicas, white box/black box, etc.
El tema es que tengo que introducir tarifas de los trabajadores envueltos en un proyecto de este tipo y por ahora he empezado a sondear el mercado, pero no he tenido mucha suerte preguntando a las empresas acerca de esto, entiendo que son bastante reticentes a dar pistas de sus tarifas a tipos que no van a ser potenciales clientes.
¿Alguien sabe en cuanto se esta moviendo el mercado, al menos para los puestos de Testing Lead y Tecnico de testing funcional? Cualquier ayuda se agradece un montón.
Un saludo.
Las empresas no te pueden ayudar porque lo más normal es no tener ninguno, o subcontratarlos.
La respuesta corta es que los hay contados con los dedos de una mano. Tiene que ser alguien que venga de trayectoria profesional técnica y le diera por pasarse a hacer test y automatización, que no es nada glamuroso. Como hay pocos pillan buenos puestos y se les paga decente. Una pasada por CV-Library me dice que sobre 30k un medior y de 40 a 60k al año un lead.
Si lo que quieres es un puesto de tester manual, salario mínimo o subcontrata a europa del este. Los he conocido de estos con años y años de experiencia y no soy capaz de apreciar la diferencia con los juniors excepto que están más resabiaos.
^MiSaTo^
10/10/2016, 22:36
Mi experiencia es muy distinta a la de Pakoito. Es más, he conocido desde empresas de testing sólo, consultoras como CapGemini que tiene una división sólo de testers (y no cobran muy mal) y por último freelances que deben cobrar muy bien porque 2 que venían a mi empresa tenían un Tesla Model S.
La verdad es que no se cuánto cobran pero aquí en Holanda puedo asegurar que no viven mal. Cobran menos que los informáticos, eso sí.
EDIT: Para que veais que no miento, este es uno de los últimos tester freelances de mi proyecto (ABN Amro era el cliente, un banco tocho de aquí) https://www.linkedin.com/in/simonsaysnomore
Yo sólo he topado con los freelancers excepto en mi empresa actual que los cazan frescos de la universidad, pero la mayoría al tiempo o se van o pasan a desarrollar.
^MiSaTo^
11/10/2016, 00:31
Yo sólo he topado con los freelancers excepto en mi empresa actual que los cazan frescos de la universidad, pero la mayoría al tiempo o se van o pasan a desarrollar.
Sí? Aquí es diferente. Conozco a muchos que llevan muchos años de testers, van a conferencias de lo suyo, etc. Y son mayores eh? Ese que he puesto ahí arriba tendrá 45 años fácilmente.
No todos son así por supuesto y tb tuvimos a un indio que no hacía el put0 huevo que luego despidieron. Pero en general son otra parte más del equipo como los diseñadores gráficos o los UX.
Entiendo que esto por países y empresas será distinto
Yo estoy con Pakoito normalmente los tester manuales se subcontratan y los sueldos suelen ser bastante bajos, suelen tener una rotacion bastante alta ya que se considera este puesto como algo provisional para aguantar mientras se consigue un trabajo mejor. Y aunque es cierto que hay empresas que tienen areas de pruebas sus sueldos son inferiores a los que tienen sus compañeros que se dedican a desarrollar.
Estimados apañeros,
recientemente estoy envuelto en un proyecto final de estudios en el que tengo que realizar un proyecto de calidad de software. La idea es definir todos los procesos que envuelven un proyecto de testing, tanto funcional como no funcional, que incluya pruebas estaticas, dinamicas, white box/black box, etc.
El tema es que tengo que introducir tarifas de los trabajadores envueltos en un proyecto de este tipo y por ahora he empezado a sondear el mercado, pero no he tenido mucha suerte preguntando a las empresas acerca de esto, entiendo que son bastante reticentes a dar pistas de sus tarifas a tipos que no van a ser potenciales clientes.
¿Alguien sabe en cuanto se esta moviendo el mercado, al menos para los puestos de Testing Lead y Tecnico de testing funcional? Cualquier ayuda se agradece un montón.
Un saludo.
Para un proyecto de final de estudios...inventatelo.
Bueno, yo mismo he trabajado en ese tipo de puestos, pero me temo que no sé cuánto le cobran al cliente final. Eso sí, el proyecto de testing abarcaba no uno sino varios programas, así que la cosa es que son ya varios ceros.
Y bueno, al menos no contrataban extranjeros, sino informáticos de la tierra... y me parece que el que más experiencia tenía en el equipo cuando estuve fui yo, así que ^^U
Y por lo que me contaron meses después, me parece que pocos pasaron del contrato de prácticas... al menos creo que algunos pasaron a tener sueldo de empleado. Por lo menos contrataron gente y les dieron cursos y experiencia.
Las empresas cuando trabajan para un gran cliente cobran desde 30 hasta los 100 euros/hora en bruto: en según qué casos, incluso mas. Descuenta de ahi todo lo demás (impuestos, salarios, gastos, etc.).
Lo que yo conozco va de 26k a 32k en españa.
Enfocado a apps moviles.
Tambien lo hay de eso de 12k al año, pero hablo de cosas serias, siendo lo mas bajo test manual y lo mas alto o incluso mas ingenieros que usan herramientas para automatizar los test
siendo lo mas bajo test manual y lo mas alto o incluso mas ingenieros que usan herramientas para automatizar los test
Esto no lo he entendido ¿Que es más barato hacer tests manuales que automatizados? Porque me parece que es al revés, más que nada, por el tiempo de ejecución y el personal contratado.
Esto no lo he entendido ¿Que es más barato hacer tests manuales que automatizados? Porque me parece que es al revés, más que nada, por el tiempo de ejecución y el personal contratado.
Test manuales los puede hacer un mono. Es sentarse delante del ordenador, ejecutar la aplicación y ponerse a probar cada cosa. No te hace falta saber programar, ni siquiera saber en qué lenguaje está programado el programa, ni nada. Sólo clickar y rellenar campos.
Sin embargo ara hacer test automatizados necesitas a gente con experiencia y que sepa.
Test manuales los puede hacer un mono. Es sentarse delante del ordenador, ejecutar la aplicación y ponerse a probar cada cosa. No te hace falta saber programar, ni siquiera saber en qué lenguaje está programado el programa, ni nada. Sólo clickar y rellenar campos.
Sin embargo ara hacer test automatizados necesitas a gente con experiencia y que sepa.
Para hacer monkey testing de una regresión completa de un producto necesitas semanas. Tienen que coger el doc o excel o lo que tengan, e ir por cada uno de los casos de uso para los distintos estados en cada uno de los cacharros y sus versiones. Se puede paralelizar y escala linealmente, asi que si quieres reducir el tiempo sólo tienes que contratar a más testers. Por ejemplo, había empresas en India donde cada tester tenía un model de móvil distinto asignado, y los subcontratabas temporalmente para que te dijeran qué modelos daban problemas.
Con buena arquitectura y test automatizados es unas horas como mucho en lo que corren en el servidor. Tienes los resultados inmediatamente junto con vídeos y stacktraces de los problemas. Para los desarrolladores ésto es chachi, porque la ownership de los tests es compartida con QA, y además sabes qué condiciones exactas causan los problemas y además tienes el código del test como referencia. Luego añades un par de días de smoke testing manual de un par de personas para ver si hay algún fallo pequeño que se haya pasado.
Eso en papel, claro. Cuando ves las rageadas en el foro de programación, normalmente va porque alguien no se adhiere al segundo paradigma y hace que todo el equipo se ralentice y el producto requiera más tests manuales.
Esto no lo he entendido ¿Que es más barato hacer tests manuales que automatizados? Porque me parece que es al revés, más que nada, por el tiempo de ejecución y el personal contratado.
Yo hablo de sueldos de tester, no de precio por servicio o hora.
Y obviamente un test manual que es seguir un guion, rellanar un excel/jira y elevar bandera roja es mucho mas barato que un ingeniero que automatiza tareas y conoce servicios que dan estadisticas y pantallazos
Yo hablo de sueldos de tester, no de precio por servicio o hora.
Y obviamente un test manual que es seguir un guion, rellanar un excel/jira y elevar bandera roja es mucho mas barato que un ingeniero que automatiza tareas y conoce servicios que dan estadisticas y pantallazos
Pero es que eso no es así. En parte es como dice Pakoito, que se necesita un manual de cómo funciona el programa (cosa que no te suelen dar, porque es una beta, y los documentos de diseño suelen ser "secretos") y el que prueba la aplicación tiene que estar familiarizado con otras similares y el sistema en el que se prueba.
Pero es que la lista de casos de prueba también hay que hacerlo, y eso tampoco te lo dan hecho, y se tiene que encargar otra persona. Al menos, a mi me lo daban hecho, y al final, tenía que añadir a mano unos cuantos más para justificar una "bandera roja" por un bug grave que he encontrado al margen de las pruebas unitarias. A lo que voy es que ya son al menos dos personas (una es, al menos, técnico especializado) que tiene que trabajar en modo manual.
Y te añado más, nuestra política consistía en que había que localizar la mayor cantidad de errores posibles. Eso de "no se ha podido realizar la prueba por un error previo" no existía, lo que significaba que, en algunos casos, nos teníamos que ir al código fuente a poner un parche, o inventarnos algo para conseguir instalar un programa rebelde (y es que han sido varios los programas que me han pasado en formato Windows para Linux, o con librerías que faltaban, o con pasos de instalación que se habían omitido en el manual). Pues eso, que el tester tampoco podía ser un mono amaestrado, aunque se le pagase igual.
Aparte de que luego, hay pruebas que de forma automática se hacen en cuestión de minutos, en lugar de horas. Por ejemplo, las pruebas de redundancia o de comentarios en código Java. Las pruebas de estrés tampoco se pueden hacer a mano sin contratar a miles de personas con sus equipos. Las pruebas de rendimiento no se pueden hacer a "ojímetro"...
Entiendo que muchas veces se tarda muchisimo en automatizar una tarea, porque hay que programar tanto el "automatizador" como el script a ejecutar, pero hay muchísimas herramientas disponibles para los lenguajes más famosos, y si el código está bien hecho da igual cómo programes la interfaz, pueden mandar al programa de test a que ejecute las funciones de "segundo nivel" (nunca me acuerdo del nombre técnico ^^U) y a esperar resultados.
Pero es que eso no es así. En parte es como dice Pakoito.....
El manual no lo hacen los ingenieros de QA, y sinceramente, a la gente no se le paga sueldazos por saber leer un manual.
Los test cases no los desarrollan los ingenieros rasos de QA, en todo caso un manager de testing.
Y no, las pruebas de redundancia o de comentarios no se consideran test de QA.
Las pruebas programaticas de QA suelen involucrar varios servicios y codigo ad-hoc para poder lanzar instancias de la aplicacion en distintos entornos controlados y no controlados y poder obtener metricas y resultados evaluables, ya sea de forma manual o en forma de preciosas estadisticas en un panel.
Pero vamos, que en resumen, automatizar no es hacer testing.
El manual no lo hacen los ingenieros de QA, y sinceramente, a la gente no se le paga sueldazos por saber leer un manual.
No, los manuales deberían hacerlos los propios desarrolladores de la aplicación, pero eso es como los comentarios del código, las buenas prácticas y la documentación del código: nunca hay tiempo para hacerlo :lol:
O al menos, los diseñadores del mismo, pero suelen ser documentos incompletos, de versiones alpha, y con información muy vaga.
Así que el tester tiene que imaginarse cómo funciona el programa, y eso es tiempo, dinero, y muchas posibilidades de tener un quebradero de cabeza o un negativo crítico :P
Los test cases no los desarrollan los ingenieros rasos de QA, en todo caso un manager de testing.
Ese es mi punto: ya tienes dos personas trabajando, y una de ellas es un especialista, por lo que los costes aumentan considerablemente frente a tener un "currito" apretando un botón del autoanálisis, o un senior creando el automatizador.
Y no, las pruebas de redundancia o de comentarios no se consideran test de QA.
No sé si estar de acuerdo en eso, pero de todas maneras son pruebas que vienen en los programas de testing y se hacen de todas formas.
Nosotros teníamos una serie de porcentajes para considerarlo warning, fallo leve e incluso fallo crítico.
Las pruebas programaticas de QA suelen involucrar varios servicios y codigo ad-hoc para poder lanzar instancias de la aplicacion en distintos entornos controlados y no controlados y poder obtener metricas y resultados evaluables, ya sea de forma manual o en forma de preciosas estadisticas en un panel.
Pero vamos, que en resumen, automatizar no es hacer testing.
Lo bueno de Java es que es tan modular que puedes acceder desde fuera a cualquier parte del código, por lo que puedes invocar servicios o lo que quieras ignorando el resto del programa y hacer tus métricas.
Yo he usado, por ejemplo, BadBoy para hacer unas métricas de velocidad de acceso a un webservice, que me hacía 1000 peticiones por segundo. Imagina tener que hacerlo sin automatizarlo. Y el script lo escribía en 30 segundos o menos.
Por eso digo, en casi todos los casos, especialmente en Java, automatizar las tareas sale más barato que hacer las pruebas a mano. Otra cosa es que tengas que hacer pruebas funcionales y empieces a hacer clic en botones y demás, pero las llamadas a los métodos que invocan esos botones los puedes hacer desde fuera, de forma automática, y te sobra la interfaz.
IMHO el manual no lo tiene que hacer el programador, el programador tiene que programar y no hacer miles de cosas para que después te echen la bronca de que algo no esta hecho, pues porque llevo dos días haciendo el **** manual...
Hay gente que se dedica hacer manuales, no es fácil hacer un buen manual, yo lo veo como escribir un libro, y si quieres hacer una aplicación decente dedicate a programar y que otros hagan los iconos, diseño del interface, manual, etc.
En Españishtan es mejor pagar 1.000€ a un tio que haga de todo y ya esta, despues te pegas un monton de horas para hacer o retocar unos iconos de mierda cuando un diseñador gráfico en la mitad de tiempo te haría un trabajo muchísimo mejor, pero claro hay que pagarle también, aunque la ventaja es que el programador podría seguir implementando otras funciones o corrigiendo errores.
SplinterGU
19/10/2016, 16:26
aca drumpi se esta confundiendo, pensando que test automatizado es un tio que usa un script que no hizo para probar algo... no es asi, el testeo automatizado lo hace el profesional que lo automatiza (no tiene sentido que uno haga el script y otro lo corre, directamente lo corre quien lo hace, otro luego puedo reutilizar, pero el test en cuestion lo hace quien lo automatiza), haciendo scripts o usando herramientas de automatizacion de testeos, en ambos casos requiere conocimientos para llevar a cabo la tarea, y si bien puede parecer que lleva mas tiempo, por el contrario los reduce, en las iteraciones repetitivas de un testeo, o en testeos integrales o de stress.
ser tester no es agarrar un programa y empezar a probarlo a ver que sale, los tester siguen lo que se llama "casos de prueba" o "test case", donde especifica cuales son los comportamientos que debe tener el componente a testear, por ejemplo, si es un input en un campo, validar longitud, tipo de dato, etc... pueden ser infinidad de cosas, pero deben estar incluida en el "test case"... esos test case, no son la documentacion del producto, ni tienen ni pretenden serlo... los test case, ni la documentacion, no las desarrolla el programador, por el contrario, el programador deberia recibir el mismo documento (o casi, informacion mas o menos) para hacer el desarrollo...
desarrollador, recibe documento o pedido con detalles de comportamiento de lo que se necesita desarrollar
QA, verifica que lo desarrollado coincida con el documento o pedido
y despues por otro lado, tenes los betatesters que esos son los que agarran la beta de un producto y ahi lo empiezan a probar por todos lados.
como sea, un perfil de automatizador, es mas valioso que un perfil de test manual... simplemente porque necesita tener una formacion diferente...
Swapd0: No, el manual definitivo no lo tiene que hacer el desarrollador. Al desarrollador se le da un documento con características que se deben implementar, pero este debe devolver un documento indicando la organización del código, los bloques funcionales, etc... y entre todo eso, cómo funciona la interfaz o cómo está implementada. Pero no es un manual como los que leemos, sino un documento hecho de forma rápida, que lo entienda un ingeniero o alguien familiarizado con los ordenadores. Es más, debería ser simplemente una corrección del manual de características con los cambios que se han hecho por problemas del diseño o cosas que no se han tenido en cuenta.
Quieras o no, el desarrollador debe hacer más que programar. Es un peñazo, pero debe DOCUMENTARLO TODO, y eso debería incluir un mínimo manual de uso, porque es el último que realiza cambios a la interfaz.
Splinter: no te equivoques, que yo he dicho que he tenido que hacer los scripts del análisis antes de ejecutarlos, a mi no me los daba nadie.
Los "test case" sí que me los pasaban ya hechos, pero teníamos gente que se dedicaba exclusivamente a ello, no nos venían hechos desde el cliente. Pero claro, si el test case te dice "generar un documento" ¿tú que haces? A mi no me daban un manual de uso (sólo es de despliegue). Así que iba y buscaba el típico botón de la hoja de papel blanca con la esquina doblaba, lo pulsaba y a esperar lo mejor. Generalmente funcionaba, pero luego te decías "¿y lo hará a través de archivo->nuevo...?", lo probabas y fallaba... y eso deberían considerarse dos test case diferentes.
O peor aun: ambos métodos te funcionaban, pero luego cogías, editabas el documento y te dices "¿y si le doy ahora para generar un segundo documento?". Le dabas al botón y ¡CRASH! ¿Qué haces? ¿pones fallo al generar el documento? ¿lo pones en la edición? Al final tenía que añadir otro test case, darlo como fallo crítico y mandarlo de vuelta... Bueno, no, tenía que realizar el resto de pruebas y después mandarlo de vuelta.
El chequeo manual es más efectivo en la localización de errores, pero mucho más lento, y por tanto, costoso. Pero todo lo que implica QA se hace en el grupo de QA, test cases incluidos, y si no hay una documentación del producto mínima, no puedes hacer nada. Yo no puedo probar un Hadooken si no me han escrito en alguna parte que se ejecuta con la combinación de botones tal, y eso es un manual de uso que viene de parte del desarrollo, pero no necesito un artwork de Ryu con flechitas de colores.
Yo por manual me referia al manual que se va a leer el usuario para aprender a usar la aplicación, y IMHO eso no lo debe hacer el programador.
El problema de documentarlo todo es que puede que se quede obsoleto, puedes cambiar el código y no cambiar la documentación... asi que últimamente lo que hago es que si hace falta escribir un bloque de comentarios es que el código no esta claro, asi que toca refactorizar.
Lo otro que comentas, no se donde trabajais pero lo normal es que el jefe cada día te diga haz esto, haz lo otro, etc... o sea que no hay nada escrito sobre lo que se va a hacer, simplemente vas implementando lo que de dice el jefe. Un día te llama y tienes que dejar lo que estés haciendo a medias para añadir una nueva funcionalidad de prisa y corriendo para que el cliente vea que somos serios y rápidos implementando nuevas funcionalidades.
Nathrezim
21/10/2016, 14:03
El problema de documentarlo todo es que puede que se quede obsoleto, puedes cambiar el código y no cambiar la documentación... asi que últimamente lo que hago es que si hace falta escribir un bloque de comentarios es que el código no esta claro, asi que toca refactorizar.
Precondicion y postcondicion de las funciones, la documentacion se debería hacer sola.
Y lo de las interfaces, supongo que os dan libertad porque os referireis a los contratos entre componentes software, porque lo que es la interfaz gráfica tiene que venir especificada en un documento de requisitos firmado con sangre por el usuario.
Yo por manual me referia al manual que se va a leer el usuario para aprender a usar la aplicación, y IMHO eso no lo debe hacer el programador.
El problema de documentarlo todo es que puede que se quede obsoleto, puedes cambiar el código y no cambiar la documentación... asi que últimamente lo que hago es que si hace falta escribir un bloque de comentarios es que el código no esta claro, asi que toca refactorizar.
Lo otro que comentas, no se donde trabajais pero lo normal es que el jefe cada día te diga haz esto, haz lo otro, etc... o sea que no hay nada escrito sobre lo que se va a hacer, simplemente vas implementando lo que de dice el jefe. Un día te llama y tienes que dejar lo que estés haciendo a medias para añadir una nueva funcionalidad de prisa y corriendo para que el cliente vea que somos serios y rápidos implementando nuevas funcionalidades.
A eso me refiero: el manual del usuario lo hace otra persona, generalmente un artista (al menos, hace más de 20 años) que solía encargarse también del diseño del empaquetado. Pero antes de eso, hay un manual para desarrollo, y al QA llega un borrador sucio hecho en 20 minutos ¡o debería!.
Y no son pocas las veces que me han llegado documentos desactualizados... hasta el punto de llamarme la atención el cliente por no haber implementado algo que no estaba en la documentación (así que había que poner cara de póker, decir que sí, hablar con el jefe (opcional) y ponerse a implementarlo tan rápido como sea posible).
Lo del tercer párrafo depende. Yo estuve trabajando en QA y en desarrollo, en cada sitio se trabajaba de forma diferente. QA era todo más cuadriculado, más automático ("hazme esto" y lo hacías, y al terminar, te pasaban otro programa). En desarrollo sí que era "deja eso en cuanto puedas y resuelve este bug" o "necesito que me implementes esto para mañana", y en ocasiones eso se traducía en "modifica todo el código entero porque el cliente lo quiere por orden alfabético, no por orden de llegada" (bueno, no es un buen ejemplo, pero es que no quiero decir ninguno concreto), y tenías que recurrir a "soluciones creativas".
SplinterGU
21/10/2016, 19:13
Swapd0: No, el manual definitivo no lo tiene que hacer el desarrollador. Al desarrollador se le da un documento con características que se deben implementar, pero este debe devolver un documento indicando la organización del código, los bloques funcionales, etc... y entre todo eso, cómo funciona la interfaz o cómo está implementada. Pero no es un manual como los que leemos, sino un documento hecho de forma rápida, que lo entienda un ingeniero o alguien familiarizado con los ordenadores. Es más, debería ser simplemente una corrección del manual de características con los cambios que se han hecho por problemas del diseño o cosas que no se han tenido en cuenta.
Quieras o no, el desarrollador debe hacer más que programar. Es un peñazo, pero debe DOCUMENTARLO TODO, y eso debería incluir un mínimo manual de uso, porque es el último que realiza cambios a la interfaz.
Splinter: no te equivoques, que yo he dicho que he tenido que hacer los scripts del análisis antes de ejecutarlos, a mi no me los daba nadie.
Los "test case" sí que me los pasaban ya hechos, pero teníamos gente que se dedicaba exclusivamente a ello, no nos venían hechos desde el cliente. Pero claro, si el test case te dice "generar un documento" ¿tú que haces? A mi no me daban un manual de uso (sólo es de despliegue). Así que iba y buscaba el típico botón de la hoja de papel blanca con la esquina doblaba, lo pulsaba y a esperar lo mejor. Generalmente funcionaba, pero luego te decías "¿y lo hará a través de archivo->nuevo...?", lo probabas y fallaba... y eso deberían considerarse dos test case diferentes.
O peor aun: ambos métodos te funcionaban, pero luego cogías, editabas el documento y te dices "¿y si le doy ahora para generar un segundo documento?". Le dabas al botón y ¡CRASH! ¿Qué haces? ¿pones fallo al generar el documento? ¿lo pones en la edición? Al final tenía que añadir otro test case, darlo como fallo crítico y mandarlo de vuelta... Bueno, no, tenía que realizar el resto de pruebas y después mandarlo de vuelta.
El chequeo manual es más efectivo en la localización de errores, pero mucho más lento, y por tanto, costoso. Pero todo lo que implica QA se hace en el grupo de QA, test cases incluidos, y si no hay una documentación del producto mínima, no puedes hacer nada. Yo no puedo probar un Hadooken si no me han escrito en alguna parte que se ejecuta con la combinación de botones tal, y eso es un manual de uso que viene de parte del desarrollo, pero no necesito un artwork de Ryu con flechitas de colores.
no, el desarrollador nunca hace ningun documento, "documenta el codigo" que es otra cosa muy diferente... esa documentacion nunca es para otro role que no sea el de desarrollador... o sea, que esta no tiene que ser una herramienta para QA... solo para otros programadores...
la verdad que el que arma el diseñado deberia ser quien arme los test case en el requerimiento, el cliente no lo hace, a menos que se trate de una fabrica de software y el cliente solo contrate desarrollo... si cada uno cumple con su rol como corresponde, QA deberia limitarse a probar lo que se le especifico en los "test case"...
para el documento de usuario (interno/externo), existe el perfil de documentador, y este se tiene que encargar de reunirse con todas las partes involucradas o necesarias y preguntar todo lo que necesite para poder realizar tal documento, pero un programador no debe hacer ningun documento salvo documentar el codigo en el mismo fuente (cosa que no siempre se aplica), o algun instructivo de instalacion o algo basico... lo mismo que las pruebas unitarias, que no es lo mismo que una prueba de QA, son pruebas basicas...
ahora que en algunas empresas hayan recursos que sean multiroles, eso es otra cuestion diferente... pero cada role tiene su responsabilidad.
-----Actualizado-----
Precondicion y postcondicion de las funciones, la documentacion se debería hacer sola.
Y lo de las interfaces, supongo que os dan libertad porque os referireis a los contratos entre componentes software, porque lo que es la interfaz gráfica tiene que venir especificada en un documento de requisitos firmado con sangre por el usuario.
si, siempre tiene que venir firmado por el usuario/cliente en el requerimiento, y aprender a no salirse de eso en el momento de desarrollo, porque sino es un nunca acabar, al usuario nunca le gusta el tono de gris que usaste para el boton o la altura o tipo font del input X... asi que se especifica todo y eso se hace, no se sale de eso...
totalmente...
^MiSaTo^
21/10/2016, 19:42
Uff qué waterfall suena eso
SplinterGU
21/10/2016, 21:29
a que te referis con "waterfall" ?
a que te referis con "waterfall" ?
https://en.wikipedia.org/wiki/Waterfall_model
SplinterGU
22/10/2016, 02:04
https://en.wikipedia.org/wiki/Waterfall_model
gracias...
y respondiendo a ^MiSaTo^, para nada, no necesariamente lo que dije tiene que ser Waterfall, por el contrario, muchas cosas se hacen en paralelo... igualmente hay cosas que no se pueden hacer sin que este la fase anterior terminada, QA no puede testear algo que esta en desarrollo, incluso testear algo que este en WIP, no se puede considerar como un test valido, ya que desarrollo puede romper algo que funcionaba y si lo testeas antes que este terminado, perdiste tiempo de QA... lo mismo desarrollar sin especificaciones... eso seria mas que nada investigacion que puede servir, pero no seria desarrollo final...
¿Existe la figura del "documentador"? ¿Que se encarga de leerse el código de los desarrolladores y de explicar lo que se ha hecho? ¿No es doble trabajo, teniendo al desarrollador que se conoce el código de memoria? No sé, me parece raro (y nunca oí hablar de él).
Pero yo no hablo de un docmento tipo UML ni nada por el estilo, símplemente cosas como "para abrir un documento pulsar...", o "para crear un cuadro de texto hacer clic en tal, tal, y tal".
Y cuando digo cambios en el código o la interfaz me refiero a que, yo que sé, que el cliente diga que quiere una ventana de "nuevo proyecto", y se le olvide incluir el campo "idioma" porque se puede cambiar en un submenú, pero es fundamental para el formato de las cadenas de texto de dicho proyecto, que no se pueden modificar tras crearlo (porque no exista una función o porque altere todo el contenido de la base de datos o lo que sea). Cosas que el cliente pide muy feliz, pero que el código no te deja o se vuelven muy rebuscadas.
SplinterGU
22/10/2016, 03:11
¿Existe la figura del "documentador"? ¿Que se encarga de leerse el código de los desarrolladores y de explicar lo que se ha hecho? ¿No es doble trabajo, teniendo al desarrollador que se conoce el código de memoria? No sé, me parece raro (y nunca oí hablar de él).
Pero yo no hablo de un docmento tipo UML ni nada por el estilo, símplemente cosas como "para abrir un documento pulsar...", o "para crear un cuadro de texto hacer clic en tal, tal, y tal".
Y cuando digo cambios en el código o la interfaz me refiero a que, yo que sé, que el cliente diga que quiere una ventana de "nuevo proyecto", y se le olvide incluir el campo "idioma" porque se puede cambiar en un submenú, pero es fundamental para el formato de las cadenas de texto de dicho proyecto, que no se pueden modificar tras crearlo (porque no exista una función o porque altere todo el contenido de la base de datos o lo que sea). Cosas que el cliente pide muy feliz, pero que el código no te deja o se vuelven muy rebuscadas.
no el perfil documentador lo que hace es agarrar el documento de diseño/especificacion/producto (si existen), reunirse con el o los programadores, y con quien haga falta que haya estado en el proceso de produccion del producto, y preguntar, preguntar, agarrar el producto y usarlo, item por item, y va armando el documento de usuario/uso/detalles... cada reunion es corta, lo necesario para responder las preguntas y obtener algo otro dato util que salga de la charla y pueda servir como nota o detalle... redacta, formatea y demas del documento... y si es necesario volver a reunirse lo hace con las personas involucradas lo hace, pero de esta forma mantenes liberado a un recurso caro (como ser un programador) para seguir desarrollando y no perder tiempo en documentar... y te repito, una cosa distinta es documentar el codigo, en el fuente... eso no lo hace el documentador...
claro que existe el perfil documentador... y es super util y productivo tener un perfil de esos en la estructura... agiliza, libera y le baja niveles de tension a los demas recursos, a ningun programdor le gusta hacer documentos de usuarios... las veces que toca hacer documentos a un programador, siempre es una tocada de huevos y se pierde mas tiempo del que se gana...
-----Actualizado-----
ah, y el documentador puede ir trabajando en paralelo con el desarrollo... no necesita que este terminado el desarrollo... luego puede ajustar una vez terminado el desarrollo.
Ah, a "eso" lo llamamos "jefe", suele ser el jefe de equipo el encargado de llevar eso, amén de reparir las tareas, y algún tirón de orejas cuando alguien se duerme o se retrasa :D
Pero ya te digo, en mi último proyecto hice las veces de desarrollador, debugger, y encargado de mantener la documentación (esquemas UML, esquemas funcionales, descripción de métodos y clases...) al día. Esto último me supuso tres días de trabajo la primera vez (porque llevaba meses sin tocarse), y cada mes un poco menos (la última vez fueron un par de horas). Se nota que yo era el último mono... bueno, penúltimo, que al último le tocó lidiar con la base de datos :D:D:D
SplinterGU
23/10/2016, 19:06
Ah, a "eso" lo llamamos "jefe", suele ser el jefe de equipo el encargado de llevar eso, amén de reparir las tareas, y algún tirón de orejas cuando alguien se duerme o se retrasa :D
Pero ya te digo, en mi último proyecto hice las veces de desarrollador, debugger, y encargado de mantener la documentación (esquemas UML, esquemas funcionales, descripción de métodos y clases...) al día. Esto último me supuso tres días de trabajo la primera vez (porque llevaba meses sin tocarse), y cada mes un poco menos (la última vez fueron un par de horas). Se nota que yo era el último mono... bueno, penúltimo, que al último le tocó lidiar con la base de datos :D:D:D
yo hablo de la organizacion ideal, claro esta que hay empresas donde si no tienen presupuesto para el de limpieza, cuando terminas de programar te hacen barrer el piso... (metaforicamente hablando...)
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.